Reconsider peer connection strategy

[rakoo]

Currently, we accept all incoming connections and try to connect to all new peers we learn of. According to this blog post from libtorrent main dev, the standard behavior is to cap connectivity to 50 peers.

The outcome of this strategy is that global connectivity is low, and it is long until a new entrant can find anyone willing to share in the swarm.

The proposed alternative is to have a commutative function that depends on both peers' address and outputs a priority, and select peers with highest priority first (even going as far as disconnecting peers we are currently connected to if another one turns out to be better).

Here's the function (from the simulator code):

def prio(n1, n2):
        if n1 > n2:
                t = n2
                n2 = n1
                n1 = t

        if (n1, n2) in prio_cache: return prio_cache[(n1, n2)]

        h = hashlib.sha1()
        h.update('%d%d' % (n1, n2))
        p = h.hexdigest()
        prio_cache[(n1, n2)] = p
        return p

Fairly simple, could be interesting to consider.

[jackpal]

Yeah, TT should do something better than it currently does. Fine with me if
you want to implement this proposed policy. (Might be nice if the policy is
pluggable and independently testable.)

On Wed Jan 15 2014 at 1:00:45 PM, Matthieu Rakotojaona <
notifications@github.com> wrote:

Currently, we accept all incoming connections and try to connect to all
new peers we learn of. According to this blog post from libtorrent main
dev http://blog.libtorrent.org/2012/12/swarm-connectivity/, the
standard behavior is to cap connectivity to 50 peers.

The outcome of this strategy is that global connectivity is low, and it is
long until a new entrant can find anyone willing to share in the swarm.

The proposed alternative is to have a commutative function that depends on
both peers' address and outputs a priority, and select peers with highest
priority first (even going as far as disconnecting peers we are currently
connected to if another one turns out to be better).

Here's the function (from the simulator codehttps://github.com/arvidn/peer_ordering
):

def prio(n1, n2):
if n1 > n2:
t = n2
n2 = n1
n1 = t

    if (n1, n2) in prio_cache: return prio_cache[(n1, n2)]

    h = hashlib.sha1()
    h.update('%d%d' % (n1, n2))
    p = h.hexdigest()
    prio_cache[(n1, n2)] = p
    return p

Fairly simple, could be interesting to consider.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/33
.

[jbenet]

It's worth mentioning that policies like this can lead to vulnerability to sybil (and other) attacks. (e.g. people can fabricate peerids to attack particular hosts. (For ex, Kademlia's trusting "oldest" peers more mitigates this). This is probably not worth worrying much about though :)

[jackpal]

Just a point of information, it looks like TT currently does have a limit of MAX_NUM_PEERS per torrent session and MAX_NUM_PEERS is currently 60.

[sashabaranov]

I've tested transmission and TT on same magnet link and TT is always slower. I wonder if it is because wrong peers(with low speed) are chosen.

[nictuku]

There can be multiple possible explanations for that. For example, transmission is probably better about punching UDP/TCP holes for NAT connections.