Connection Request ("STUN" over DHT)

[whyrusleeping]

In a similar vein to #57, I would like to have a message or a service that implements 'connection requests', for example, peer X is behind a NAT and peer Y wants to connect to him. Peer Z has an open connection to X, so peer Y sends a request to Y through Z containing his public IP address and requesting X to connect directly to him.

[jbenet]

More ambitiously, I want to build an overlay with full on message routing. :)

[whyrusleeping]

I almost feel like that is too ambitious for ipfs... but maybe

[jbenet]

I'll be building this service, including a modification to the DHT FindPeer rpc. I'll introduce:

// omitting unchanged things
message Message {
    enum ConnectionType {
        // sender does not have a connection to peer, and no extra information (default)
        NOT_CONNECTED = 0;

        // sender has a live connection to peer
        CONNECTED = 1;

        // sender recently connected to peer
        CAN_CONNECT = 2;

        // sender recently tried to connect to peer repeatedly but failed to connect
        // ("try" here is loose, but this should signal "made strong effort, failed")
        CANNOT_CONNECT = 3;
    }

    message Peer {
        // used to signal the sender's connection capabilities regarding the peer
        optional ConnectionType connection = 3;
    }
}

DHT nodes can (should) set the connection value. That way, we can use dht queries to find out who is connected to a peer, and ask them to send our addresses. (i.e. STUN for free). And since queries, we can try many nodes :). (this is of course long before we have a full packet forwarding network (:package: :fast_forward:) :P)

[whyrusleeping]

Before relying on queries too heavily, take a look at #308

[jbenet]

@whyrusleeping that problem sucks and we should fix it, but i dont think it affects this, since this is essentially piggybacking on a FindPeer query.

[whyrusleeping]

Ah, okay. As long as a single request only needs a single response, it should work fine

[Stebalien]

Closing for spring cleaning. Anyone interested in discussing message routing should file an issue here: https://github.com/libp2p/notes/issues.

Note: The current plan (until we get message routing) is to open a relayed connection, signal over that, and then migrate to a direct connection.