DHTClient mode breaks peer routing

[Stebalien]

In order for peer routing to work, the peer being found needs to be in someone's routing table. That doesn't happen (for obvious reasons) when the peer is running the DHT in client-only mode.

We need a way to say "I'm actually looking for info on this peer, they don't need to be a server".

[Stebalien]

@whyrusleeping ^^ does this sound right?

[Stebalien]

Note: this sort of works currently because, while the peer won't get added to the routing table on connect, they will when they make a request.

Of course, that's also a bug #162

[whyrusleeping]

@Stebalien great catch. I knew something felt a little off about client mode.

In handleFindPeer we should check if the target peer is in our peerstore, and if so, add it to the output.

[Stebalien]

In handleFindPeer we should check if the target peer is in our peerstore, and if so, add it to the output.

Unfortunately, we'll probably end up with outdated peer info if we did that. To fully fix this, we'd probably want FindPeer to actually try connecting to the peer in question before ending the search.

Alternatively, (additionally?) we could add an extra field to the peer info records indicating age. A missing age field would mean "currently connected".

[whyrusleeping]

@Stebalien hrm... i guess we could add a connectedness check before looking in the peerstore, which should solve that issue

[Stebalien]

i guess we could add a connectedness check before looking in the peerstore, which should solve that issue

Maybe? I'm worried that these peers will have no weight in the connection manager so the DHT server will just disconnect them. We could just weight the N (20?) closest peers highly in the connection manager. Actually, that's not a bad idea.

However, there's annother issue. It turns out we use the FIND_NODE request for GetClosestPeers. This will cause us to try to put values to DHT nodes in client-only mode.

Speaking of which... we already have that problem. I doubt there are many DHT client-only nodes, but they're probably contributing to our DHT problems.

---

I think we really do need a "is DHT server" bit.

[whyrusleeping]

I think we really do need a "is DHT server" bit.

We have that. Check the peerstore for a peers supported protocols. If they support the DHT protocols, they are a 'server'.

[Stebalien]

We have that. Check the peerstore for a peers supported protocols. If they support the DHT protocols, they are a 'server'.

Once you actually connect to the node. However, they'll still count towards the closest neighbors and you'll still have to connect to the node to find this out.

[whyrusleeping]

but you only get them in your closest peers if they are in someones routing table, and they only get in someones routing table if that someone connects to them, and if someone connects to them, they can check if they are a server before adding them to their routing table, no?

[Stebalien]

Ah, I misunderstood:

In handleFindPeer we should check if the target peer is in our peerstore, and if so, add it to the output.

That means just add the target, not the all nearest peers found in the peerstore. Got it.