Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

p2p behind NATs #822

Closed
inosms opened this issue Jan 6, 2019 · 4 comments
Closed

p2p behind NATs #822

inosms opened this issue Jan 6, 2019 · 4 comments

Comments

@inosms
Copy link

inosms commented Jan 6, 2019

Hi there!
Thanks for all the efforts you put into this library! I have a question and didn't exactly know where to ask it, thus this issue.

I have been playing around with writing a decentralized backup tool and really want to try using this library for that. However I am stuck with the problem that I don't know how to implement a peer to peer connection when both peers are behind different NATs (using the IPFS Kademlia DHT for bootstrapping like in the ipfs-kad example).

I assume it is my lack of knowledge in p2p systems, but is there any chance you can hint me into the correct direction? I tried to reconstruct a go-libp2p example (https://github.com/libp2p/go-libp2p-examples/tree/master/chat-with-rendezvous), which lead me to #297 . I was unable to translate calls to discovery like discovery.Advertise(). Would this be add_provider() in rust_libp2p (which is not yet implemented?)
Did I maybe misunderstand the purpose of this library?
Any help would be appreciated! Thanks! :)

(Also I think for other people who have the same/a similar use case, it would be good to have this kind of problem as an example in this repository - I will add that once I understand how to do it)

@tomaka
Copy link
Member

tomaka commented Jan 7, 2019

👋

If I'm not mistaken, discovery.Advertise() only advertises the current node to the Kademlia DHT, which is not exactly related to NAT traversal.

There are three mechanisms in play that are related to NATs:

  • The identify behaviour, if used, will automatically query remote nodes for the external IP of the local node. This can then be retrieved through the Swarm and the PollParameters.
  • There is a relay protocol and behaviour that can be used to relay communications between two nodes if they both connect a third. However this is not implemented (Add back the relay #725).
  • It would eventually be nice to support UPnP or PCP, but this isn't implemented either (UPnP in the TcpConfig #558).

@inosms
Copy link
Author

inosms commented Jan 8, 2019

Thank you very much the detailed reply! This definitely makes things clearer! I will play around with it and see how far I can get 😃
I assume this issue can be closed then.

@povilasb
Copy link

I remember asking @tomaka the same thing on IRC and he said you can use rust-libp2p with an existing system socket. So you can rely on external code to do NAT traversal and just use the TCP/UDP socket bound to address that is mapped to the externally reachable port...

At MaidSafe we have developed a pure Rust implementation solely for hole punching: https://github.com/ustulation/p2p . Unfortunately, it only works with mio, not tokio and you should glue it with DHT you decide to use, etc.

Wish there was an I/O free implementation of such library. Then it could be plugged into any type of networking implementation, etc. See the hole punching module from tox-rs project :)

@tomaka
Copy link
Member

tomaka commented Mar 20, 2019

I just wrote a summary of what we're doing at the moment: #794 (comment)

@romanb romanb closed this as completed Feb 23, 2021
@libp2p libp2p locked and limited conversation to collaborators Feb 23, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants