Comments and docs: the network threads, not a writer thread per player

Co-Authored-By: Claude Opus 5.5 <[email protected]>

crates/horizon-client/src/game/lan.rs

@@ -1369,7 +1369,7 @@ impl Game<'_> {
         self.award_leave_game_to_all(&mut host);
         self.save_leaving_guests(&mut host);
         host.hub.disconnect_all();
-        // Give the writer threads a moment to flush the disconnect packets.
+        // Give the network threads a moment to flush the disconnect packets.
         std::thread::sleep(std::time::Duration::from_millis(100));
         self.world.block_log = None;
         self.world.light_log = None;

crates/horizon-client/src/lan/hub.rs

@@ -1698,10 +1698,9 @@ impl Hub {
                 }
             }
         }
-        // keepConnectionAlive's timeout, checked once a second here, not on
-        // the writer thread: a client that stops reading blocks that thread
-        // and would hold its slot forever. Kicked, it gets the reason; still
-        // here a second later, its connection is closed under the writer.
+        // keepConnectionAlive's timeout, checked once a second here. Kicked,
+        // the client gets the reason; still here a second later (it reads
+        // nothing, so its disconnect waits unwritten), its connection is closed.
         if self.ticks.is_multiple_of(20) {
             for g in &self.guests {
                 if !g.left_reason.is_empty() && g.sender.timed_out() {

crates/horizon-client/src/lan/mod.rs

@@ -1,9 +1,10 @@
 //! Hosting a world on the local network. The network side lives here: the
-//! listener, the per-connection handshake/login/configuration threads and the
-//! writer threads (`conn`), plus the data the configuration phase sends
-//! (`data`). The play state is driven by the game thread (`hub`), which only
-//! ever exchanges decoded packets with these threads through channels, so a
-//! world that is not open to the network pays nothing.
+//! listener, the per-connection handshake/login/configuration threads
+//! (`conn`), the network threads every player in the play state is served on
+//! (`io_pool`), plus the data the configuration phase sends (`data`). The play
+//! state is driven by the game thread (`hub`), which only ever exchanges
+//! decoded packets with these threads, so a world that is not open to the
+//! network pays nothing.
 mod advancements;
 pub mod anticheat;
 pub mod attributes;

docs/server-next.md

@@ -255,7 +255,7 @@ NBT, the random's state. On top of that, the harnesses that cover server code ru
 - section encoding once per chunk, on helper threads (#623, `lan/chunks.rs`);
 - chunk frames compressed once for every player (`SharedFrames`, `lan/conn.rs`);
 - vanilla's chunk batch pacing (`ChunkBatchReceived`) and its move checks (#586);
-- a reader and a writer thread per connection (#649 made the writer wake once per tick).
+- a fixed pool of network threads for every play connection (5.1, `lan/io_pool.rs`).
 
 #3036 (hectoreccles) moves batch bodies to helper threads. W1 builds on it rather than redoing it.
 
@@ -268,6 +268,11 @@ budget gets its chunk sending throttled first (as vanilla's batch pacing does).
 disconnects stay unchanged. **Removes:** thread switches and lock traffic per packet. Bench: CPU per player at
 200 idle bots.
 
+**Done** (`lan/io_pool.rs`): the pool, one bounded outbox per player (past `MAX_PENDING` it disconnects), and the
+integrated server's own player on the same threads through its in-memory pipe. Login and configuration still run
+on a thread of their own until the player enters play. `SharedFrames` hashes a body once (XXH3-128 keyed by a
+random secret) and a second sender of a body being compressed waits for that frame instead of compressing it again.
+
 ### 5.2 Join
 
 Login and configuration (registries, tags, known packs) are the same for every player. They are encoded once