Leave 5% of connection slots for incoming connections

[jch]

Currently, we actively connect to peers as long as we haven't reached the torrents maxPeerCount. Leave 5% of that value for incoming connections, which will make firewalled peers somewhat more likely to get a peer.

Note the rounding: this has no effect when maxPeerCount is less than 11.

--Juliusz

[charles]

jch: that patch is straightforward enough, but what's the rationale for it?

[jch]

In a typical swarm, there's a number of reachable peers and an unpleasantly large number of unreachable peers. The reachable peers are overloaded, while the unreachable ones have spare throughput (since they can only speak to the overloaded reachable peers).

The idea of this patch is that we want to encourage speaking to unreachable peers, in the hope of spreading the load more evenly, or, if you prefer, to use as much as possible the spare throughput of unreachable peers.

Running a peer that's unreachable over IPv4 but reachable over IPv6, I find that with this patch, I quickly get a number of incoming connections from fast IPv6 peers that probably discovered me through PEX (possibly due to #2502). Without it, I quickly aquire 60 IPv4 peers, and I cannot accept connections from the fast IPv6 peers I'm reachable for.

For what it's worth, according to 8472, Azureus does something similar (although it is my understanding that they make more efforts to determine the number of slots to let free -- overkill in my opinion).

I suggest applying this patch to the trunk just after 1.80 is branched, and seeing how it goes.

--Juliusz (who is carefully avoiding the term bandwidth, since he doesn't fully understand Shannon's law)

[charles]

Implemented in trunk for 2.00 by r10544