Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building a web app using webtorrent for music, server down when seeding restarts #1663

Open
LapGAURAV opened this issue Jul 4, 2019 · 7 comments
Labels

Comments

@LapGAURAV
Copy link

@LapGAURAV LapGAURAV commented Jul 4, 2019

Versions:

"webtorrent": "^0.103.1",
"webtorrent-hybrid": "^2.1.1"

node : v8.15.1

I am bulding a music app using webtorrent. for WebRTC support i am using webtorrent-hybrid.
There is files uploading provision in the application to server and after that server starts its seeding from back end. In the linux environment, after sometimes such kind of warnings comes up (node:2813) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 data listeners added. Use emitter.setMaxListeners() to increase limit

after 8-10 warnings server goes completely down and another warnings comes up like this

[warn] epoll_create: Too many open files
[err] evsignal_init: socketpair: Too many open files

i observe that when numbers of users increases and click on the song repeatedly then this situation comes up.

here is my code:

var WebTorrent = require('webtorrent-hybrid')
var Client = new WebTorrent()

var magnetURL = "magneturl"            // Requested magnetURL by user, saved in db at the time file uploaded at server
if(Client.get(magnetURL) == null){
    Client.seed(path, (torrent) => {             // Restarting seeding from the path of the file if not available
          // return magnetURL after seed, if not available.
     })
     Client.on('error', function (err) {
         console.log(error);
      })
 }else{
      // return magnetURL if already exists
}

May be it is happening because of number of peers increases to server and more files added to peer. is it relating to something TCP/UDP connections?

@jimmywarting

This comment has been minimized.

Copy link
Contributor

@jimmywarting jimmywarting commented Jul 4, 2019

don't put everything in the title and explain more clearly

@LapGAURAV

This comment has been minimized.

Copy link
Author

@LapGAURAV LapGAURAV commented Jul 4, 2019

don't put everything in the title and explain more clearly

@jimmywarting i added more content to explain, that happened by mistake

@LapGAURAV

This comment has been minimized.

Copy link
Author

@LapGAURAV LapGAURAV commented Jul 4, 2019

I don't know why these listeners added, should i removed them manually.... or something else is happening behind the scene

@LapGAURAV

This comment has been minimized.

Copy link
Author

@LapGAURAV LapGAURAV commented Jul 4, 2019

any help?

@SilentBot1

This comment has been minimized.

Copy link
Member

@SilentBot1 SilentBot1 commented Jul 20, 2019

Hi @LapGAURAV

From the error messages provided, it sounds like the server is running into the limits of how many file descriptors you can have open at a single time, in this case this error typically comes about when too many TCP sockets are left open and not closed correctly or where you legitimately have lots of open TCP connections.

You will need to increase the maximum number of file descriptors which can be opened on your server, but how to do this varies between the different Linux distributions.

Alternatively you will need to decrease the number of simultaneous TCP connections you have open.

If you need further help with this, please let me know.

Kind regards
Brad

@LapGAURAV

This comment has been minimized.

Copy link
Author

@LapGAURAV LapGAURAV commented Jul 22, 2019

@silent i observed that when a requested peer connects to the client, it connects to it and remains connected even if no activity perform by the connected peer after access fill and acquires TCP connections and if more peers comes to access same file then again same process follows,

as process going on, too many peers connects to the client and starts chocking file descriptors.

Now assume my case, if i am seeding a mp3 file from my server and access by a single user from the browser then it's fine. But if 50 or 100 or even more than 1000 user access that same file then server goes down. So, In that situation how could i know that which peer has no activity perform or any method which let the peer disconnects from the client if user access the seeding file at once to release acquired connections for upcoming new requests.

@SilentBot1

This comment has been minimized.

Copy link
Member

@SilentBot1 SilentBot1 commented Jul 22, 2019

Hi @LapGAURAV

When a connection is established between peers, currently WebTorrent sets the keep alive inteval to one minute and automatically sends keep alive messages to ensure that the peers don't disconnect.

If you call the function wire.setKeepAlive(false) the protocol will stop automatically sending keep alive messages, causing the peers to disconnect after two minutes of not sending another request to your client (download or upload).

This could be done for all peers by using the following example code:

var WebTorrent = require('webtorrent')
var client = new WebTorrent()

//This will set all torrents added to the client to stop sending keep alive messages.
client.on('torrent', (torrent)=>{
  torrent.on('wire', (wire)=>{
    console.log(`Setting keep alive for peer ${wire.peerId} to FALSE!`)
    wire.setKeepAlive(false)
  })
})

//This will set a single torrent to stop sending keep alive messages.
var torrent = client.add('magnet:?xt=urn:btih:08ada5a7a6183aae1e09d831df6748d566095a10&dn=Sintel&tr=udp%3A%2F%2Fexplodie.org%3A6969&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.empire-js.us%3A1337&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&tr=wss%3A%2F%2Ftracker.btorrent.xyz&tr=wss%3A%2F%2Ftracker.fastcast.nz&tr=wss%3A%2F%2Ftracker.openwebtorrent.com&ws=https%3A%2F%2Fwebtorrent.io%2Ftorrents%2F&xs=https%3A%2F%2Fwebtorrent.io%2Ftorrents%2Fsintel.torrent')
torrent.on('wire', (wire)=>{
  console.log(`Setting keep alive for peer ${wire.peerId} to FALSE!`)
  wire.setKeepAlive(false)
})

This should cause stale clients to fall off once they are no longer making requests when they're finished downloading the torrent.

I'm unsure if this is the optimal way, as ideally you would check for a finished download and disconnect that peer from your seeding server while leaving the peer in the swarm for distribution between WebRTC browser clients but I haven't looked into how to do this properly.

Hope this helps and points you in the right direction.

@feross feross added the question label Jul 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.