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>
3.7 KiB
• حالت تونل کامل حالا هر اتصال 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 ~500–2000 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