@torrent-tv/proxy 2.89.6 → 2.89.7

package/research/delivery-wedge-stand-ladder-2026-09-13.md

@@ -1,329 +1,329 @@
-# Клин доставки: лестница на стенде и чтение исходника usrsctp — 2026-09-13
-
-Всё ниже либо замерено на стенде, либо прочитано из исходника на закреплённом
-коммите. Где вывод не подтверждён замером, это сказано прямо.
-
-## 0. Что установлено за день, одним абзацем
-
-Клин воспроизводится по требованию — четыре прогона из четырёх — и не зависит
-ни от чего, чем мы можем управлять: ни от размера сообщения, ни от
-ненадёжного канала, ни от видимости вкладки, ни от паузы между запросами, ни от
-торрента с кодировщиком. Разбор через учёт полёта в usrsctp построен и **сам же
-опровергнут** дальнейшим чтением. Наверх заведён `sctplab/usrsctp#750` с
-воспроизведением и с поправкой. Чего по-прежнему нет — счётчиков живой
-заклинившей ассоциации.
-
-## 1. Стенд
-
-Три места, три роли:
-
-1. **хост Home Assistant** — контейнер `ttv-wedge-stand` из образа дополнения
-   `b34a1737/aarch64-addon-torrent_tv_proxy:0.74.4`, на порту 9090, с ключом
-   `--delivery-sink`. Отправитель. Своё дополнение при этом остановлено;
-2. **машина разработчика** — Chrome Canary с отладочным портом, вкладка на
-   `webauth.courses`. Внутри страницы цикл поднимает СВОЁ соединение
-   (`new WebRtcProxy(id)`) и подряд просит по 4 МБ. Приёмник и источник
-   нагрузки;
-3. **дроплет** — только сигналинг и отчёты цикла по HTTP.
-
-Выбранная пара за все прогоны: `2001:1c00:a603:2100:…:9090 -> 2001:1c00:a603:2100:…`
-(host/srflx), оба адреса в одном `/64` — то есть напрямую, внутри домашней сети,
-мимо дроплета. Это та же форма пары, что и в полевом клине 2026-09-12.
-
-Загрузчик — `stand/wedge/browser-loader.js` (в родительской папке, рядом с
-`driver.mjs`). Раньше он жил только во вкладке и пропадал вместе с ней.
-
-### Три вещи, каждая из которых стоила прогона
-
-1. **правка в контейнере дополнения не выживает.** `ha apps restart` пересоздаёт
-   контейнер из образа, а убийство процесса внутри будит watchdog, который тоже
-   пересоздаёт. Поэтому свой контейнер — watchdog его не трогает;
-2. **целиться по идентификатору, а не по имени.** Локальный стенд разработчика
-   назывался так же, и цикл подключился к нему;
-3. **отладочный порт Chrome не открывается на профиле по умолчанию** начиная со
-   136-й версии. Нужен явный `--user-data-dir`. А чтобы перекрытое окно
-   считалось видимым — `--disable-features=CalculateNativeWinOcclusion`.
-
-## 2. Лестница: четыре плеча, четыре клина
-
-| плечо | что менялось | клин | скорость |
-|---|---|---|---|
-| опорное (2026-09-12) | — | 2696 МБ | 190-325 Мбит/с |
-| `16k` | сообщение 16 КБ вместо ≈65 КБ | 1220 МБ | 43-49 Мбит/с |
-| `nofast` | без канала `proxy-fast`, вкладка видима | 288 МБ | 40-64 Мбит/с |
-| `drain` | пауза 300 мс между запросами | 5300 МБ | 34 Мбит/с |
-
-Форма приговора одинакова во всех: запрос висит 30 с и не получает ничего,
-канал при этом `open`; со стороны прокси все каналы встают на одном счётчике,
-`queued[…0B]`, `rtt` 20-30 мс, `pc=connected ice=completed`. Это форма поля
-дословно.
-
-**Разброс 288-5300 МБ, восемнадцатикратный, при одном прогоне на плечо.** Ни
-одно плечо от другого не отделено: полевой разброс сам по себе был 485-2694 МБ.
-Поэтому «пауза помогает» утверждать нельзя, хотя `drain` и прошёл дальше всех.
-
-**Чего лестница не имеет и что надо снять первым делом:** нескольких прогонов
-опорного плеча подряд. Без измеренного разброса любое плечо нечитаемо — это та
-самая ошибка, что сделана сегодня дважды.
-
-## 3. Что снято замерами
-
-1. **размер сообщения** — не влияет. Клин и на 65 КБ, и на 16 КБ. Гипотеза, ради
-   которой строился `--send-chunk-bytes`, закрыта;
-2. **ненадёжный канал `proxy-fast`** (`ordered: false, maxRetransmits: 0`) — не
-   нужен для клина. Прогон `nofast` не создавал его вовсе. Это же снимает
-   подозрение, на котором стоит открытый с 2020 года `sctplab/usrsctp#427`;
-3. **скрытая вкладка и торможение приёмника** — не при чём, `peerTab=visible`
-   весь прогон `nofast`;
-4. **пауза, дающая полёту вычерпаться** — не спасает;
-5. **торрент, кодировщик, нарезка, хранилище кусков** — не при чём, стенд отдаёт
-   синтетические байты.
-
-## 4. Чтение usrsctp `fec583d5` — и почему разбор не устоял
-
-**Что прочитано и верно:**
-
-1. `sctp_indata.c:5144` — `peers_rwnd = sctp_sbspace_sub(a_rwnd, total_flight +
-   total_flight_count * 256)`. Наше представление об окне пира — это объявленное
-   им окно МИНУС наш собственный учёт полёта;
-2. `sctp_output.c:8481` — при `peers_rwnd == 0` и `total_flight > 0` ставится
-   `no_data_chunks = 1`: данные не отправляются вовсе;
-3. `sctp_output.c:9376` — зондирование окна ставится только при
-   `total_flight == 0`;
-4. `sctp_var.h:338` — вычет учёта несимметричен: прибавка безусловна, вычет
-   только если байты сходятся, иначе оба счётчика обнуляются.
-
-Из 1-3 следует состояние, объясняющее каждый факт с провода: завышенный и не
-убывающий счётчик полёта делает окно нулевым при любом объявленном, данные не
-идут, зонда нет, ретрансмиссии нет, подтверждения обрабатываются.
-
-**Чем это опровергнуто — дальнейшим чтением того же файла.** Пустую очередь
-отправленного исправляют ТРИ места, а не одно:
-
-1. `sctp_handle_sack:4836` — ловит «очередь пуста, полёт положителен», печатает
-   предупреждение, под INVARIANTS падает, обнуляет `total_flight`;
-2. `sctp_handle_sack:5007` — обнуляет полёт по всем путям, оба счётчика, и
-   останавливает таймеры;
-3. `sctp_express_handle_sack:4226` — то же.
-
-Подтверждения во время клина приходят — это доказано проводом. Значит состояние
-«байты числятся, очередь пуста» исправлялось бы на ближайшем подтверждении и
-существовать не может.
-
-Остаётся другая форма: очередь **не** пуста, а куски на ней учтены и никогда не
-будут подтверждены. Её и стережёт `sctp_fs_audit`, и вот он затворён
-(`j == 0`, `sent_queue_retran_cnt == 0`, `win_probe_recovered == 0`,
-`done_once == 0`, плюс ранний выход при `pr_sctp_cnt >= sent_queue_cnt`). Но эта
-форма плохо ложится на провод: куски на очереди должны держать таймер
-ретрансмиссии и порождать повторы, а повторов нет 178,8 с.
-
-**Механизма, который я готов защищать, на сегодня нет.**
-
-## 5. Наверх
-
-`sctplab/usrsctp#750` — наблюдение, воспроизведение, снятые причины, вопросы,
-и отдельным сообщением поправка, снимающая разбор из раздела 4. PR не подан
-сознательно: подавать правку по опровергнутому разбору нельзя.
-
-`#427` открыт с 2020 года, сопровождающие не воспроизвели ни на FreeBSD, ни на
-usrsctp. У нас воспроизведение есть — это и есть то, чего им не хватало.
-
-## 6. Что делать дальше, по убыванию пользы
-
-1. **прочитать счётчики живой заклинившей ассоциации** — `total_flight`,
-   `total_flight_count`, `peers_rwnd`, `cwnd`, состояние очереди отправленного.
-   Единственный способ назвать причину. На БОЕВОМ прокси это однажды заморозило
-   процесс (пункт 77); **на стенде безопасно** — отдельный контейнер, зрителей
-   нет. Для этого построено плечо `hold`: оно не закрывает ассоциацию после
-   приговора, чего не делало ни одно прежнее, поэтому читать было нечего;
-2. **объявлять заклинивший канал потерянным — на ПРИЁМНИКЕ.** Детекторы прокси
-   смотрят на его очередь, а она читается нулём: байты уже отданы в usrsctp. В
-   поле 2026-09-06 прокси объявил клин на шестнадцать минут позже браузера.
-   Браузер же знает сразу: висящий запрос без единого байта, когда предыдущие
-   приходили за секунду. Порог не выбирается, а выводится из измеренного худшего
-   времени ответа этого соединения;
-3. **восстановление, и оно может быть незаметным.** Вторая ассоциация к тому же
-   пиру поднимается за 232 мс и сразу даёт 310 Мбит/с — замерено трижды. Подушка
-   зрителя 120 с. Лестница пересоединения уже есть и работает на ЗАКРЫТОМ канале
-   (поле 2026-09-12, 20:03); не срабатывает она только потому, что заклинивший
-   канал остаётся `connected`. То есть строить надо пункт 2, а не восстановление;
-4. **несколько прогонов опорного плеча** — измеренный разброс, без которого
-   лестница не читается.
-
-
-## 6.1. Попытка прочитать счётчики: сделана, не удалась, причина названа
-
-Плечо `hold` заклинило на 1436 МБ и **удержало ассоциацию открытой** — первый
-раз, когда было что читать. `gdb` в контейнере стенда есть.
-
-Четыре подключения подряд, только чтение, срок жизни задан снаружи
-(`timeout -s KILL`). Результат:
-
-1. `system_base_info` найден по адресу `0x7f5a9eb8b0` — но как символ **без
-   отладочной информации**;
-2. `ptype struct sctp_association` — `No struct type named sctp_association`;
-3. `list sctp_output.c:8481` — `No source file named sctp_output.c`.
-
-Секции `.debug_info`, `.debug_abbrev`, `.debug_str` в `node_datachannel.node`
-присутствуют, но покрывают C++ часть libdatachannel; C-модули usrsctp собраны
-без `-g`. Значит разметки структур нет, и прочитать поля по имени нельзя.
-
-**Читать по жёстко забитым смещениям — нельзя.** Смещения зависят от флагов
-сборки (`INET6`, `SCTP_DEBUG` и прочих), а ошибка в смещении даёт правдоподобное
-число, которое ничем не отличить от верного.
-
-**Отдельный результат, важный для пункта 77 роадмапа: чтение отладчиком
-безопасно.** Процесс пережил все четыре подключения и отвечает на `/healthz`.
-Губителен был не отладчик как таковой, а **вызов функции внутри исследуемого
-процесса** (`usrsctp_getsockopt`), прерванный убийством: он оставил захваченный
-замок и тупик. Правило, которое из этого следует: подключаться можно, читать
-можно, вызывать внутри процесса — нельзя.
-
-**Что осталось для этого чтения:** собрать node-datachannel с `-g` под aarch64
-и поставить в контейнер стенда. Это не форк — те же исходники, отладочная
-сборка, и только для стенда.
-
-
-## 6.2. ПРИЧИНА НАЗВАНА: таймер ретрансмиссии не запланирован
-
-Счётчики прочитаны из живой заклинившей ассоциации 2026-09-13. Это отменяет
-раздел 6.1, где сказано, что прочитать не удалось: не удавалось с поставляемым
-модулем, а с отладочной сборкой удалось.
-
-### Как получена сборка (воспроизводимо)
-
-Сборочный контейнер из образа дополнения, `apk add cmake git ninja pkgconf
-openssl-dev linux-headers`, затем:
-
-```
-git clone --depth 1 --branch v0.32.3 --recurse-submodules     https://github.com/murat-dogan/node-datachannel.git
-npm i -g cmake-js && npm i --no-save --ignore-scripts node-addon-api
-cmake-js compile --CDCMAKE_BUILD_TYPE=RelWithDebInfo --CDOPENSSL_ROOT_DIR=/usr --parallel 4
-```
-
-Две грабли: `npm ci` падает на рассинхроне замка, а нужен из всего этого только
-`node-addon-api` ради `napi.h`; и CMake не находит libcrypto, хотя он на месте —
-корень OpenSSL приходится указать явно. Получается 58 МБ с отладочной
-информацией; libdatachannel v0.24.2 и usrsctp `fec583d5` внутри — ровно те
-версии, что работают в поле.
-
-Модуль подменяется в контейнере стенда поверх поставляемого (копия рядом,
-`.orig`).
-
-### Обход структур usrsctp
-
-`system_base_info.sctppcbinfo.listhead.lh_first` → цепочка `sctp_inpcb` по
-`sctp_list.le_next`; у каждого `sctp_asoc_list.lh_first` → цепочка `sctp_tcb`
-по `sctp_tcblist.le_next`; у каждого `asoc`, и пути по `asoc.nets` через
-`sctp_next.tqe_next`. Сценарии — `/tmp/sctp.gdb` и `/tmp/sctp3.gdb` в контейнере
-стенда. `ticks` — статическая в `sctp_callout.c`, по имени не берётся.
-
-### Что прочитано
-
-Клин на 2356 МБ, ассоциация удержана открытой плечом, которое не закрывает её
-после приговора:
-
-```
-TCB state=8 flight=95786 fcount=82 rwnd=4572914 sentq_cnt=82 sendq_cnt=0
-    retran=0 prsctp=0 sentq_empty=0
-NET rxt_timer: flags=0x0 c_time=342660
-    cwnd=95450 flight_size=95786 ssthresh=83634 RTO=200 error_count=0
-    partial_bytes_acked=0 fast_retran_loss_recovery=0 dest_state=0x1c1
-ASOC last_acked_seq=1527044401 sending_seq=1527044484
-CHUNK tsn=1527044402 sent=1 snd_count=1 book_size=1172
-CHUNK tsn=1527044403 sent=1 snd_count=1 book_size=1172
-CHUNK tsn=1527044404 sent=1 snd_count=1 book_size=1172
-```
-
-### Диагноз
-
-**`rxt_timer.flags = 0x0`** — ни `SCTP_CALLOUT_PENDING` (0x0004), ни
-`SCTP_CALLOUT_ACTIVE` (0x0002). Таймер ретрансмиссии НЕ ЗАПЛАНИРОВАН, при том
-что 82 куска лежат неподтверждёнными, каждый отправлен ровно один раз
-(`snd_count=1`, `sent=SCTP_DATAGRAM_SENT`) и ни один не помечен к пересылке.
-
-**Полёт 95786 против окна перегрузки 95450** — окно заполнено, `sctp_med_chunk_output`
-нового не отправит.
-
-Замок замкнут сам на себя: подтвердить куски некому, переслать некому, полёт не
-убывает, окно не освобождается, не уходит ничего. Навсегда.
-
-Это объясняет каждое наблюдение с провода: ни пакета с данными, ни
-ретрансмиссии, ни зонда окна, подтверждения обрабатываются, лечит только новая
-ассоциация.
-
-### Что этим снято ЧИСЛАМИ
-
-1. **учёт полёта точен** — `fcount=82` против `sentq_cnt=82`, фантома нет.
-   Раздел 4 опровергнут не только чтением, но и замером;
-2. **окно пира 4 572 914 байт, распахнуто**, а не ноль. Затвор
-   `peers_rwnd == 0 && total_flight > 0` не при чём;
-3. **таймер не отодвинут после неудач**: `RTO=200` — минимум, `error_count=0`.
-   Он просто не заведён.
-
-### Чего НЕ установлено
-
-Какая дорога теряет таймер. Обе, что должны его заводить, на вид верны:
-`sctp_output.c:9417` заводит после отправки, если он не запланирован;
-`sctp_indata.c:4265` заводит для каждого пути с ненулевым полётом при обработке
-подтверждения. У `sctp_t3rxt_timer` ранние выходы только через
-`sctp_threshold_management`, а при `error_count=0` он не срабатывал. По одному
-снимку дорогу не назвать: нужен ряд снимков в секундах перед обрывом.
-
-### Что это меняет для продукта
-
-Обнаружение на приёмнике и ротация остаются в силе, но теперь известно, что
-именно обходится: незаведённый таймер в конкретной ассоциации. **Ротация лечит
-это по построению** — новая ассоциация начинает с исправным таймером.
-
-Числа отправлены в `sctplab/usrsctp#750`.
-
-
-### Подтверждено на втором клине — подпись детерминированная
-
-Клин на 96 МБ (ниже прежнего минимума; отладчик к прогону не прикасался, обе
-записи переменных сделаны до создания ассоциации):
-
-| | первый | второй |
-|---|---|---|
-| полёт | 95786 | 51568 |
-| окно перегрузки | 95450 | 50566 |
-| разрыв | 336 | 1002 |
-| кусков в полёте / в очереди | 82 / 82 | 44 / 44 |
-| окно пира | 4572914 | 4647668 |
-| помечено к пересылке | 0 | 0 |
-| ошибок пути | 0 | 0 |
-| `rxt_timer.flags` | 0x0 | 0x0 |
-
-Разрыв оба раза **меньше одного пакета** — отправка встала ровно там, где
-следующий кусок перестал влезать в окно. Само по себе это нормальное поведение
-при заполнении окна; ненормально, что оно не разгребается.
-
-Ряд объёмов до клина теперь: 96, 288, 1220, 1436, 2356, 2696, 5300 МБ. Порога
-нет, разброс пятидесятипятикратный.
-
-### Вывод usrsctp: включается не тем флагом, каким кажется
-
-`option(sctp_debug "Provide debug information" 1)` в CMakeLists самого usrsctp
-включён по умолчанию — но у libdatachannel есть **свой** `option(SCTP_DEBUG
-"Enable SCTP debugging output to verbose log" OFF)`, и перекрывает именно он.
-Поэтому в обычной сборке вывода нет, хотя первый флаг говорит обратное.
-
-Проверено на живом процессе: `system_base_info.debug_printf` установлен в
-`rtc::impl::SctpTransport::DebugCallback`, а `sctpsysctl.sctp_debug_on` равен
-нулю — libdatachannel выставил бы `SCTP_DEBUG_ALL` сам, но его строка стоит под
-`#ifdef SCTP_DEBUG`, до C++ не дошедшим.
-
-Обе переменные пишутся отладчиком без вызова функций внутри процесса: указатель
-вывода можно перевести прямо на `printf`, минуя журнал libdatachannel и его
-уровень. Записи принимаются, но печатать нечего, пока нет пересборки с
-`--CDSCTP_DEBUG=ON`.
-
-## 7. Чего этот день НЕ установил
-
-1. ~~причину~~ — УСТАНОВЛЕНА, см. 6.2. Не установлена дорога, теряющая таймер;
-2. повторяемость по плечам: один прогон на плечо, разброс восемнадцатикратный;
-3. связь клина с полевыми эпизодами до 2026-08-26 — они старше и части нынешней
-   нынешнего кода не имели;
-4. что пауза в `drain` действительно помогает, а не попала в верхний край
-   разброса.
+# Клин доставки: лестница на стенде и чтение исходника usrsctp — 2026-09-13
+
+Всё ниже либо замерено на стенде, либо прочитано из исходника на закреплённом
+коммите. Где вывод не подтверждён замером, это сказано прямо.
+
+## 0. Что установлено за день, одним абзацем
+
+Клин воспроизводится по требованию — четыре прогона из четырёх — и не зависит
+ни от чего, чем мы можем управлять: ни от размера сообщения, ни от
+ненадёжного канала, ни от видимости вкладки, ни от паузы между запросами, ни от
+торрента с кодировщиком. Разбор через учёт полёта в usrsctp построен и **сам же
+опровергнут** дальнейшим чтением. Наверх заведён `sctplab/usrsctp#750` с
+воспроизведением и с поправкой. Чего по-прежнему нет — счётчиков живой
+заклинившей ассоциации.
+
+## 1. Стенд
+
+Три места, три роли:
+
+1. **хост Home Assistant** — контейнер `ttv-wedge-stand` из образа дополнения
+   `b34a1737/aarch64-addon-torrent_tv_proxy:0.74.4`, на порту 9090, с ключом
+   `--delivery-sink`. Отправитель. Своё дополнение при этом остановлено;
+2. **машина разработчика** — Chrome Canary с отладочным портом, вкладка на
+   `webauth.courses`. Внутри страницы цикл поднимает СВОЁ соединение
+   (`new WebRtcProxy(id)`) и подряд просит по 4 МБ. Приёмник и источник
+   нагрузки;
+3. **дроплет** — только сигналинг и отчёты цикла по HTTP.
+
+Выбранная пара за все прогоны: `2001:1c00:a603:2100:…:9090 -> 2001:1c00:a603:2100:…`
+(host/srflx), оба адреса в одном `/64` — то есть напрямую, внутри домашней сети,
+мимо дроплета. Это та же форма пары, что и в полевом клине 2026-09-12.
+
+Загрузчик — `stand/wedge/browser-loader.js` (в родительской папке, рядом с
+`driver.mjs`). Раньше он жил только во вкладке и пропадал вместе с ней.
+
+### Три вещи, каждая из которых стоила прогона
+
+1. **правка в контейнере дополнения не выживает.** `ha apps restart` пересоздаёт
+   контейнер из образа, а убийство процесса внутри будит watchdog, который тоже
+   пересоздаёт. Поэтому свой контейнер — watchdog его не трогает;
+2. **целиться по идентификатору, а не по имени.** Локальный стенд разработчика
+   назывался так же, и цикл подключился к нему;
+3. **отладочный порт Chrome не открывается на профиле по умолчанию** начиная со
+   136-й версии. Нужен явный `--user-data-dir`. А чтобы перекрытое окно
+   считалось видимым — `--disable-features=CalculateNativeWinOcclusion`.
+
+## 2. Лестница: четыре плеча, четыре клина
+
+| плечо | что менялось | клин | скорость |
+|---|---|---|---|
+| опорное (2026-09-12) | — | 2696 МБ | 190-325 Мбит/с |
+| `16k` | сообщение 16 КБ вместо ≈65 КБ | 1220 МБ | 43-49 Мбит/с |
+| `nofast` | без канала `proxy-fast`, вкладка видима | 288 МБ | 40-64 Мбит/с |
+| `drain` | пауза 300 мс между запросами | 5300 МБ | 34 Мбит/с |
+
+Форма приговора одинакова во всех: запрос висит 30 с и не получает ничего,
+канал при этом `open`; со стороны прокси все каналы встают на одном счётчике,
+`queued[…0B]`, `rtt` 20-30 мс, `pc=connected ice=completed`. Это форма поля
+дословно.
+
+**Разброс 288-5300 МБ, восемнадцатикратный, при одном прогоне на плечо.** Ни
+одно плечо от другого не отделено: полевой разброс сам по себе был 485-2694 МБ.
+Поэтому «пауза помогает» утверждать нельзя, хотя `drain` и прошёл дальше всех.
+
+**Чего лестница не имеет и что надо снять первым делом:** нескольких прогонов
+опорного плеча подряд. Без измеренного разброса любое плечо нечитаемо — это та
+самая ошибка, что сделана сегодня дважды.
+
+## 3. Что снято замерами
+
+1. **размер сообщения** — не влияет. Клин и на 65 КБ, и на 16 КБ. Гипотеза, ради
+   которой строился `--send-chunk-bytes`, закрыта;
+2. **ненадёжный канал `proxy-fast`** (`ordered: false, maxRetransmits: 0`) — не
+   нужен для клина. Прогон `nofast` не создавал его вовсе. Это же снимает
+   подозрение, на котором стоит открытый с 2020 года `sctplab/usrsctp#427`;
+3. **скрытая вкладка и торможение приёмника** — не при чём, `peerTab=visible`
+   весь прогон `nofast`;
+4. **пауза, дающая полёту вычерпаться** — не спасает;
+5. **торрент, кодировщик, нарезка, хранилище кусков** — не при чём, стенд отдаёт
+   синтетические байты.
+
+## 4. Чтение usrsctp `fec583d5` — и почему разбор не устоял
+
+**Что прочитано и верно:**
+
+1. `sctp_indata.c:5144` — `peers_rwnd = sctp_sbspace_sub(a_rwnd, total_flight +
+   total_flight_count * 256)`. Наше представление об окне пира — это объявленное
+   им окно МИНУС наш собственный учёт полёта;
+2. `sctp_output.c:8481` — при `peers_rwnd == 0` и `total_flight > 0` ставится
+   `no_data_chunks = 1`: данные не отправляются вовсе;
+3. `sctp_output.c:9376` — зондирование окна ставится только при
+   `total_flight == 0`;
+4. `sctp_var.h:338` — вычет учёта несимметричен: прибавка безусловна, вычет
+   только если байты сходятся, иначе оба счётчика обнуляются.
+
+Из 1-3 следует состояние, объясняющее каждый факт с провода: завышенный и не
+убывающий счётчик полёта делает окно нулевым при любом объявленном, данные не
+идут, зонда нет, ретрансмиссии нет, подтверждения обрабатываются.
+
+**Чем это опровергнуто — дальнейшим чтением того же файла.** Пустую очередь
+отправленного исправляют ТРИ места, а не одно:
+
+1. `sctp_handle_sack:4836` — ловит «очередь пуста, полёт положителен», печатает
+   предупреждение, под INVARIANTS падает, обнуляет `total_flight`;
+2. `sctp_handle_sack:5007` — обнуляет полёт по всем путям, оба счётчика, и
+   останавливает таймеры;
+3. `sctp_express_handle_sack:4226` — то же.
+
+Подтверждения во время клина приходят — это доказано проводом. Значит состояние
+«байты числятся, очередь пуста» исправлялось бы на ближайшем подтверждении и
+существовать не может.
+
+Остаётся другая форма: очередь **не** пуста, а куски на ней учтены и никогда не
+будут подтверждены. Её и стережёт `sctp_fs_audit`, и вот он затворён
+(`j == 0`, `sent_queue_retran_cnt == 0`, `win_probe_recovered == 0`,
+`done_once == 0`, плюс ранний выход при `pr_sctp_cnt >= sent_queue_cnt`). Но эта
+форма плохо ложится на провод: куски на очереди должны держать таймер
+ретрансмиссии и порождать повторы, а повторов нет 178,8 с.
+
+**Механизма, который я готов защищать, на сегодня нет.**
+
+## 5. Наверх
+
+`sctplab/usrsctp#750` — наблюдение, воспроизведение, снятые причины, вопросы,
+и отдельным сообщением поправка, снимающая разбор из раздела 4. PR не подан
+сознательно: подавать правку по опровергнутому разбору нельзя.
+
+`#427` открыт с 2020 года, сопровождающие не воспроизвели ни на FreeBSD, ни на
+usrsctp. У нас воспроизведение есть — это и есть то, чего им не хватало.
+
+## 6. Что делать дальше, по убыванию пользы
+
+1. **прочитать счётчики живой заклинившей ассоциации** — `total_flight`,
+   `total_flight_count`, `peers_rwnd`, `cwnd`, состояние очереди отправленного.
+   Единственный способ назвать причину. На БОЕВОМ прокси это однажды заморозило
+   процесс (пункт 77); **на стенде безопасно** — отдельный контейнер, зрителей
+   нет. Для этого построено плечо `hold`: оно не закрывает ассоциацию после
+   приговора, чего не делало ни одно прежнее, поэтому читать было нечего;
+2. **объявлять заклинивший канал потерянным — на ПРИЁМНИКЕ.** Детекторы прокси
+   смотрят на его очередь, а она читается нулём: байты уже отданы в usrsctp. В
+   поле 2026-09-06 прокси объявил клин на шестнадцать минут позже браузера.
+   Браузер же знает сразу: висящий запрос без единого байта, когда предыдущие
+   приходили за секунду. Порог не выбирается, а выводится из измеренного худшего
+   времени ответа этого соединения;
+3. **восстановление, и оно может быть незаметным.** Вторая ассоциация к тому же
+   пиру поднимается за 232 мс и сразу даёт 310 Мбит/с — замерено трижды. Подушка
+   зрителя 120 с. Лестница пересоединения уже есть и работает на ЗАКРЫТОМ канале
+   (поле 2026-09-12, 20:03); не срабатывает она только потому, что заклинивший
+   канал остаётся `connected`. То есть строить надо пункт 2, а не восстановление;
+4. **несколько прогонов опорного плеча** — измеренный разброс, без которого
+   лестница не читается.
+
+
+## 6.1. Попытка прочитать счётчики: сделана, не удалась, причина названа
+
+Плечо `hold` заклинило на 1436 МБ и **удержало ассоциацию открытой** — первый
+раз, когда было что читать. `gdb` в контейнере стенда есть.
+
+Четыре подключения подряд, только чтение, срок жизни задан снаружи
+(`timeout -s KILL`). Результат:
+
+1. `system_base_info` найден по адресу `0x7f5a9eb8b0` — но как символ **без
+   отладочной информации**;
+2. `ptype struct sctp_association` — `No struct type named sctp_association`;
+3. `list sctp_output.c:8481` — `No source file named sctp_output.c`.
+
+Секции `.debug_info`, `.debug_abbrev`, `.debug_str` в `node_datachannel.node`
+присутствуют, но покрывают C++ часть libdatachannel; C-модули usrsctp собраны
+без `-g`. Значит разметки структур нет, и прочитать поля по имени нельзя.
+
+**Читать по жёстко забитым смещениям — нельзя.** Смещения зависят от флагов
+сборки (`INET6`, `SCTP_DEBUG` и прочих), а ошибка в смещении даёт правдоподобное
+число, которое ничем не отличить от верного.
+
+**Отдельный результат, важный для пункта 77 роадмапа: чтение отладчиком
+безопасно.** Процесс пережил все четыре подключения и отвечает на `/healthz`.
+Губителен был не отладчик как таковой, а **вызов функции внутри исследуемого
+процесса** (`usrsctp_getsockopt`), прерванный убийством: он оставил захваченный
+замок и тупик. Правило, которое из этого следует: подключаться можно, читать
+можно, вызывать внутри процесса — нельзя.
+
+**Что осталось для этого чтения:** собрать node-datachannel с `-g` под aarch64
+и поставить в контейнер стенда. Это не форк — те же исходники, отладочная
+сборка, и только для стенда.
+
+
+## 6.2. ПРИЧИНА НАЗВАНА: таймер ретрансмиссии не запланирован
+
+Счётчики прочитаны из живой заклинившей ассоциации 2026-09-13. Это отменяет
+раздел 6.1, где сказано, что прочитать не удалось: не удавалось с поставляемым
+модулем, а с отладочной сборкой удалось.
+
+### Как получена сборка (воспроизводимо)
+
+Сборочный контейнер из образа дополнения, `apk add cmake git ninja pkgconf
+openssl-dev linux-headers`, затем:
+
+```
+git clone --depth 1 --branch v0.32.3 --recurse-submodules     https://github.com/murat-dogan/node-datachannel.git
+npm i -g cmake-js && npm i --no-save --ignore-scripts node-addon-api
+cmake-js compile --CDCMAKE_BUILD_TYPE=RelWithDebInfo --CDOPENSSL_ROOT_DIR=/usr --parallel 4
+```
+
+Две грабли: `npm ci` падает на рассинхроне замка, а нужен из всего этого только
+`node-addon-api` ради `napi.h`; и CMake не находит libcrypto, хотя он на месте —
+корень OpenSSL приходится указать явно. Получается 58 МБ с отладочной
+информацией; libdatachannel v0.24.2 и usrsctp `fec583d5` внутри — ровно те
+версии, что работают в поле.
+
+Модуль подменяется в контейнере стенда поверх поставляемого (копия рядом,
+`.orig`).
+
+### Обход структур usrsctp
+
+`system_base_info.sctppcbinfo.listhead.lh_first` → цепочка `sctp_inpcb` по
+`sctp_list.le_next`; у каждого `sctp_asoc_list.lh_first` → цепочка `sctp_tcb`
+по `sctp_tcblist.le_next`; у каждого `asoc`, и пути по `asoc.nets` через
+`sctp_next.tqe_next`. Сценарии — `/tmp/sctp.gdb` и `/tmp/sctp3.gdb` в контейнере
+стенда. `ticks` — статическая в `sctp_callout.c`, по имени не берётся.
+
+### Что прочитано
+
+Клин на 2356 МБ, ассоциация удержана открытой плечом, которое не закрывает её
+после приговора:
+
+```
+TCB state=8 flight=95786 fcount=82 rwnd=4572914 sentq_cnt=82 sendq_cnt=0
+    retran=0 prsctp=0 sentq_empty=0
+NET rxt_timer: flags=0x0 c_time=342660
+    cwnd=95450 flight_size=95786 ssthresh=83634 RTO=200 error_count=0
+    partial_bytes_acked=0 fast_retran_loss_recovery=0 dest_state=0x1c1
+ASOC last_acked_seq=1527044401 sending_seq=1527044484
+CHUNK tsn=1527044402 sent=1 snd_count=1 book_size=1172
+CHUNK tsn=1527044403 sent=1 snd_count=1 book_size=1172
+CHUNK tsn=1527044404 sent=1 snd_count=1 book_size=1172
+```
+
+### Диагноз
+
+**`rxt_timer.flags = 0x0`** — ни `SCTP_CALLOUT_PENDING` (0x0004), ни
+`SCTP_CALLOUT_ACTIVE` (0x0002). Таймер ретрансмиссии НЕ ЗАПЛАНИРОВАН, при том
+что 82 куска лежат неподтверждёнными, каждый отправлен ровно один раз
+(`snd_count=1`, `sent=SCTP_DATAGRAM_SENT`) и ни один не помечен к пересылке.
+
+**Полёт 95786 против окна перегрузки 95450** — окно заполнено, `sctp_med_chunk_output`
+нового не отправит.
+
+Замок замкнут сам на себя: подтвердить куски некому, переслать некому, полёт не
+убывает, окно не освобождается, не уходит ничего. Навсегда.
+
+Это объясняет каждое наблюдение с провода: ни пакета с данными, ни
+ретрансмиссии, ни зонда окна, подтверждения обрабатываются, лечит только новая
+ассоциация.
+
+### Что этим снято ЧИСЛАМИ
+
+1. **учёт полёта точен** — `fcount=82` против `sentq_cnt=82`, фантома нет.
+   Раздел 4 опровергнут не только чтением, но и замером;
+2. **окно пира 4 572 914 байт, распахнуто**, а не ноль. Затвор
+   `peers_rwnd == 0 && total_flight > 0` не при чём;
+3. **таймер не отодвинут после неудач**: `RTO=200` — минимум, `error_count=0`.
+   Он просто не заведён.
+
+### Чего НЕ установлено
+
+Какая дорога теряет таймер. Обе, что должны его заводить, на вид верны:
+`sctp_output.c:9417` заводит после отправки, если он не запланирован;
+`sctp_indata.c:4265` заводит для каждого пути с ненулевым полётом при обработке
+подтверждения. У `sctp_t3rxt_timer` ранние выходы только через
+`sctp_threshold_management`, а при `error_count=0` он не срабатывал. По одному
+снимку дорогу не назвать: нужен ряд снимков в секундах перед обрывом.
+
+### Что это меняет для продукта
+
+Обнаружение на приёмнике и ротация остаются в силе, но теперь известно, что
+именно обходится: незаведённый таймер в конкретной ассоциации. **Ротация лечит
+это по построению** — новая ассоциация начинает с исправным таймером.
+
+Числа отправлены в `sctplab/usrsctp#750`.
+
+
+### Подтверждено на втором клине — подпись детерминированная
+
+Клин на 96 МБ (ниже прежнего минимума; отладчик к прогону не прикасался, обе
+записи переменных сделаны до создания ассоциации):
+
+| | первый | второй |
+|---|---|---|
+| полёт | 95786 | 51568 |
+| окно перегрузки | 95450 | 50566 |
+| разрыв | 336 | 1002 |
+| кусков в полёте / в очереди | 82 / 82 | 44 / 44 |
+| окно пира | 4572914 | 4647668 |
+| помечено к пересылке | 0 | 0 |
+| ошибок пути | 0 | 0 |
+| `rxt_timer.flags` | 0x0 | 0x0 |
+
+Разрыв оба раза **меньше одного пакета** — отправка встала ровно там, где
+следующий кусок перестал влезать в окно. Само по себе это нормальное поведение
+при заполнении окна; ненормально, что оно не разгребается.
+
+Ряд объёмов до клина теперь: 96, 288, 1220, 1436, 2356, 2696, 5300 МБ. Порога
+нет, разброс пятидесятипятикратный.
+
+### Вывод usrsctp: включается не тем флагом, каким кажется
+
+`option(sctp_debug "Provide debug information" 1)` в CMakeLists самого usrsctp
+включён по умолчанию — но у libdatachannel есть **свой** `option(SCTP_DEBUG
+"Enable SCTP debugging output to verbose log" OFF)`, и перекрывает именно он.
+Поэтому в обычной сборке вывода нет, хотя первый флаг говорит обратное.
+
+Проверено на живом процессе: `system_base_info.debug_printf` установлен в
+`rtc::impl::SctpTransport::DebugCallback`, а `sctpsysctl.sctp_debug_on` равен
+нулю — libdatachannel выставил бы `SCTP_DEBUG_ALL` сам, но его строка стоит под
+`#ifdef SCTP_DEBUG`, до C++ не дошедшим.
+
+Обе переменные пишутся отладчиком без вызова функций внутри процесса: указатель
+вывода можно перевести прямо на `printf`, минуя журнал libdatachannel и его
+уровень. Записи принимаются, но печатать нечего, пока нет пересборки с
+`--CDSCTP_DEBUG=ON`.
+
+## 7. Чего этот день НЕ установил
+
+1. ~~причину~~ — УСТАНОВЛЕНА, см. 6.2. Не установлена дорога, теряющая таймер;
+2. повторяемость по плечам: один прогон на плечо, разброс восемнадцатикратный;
+3. связь клина с полевыми эпизодами до 2026-08-26 — они старше и части нынешней
+   нынешнего кода не имели;
+4. что пауза в `drain` действительно помогает, а не попала в верхний край
+   разброса.