diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-10-16 12:28:25 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-10-16 12:28:25 +0200 |
| commit | 82b78441aa19ca54c2c84db2a413c88db386cd7b (patch) | |
| tree | b5d4986044a37dd5ef93cef57f1e8857b6a34453 /packages/meshbay-node/tests/test_stream_seek_reports_the_keyframe.py | |
| parent | 1557ba53d8a7110869484ac5f9ccf03c5cfea322 (diff) | |
| download | meshbay-82b78441aa19ca54c2c84db2a413c88db386cd7b.tar.gz | |
fix(node): datagrams straight through the socket on Windows' event loop
The ProactorEventLoop's datagram transport keeps one overlapped operation
per direction and starts the next from the previous one's completion, on a
later turn of the loop: one datagram sent and one received per socket and
per turn, however many wait. The busier the node, the slower every
connection, with cores to spare. Measured on loopback with the loop busy
0.5 ms a turn: 1,928 datagrams sent a second and 1,954 received, 87 % of
the rest dropped by the kernel. A browser's download from a node holding
its connections ran at 9 MB/s, the node at 45 % of a core, SCTP round trip
745 ms. Now a datagram goes out with a non-blocking sendto when nothing is
queued, and a completed read is followed by whatever the socket holds
before the next one is posted. Two-core machine, 400 MB: CLI download 27 ->
33 MB/s, upload 18 -> 22, browser over eight connections 9-14 -> 17-19.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Diffstat (limited to 'packages/meshbay-node/tests/test_stream_seek_reports_the_keyframe.py')
0 files changed, 0 insertions, 0 deletions