Heartbeat (exec-канал `while :; do echo; sleep 1; done`) мультиплексирован в
том же SSH-соединении, что и полезный трафик проброса. На большой выгрузке
строка heartbeat опаздывает за данными, MonitorLoop считает туннель мёртвым и
зовёт Reconnect(), который Stop()/Dispose()-ит ForwardedPortRemote — обрывая ту
самую передачу, которая и вызвала задержку.
По логам sshd: 1670 переподключений за месяц, все с формулировкой
"Connection terminated by the client"; распределение интервалов двумодальное —
82% короче 30 с (шторм) против 16% длиннее 10 минут (покой), а в час активной
передачи данных разрывов в 4-8 раз больше фонового уровня.
Что сделано:
1. Порог молчания вынесен в HeartbeatSilenceSec (60 с). Раньше считался как
Math.Max(5, MaxPingFailures) при дефолте MaxPingFailures=3 — то есть жёстко
5 секунд, а настройка была ниже пола и не влияла ни на что. В UI предел
тоже был 10. MaxPingFailures сохранён для чтения старых settings.ini.
2. Решение о переподключении принимает e2e-проверка проброса, а не тишина
heartbeat. Поднимается ForwardedPortLocal на серверный RemotePort, и
TCP-подключение к нему проходит весь маршрут по кругу: процесс -> SSH ->
слушатель обратного проброса на сервере -> SSH обратно -> LocalPort.
Это ловит и обратный случай, когда проброс завис, а heartbeat бодро отвечает.
Рвём только после ProbeFailuresBeforeReconnect (2) неудач подряд.
Если порт проверки поднять не удалось, проверка считается пройденной — иначе
неисправная диагностика начала бы рвать рабочий туннель.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
monster
