ilkkapoutanen-61n
commented
1 month ago Hi! I find myself in need of QUIC datagram support in Node.js, but also in the unenviable position of being quite unfamiliar with the details of QUIC, and not much better at Rust. Anyway, after poking around in the js-quic source, it seems that the napi mod already wraps the dgram_send* and dgram_recv* functions for a connection. Would it be possible to "just" expose these through the TS QUICConnection API in order to have basic dgram support?
Specification
The quiche library supports dgrams. This means the dgrams run on top of an existing QUIC connection. In contrast to streams, the dgrams end up being stateless. It's useful if we are virtualising a connection on top of QUIC to avoid double-congestion control.
Suppose we want to do decentralised relaying for PK agents. Then in order to relay another QUIC connection (and their associated streams), we would pass through the underlying UDP dgrams and inject as dgrams on an existing QUIC connection.
At the moment, I'm unsure how to exactly go about this. Suppose agents A, B and C where B is relaying the connection between A and C.
One way is for B to simply propagate the dgrams it receives from A and just proxy it to C. In that sense, there's no actual need for QUIC dgram support. B is just a network proxy like we used to do in PK's network domain.
Alternatively, B is connected to A and C over a QUIC connection. However the QUIC connection acts like a "lower layer". Then when A connects to C, it creates another QUIC connection, but this is done on top of the lower layer QUIC connection. In order to expose this, the lower QUIC connection must use the QUIC dgrams to pass through.
In that sense, it's possible for this library to expose the dgram support, and "recursively" use QUIC on top of QUIC.
Right now
QUICServerandQUICClientboth requireQUICSocket. TheQUICSockethardcodes the usage of node's dgram module using UDP. IfQUICSocketcan be made more generic, it would be possible to supply it with aQUICVirtualSocket, where the underlying strategy could be to use the UDP dgrams, or an existing QUICConnection's dgram system.One major important difference is that QUICConnection's dgrams would have no use for things like the address. The QUICConnection's dgrams is already connected, and it's not possible to send it elsewhere. That would mean, that is up to the bottom layer quic connection to receive the entire encapsulated UDP dgram and then process it appropriately.
This is how we could create an "overlay" network with QUIC.
However would this really be needed to do decentralised relaying for Polykey, or can just standard transparent networking proxying of the UDP dgram packets be suitable for decentralised relaying?
Note that Tailscale often needs to use relays, but in their case, their relays are done over TCP. So they are encapsulating wireguard (UDP packets) as TCP. I think it ends up looking like HTTP too, which allows them to bypass some corporate firewalls. If this QUIC library was built so that it can re-use any underlying "virtual socket", that would make it easier to run this QUIC library on top of whatever underlying socket system (whether another QUIC connection, or tailscale like DERP thing).
Additional context
Tasks