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•1h 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•1h 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•1h 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•1h 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•1h 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•1h 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•1h 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 :)
jayd16•16m ago
Ok so you need to trust each other's certs. What's the big deal? Presumably you already have some other channel to share addresses so you can also share temporary self signed certs for this purpose.
CorneliusCorb•7m ago
I'm working with QUIC in a personal project, while you can roll your own QUIC library the spec is large enough that it's quite a bit of work to implement it yourself. Most libraries allow you to pass in your own certificates. Realistically you could just bake in certs to your program and call it a day. Otherwise yes, you can implement your own cert logic that completely ignores certs altogether. s2n-quic for example specifically allows for both, though the former is much easier to do.
throw0101d•9m ago
> 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.
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•1h ago
embedding-shape•1h 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•1h ago