Skip to content

addClient findClient

Jump to bottom
Lukas Röllin edited this page Nov 24, 2018 · 3 revisions

All of these methods assume no NAT. This is not the real world, but it would add much more complexity otherwise

Method 1

AddClient stores all its known peer addresses in the DHT

An alternative would be to ping each well-known peer (the ones we also use to bootstrap) and store the IPs on how they reach us in the DHT. Drawbacks:

  • Performance. This takes ages
  • If no local IPs are gathered from this, a peer that would have a local connection to us would only find the public way. This public IP may not work

Method 2

We discover our public IP addresses and store all of them. In findClient, we check which ones we can reach.

What we did in the end

We tried method 2. In the end, this proofed to be a bit of a problem. Adding was fine, but finding the pinged correct ones didn't work properly (we suspect a deadlock issue)

Now, the following happens:

  1. addClient gathers responses from all its bootstrap peers (meaning, well-known peers) how it's seen from their POV. The first response is written in the DHT. If no response is received (or no bootstrap peers etc.), peer.peerAddress is used.
  2. findClient just uses the peer address in the DHT

This way, we have at least a chance of getting a correct peer address in the DHT. We just assume it to be true when connecting.

We could also add this to the design decisions!

Clone this wiki locally