-
-
Notifications
You must be signed in to change notification settings - Fork 625
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
Webseed update timer #932
Webseed update timer #932
Conversation
As additional background here are the torrent details from a resent test-run of the erigon downloader. The overall run results where as follows:
The status of the incomplete files reveals this:
|
Sorry for the delay on this, I'll get to it soon. |
I think I follow. I don't quite understand the implementation of your fix though. I don't think the requester (pretty sure it should be an e not an o) needs to be checking a bunch of stuff about whether it should fire a request update. The timer code for peerconns should be just using a timer as a fallback, I think it's fine to do something similar if you think it would work.
I've cherry picked this to master, this looks good. |
The issue is as follows: When you start a set of requester's (o is the english spelling) (I'll fix) for the a webpeer once they have started and exhausted any initial requests they have they will just sit waiting for a signal before doing anything else. If the condition is only signaled by a request being processed (in _request) if the webseed is starved of requests (because some get stolen, or fail) - the requester will sit on the condition forever and never process any more requests. This is the condition we're hitting - in the examaple we have 1 good webseed and 14 bad peers, so the chances of the webseed not getting bumped are pretty high with small torrents. What I have done here is introduced a timer to kick one of the responers into life to see if there is any more work to be done. I think it needs a timer as the as the connection is otherwise passive - there is no networking event to catch. A more natural implementation of this I think would be to have channels and a select loop with a timeout. But I went for the minimal change which I think achieves the same effect. |
updateRequestor->updateRequester
Okay that makes sense. I commented on the code a bit. Is it possible just to add more condition signalling somewhere to bring them back to life? |
I'll close this as there's no activity. However I really appreciate the effort and am receptive to restarting it to get the parts that weren't already accepted. |
This fixes an issue with small files (1 to 2 pieces) when they are seeded from web peers into a sparse torrent network.
If there are a significant number of peers in the network which don't have the requested torrent on initial download a webpeer with the file is not guaranteed to be the selected request provider. When this happens if the webpeer does not do an update to its request state it will wait forever and the torrent will never get downloaded.
This fix also includes an update to steal processing in
applyRequestState
- so that rejecting and cancelled peers do not steal from a potentially good peer. Also the steal logic uses after instead of before in its time logic, to avoid a peer with equal time (which is zero at initial download) preemptively stealing as this creates a chain reaction on initial download.