Benjamin Saunders

Yeah, that generally makes sense. I'm curious how much the extra API complexity would actually buy us, though. Streams can have much larger individual writes, though I guess in either...

Added a test for the sender-side behavior that should prevent future regressions, seeing as we've already inadvertently broken this once.

The assertion in question: ``` assert_eq!(pair.client_conn_mut(client_ch).lost_packets(), 0); ``` If it doesn't reproduce consistently then it's probably due to the randomized packet number skipping. I don't *think* packet loss should be...

Initial notes from the logs: failed case has the server skipping pn 4, which shouldn't matter, as the key update happens on client packet 11. The server fails to decrypt...

Saw this again on stable in FreeBSD at https://github.com/quinn-rs/quinn/actions/runs/7535071853/job/20510448889. This time there doesn't seem to have been any PN skipping at all, so I guess that was a red herring....

Another failure on Ubuntu beta: https://github.com/quinn-rs/quinn/actions/runs/7535119285/job/20510576738?pr=1740 Logs ``` 2024-01-15T23:54:23.893633Z INFO quinn_proto::tests::util: connecting 2024-01-15T23:54:23.893695Z TRACE client: quinn_proto::endpoint: initial_dcid=d4e84704fc6ce6b84bddd195430f106dbffdef15 2024-01-15T23:54:23.894521Z TRACE client: quinn_proto::connection: wrote 273 Initial CRYPTO bytes 2024-01-15T23:54:23.894606Z TRACE client:send{space=Initial pn=0}:...

Again: https://github.com/quinn-rs/quinn/actions/runs/10185475414/job/28175129233 Logs ``` 2024-07-31T18:16:25.847294Z INFO quinn_proto::tests::util: connecting 2024-07-31T18:16:25.847359Z TRACE client: quinn_proto::endpoint: initial_dcid=ba61a6c3391916180361ec9ec0ce5f8ce0088592 2024-07-31T18:16:25.848191Z TRACE client: quinn_proto::connection: wrote 271 Initial CRYPTO bytes 2024-07-31T18:16:25.848259Z TRACE client:send{space=Initial pn=0}: quinn_proto::connection: CRYPTO: off 0...

Hmm, this needs a mechanism to broadcast wakeups when the UDP socket is backpressured... edit: solved by duplicating (`try_clone`ing) the socket

I've replaced the original `try_clone_box` mechanism with the runtime's built-in concurrent I/O support, which exists in both tokio and async-std. This required a somewhat fiddly extension of the runtime abstraction...

I haven't benchmarked this very rigorously yet, since I don't have convenient access to a machine that's both running Linux (for our most optimized UDP backend) and not a laptop...