diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/MESHBAY_DESIGN.md | 6 | ||||
| -rw-r--r-- | docs/WINDOWS-PORT.md | 47 |
2 files changed, 51 insertions, 2 deletions
diff --git a/docs/MESHBAY_DESIGN.md b/docs/MESHBAY_DESIGN.md index d0b5475..0703993 100644 --- a/docs/MESHBAY_DESIGN.md +++ b/docs/MESHBAY_DESIGN.md @@ -1463,7 +1463,10 @@ dies takes its own connections with it, which their clients see as a dropped connection and reopen, and is replaced at the next offer. The loopback socket is TCP because that is the one transport the event loop offers identically on every platform; a process proves it is the one the node started by returning 32 random -bytes handed to it on its standard input. +bytes handed to it on its standard input. A frozen node (the Windows build) has +no interpreter to start one with and starts a copy of itself, +`meshbay-node.exe webrtc-worker`, which the build runs for both of its +executables (`packaging/win/smoke-connection-process.py`). **Uploads met the same wall from the other side.** A browser 22 ms away uploaded at 6.5 MB/s, with no core busy on either machine and no loss in the node's log. @@ -4465,7 +4468,6 @@ process runs it — `systemctl --user` on Linux, Task Scheduler on Windows. | **A folder renamed on the node's disk empties until the next reconciliation** | Seen live (2026-10-10, ntfs3): renaming a 2,441-file folder inside a root made the watcher drop every entry under the old path and announce none under the new one, so the group read as empty, and the loop was busy long enough for the hub's keepalive to time out. A restart (full scan) brought them back. A directory moved within a root should rescan its new subtree at once, not wait for the periodic scan | | **A photo deleted from the group comes back after a reinstall** | The backup's memory of what it sent is the phone's ledger (§9.12); a reinstall or cleared data empties it, and the folder no longer holds the deleted photo, so it is sent again. Clean fix: the node keeps a tombstone per folder on `file_delete` (name, size, SHA-256 taken before deleting), the index carries them, and the backup records a match as sent. Not done: a protocol field and a node table for a rare case | | **`connection_processes` has no CLI verb** | Set from the Node page or `node.toml`; `meshbay-node` has no command for it, unlike the transfer caps | -| **Connection processes are untested on Windows and in a frozen build** | The frozen node starts them as `meshbay-node webrtc-worker`; written, never run there | | **A connection process does not slow a peer the node cannot keep up with** | What a process receives is forwarded to the node unbounded. An upload is bounded by its own rate, 5 to 6 MB/s a connection, so it would take a node stalled for seconds to matter | | **The home page says "No groups yet" when the hub cannot be reached** | An unreachable hub reads as an account with no groups, rather than as an error | | **`meshbay-node init` says "Settings → Link Node"** | The control is on the Profile page, as QUICKSTART says | 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 |