mirror of
https://github.com/therealaleph/MasterHttpRelayVPN-RUST.git
synced 2026-05-18 07:44:47 +03:00
therealaleph
434ad19b9d
Two PRs from @yyoyoian-pixel field-tested in Iran: - #448: adaptive batch coalescing replaces fixed 8ms window. P75 RTT 6.2s → 3.0s in Iran network testing. Configurable via coalesce_step_ms / coalesce_max_ms. - #446: tunnel-node long-poll 5s → 15s for Telegram/Google Push persistent connection stability. Adaptive 40ms-step / 500ms-max straggler settle replaces fixed 30ms. Includes desktop UI build fix: round-trip the new coalesce_* fields through to_config(). Desktop UI sliders queued for v1.8.x batch.
9 lines
4.1 KiB
Markdown
9 lines
4.1 KiB
Markdown
<!-- see docs/changelog/v1.1.0.md for the file format: Persian, then `---`, then English. -->
|
||
• **adaptive batch coalescing** برای کاهش تعداد Apps Script roundtripها (PR [#448](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/pull/448) از @yyoyoian-pixel): قبلاً هر op فقط ۸ms برای opهای همزمان دیگر صبر میکرد + اکثراً batchها فقط ۱ op داشتن. حالا scheme adaptive: اولین op یک timer ۴۰ms استارت میزنه، opهای جدید reset میکنن، اگر ۴۰ms idle شد batch fire میشه. cap نهایی ۱۰۰۰ms. نتیجه field test روی شبکه ایران: ops/batch از ۱.۰ به ۲-۳، P75 RTT از ۶.۲s به ۳.۰s، کاهش ~۵۰٪ Apps Script call. configurable از طریق `coalesce_step_ms` / `coalesce_max_ms` در config + در Android UI Advanced section با slider
|
||
• **tunnel-node long-poll از ۵s به ۱۵s** برای پایداری Telegram + Google Push (PR [#446](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/pull/446) از @yyoyoian-pixel): قبلاً connectionهای persistent (Telegram XMPP پورت ۵۲۲۲، Google Push پورت ۵۲۲۸) هر ۵ ثانیه empty-response برمیگرفتن + apps این رو instability تفسیر میکردن + session reconnect میزدن. هر reconnect معادل یک TLS handshake کامل (~۴s از طریق Apps Script) یعنی buffering قابل مشاهده در تماس Telegram یا playback. حالا long-poll تا ۱۵ ثانیه باز میمونه + persistent connection پایدار میمونه
|
||
• **adaptive straggler settle** در tunnel-node (PR [#446](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/pull/446)): قبلاً fixed ۳۰ms wait بعد از اولین session که data داشت. حالا adaptive ۴۰ms-step تا ۵۰۰ms-max که زود break میشه اگر همه sessionها ready باشن. در شبکههای latency بالا (~۱.۵s Apps Script overhead) packing بیشتر session response در یک batch، quota مصرف کمتری ایجاد میکنه
|
||
---
|
||
• **Adaptive batch coalescing** to reduce Apps Script round-trip count (PR [#448](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/pull/448) by @yyoyoian-pixel): the previous fixed 8ms coalesce window barely caught concurrent ops — most batches were a single op. The new adaptive scheme starts a 40ms timer on first arrival, resets on each new op, fires the batch when the window stays empty, with a hard 1000ms cap. Field testing on a network in Iran showed ops/batch went from ~1.0 to 2-3, P75 RTT 6.2s → 3.0s, fast (<3s) batches 61% → 74-85%, total Apps Script calls roughly halved. Both values configurable via `coalesce_step_ms` / `coalesce_max_ms` in `config.json` and via sliders in the Android UI's Advanced section. Desktop UI sliders are queued for the v1.8.x desktop UI batch alongside the system-proxy toggle (#432).
|
||
• **tunnel-node long-poll raised from 5s to 15s** for persistent-connection stability (PR [#446](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/pull/446) by @yyoyoian-pixel): at 5s long-poll, persistent connections like Telegram XMPP (`:5222`) and Google Push (`mtalk.google.com:5228`) interpreted the frequent empty-poll returns as connection instability and rotated sessions. Each reconnect cost a full TLS handshake (~4s through Apps Script), causing visible interruptions during Telegram video/voice calls and media playback. The 15s long-poll holds the response open until server data actually arrives, keeping persistent sessions alive without unnecessary re-handshakes.
|
||
• **Adaptive straggler settle in tunnel-node** (PR [#446](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/pull/446)): the previous fixed 30ms straggler settle was too short to catch neighboring sessions with data. Replaced with adaptive 40ms-step / 500ms-max settle that breaks early when all sessions in a batch have data. On high-latency relays (~1.5s Apps Script overhead per call), packing more session responses into one batch saves quota; the early-break prevents wasted time when all data is already ready.
|