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

Note Detail

Reply to @dthompson@toot.cat
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.
---Reply---
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.

---Replies---

ArneBab@ArneBab@rollenspiel.social (2026-10-20 00:27:05)
@dthompson There’s always the option of just building your own layer on top of UDP.

It’s not like there is no precedent (looking at Freenet / Hyphanet …).

The ordering requirement makes that a bit expensive, though. Once you need the order preserved, just using TCP is usually a better fit than UDP, since it does all the heavy lifting, including load balancing, re-transmit, and so on.

Does UPnP not work anymore to open ports for TCP dynamically?