|
|
|
|
|
by tbocek
222 days ago
|
|
UDP-based protocols are well suited for P2P, since hole punching is straightforward if you have predictable port mapping, you cannot disallow it. In that spirit, we are currently exploring this with: https://github.com/tbocek/qotp and https://github.com/qh-project/qh The main idea is to have a simple encryption (ed25519/chacha20+poly1305) for encryption in the transport layer, on top of that then qh, where certs are use for signing content. With out of band key exchange, you can establish a connection after you successfully punched a hole. However, its not QUIC compatible in any way (https://xkcd.com/927) |
|
"Cannot" is a strong word:
> UDP hole punching will not work with symmetric NAT devices (also known as bi-directional NAT) which tend to be found in large corporate networks. In symmetric NAT, the NAT's mapping associated with the connection to the known STUN server is restricted to receiving data from the known server, and therefore the NAT mapping the known server sees is not useful information to the endpoint.
* https://en.wikipedia.org/wiki/UDP_hole_punching#Overview
I've also heard lots of people complain about how they're stuck behind CG-NAT and various P2P things do not work.