Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- "Unfortunately, no matter how hard you try, there is a certain percentage of nodes for whom hole punching will never work."
It might be helpful to cite the percentage
It's relatively small
A default policy that relays traffic through a third party is asinine
For the small percentage, the third parties will always be there if they need them. The internet has an enormous supply of middlemen, like Google
For everyone else, the third parties, i.e. the middlemen, can be avoided
- If I recollect, sha256 public or private signatures that are used on a thin-client for P2P server architecture.
Carrier peering using the UDP hashes for encrypting network traffic from a WAN to serve a Tier 1 network.
- Wait? How does that work? QUIC REQUIRES CA TLS for all endpoints. So you can do the discovery/router workarounds but then the person trying to connect to you with QUIC won't be able to unless you have a signed corporate CA TLS cert. I guess you could integrate some Lets Encrypt ACME2 periodic updater scheme into your P2P program but that's getting pretty complex and fragile. And it also provides a centralized way for anyone who doesn't like your P2P tool to legally/socially pressure it to shut it down.by superkuh
- Any UDP protocol can be made P2P if it can be bidirectionally authenticated.
For TCP based protocols it's very hard since there is no reliable way to hole punch NATs and stateful firewalls with TCP.
by api - I hope some day the browser's webtransport also gets p2p support.
It seemed like there was such a good exciting start, but the spec has been dormant for years. https://github.com/w3c/p2p-webtransport
- > Unfortunately, no matter how hard you try, there is a certain percentage of nodes for whom hole punching will never work. This is because their NAT behaves in an unpredictable way.
Or they are centrally/corporate-controlled and do not allow hole punching.
by throw0101d