Support connections from users behind symmetric NATs.

[kristovatlas]

Enhancement request.

[cpacia]

So I think what I'd like to eventually do is extend the node object:

message Node {
    required bytes guid             = 1;
    required bytes signedPublicKey  = 2; 
    required NAT natType            = 3;
    required IPAddress nodeAddress  = 4;
    optional IPAddress relayAddress = 5;
    optional bool vendor            = 6 [default = false];
}

If anything other than full cone: On startup ping each ip in our cache (or what we got from the seed), measure the latency and pick the best one to set as the relay node.

When you connect to another node: If full cone --> connect directly If restricted NAT --> go straight to hole punching don't wait for a timeout. If symmetric NAT --> relay all packets through that node.

That should allow for fully p2p NAT traversal and eliminate the slow queries that we currently have where we wait for a partial timeout before hole punching.

The issue we will have if we do that is that the Node object gets stored in the DHT for all of your listings/keywords. If your relay node goes offline, then all those pointers in the DHT will be broken.

@hoffmabc