search

libp2p / go-libp2p-circuit

Circuit Switching for libp2p
MIT License
48 stars 16 forks source link

What happens when we have *a lot* of relays? #41

Closed whyrusleeping closed 5 years ago

whyrusleeping commented 6 years ago

right now we try relays in random order. If we have a lot of relays and try to connect to a peer that is either offline or very sparsely connected, we will end up sending quite a few messages to random peers all over the network. This feels suboptimal, especially in cases like the DHT where we somewhat often will be trying to connect to peers that are offline (at least, currently).

One thing that might help is to instead sort the 'relays to try' by their XOR distance to the target. Since the DHT currently causes the network to prefer connections to peers close to them in the XOR keyspace, they are more likely to have connections. This helps in the case of a sparsely connected peer, but the degenerate case of an offline peer still sucks.

Stebalien commented 6 years ago

Ideally, peers would put their prefered relays in their peer address announcement but this is still a good heuristic.

We'll also need to fix: https://github.com/libp2p/go-libp2p-kad-dht/issues/147

raulk commented 5 years ago

Following the train of thought, with self-signed, versioned DHT peer records, peers would be able to update their XOR vicinity with their preferred relay once it's setup during bootstrap, or if it changes during runtime.

The problem here is consistency upon query and getting stale records, which makes it look like the IPNS problem but it isn't: we can start dialing unknowingly stale records as we get back records from the DHT, and cancel those dial as fresher records roll in.

Stebalien commented 5 years ago

Following the train of thought, with self-signed, versioned DHT peer records, peers would be able to update their XOR vicinity with their preferred relay once it's setup during bootstrap, or if it changes during runtime.

At the moment, DHT nodes only report peer routing records for peers they're directly connected to. I believe "push identify" was designed to fix the updating issue (although it hasn't yet been widely deployed).

However, self-signed, timestamped peer routing records may help protect against malicious actors.

Stebalien commented 5 years ago

Users now choose their own relays.