1. Спасибо за информацию.
2. Если я правильно понял, то проверка канала пинг-ом является "глобальной", и предназначена выдавать предупреждение даже в случае, когда в течение интервала пинга (30 секунд) ЦУ не имел событий для отправки удалённому ДО?
Здесь напрашивается прямое решение минимизации ложной тревоги "Нет связи с ЦУ", а именно:
- уменьшить интервал посылки пинга "Дежурным Оператором", например, в два раза (опрашивать раз не в 30 секунд, а в 15);
- реагировать сообщением "Нет связи с ЦУ" не по первому "не-ответу" на пинг, а по второму (т.е. в случае двух подряд неудачных пингов).
При этом, мы сохраним максимальное время реакции системы на аварию канала (не более 30 секунд). Но избавимся от ложных тревог, обусловленных случайными потерями ответов на пинг (вызванными, например, кратковременными флуктуациями канала или "тормознутостью" сетевого процесса на "дальней" машине с ЦУ). Так будет меньше "ложняков".
Верно?
3. Если я правильно трактую взаимосвязи между ДО и ЦУ (см. скриншот), то ДО получает от ЦУ только "флаг" (извещение) о наличии нового события (сокет с рабочих портов 5050 и 5051). В данном контексте не важно, - "запрашивает" ли инициативно ДО Центр управления или наоборот, - ЦО инициативно "информирует" ДО.
А вот "вычитывает" событие, похоже, сам ДО - непосредственно из Базы данных(?).
Или это не соответствует действительности? Иначе, зачем нужны ещё два сокета, открытых непосредственно между приложением ДО и процессом MSSQL (рабочие порты: 56837 - 49187 и 56839 - 49187)?
То есть, событие "Потеря связи с Базой данных" генерируется по результатам действия совершенно другого механизма, нежели пингование IP-адреса машины с ЦУ(?)
Если это так, то в моём случае нужно точно выяснить (у девушек-операторов удалённого ДО), какое именно событие "всплывает" при появлении проблемы:
"Нет связи с ЦУ" или "Потеря связи с БД"
и на основании этого уже двигаться дальше...
Спасибо, ещё раз за помощь.