Files
therealaleph 8221d4280b v1.4.0: connect_data RTT win, Android ONLY-mode edge case, range-cap
Rolls up #150 + #151 + #153 (all merged on main) into a tagged release.

Highlights:

- Full Tunnel mode opens new HTTPS connections ~500-2000 ms faster
  (#153). The new connect_data tunnel op bundles the client's first
  bytes (typically TLS ClientHello) with the CONNECT call, eliminating
  one full Apps Script round trip per new flow. Backward compat is
  handled via UNSUPPORTED_OP detection + sticky AtomicBool fallback +
  pending_client_data replay so older deployments keep working without
  byte loss. New `connect_data preread: X win / Y loss / Z skip`
  metric in logs lets us measure the win ratio empirically.
- Android ONLY-mode split fix (#150): when the allow-list contained
  only mhrv-rs or stale uninstalled packages, every
  addAllowedApplication call silently failed and Android applied the
  TUN to every app — looping our own proxy traffic. Now we count
  successful adds; if zero, we fall back to ALL-mode self-exclusion.
  Complements PR #143 which fixed the empty-list case.
- Memory-safety cap on relay range stitching (#151): a hostile or
  buggy origin could advertise an absurd Content-Range total
  (e.g. 10 GiB) and force range-parallel to plan millions of chunks
  and preallocate a huge stitched buffer. Now capped at 64 MiB; larger
  totals fall back to a normal single GET.

Tests: 91 lib tests pass (was 82; +1 from #151, +8 from #153).
Tunnel-node: 6 tests pass (all new from #153).

Local Android build verified — universal + four per-ABI APKs all
produced at expected sizes (universal 53 MB, arm64-v8a 21 MB,
armeabi-v7a 18 MB, x86_64 23 MB, x86 22 MB). Installed on mhrv_test
emulator, app launches and renders correctly with v1.4.0 in title.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-25 01:21:05 +03:00

3.7 KiB
Raw Permalink Blame History

• حالت تونل کامل حالا هر اتصال HTTPS جدید رو حدود ۵۰۰ تا ۲۰۰۰ میلی‌ثانیه سریع‌تر باز می‌کنه (#153): یک عملیات تونلی جدید به نام connect_data اضافه شد که بایت‌های اول کلاینت (معمولاً TLS ClientHello) رو با درخواست connect ترکیب می‌کنه — یک round-trip کامل Apps Script حذف میشه. برای backward compatibility، کلاینت با deploymentهای قدیمی (بدون این بهینه‌سازی) خودکار fallback می‌کنه؛ بایت‌های buffered در fallback از دست نمیرن. متریک داخلی connect_data preread: X win / Y loss / Z skip به لاگ اضافه شد تا نسبت موفقیت رو روی بار کاری واقعی بشه سنجید • رفع edge case حالت ONLY در App Splitting اندروید (#150): اگر لیست appهای انتخابی خالی یا فقط شامل خود mhrv-rs بود و همهٔ مدخل‌ها در addAllowedApplication شکست می‌خوردن، اندروید TUN رو روی همهٔ appها اعمال می‌کرد — که باعث loop کردن ترافیک خود پروکسی می‌شد. حالا تعداد موفق‌ها شمرده میشه و اگر صفر بود، fallback به self-exclude (مثل حالت ALL) انجام میشه • سقف ۶۴ مگابایتی برای range stitching در relay (#151): قبلاً اگر origin یک Content-Range-total خیلی بزرگ (مثلاً ۱۰ گیگابایت) برمی‌گردوند، کلاینت سعی می‌کرد اون مقدار حافظه رو preallocate کنه که باعث OOM می‌شد. حالا اگر total > 64 مگ باشه، به یک GET معمولی fallback می‌کنه. هیچ پاسخ موفق جعلی برگشت داده نمیشه

• Full Tunnel mode now opens every new HTTPS connection ~5002000 ms faster (#153): a new connect_data tunnel op bundles the client's first bytes (typically the TLS ClientHello) with the CONNECT request, eliminating a full Apps Script round trip per new flow. Backward compatibility is handled automatically — clients hitting older deployments detect UNSUPPORTED_OP once per session and fall back to the legacy two-RTT path with no bytes lost. A new internal metric (connect_data preread: X win / Y loss / Z skip) lands in logs so we can measure the real-world win ratio • Android ONLY-mode split edge case fix (#150): when the allowed-apps list contained only mhrv-rs or stale/uninstalled packages, every addAllowedApplication call silently failed and Android fell back to "apply to all apps" — which then tunnelled our own proxy traffic through the TUN and looped. Now we count successful adds; if zero, we fall back to the ALL-mode self-exclusion behaviour so establish() produces a working VPN • Memory-safety cap on range stitching in the relay (#151): a hostile or buggy origin could advertise an absurd Content-Range total (e.g. 10 GiB) and cause relay_parallel_range to plan millions of chunks and preallocate a huge stitched buffer. Synthetic stitching is now capped at 64 MiB; larger totals fall back to a normal single GET instead of returning a fake truncated success