mirror of
https://github.com/therealaleph/MasterHttpRelayVPN-RUST.git
synced 2026-05-18 07:44:47 +03:00
therealaleph
75401acf0c
@bankbunk reported (#460) that on a 1 Gbps VPS, raw MP4 streams in Full mode died with `batch JSON parse error: EOF while parsing a string at line 1 column 52428685` minutes into playback. Root cause: drain_now took the entire per-session read buffer in one shot. On high-bandwidth VPS the reader task fills the buffer with tens of MiB between polls; the resulting batch response (raw + base64 1.33× + JSON envelope) exceeded Apps Script's ~50 MiB hard cap; Apps Script truncated mid-base64; the client's serde_json parse hit EOF and the stream tore. Fix: drain_now now returns at most TCP_DRAIN_MAX_BYTES (16 MiB) per call and leaves the tail in the buffer for the next poll. EOF is held back until the buffer is fully drained so partial drains don't tear the session prematurely. Three regression tests cover the cap, the under-cap pass-through, and the EOF-holdback case (33 tunnel-node tests passing). @bankbunk's wondershaper rate-limit workaround (40 Mbps cap on the VPS interface) is no longer necessary — high-bandwidth VPS users can run at line rate again.
5 lines
2.8 KiB
Markdown
5 lines
2.8 KiB
Markdown
<!-- see docs/changelog/v1.1.0.md for the file format: Persian, then `---`, then English. -->
|
||
• fix tunnel-node: cap هر TCP drain روی ۱۶ MiB تا batch response از سقف Apps Script (~۵۰ MiB) عبور نکنه ([#460](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/issues/460) از @bankbunk): روی VPS های پر-bandwidth (۱ Gbps) reader task میتونه هزاران مگابایت رو در buffer per-session جمع کنه قبل از اینکه poll بعدی بیاد. قبلاً `drain_now` همهی buffer رو در یک batch response میگرفت، base64 encoding (~۱.۳۳×) + JSON envelope اضافه میکرد، نتیجه از سقف ۵۰ MiB Apps Script رد میشد. Apps Script body رو wrap-around mid-base64 کوتاه میکرد + client side `serde_json` parse error با `EOF while parsing a string at line 1 column 52428685` میگرفت. برای استریم MP4 یا هر بایتسنگین upstream این bug stream رو مرتب کرش میداد. حالا `drain_now` حداکثر ۱۶ MiB در هر poll برمیگردونه + tail رو در buffer برای poll بعدی نگه میداره. eof تا finalize شدن buffer reported نمیشه که session بیموقع tear نشه. workaround قبلی @bankbunk (محدودکردن interface VPS با `wondershaper` به ۴۰ Mbps) دیگر لازم نیست — fix server-side پیاده شد و کاربران throughput عادی VPS رو خواهند داشت
|
||
---
|
||
• Fix tunnel-node: cap each TCP drain at 16 MiB so batch responses stay under Apps Script's ~50 MiB body ceiling ([#460](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/issues/460) by @bankbunk): on high-bandwidth VPS (1 Gbps+), the reader task can stuff the per-session read buffer with tens of MiB between client polls. The old `drain_now` took the entire buffer in one shot, base64-encoded it (1.33× overhead), wrapped it in JSON, and the resulting body exceeded Apps Script's hard ~50 MiB Web App response limit. Apps Script truncated the body mid-base64; the client failed `serde_json` parse with `EOF while parsing a string at line 1 column 52428685` (= 50 MiB) and the stream tore. Most visibly, raw MP4 streams crashed minutes into playback. The fix splits oversized buffers: at most `TCP_DRAIN_MAX_BYTES` (16 MiB) is returned per drain, and the remainder stays in the buffer for the next poll. EOF is held back until the buffer is fully drained so partial drains don't prematurely close the session. Three regression tests cover the cap, the under-cap pass-through, and the EOF-holdback case (33 tunnel-node tests passing). @bankbunk's `wondershaper` workaround (rate-limiting the VPS interface to 40 Mbps) is no longer necessary — high-bandwidth VPS users can let throughput run at line rate again.
|