add credit based mux window

README.md

@@ -202,7 +202,9 @@ forwarding and case-insensitive matching, regex wildcard pattern routing,
 multi-megabyte transfers, concurrent
 streams spreading across multiple worker connections, HAProxy v2 source-address
 propagation, player- and destination-initiated disconnect propagation, wrong-PSK
-rejection, and dropping of unmatched hostnames. The Go and Java crypto layers are
+rejection, dropping of unmatched hostnames, stream isolation under a slow
+player and under a slow destination (no head-of-line blocking), and rejection
+of pre-flow-control peers. The Go and Java crypto layers are
 independently pinned to the same SHA3-224 test vector so they cannot silently
 drift apart.
 
@@ -212,10 +214,12 @@ drift apart.
   ChaCha20-encrypted (no AEAD tag) to minimize overhead. This protects against
   casual sniffing, not a determined active attacker (see the note at the top of
   [PROTOCOL.md](PROTOCOL.md) and [docs/architecture.md](docs/architecture.md) §8).
-* **No per-stream flow control.** Multiplexing relies on TCP back-pressure per
-  worker connection, so one very slow stream can head-of-line-block others on
-  the same connection. Raising `maxConn` spreads load. Fine for interactive
-  Minecraft traffic; not a general-purpose high-throughput mux.
+* **Per-stream flow control.** Each stream has credit-based windows in both
+  directions (windows exchanged at session setup, default 256 KiB), so a slow
+  player or slow destination jams only its own stream at a bounded buffer — no
+  application-level head-of-line blocking between streams. What remains is
+  TCP-level HOL (packet loss stalls a whole worker connection briefly);
+  raising `maxConn` spreads that.
 * **Single hub event loop.** The hub deploys one Vert.x verticle, so all state
   is confined to one event loop (no locking). Throughput is bounded by one core;
   ample for hundreds of players, not designed for tens of thousands.