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

A new peer takes too long to connect to other peers. #612

Closed
parth1729 opened this issue Feb 10, 2016 · 4 comments
Closed

A new peer takes too long to connect to other peers. #612

parth1729 opened this issue Feb 10, 2016 · 4 comments
Labels

Comments

@parth1729
Copy link

@parth1729 parth1729 commented Feb 10, 2016

Hi, I am using the bittorrent tracker and Webtorrent both in my application. I am using Webtorrent just to seed a file using "seed" method. Here is the code snippet:

var file = fs.createWriteStream("C:/"+filename);
    console.log(filename);
    var request = needle.get(UrlPath).pipe(file);
    var client=new WebTorrent();
    file.on('finish', function() {
        file.close(createTorrent("C:/"+filename, function (err, torrent) {
            if (!err) {
                client.seed("C:/"+filename);
                fs.writeFile(config.torrentFilePath, torrent);
                res.send(torrent);
            }
   });
});

A new peer connects to the other peers after around 10-15 minutes, maybe in the second announce interval. Earlier I was using just the bittorrent tracker and I was seeding the file manually using a torrent client. This approach did not take much time to discover a newly added peer.But, after seeding the file using Webtorrent's "seed" method, I observed this behaviour. I don't know if it has something to do with the client(Utorrent) that I am using to download the file. Could somebody please help me out with this?

@feross

This comment has been minimized.

Copy link
Member

@feross feross commented Feb 10, 2016

@parth1729 What exactly are you trying to do?

It seems like you're sending back the created .torrent file in an http response, right?

You might consider waiting until the client has completed fully seeding the file (creating the .torrent, announcing to trackers and the DHT, etc.) before doing that. client.seed takes a callback that will get called once the client is actually seeding the file.

Try this:

var file = fs.createWriteStream('C:/' + filename)
console.log(filename)
var request = needle.get(UrlPath).pipe(file)
var client = new WebTorrent()
file.on('finish', function () {
    file.close(function () {
        client.seed('C:/' + filename, function (torrent) {
            fs.writeFile(config.torrentFilePath, torrent.torrentFile)
            res.send(torrent.torrentFile)
        })
    })
})

I eliminated the unnecessary call to createTorrent since that's already done internally for you in client.seed. You can get the generated .torrent file with the .torrentFile property.

@feross feross closed this Feb 10, 2016
@feross feross added the question label Feb 10, 2016
@parth1729

This comment has been minimized.

Copy link
Author

@parth1729 parth1729 commented Feb 11, 2016

@feross Tried the approach you mentioned, but still no luck. It functions same as before.
Actually, I'm developing an application in which the user will initially be served a torrent file. When the user starts downloading the file, I want to seed the file from one end so that the user can download the file. And yes, I'm sending the torrent file as Http response for the user to download the torrent file.
@feross Any help on this would be really appreciated.

@godigex

This comment has been minimized.

Copy link

@godigex godigex commented Feb 19, 2016

Ditto for this problem. I find that downloading clients can't connect to any seeds/peers for 10~20 minutes, generally after the second or third announce. It behaves the same way with subsequent downloads from additional clients - always after a few announces regardless of how long the client has been seeding. Any ideas about what's going on here?

@lock

This comment has been minimized.

Copy link

@lock lock bot commented May 4, 2018

This thread has been automatically locked because it has not had recent activity. To discuss futher, please open a new issue.

@lock lock bot locked as resolved and limited conversation to collaborators May 4, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Linked pull requests

Successfully merging a pull request may close this issue.

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