Merge pull request #131 from vahidlazio/feat/uncap-pipeline-depth

feat: remove pipeline depth cap — scales with deployment count

README.md

@@ -272,7 +272,7 @@ Full tunnel mode (`"mode": "full"`) routes **all** traffic end-to-end through Ap
 Each Apps Script batch request takes ~2 seconds round-trip. In full mode, `mhrv-rs` runs a **pipelined batch multiplexer** that fires multiple batch requests concurrently without waiting for the previous one to return. The number of in-flight batches (the *pipeline depth*) scales directly with the number of deployment IDs you configure:
 
 ```
-pipeline_depth = number_of_script_ids  (clamped to 2..12)
+pipeline_depth = number_of_script_ids  (minimum 2)
 ```
 
 | Deployments | Pipeline depth | Effective batch interval | Notes |
@@ -280,7 +280,8 @@ pipeline_depth = number_of_script_ids  (clamped to 2..12)
 | 1 | 2 | ~1.0s | Minimum — still pipelines 2 batches |
 | 3 | 3 | ~0.7s | Good for light browsing |
 | 6 | 6 | ~0.3s | Recommended for daily use |
-| 12 | 12 | ~0.17s | Maximum — diminishing returns past this |
+| 12 | 12 | ~0.17s | Sweet spot for most users |
+| 20 | 20 | ~0.10s | Multi-account setups |
 
 More deployments = more concurrent batches = lower per-session latency. Each batch round-robins across your deployment IDs, so the load is spread evenly and you're less likely to hit a single deployment's quota ceiling.
 
@@ -630,7 +631,7 @@ Donations cover hosting, self-hosted CI runner costs, and continued maintenance.
 هر درخواست دسته‌ای (`batch`) به `Apps Script` حدود ۲ ثانیه طول می‌کشد. در حالت `full`، برنامه یک **لولهٔ موازی** (`pipeline`) اجرا می‌کند که چند درخواست دسته‌ای را همزمان می‌فرستد بدون اینکه منتظر پاسخ قبلی بماند. تعداد درخواست‌های همزمان مستقیماً با تعداد `Deployment ID`ها رابطه دارد:
 
 ```
-عمق لوله = تعداد Deployment IDها  (حداقل ۲، حداکثر ۱۲)
+عمق لوله = تعداد Deployment IDها  (حداقل ۲)
 ```
 
 | تعداد Deployment | عمق لوله | فاصلهٔ مؤثر بین دسته‌ها | |
@@ -638,7 +639,8 @@ Donations cover hosting, self-hosted CI runner costs, and continued maintenance.
 | ۱ | ۲ | ~۱ ثانیه | حداقل |
 | ۳ | ۳ | ~۰.۷ ثانیه | مناسب مرور سبک |
 | ۶ | ۶ | ~۰.۳ ثانیه | توصیه‌شده برای استفادهٔ روزانه |
-| ۱۲ | ۱۲ | ~۰.۱۷ ثانیه | حداکثر |
+| ۱۲ | ۱۲ | ~۰.۱۷ ثانیه | نقطهٔ بهینه |
+| ۲۰ | ۲۰ | ~۰.۱ ثانیه | چند حساب |
 
 بیشتر `Deployment` = بیشتر درخواست همزمان = تأخیر کمتر برای هر نشست. هر دسته بین `ID`ها چرخش می‌کند (`round-robin`)، پس بار به‌طور یکنواخت توزیع می‌شود.
 

src/tunnel_client.rs

@@ -2,9 +2,8 @@
 //!
 //! A central multiplexer collects pending data from ALL active sessions
 //! and fires batch requests without waiting for the previous one to return.
-//! Pipeline depth scales with the number of script deployments (1 per
+//! Pipeline depth equals the number of script deployments (minimum 2),
-//! script, clamped to 2..12), so users with more deployments get lower
+//! so users with more deployments get lower latency automatically.
-//! latency automatically.
 
 use std::sync::Arc;
 use std::time::Duration;
@@ -17,8 +16,6 @@ use tokio::sync::{mpsc, oneshot, Semaphore};
 
 use crate::domain_fronter::{BatchOp, DomainFronter, TunnelResponse};
 
-/// Hard ceiling on pipeline depth regardless of script count.
-const MAX_PIPELINE_DEPTH: usize = 12;
 /// Minimum pipeline depth even with a single script.
 const MIN_PIPELINE_DEPTH: usize = 2;
 
@@ -69,8 +66,7 @@ pub struct TunnelMux {
 
 impl TunnelMux {
     pub fn start(fronter: Arc<DomainFronter>) -> Arc<Self> {
-        let pipeline_depth =
+        let pipeline_depth = fronter.num_scripts().max(MIN_PIPELINE_DEPTH);
-            fronter.num_scripts().clamp(MIN_PIPELINE_DEPTH, MAX_PIPELINE_DEPTH);
         tracing::info!(
             "tunnel mux: pipeline_depth={} (from {} script deployments)",
             pipeline_depth,

tunnel-node/README.md

@@ -82,7 +82,7 @@ TUNNEL_AUTH_KEY=your-secret PORT=8080 ./target/release/tunnel-node
 
 ## Performance: deployment count and pipeline depth
 
-The mhrv-rs client runs a pipelined batch multiplexer in full mode. Each Apps Script round-trip takes ~2s, so the client fires multiple batch requests concurrently — the pipeline depth equals the number of configured script deployment IDs (clamped 2..12).
+The mhrv-rs client runs a pipelined batch multiplexer in full mode. Each Apps Script round-trip takes ~2s, so the client fires multiple batch requests concurrently — the pipeline depth equals the number of configured script deployment IDs (minimum 2, no upper cap).
 
 More deployments = more concurrent batches hitting the tunnel-node = lower per-session latency. With 6 deployments, a new batch arrives every ~0.3s instead of every 2s.