persist BEP-21 upload_only on peer_list entry#8519
Conversation
|
this seems reasonable. The main risk, that I see, is that In an ideal world it would not be persisted for quite as long, but this definitely seems like an improvement. The comments are a bit verbose; I don't think they need to reference github tickets. You'll find the tickets/PRs via Would you mind adding a new unit test for peer_list, it can probably be modeled after |
Yes, and the peer upload_only state will track 0->1 and 1->0. Tried to make that explicit in comments.
Will add test. |
Previously only the live m_upload_only was updated; the persistent torrent_peer had no record. After disconnect, the next tracker announce re-promoted the address every ~60s. Add an upload_only:1 bit (distinct from seed and maybe_upload_only), widen is_connect_candidate to filter on it, and sync both bits both ways.
Mirrors the existing set_seed test, with an extra section verifying that flipping upload_only back to false restores connect candidacy (exercises the symmetric +1/-1 candidate-count update).
|
@arvidn should I also submit PR against RC_2_0 or are you done updating 2.0? |
2 participants
Fixes #7700.
There is a long standing problem in LT where it immediately drops connections from peers which advertise "upload_only" in the LTEP handshake, and thus even when LT is a seed it keeps recontacting the same peers which are also seeds. Transmission and other clients get this right and hold on to the upload_only indication and stop connecting peer-seeds when unnecessary.
This PR dramatically reduces connection chatter from LT clients. Currently, as described in #7700, LT will attempt to aggressively reconnect to peer-seeds up to once per minute. When trackers do not seed-filter the peer list sent back on announce, this is an enormous number of outbound connections.
The core problem is that
upload_onlyis sent during LTEP exchange, before thehave_allmessage is sent during torrent messages that would indicate a seed. So that connection is dropped by LT before it ever sees thehave_allmessage.See also qbittorrent/qBittorrent#22432