From 176b5ed563f7022009b70751e62b7ee7901e6da0 Mon Sep 17 00:00:00 2001 From: Christophe Besson Date: Sun, 11 Oct 2026 19:09:04 +0200 Subject: feat(node): carry connections on several cores 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 --- CLAUDE.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'CLAUDE.md') diff --git a/CLAUDE.md b/CLAUDE.md index 24f024b..460a709 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -737,6 +737,18 @@ do. Read them before writing anything that touches the same mechanism. with one connection and with eight, so only a browser on another machine measures it +- **Measure which machine is the limit before adding cores to one of them.** + "Two clients will share the node's one core" was the reasoning; measured, two + browsers downloading at once left the node at 60 % of a core and saturated + the four cores of the machine receiving. The node's ceiling is real (one + aiortc process, about 35 MB/s over all its connections) but it is the third + fast client that meets it, not the second. What moved to other processes is + only the stack below the data channel (`connection_processes`, + `transport/webrtc/workers.py`, `docs/MESHBAY_DESIGN.md` ยง5.5), because that + is where the CPU went: with four processes the node proper used 18 % of a + core at 131 MB/s. Splitting there also means no key leaves the node's own + process + ### More of the same, from four rounds of live testing - **A protocol harness cannot test the SPA.** Any second implementation of the -- cgit v1.2.3