Question on UDP hole punching

[andrewarrow]

thanks for this repo, just what I was looking for.

Question on UDP hole punching: is this something the big peer networks do reliable to the point they don't have to send people to https://portforward.com or do the majority of peer to peer networks not use UDP hole punching because it isn't 100% reliable and having the user go into their router and make a real open port is always a more reliable solution?

[xdanx]

Hey Andrew,

UDP hole punching needs to be supported by both the sender and receiver. What do you mean when you say "big peer networks"? Do you mean ISPs? If yes, then in this case it's a matter of commodity. You usually just assign your clients one router which is doing NAT and then you don't care about port forwarding. You let the client choose which ports to forward. Most of the time, clients are the ones initiating connections to a server which has a public IP address.

So in this case, allowing the client to open whichever ports he prefer is better.

Did this answer your question?

[andrewarrow]

well I mean systems like Bitcoin, BitTorrent, Ethereum, do they either:

1) use UDP hole punching for something like 90%+ of all their peer nodes or 2) make each person running one of their nodes configure their home router and UDP hole punching is rarely used, if at all or 3) some combination of 1 and 2 like 50% UDP hole punching, 50% direct port access

The reason I'm asking is I'm working on my own peer to peer system and wanted to see if I need to go down this route of complexity.

I'm down to learn UDP Hole Punching if it'll really works so that:

1) My friend at his office job can run my client and listen on 150.34.123.33:8999 i.e. some random ip and port and 2) From my office job I can run my client and and listen on 55.22.122.33:8999 i.e. another random ip and port and 3) I can connect to my friend's client and he can connect to mine even though we are both behind corporate firewalls and NATs

Thanks!