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

2026-10-12T22:30:39Z

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

fix(node): tell the Node page how many cores there are

2026-10-11T19:17:09Z

The page reads its settings from list_groups, which lacked cpu_count, so the field showed "of 1" and stayed at 1. Co-Authored-By: Claude Opus 5.5

feat(node): carry connections on several cores

2026-10-11T17:09:04Z

connection_processes (default 1) starts that many processes for the WebRTC stack; sessions and keys stay in the node. Set from node.toml or the Node page, applied to new connections. Co-Authored-By: Claude Opus 5.5

meshbay.git/packages/meshbay-node/tests/test_connection_processes.py, branch main

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

fix(node): tell the Node page how many cores there are

feat(node): carry connections on several cores