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

High number of WebRTC peer connections is being created during transfer #805

Open
marcovidonis opened this issue Jan 25, 2023 · 5 comments

Comments

@marcovidonis
Copy link
Collaborator

Looking at the WebRTC / webtorrent part of the project, I noticed that, when downloading a file, a new offer is being created (seemingly) at every piece transferred. This happens when TrackerClient.Announce() is called, in which TrackerClient.newOffer() creates a new offer with a new WebRTC peer connection.

I'd imagined that we'd create a peer connection for each connection to a torrent peer (naming gets a bit confusing here) and keep it open for as long as we're transferring pieces from that peer, but it looks like this is not the case. I was wondering whether this is part of the torrent protocol, or if there is another reason for it?

@anacrolix
Copy link
Owner

There should be an announce each time it connects, and then one each time that one is answered. If that's not the case, let me know! Also if this could be a source of PeerConnection leaks, (maybe I'm forgetting to close one on announces), that would be great, I'm sure there's a leak somewhere.

@marcovidonis
Copy link
Collaborator Author

Does the seeder send an answer at each torrent piece? Currently it looks like we're opening and closing dozens of PeerConnections even for short transfers, and I'm not sure whether that's what's supposed to happen.

I believe all connections are being closed properly though, so I don't think there's a leak here as far as I can tell.

@anacrolix
Copy link
Owner

No, WebRTC is used as a regular transport, just like uTP or TCP. So an offer is sent at connection, and at each reannounce, when an answer is received, it drops into regular behaviour, a single connection can be used for many pieces (and should). Conversely if an offer is seen from a tracker and we want it, we try to answer it and then drop into the same handling as for our sent offers.

Are you certain it's a single connection per piece, or does it just appear to be like that?

@marcovidonis
Copy link
Collaborator Author

I'm sure there are several peer conns being created, but I'm not certain it's one per piece.

For example, I'm transferring a 250MB file from a seeder to a leecher, both on my machine, using a local websocket tracker.
If I just add a log in TrackerClient.Announce(), where a new peer connection is created along with a new offer, I see that the seeder only creates one peer connection, but the leecher goes through 25-30 announces during the download.

Since there was one offer from the seeder, I would expect the leecher to pick that one up once and transfer all the pieces in one connection.

@anacrolix
Copy link
Owner

Could it be that it's attempting to create more peer connections, and realizing they're duplicates of the one it already has? I think I added code so that it could extract an IP from WebRTC connections, it might not do that duplicate check until the connection is established. I think in WebRTC terms, it would be necessary to filter out the connection before it's established (from just the offer). Does that sound right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants