Every MTProto session through a WEB proxy is a stream on a single
carrier whose relay keeps one FIFO per direction. Bulk media and
uploads filled that FIFO, every session's own 4-8s receive timer then
fired at once, and the reconnects piled new OPENs behind the same
backlog.
- Uplink: a scheduler serves interactive streams first, download
requests next and uploads round-robin in 64 KiB frames, with at most
1 MiB of upload bytes uncredited by the relay (one bounded batch in
front of a chat request); a burst guard keeps uploads from starving.
- Downlink: download streams keep only a share of a 2 MiB credit budget
(256 KiB..1 MiB each) instead of the full 4 MiB window, so media waits
in the backend's TCP buffers rather than in front of chat replies.
- Liveness: a WEB session asks the carrier before dropping its stream.
It waits while its request is still queued or the downlink is busy,
fails when the pipe is quiet for 8s after delivery, busy for 30s, or
after 64s total. A carrier with bytes outstanding and no relay
progress for 20s is recovered once, for all streams.
- A WEB session opens one stream instead of racing identical ones, and
a -404 on a WEB stream reconnects first; only a second -404 before any
reply decrypts destroys the temporary key.
- Uploads and downloads use at most two sessions per DC through a WEB
proxy, and slow upload parts are no longer cancelled and moved.
- web_carrier diagnostics report carrier state, stalls, per-class
stream and queue counts, credit and throughput every 10s of activity.
The policy lives in web_proxy_flow.{h,cpp} and is covered by the new
test_web_proxy_flow target and a source guard.
loop-uh
c8120a7a6d