test(node): run the connection processes on Windows, source and frozen

Connection processes and the larger UDP receive buffer were written and
measured on Linux; nothing had run on Windows, and `meshbay-node.exe
webrtc-worker` had never run from a frozen build on any system.

- test_connection_processes.py failed on Windows (8 tests): the selector
  loop the suite uses there cannot start a process. A test marked
  `daemon_loop` now runs on the daemon's own loop, chosen through
  pytest-asyncio's loop factories.
- The build starts both frozen executables as connection processes and
  carries a connection through each (smoke-connection-process.py). The
  daemon's own smoke test never signs in to a hub, which is when the
  processes start.
- The warning for a receive buffer below what was asked named
  net.core.rmem_max on every system; it names it on Linux only. Windows
  grants the 4 MB.

Measured on an installed build in service mode, docs/WINDOWS-PORT.md §5.12:
two processes at startup and on a live change, a browser's handshake, chat,
a 200 MB download over 8 connections across both processes, an upload, a
video stream, and stop, restart and start leaving no process behind.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

1 files changed, 47 insertions, 0 deletions

diff --git a/docs/WINDOWS-PORT.md b/docs/WINDOWS-PORT.md
index 7e13aa0..840f22a 100644
--- a/docs/WINDOWS-PORT.md
+++ b/docs/WINDOWS-PORT.md
@@ -623,6 +623,53 @@ hidden-icons overflow until the person drags it onto the taskbar. No API
 promotes it, and an installer that edits the registry to force it is the kind
 of thing this project does not do.
 
+### 5.12 Connection processes and the receive buffer (2026-10-12)
+
+**Scope:** `packaging/win/smoke-connection-process.py`,
+`build-node-runtime.ps1`, `test_connection_processes.py`,
+`transport/webrtc_server.py` (one log line)
+
+Both were written and measured on Linux (`docs/MESHBAY_DESIGN.md` §5.5) and
+neither had run here. Measured on the VM, Windows 11, an installed build in
+service mode:
+
+- **The receive buffer needs nothing.** Windows has no ceiling like
+  `net.core.rmem_max`: a socket asked for 4 MB gets 4 MB (and 1 GB when asked),
+  and a 3.6 MB burst sent at a socket nobody reads arrives whole, where the
+  default buffer keeps 66 KB of it. The node logs `UDP receive buffer: 4096 KB
+  per socket`. The warning for a smaller grant named the Linux sysctl whatever
+  the system; it names it on Linux only now.
+- **A frozen node starts its connection processes.** With
+  `connection_processes = 2` the daemon in session 0 starts two copies of
+  itself (`meshbay-node.exe webrtc-worker`), at startup and when the setting
+  changes alike. The windowless `meshbay-nodew.exe` of the Store package works
+  as a connection process too (the build's check, below): its standard input
+  is a pipe, so it is there to read although the build has no console.
+- **A browser's connection lands in one of them.** From the installed
+  application: handshake, chat, the index of a folder changed on disk, a 200 MB
+  download over 8 connections spread across both processes (12 MB/s, both ends
+  on this 2-core VM, no loss), an 80 MB upload, a video stream. Every file
+  arrived with the checksum it left with.
+- **Stopping leaves nothing behind.** `autostart stop`, `restart-daemon` and
+  `autostart start` take one to three seconds with two processes running, and
+  no `meshbay-node.exe` is left after a stop. A frozen process whose parent is
+  killed outright ends within a second, because it ends when its socket to the
+  node does: an upgrade does not find the executable held by an orphan. Back
+  to 1, a process leaves when its last connection closes.
+
+Two things keep this from going unrun again. The build starts both executables
+as connection processes and carries a connection through each
+(`smoke-connection-process.py`): the daemon's own smoke test never signs in to
+a hub, which is when the processes start. And `test_connection_processes.py`
+runs on Windows, on the daemon's event loop: the selector loop the suite uses
+there cannot start a process, and exists for two aiortc ends in one process,
+which these tests do not have. A test asks for that loop with the
+`daemon_loop` mark (`on_the_daemons_loop` in the node's `conftest.py`), which
+the suite answers through pytest-asyncio's loop factories.
+
+A process the node ends reports exit code 1 on Windows however it left
+(`TerminateProcess`), so the code says nothing about how a stop went.
+
 ---
 
 ## 6. Execution order