Compiled new

README.md

@@ -507,6 +507,12 @@ path probe: upload=32768 download=1400 persistent=true
 `adaptiveSizer` keeps one instance per direction plus two landmarks: `good`, the
 largest size known to work, and `bad`, the smallest known to fail.
 
+An I/O timeout is different from a size failure. It is a hard tunnel boundary:
+the timed-out socket is closed and the error is returned immediately. The client
+does not replay that request on the same logical session and does not walk every
+smaller record or batch size. The application's next connection creates a new
+tunnel. Other non-timeout transport failures can still use the adaptation below.
+
 **On failure** at the current size:
 
 * record `bad = min(bad, attempted)`,
@@ -1208,9 +1214,10 @@ manual tuning makes things worse.
   `adaptive download batch: N -> N/2`, the path cannot sustain that depth.
 * **Streams die mid-transfer, or nothing loads at all.** Set `Reconnect every`
   to `1` (auto). Auto starts persistent and retries an idempotent request once on
-  a fresh connection. If reuse itself failed, only that lane switches to one
-  logical request per connection. This avoids turning one imperfect startup
-  probe into connection churn for every active tunnel.
+  a fresh connection for non-timeout failures. An I/O timeout ends the logical
+  tunnel immediately because replaying an upload whose response was lost can
+  duplicate data. If reuse itself failed without timing out, only that lane
+  switches to one logical request per connection.
 * **Logs show the same transition many times over (`128 -> 64` repeatedly).**
   Each tunnel adapts independently, so a burst of flows produces a burst of
   identical lines. The app collapses consecutive duplicates into a counted line;
@@ -1225,6 +1232,9 @@ manual tuning makes things worse.
 * **Frequent `after transport failure` lines.** The network is dropping large
   records. Lower `Max chunk` to a size the probe already found safe — 1400 is
   common — so the client stops rediscovering the limit.
+* **`i/o timeout`.** The active physical connection is closed and the tunnel
+  exits immediately. It no longer redials that session or repeats the request at
+  512 KiB, 256 KiB, and every smaller size.
 * **Connection dies periodically, then recovers.** A middlebox is capping requests
   per connection. Set `Reconnect every` to 8–32.
 * **High-latency, high-bandwidth link.** Leave `--tcp-buffer` at 0 first. Only for
@@ -1263,6 +1273,7 @@ manual tuning makes things worse.
 | `upload gap: got N expected M` | The same, in the upload direction. Reconnect. |
 | `server maximum chunk N is below client minimum M` | Raise the server's `--chunk-max` or lower the client's `Min chunk`. |
 | `download failed at minimum chunk` | Eight consecutive failures at the smallest record size — the path is not passing traffic at all. |
+| `i/o timeout` | The physical connection timed out; its tunnel was terminated immediately without replay or a chunk-size retry loop. |
 | DNS works, QUIC/UDP apps do not | By design: only DNS is carried over UDP (§7.7). |
 | No IPv6 anywhere | By design: IPv6 is captured and blackholed (§7.4). |
 | Connections hang instead of failing fast | Expected only for non-SYN packets to unknown flows, which receive an RST. Anything else warrants the logs. |
@@ -1282,6 +1293,7 @@ Coverage:
 * the adaptive record sizer recovering from the minimum rather than latching
   there,
 * `reconnectEvery == 0` meaning persistent,
+* B and BP timeouts returning after one physical connection without replay,
 * a pinned batch never growing or shrinking across repeated failures,
 * a pinned batch surviving the ~1 MiB per-batch cap while an unpinned one is still
   trimmed by it,