libp2p : Proper way to connect 2 peers behind their respective NAT each other

[canewsin]

Hey Made this Issue because there is no clear cut solution using libp2p-rust till now.
This will be updated with my observations and their successful attempts, so that other user can took from these.
These Observations are made, while I was building My P2P Application DecentNetwork.
First Attempt : Half Successful Attempts.

Transport : TokioTcpTransport with port_reuse.

let auth_keys = self.auth_key_pair().expect("can create auth keys");
let transp = TokioTcpConfig::new()
    .nodelay(true)
    .port_reuse(true)
    .upgrade(upgrade::Version::V1)
    .authenticate(NoiseConfig::xx(auth_keys).into_authenticated())
    .multiplex(mplex::MplexConfig::new())
    .boxed();

Network Behaviour Impl

pub struct DecentNetworkBehaviour {
    pub floodsub: Floodsub,
    pub kademlia: Kademlia<MemoryStore>,
    pub mdns: Mdns,
    pub identify: Identify,
    pub protocol: RequestResponse<DecentNetCodec>,
    #[behaviour(ignore)]
    pub rendezvous: RendezvousBehaviour,
    #[behaviour(ignore)]
    pub config: NetworkConfig,
    #[behaviour(ignore)]
    pub requests: HashSet<(RequestId, NetworkId, bool)>,
}

Since App is in WIP, there should be some online proxy to initialize peers with some data, so the same app runs on VPS, for this reason it has Rendezvous Behavior.
Workings :
Server : Full App will runs here in server mode. Only initial client with no other nodes on network.
Client 1: When Client want to enter into network, client connects to boot_server, sends Identify requests, Server gets external IP and stores it in Kademlia Memory Store.
Client 2(Subsequent): Same thing above but in turn this will get known_peers from server, because server has more than one peer.

When ever client joins network, server will send new peers ip to all known peers, as well as all known peers ip to new node.
Upon receiving the data, each client tries to connect with others.

Result : Half successful(Failed, if peers some how determines others via mDNS, even though I switched of functionality while testing.)

Other Theoretical observations : I read about hole punching in several articles, most of those mentioned that to establish Hole Punch with TCP, client need to send SYN packet to other, router waiting for ACK packet, I don't think this is happening above because each of those trying to connect using SYN packets at first because, they don't which is client or server in TCP protocol terms.

If I use UDP protocol, what are the abilities I will loose.

Reason for Issue rather discussion is most of discussions feature is not that used by Users. Subsequently we can move this to discussions.

How many of you successful in Hole Punching in production apps?

[canewsin]

Other Considerations :
Include circuit relay to network behaviour.

I want try circuit relay v2 pr and DCUtR pr, are they at prototyping stage ?

[mxinden]

NAT traversal is tracked in #2052. I recommend subscribing to the issue to stay up-to-date.

I want try circuit relay v2 pr and DCUtR pr, are they at prototyping stage ?

They are ready for review. See #2052 (comment).

For a high level overview on Project Flare (hole punching in libp2p) see libp2p/specs#312 (comment).

[mxinden]

We now have a hole punching tutorial. I am closing here. Feel free to open a new issue in case you have more questions.

https://github.com/libp2p/rust-libp2p/blob/master/src/tutorials/hole_punching.rs