docs: receiver-side SCTP rules, session gating on reconnect, processes default

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

1 files changed, 7 insertions, 6 deletions

diff --git a/docs/USERGUIDE.md b/docs/USERGUIDE.md
index 1808598..ab5ee8c 100644
--- a/docs/USERGUIDE.md
+++ b/docs/USERGUIDE.md
@@ -852,15 +852,16 @@ and running `meshbay-node reload`:
 | `max_concurrent_downloads` | 8 | node-wide download slots |
 | `max_concurrent_uploads` | 8 | node-wide upload slots |
 | `max_upload_gb` | 8 | the largest single file a member may send you |
-| `connection_processes` | 1 | how many CPU cores carry members' connections |
+| `connection_processes` | one per core, up to 4 | how many CPU cores carry members' connections |
 | `transcode_incompatible_video` | true | re-encode video no browser can play |
 | `hardware_video_encode` | true | use the GPU for that, if one actually works |
 
-`connection_processes` is the one for speed. With 1, everything a node sends
-goes through one core, about 35 MB/s shared between everyone downloading at
-that moment. Raise it when several people download at once and the machine has
-cores to spare: each one adds a core's worth, and about 85 MB of memory. It
-applies to connections opened after the change.
+`connection_processes` is the one for speed. Each process is a core's worth
+of sending, shared between everyone downloading at that moment, and about 85 MB
+of memory. With 1, everything a node sends goes through one core: about 35 MB/s
+on Linux, much less on Windows. Lower it on a machine short of memory; raise it
+above 4 only when many people download at once. It applies to connections
+opened after the change.
 
 `max_concurrent_streams` is the one to think about: a stream costs a video
 process for as long as the film lasts, so this counts **viewers**, not