|
|
|
|
|
|
by Sean-Der
2187 days ago
|
|
|
That sounds like you need better software then :) Realistically what do you think the timelines are for QUIC? When Bernard published the QuicTransport stuff I tried a few different versions and it only worked aioquic[0] (which is a really fantastic implementation)! But with 29 drafts and most servers not supporting them all feels like we still have some time to go. So QUIC as a server is much less likely to happen then ICE/DTLS/SCTP which have implementations that work everywhere. [0] https://github.com/aiortc/aioquic |
|
|
No, it rather sounds like you have a hammer called WebRTC and you're attempting to use it on a nail called "bidirectional server/client communication".
Why deal with the complex protocol stack of WebRTC which solves, among other things, NAT traversal, mutual authentication and encryption independently of server certificates, multiplexing of data and A/V content on a single port and much more. And I say that as someone who absolutely loves WebRTC for A/V and secure P2P use cases.
There is a true gap of "UDP for the web", which this fills.
"WebSockets over UDP" don't need to be built on QUIC, but I'm assuming by the time you have added all the security features needed to make this as secure as WebSockets for web apps, you'll effectively end up with something equivalent.