monster1025andClaude Opus 5
b26271a4f9
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 Monitor v2
Windows-приложение (WinForms, .NET Framework 4.7.2) для мониторинга процесса ss.exe, поддержки SSH-туннеля и контроля состояния сервисов с логированием в UI.
Возможности
- мониторинг и автоподдержка процесса
ss.exe; - управление SSH-туннелем;
- предотвращение засыпания системы во время работы;
- логирование событий в консоль приложения;
- хранение настроек в локальном профиле пользователя;
- автообновление через GitHub Releases (с проверкой раз в час);
- поддержка proxy для запросов к GitHub API и скачивания релизов.
Требования
- Windows 10+;
- .NET Framework 4.7.2 (target
net472); - доступ к GitHub (напрямую или через proxy).
Сборка и запуск
Из корня репозитория:
dotnet build .\src\MonsterMonitor\MonsterMonitor.csproj
dotnet run --project .\src\MonsterMonitor\MonsterMonitor.csproj
Или откройте src/MonsterMonitor.sln в Visual Studio и запустите проект MonsterMonitor.
Настройки
Настройки сохраняются в:
%LOCALAPPDATA%\MonsterMonitor\settings.ini
Основные параметры:
SshHost,SshPort,SshUsername,SshPasswordProtected;RemotePort,LocalPort;MaxPingFailures,ReconnectTimeoutSec;SsProcessPath,SsArguments;Proxy— адрес proxy для GitHub-запросов (пример:http://host:port).
Часть паролей хранится в защищенном виде через DPAPI.
Автообновление
Приложение проверяет новые версии в GitHub репозитории:
- owner:
monster1025 - repo:
monster_monitor_v2
Логика:
- Определяется текущая версия приложения.
- Получается последняя версия релиза из GitHub.
- Если версия новее текущей — скачивается
.zip-ассет релиза. - Обновление подготавливается в директории приложения:
.\update\<version>\update.zip.\update\<version>\extracted.\update\<version>\apply_update.bat
- Пользователю предлагается перезапустить приложение для применения обновления.
Периодичность проверки: каждые 60 минут (и первичная проверка после старта приложения).
Интерфейс
- Главное окно:
- кнопка
Настройки; - кнопка
Выход; - консоль логов (уровни: Debug/Info/Warn/Error).
- кнопка
- При сворачивании окно уходит в трей.
Примечания
- Для автообновления релиз должен содержать
.zip-ассет с файлами приложения. - Если
/releases/latestнедоступен, используется fallback на список релизов/releases.