TCP transport: bind to the same port for outgoing connections

[BlackYoup]

Hello,

I have a simple use case where I want two peers behind different NAT to communicate. For that, I went with TCP Hole Punching with a signalization server telling both peers to initiate a communication with the other on IP X and port Y. I also added the Identify protocol to my swarm's behaviour so every peer would configure itself to know their observed address.

But if I understood the whole TCP Hole Punching concept, each peer have to bind to the same port (Y) they used to communicate with the signalization server for incoming connections and also bind to that same port when doing the ongoing connection to the other peer.

I copied the TCP transport provided by libp2p and modified it to have this behaviour and so my peers are able to connect to each other using TCP Hole Punching, as expected. But now, I wish I wouldn't have to use my "own" TCP transport with such little modifications.

I've seen a few NAT traversal discussions in the issues but nothing about binding to the same port for outgoing connections. Would it be possible to have this in rust-libp2p directly? Or maybe I'm missing something somewhere to allow me to do this already?

Thanks :)

[dvc94ch]

This is also needed for proper quic support. Maybe it makes sense to remove dial from the Transport trait and rename listen_on to bind. bind could return a BoundTransport that implements a Stream of ListenerEvents and has a dial method.

[dvc94ch]

@BlackYoup I don't think you need a signaling server, if you use the kad/ping protocols as they should keep your connection alive letting other's dial you. Maybe you need to experiment with the keep alive interval, not sure what the average time an asymetric nat keeps the port open.

[BlackYoup]

@dvc94ch thanks for the input! To my understanding of things, the issue was not to keep the connection open but rather trying to open it in the first place, between two peers that don't know each other. And for that, neither kademlia or the ping protocol would help me.

It's to note that since NAT traversal isn't yet fully available in libp2p-rust, we stopped to do TCP hole punching and went using some public NATed port instead. But TCP hole punching was working great! The only issue we had was with kademlia which announced peers that couldn't be reached unless we initiated the TCP hole punching between them, making them unable to join other peers in the DHT.

[dvc94ch]

What I was saying is that if you reuse the port for incoming and outgoing connections, and you have traffic to keep the nat from closing your port and it's a simple nat it might work, especially over udp where the nat can't introspect when the connection is closed.