Home | Notifications | New Note | Local | Federated | Search | Logout

Note Detail

Reply to @dthompson@toot.cat
dave@dthompson@toot.cat (2026-10-19 21:52:25)
Some other reliable protocols built on UDP are 1) RUDP, made by Bell Labs for Plan9, which has a draft RFC from 1999 and 2) SCTP, notably used by WebRTC. I think I can rule out SCTP as a good fit because it has multistreaming (like QUIC) and multihoming which are both unnecessary for OCapN. RUDP seems much simpler but anything that was ever deployed seems to use something that forks from the draft spec, but perhaps it's a good starting point.
---Reply---
ArneBab@ArneBab@rollenspiel.social (2026-10-19 22:39:27)
@dthompson Can there be only one peer per program? If there are multiple vats on the other node, could they use the same QUIC connection but different streams on it? That could delay running out of ports when communicating with many people. Consumer-OS’es can have quite low concurrent connection limits.

Why do you see zero roundtrip handshakes as minor? (especially if you don’t have to wait for a response)

One advantage of QUIC is that is doesn’t stand out, since HTTP3 serves as cover traffic.

---Replies---

dave@dthompson@toot.cat (2026-10-20 00:05:42)
@ArneBab "peer" is a matter of identity, so it's possible that a program could contain multiple OCapN peer identities. Only one active connection is allowed between any two peers. Having multiple processes share one network connection to the same remote peer would be possible by using a local relay as proxy, no need for QUIC.

Zero RTT is not minor in the big picture but I just meant that in comparison to all the other stuff QUIC is doing it's relatively minor. It would be easy for another protocol built on UDP to achieve this.

For my use-case I'd want the first packet to start a Noise handshake, but QUIC incorporates a TLS handshake, so that's yet another reason why it's not a good fit.