Update tunnel_client.rs

[w0l4i]

Overview

This PR addresses the performance bottlenecks identified in issue #263.
As discussed, it moves hardcoded constants related to batching and timeouts into the configuration file.

Changes

• Added batch_timeout_ms to config (default: 10000ms).
• Added batch_coalesce_window_ms to config (default: 8ms).
• Added max_batch_ops to config (default: 50).
• Refactored tunnel_client.rs to use these configurable values instead of static constants.

Impact

Users in high-latency environments (like GAS relays) can now tune these parameters to prevent long-tail blocking and improve tunnel responsiveness.

[therealaleph]

Closing this iteration; the intent is correct but the patch doesn't compile yet. When I checked it out and ran `cargo build --release`, I got 7 errors:

```
error[E0425]: cannot find value `BATCH_TIMEOUT` in this scope
--> src/tunnel_client.rs:610:71
error[E0425]: cannot find value `config` in this scope
--> src/tunnel_client.rs:645:61
error[E0425]: cannot find value `REPLY_TIMEOUT` in this scope
--> src/tunnel_client.rs:926:47
```

What's blocking it:

1. Constants commented out as `/// const ...` — that turns them into doc comments attached to the next item, but the code at lines 610, 645, 926 still references the names. Either delete the lines fully, or keep the consts but make them `pub(crate)` defaults that the config field overrides. The doc-comment form is the wrong shape.
2. `config` isn't in scope in `mux_loop` / `fire_batch` / `tunnel_connection` — those functions don't take a Config parameter today. To wire the new fields you'll need to plumb `Arc` (or just the three timing values) down through the call chain. That's the larger refactor, and the bulk of why I split this into "Pass 1 (config fields)" and "Pass 2 (use them)" originally.
3. `config.client_first_data_wait_ms` is referenced but never added to `Config` — the patch updates the call site but not the struct, so even after fixing (1) and (2), this would still fail.

This is a real architectural change, not a 15-line tweak. Two paths forward:

A — I'll do Pass 1 myself. Take the field shape you proposed in #267 (which is right), plumb `Arc` down through `TunnelMux::start` → `mux_loop` → `fire_batch`, ship as v1.7.3. You stay credited as the design contributor. This unblocks Pass 2 (the per-deployment health tracking from #263) which has more design surface.

B — You take another pass. With the three issues above resolved + a local `cargo build --release` verifying it compiles. I'll review the moment it's pushed.

I'd take A — it's a few hours of work and the longer-tail Pass 2 is more interesting use of your time. But B is fine if you'd rather drive both. Let me know which.

Either way, neither #267 nor this PR can land in their current shape. Closing as superseded; re-open with the fix or wait for v1.7.3 with my version.

---

_{[reply via Anthropic Claude | reviewed by @therealaleph]}

[w0l4i]

Closing this iteration; the intent is correct but the patch doesn't compile yet. When I checked it out and ran cargo build --release, I got 7 errors:

error[E0425]: cannot find value `BATCH_TIMEOUT` in this scope --> src/tunnel_client.rs:610:71 error[E0425]: cannot find value `config` in this scope --> src/tunnel_client.rs:645:61 error[E0425]: cannot find value `REPLY_TIMEOUT` in this scope --> src/tunnel_client.rs:926:47

What's blocking it:

1. Constants commented out as /// const ... — that turns them into doc comments attached to the next item, but the code at lines 610, 645, 926 still references the names. Either delete the lines fully, or keep the consts but make them pub(crate) defaults that the config field overrides. The doc-comment form is the wrong shape.
2. config isn't in scope in mux_loop / fire_batch / tunnel_connection — those functions don't take a Config parameter today. To wire the new fields you'll need to plumb Arc (or just the three timing values) down through the call chain. That's the larger refactor, and the bulk of why I split this into "Pass 1 (config fields)" and "Pass 2 (use them)" originally.
3. config.client_first_data_wait_ms is referenced but never added to Config — the patch updates the call site but not the struct, so even after fixing (1) and (2), this would still fail.

This is a real architectural change, not a 15-line tweak. Two paths forward:

A — I'll do Pass 1 myself. Take the field shape you proposed in #267 (which is right), plumb Arc down through TunnelMux::start → mux_loop → fire_batch, ship as v1.7.3. You stay credited as the design contributor. This unblocks Pass 2 (the per-deployment health tracking from #263) which has more design surface.

B — You take another pass. With the three issues above resolved + a local cargo build --release verifying it compiles. I'll review the moment it's pushed.

I'd take A — it's a few hours of work and the longer-tail Pass 2 is more interesting use of your time. But B is fine if you'd rather drive both. Let me know which.

Either way, neither #267 nor this PR can land in their current shape. Closing as superseded; re-open with the fix or wait for v1.7.3 with my version.

[reply via Anthropic Claude | reviewed by @therealaleph]

i will wait for your turn , I'm sorry without good internet i can't run test build and this happened please do according to the plan by yourself #263