🇷🇺 Что нового (RU)
Что добавляет этот релиз
v1.6.0 чинит давнюю проблему: мобильный Telegram (наблюдалось на iOS), провисевший в фоне часами — например, ночь — без выгрузки из памяти, при возврате зависает в статусе «обновление», пока не переключишь прокси. Поведение по умолчанию не меняется — фикс opt-in, апгрейд безопасен.
Причина
Мобильный клиент держит одно TCP-соединение часами. За это время congestion window ядра схлопывается (тяжёлые ретрансмиты + reordering). На проде поймали соединение возрастом 8.5 ч: cwnd:10, bytes_retrans:18721, reord_seen:1188, проток ~20 Б/с — клиент всё ещё активно обменивался, просто еле-еле. При возврате клиент переиспользует этот деградировавший сокет → ресинк ползёт → «обновление» висит. Переключение прокси помогает именно потому, что создаёт свежее соединение.
Решение
Новая opt-in опция max_connection_lifetime_sec (по умолчанию 0 = без лимита, поведение байт-в-байт прежнее). Релей старше лимита пересоздаётся через TCP RST (SO_LINGER{0}) → клиент сразу открывает чистое соединение, Telegram прозрачно подхватывает поверх короткого разрыва.
[server]
max_connection_lifetime_sec = 1800 # 30 мин; 0 = выкл (дефолт). Пробуйте 1800–3600Проверено на живом проде
Развёрнуто на proxy.sleep3r.ru с cap=120: журнал подтвердил recycling relay: lifetime cap 120s reached (RST -> fresh reconnect), клиент чисто переподключился, active стабилен, NRestarts=0, ошибок нет. Прод выставлен на 1800. zig build test зелёный, кросс-сборки + install-матрица (debian 11/12, ubuntu 20.04/22.04/24.04) + E2E + bench — всё зелёное.
🇬🇧 Release notes (EN)
What this release adds
v1.6.0 fixes a long-standing issue: a mobile Telegram (observed on iOS) backgrounded for hours — e.g. overnight — without being unloaded from memory sits in the "updating" status on resume until you switch proxies. Defaults are unchanged — the fix is opt-in and the upgrade is safe.
Root cause
A mobile client keeps one TCP connection alive for hours. Over that lifetime the kernel congestion window collapses (heavy retransmits + reordering). On prod we caught an 8.5h connection with cwnd:10, bytes_retrans:18721, reord_seen:1188, throughput trickling at ~20 B/s — the client was still actively exchanging, just crawling. On resume the client reuses that degraded socket, so the re-sync trickles and "updating" hangs. Switching proxies works precisely because it forces a fresh connection.
The fix
New opt-in option max_connection_lifetime_sec (default 0 = unlimited, byte-identical behavior when unset). A relay older than the cap is recycled with a TCP RST (SO_LINGER{0}), so the client immediately opens a clean connection and Telegram resumes transparently across the brief drop.
[server]
max_connection_lifetime_sec = 1800 # 30 min; 0 = off (default). Try 1800–3600Validated on live prod
Deployed to proxy.sleep3r.ru at cap=120: the journal confirmed recycling relay: lifetime cap 120s reached (RST -> fresh reconnect), the client reconnected cleanly, active stable, NRestarts=0, no errors. Production value set to 1800. zig build test green, plus cross-builds + install matrix (debian 11/12, ubuntu 20.04/22.04/24.04) + E2E + bench — all green.
Full Changelog: v1.5.0...v1.6.0