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.
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.
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.
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.
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.
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.
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 :)
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.
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.
> 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.
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.
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.
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.
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.
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 :)