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.
klabb3•56m ago
Maybe success rates are higher with UDP – I don’t know. But it certainly works to hole punch with TCP as well. If you’re lucky you can even run into a rare condition called ”TCP simultaneous open”, where both sides believe they are the dialer.
embedding-shape•43m ago
> where both sides believe they are the dialer.
First time I've heard about this, and went looking for more. Came across https://news.ycombinator.com/item?id=5969030 (95 points - July 1, 2013 - 49 comments) that had bunch of background info + useful discussions.
api•42m ago
It can be done, but it's less reliable and also requires the ability to forge packets that is not allowed on all platforms. So it's hard to use in any production application if you want it to run in user space, on Windows, or on mobile.
superkuh•44m ago
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.
embedding-shape•40m ago
I guess most if not all QUIC endpoints you come across the internet will have encryption, as the specification requires as such. But if you control both ends, say you're building a P2P application that happens to use QUIC, I don't think there is anything stopping you from using an implementation of QUIC that doesn't require that, or use something else than TLS, even if the specification would require you to have it.
superkuh•38m ago
Just as long as you statically build and ship your application. Because I guarantee the QUIC libs in $distro are not going to be compiled with the experimental flags to make this possible. You're going to be fighting QUIC all the way to get this to work. It's the wrong choice for the job. Google did not design QUIC for human use cases and the protocol design reflects this.
embedding-shape•36m ago
Judging (guessing) by the author's GitHub profile (https://github.com/marten-seemann), seems they've built their own "pure Go" QUIC implementation, maybe precisely for those purposes :)
api•1h ago
For TCP based protocols it's very hard since there is no reliable way to hole punch NATs and stateful firewalls with TCP.
klabb3•56m ago
embedding-shape•43m ago
First time I've heard about this, and went looking for more. Came across https://news.ycombinator.com/item?id=5969030 (95 points - July 1, 2013 - 49 comments) that had bunch of background info + useful discussions.
api•42m ago