| Filename | Latest commit message | Latest commit date |
|---|---|---|
loop-uh
84e2237558
All checks were successful
Desktop source guards / guards (push) Successful in 6s
A stand (test relay with a sink/echo backend, WAN emulator, env-gated self-test in the client) showed the dev-17 limits, not the relay, capping throughput: a fixed 1 MiB upload window and 2 MiB download credit, plus 2 file sessions per DC, while every bridge write waited for its own round trip through the WebView. - Bridge: frames written in one carrier turn go to the page as one batch, up to 4 page calls are in flight, and the injected script joins the frames the page posts in one task into one message. - Windows: the upload window and the shared download credit follow the bandwidth-delay product of the credit loop plus 100 ms of queue (AdaptiveWindow), with a periodic drain to keep the base honest, a per-direction share when both are busy, and a hold while new streams' initial credit floods the relay's downlink. - Upload and download session counts are upstream's again; upload frames shrink with a small window. - Media sessions over MTProxy and WEB drop a regular temporary key borrowed from their DC and use the media cluster key: the regular key sent to a -N DC was answered with -404 and destroyed in a loop. - web_carrier summaries report windows, rates, delays and bridge stats. |
||
| .. | ||
| web_proxy_flow.cpp | ||
| web_proxy_flow.h | ||
| web_proxy_frame.cpp | ||
| web_proxy_frame.h | ||
| web_proxy_selftest.cpp | ||
| web_proxy_selftest.h | ||
| web_proxy_transport.cpp | ||
| web_proxy_transport.h | ||
| web_proxy_webview.cpp | ||
| web_proxy_webview.h | ||