Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connection Request ("STUN" over DHT) #153

Closed
whyrusleeping opened this issue Oct 10, 2014 · 7 comments
Closed

Connection Request ("STUN" over DHT) #153

whyrusleeping opened this issue Oct 10, 2014 · 7 comments
Labels
topic/libp2p Topic libp2p topic/nat Topic nat

Comments

@whyrusleeping
Copy link
Member

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
Copy link
Member

jbenet commented Oct 10, 2014

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

@whyrusleeping
Copy link
Member Author

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

@jbenet jbenet changed the title Connection Request Connection Request (STUN) Nov 4, 2014
@whyrusleeping whyrusleeping added this to the α milestone Nov 5, 2014
@jbenet jbenet modified the milestones: NAT Traversal, α Nov 17, 2014
@jbenet
Copy link
Member

jbenet commented Nov 17, 2014

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)

@jbenet jbenet changed the title Connection Request (STUN) Connection Request ("STUN" over DHT) Nov 17, 2014
@whyrusleeping
Copy link
Member Author

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

@jbenet
Copy link
Member

jbenet commented Nov 17, 2014

@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
Copy link
Member Author

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

@jbenet jbenet added topic/nat Topic nat topic/libp2p Topic libp2p labels Mar 28, 2015
@jbenet jbenet removed this from the NAT Traversal milestone Mar 29, 2015
hsanjuan pushed a commit to ipfs/go-ipfs-routing that referenced this issue Feb 14, 2018
@Stebalien
Copy link
Member

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.

@aschmahmann aschmahmann mentioned this issue Sep 22, 2020
72 tasks
@aschmahmann aschmahmann mentioned this issue May 14, 2021
71 tasks
ariescodescream pushed a commit to ariescodescream/go-ipfs that referenced this issue Oct 23, 2021
@aschmahmann aschmahmann mentioned this issue Dec 1, 2021
80 tasks
laurentsenta pushed a commit to laurentsenta/kubo that referenced this issue Feb 25, 2022
* fix: String method on the OptionalString
* test(OptionalString): empty string is preserved

Co-authored-by: Marcin Rataj <lidel@lidel.org>
laurentsenta pushed a commit to laurentsenta/kubo that referenced this issue Feb 25, 2022
* fix: String method on the OptionalString
* test(OptionalString): empty string is preserved

Co-authored-by: Marcin Rataj <lidel@lidel.org>
laurentsenta pushed a commit to laurentsenta/kubo that referenced this issue Mar 4, 2022
* fix: String method on the OptionalString
* test(OptionalString): empty string is preserved

Co-authored-by: Marcin Rataj <lidel@lidel.org>
laurentsenta pushed a commit to laurentsenta/kubo that referenced this issue Mar 4, 2022
* fix: String method on the OptionalString
* test(OptionalString): empty string is preserved

Co-authored-by: Marcin Rataj <lidel@lidel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic/libp2p Topic libp2p topic/nat Topic nat
Projects
None yet
Development

No branches or pull requests

3 participants