таймаут TCP соединения

[I_m]

Вопросы:

1) Можно как-то изменить такое поведение TRIM5, когда он сбрасывает (со стороны контроллера) TCP-соединение через 5 секунд неактивности со стороны клиента?

2) Если для такого поведения контроллера есть субъективные предпосылки, то могут ли быть проблемы с принудительным опросом TRIM5 с цикличностью менее 5 секунд для поддержания соединения постоянно открытым?

[Gromov]

1. Подозреваю, что можно, через линукс и конфиги, но это не точно... Спрошу у разработчиков, при случае.
2. Проблем возникать не должно.

[Arsie]

Сообщение от I_m

Вопросы:

1) Можно как-то изменить такое поведение TRIM5, когда он сбрасывает (со стороны контроллера) TCP-соединение через 5 секунд неактивности со стороны клиента?

Trim5 в нормальных условиях не сбрасывает соединение через 5 секунд.

Сообщение от I_m

2) Если для такого поведения контроллера есть субъективные предпосылки, то могут ли быть проблемы с принудительным опросом TRIM5 с цикличностью менее 5 секунд для поддержания соединения постоянно открытым?

Минимально допустимая цикличность опроса Trim5 около 1 мсек.

[I_m]

Сообщение от Arsie

Trim5 в нормальных условиях не сбрасывает соединение через 5 секунд.

Не знаю, что вижу - о том пою. Т.е. сбрасывает.

Что такое "нормальные условия"? Для меня Trim5 - источник сигналов, не более. Подрядчик, который непосредственно программирует Trim5, говорит, что ничего сделать нельзя. В Manual_TRIM5_v1-15.pdf никакой информации по настройке тайаутов я не увидел.

[Arsie]

Сообщение от I_m

Не знаю, что вижу - о том пою. Т.е. сбрасывает.

Что такое "нормальные условия"?

Внутри этого контроллера linux. Вся работа с TCP идёт по правилам, принятым в linux.

Если TCP-стек linux'a сбрасывает соединение, значит в вашем случае сбросит соединение любой другой компьютер с этой операционной системой.

Я почему несколько раз написал слово linux - мы никак не вмешиваемся в работу базовых драйверов. Да и не думаю, что это вообще возможно без их перекомпиляции и изменения исходного кода.

[I_m]

Сообщение от Arsie

Внутри этого контроллера linux. Вся работа с TCP идёт по правилам, принятым в linux.

И linux имеет встроенный драйвер modbus tcp? Или Вы допускаете возможность отвала по таймауту только на транспортном уровне?

В том же ioLogoc "Modbus/TCP idle connection timeout interval" вполне себе настраивается.

[Arsie]

Сообщение от I_m

И linux имеет встроенный драйвер modbus tcp? Или Вы допускаете возможность отвала по таймауту только на транспортном уровне?

С точки зрения слейва, тайм-ауты возможны только транспортные. Наши контроллеры не накладывают логических тайм-аутов.

Сообщение от I_m

В том же ioLogoc "Modbus/TCP idle connection timeout interval" вполне себе настраивается.

Это точно имеет отношение к работа именно сокетов?

[I_m]

Сообщение от Arsie

Это точно имеет отношение к работа именно сокетов?

Точно, проверено. Ну, и:

The option Enable Modbus/TCP idle connection timeout interval: is used to determine the time interval
needed for the Ethernet network adaptor to disconnect the Modbus/TCP connection automatically when the host computer didn’t send any packets via the Ethernet network. When the value is “0,” the Ethernet network
adaptor remains connected unless the host computer actively disconnects the Modbus/TCP.

[Arsie]

Сообщение от I_m

Точно, проверено. Ну, и:

Меня настораживает словосочетание "Modbus TCP", т.к. сокеты - это допротокольный уровень по отношению к модбасу.

Может так статься, что это обычный логический дисконнект по неактивности мастера.

[I_m]

Сообщение от Arsie

Меня настораживает словосочетание "Modbus TCP", т.к. сокеты - это допротокольный уровень по отношению к модбасу.

Может так статься, что это обычный логический дисконнект по неактивности мастера.

Я не понимаю, что, собственно, настораживает? Разумеется, по неактивности мастера на порту 502.

Точно так же идет и отключение в случае с TRIM5, по крайней мере, как я это вижу. Только вот Вы утверждаете, что этого не может быть. Однако - есть.

[Arsie]

Сообщение от I_m

Я не понимаю, что, собственно, настораживает? Разумеется, по неактивности мастера на порту 502.

Неактивность сокета и неактивность modbus - это две разные вещи.

Я крайне сомневаюсь, что если я пропингую 502 порт на этом устройстве, то оно покажет связь с мастером. Это глупо, как минимум.

Поэтому я думаю, что это настройка верхнего уровня, а не уровня сырых сокетов.

[I_m]

Сообщение от Arsie

Я крайне сомневаюсь, что если я пропингую 502 порт на этом устройстве, то оно покажет связь с мастером. Это глупо, как минимум.

Поэтому я думаю, что это настройка верхнего уровня, а не уровня сырых сокетов.

А как, по-Вашему, modbus tcp без транспорта работать может? Оно само не умеет ведь.

[Arsie]

Сообщение от I_m

А как, по-Вашему, modbus tcp без транспорта работать может? Оно само не умеет ведь.

Вы понимаете, что такое socket и зачем они нужны?

Какое место в модели OSI они занимают и какое место там занимает modbus?

[I_m]

Сообщение от Arsie

Вы понимаете, что такое socket и зачем они нужны?

Какое место в модели OSI они занимают и какое место там занимает modbus?

Никакого места они в OSI не занимают, поскольку это не протокол. А вот TCP - транспортный уровень, Modbus/TCP - уровень приложения.

Что касается Вашего пассажа про "пинг" на 502-ой порт. Смотрим картинку в аттаче. Установлено соединение с сервером (ioLogic), у которого период неактивности задан = 1 минуте. У клиента включена опция "Send Keepalives to server". Прочитали три регистра и стоим. Так вот, то, что красным обведено, это и есть "пинги", как Вы изволили выразиться, на 502-ой порт. И сервер соединение держит, не рвет через минуту, что видно по строке состояния, обведенной зеленым. Я бы и TRIM5 такое попробовал, но, к сожалению, Ananas не позволяет менять периодичность keepalives, а она у него порядка 30 секунд. С другой стороны, это ничем принципиально не отличается от цикличного опроса раз в 2.5 секунды одного из регистров TRIM5 в приложении SCADA.

[Arsie]

Сообщение от I_m

Смотрим картинку в аттаче. Установлено соединение с сервером (ioLogic), у которого период неактивности задан = 1 минуте. У клиента включена опция "Send Keepalives to server". Прочитали три регистра и стоим. Так вот, то, что красным обведено, это и есть "пинги"

На скриншоте я вижу пакет, который был расшифрован и отвергнут. На пинг не похоже. Пинг нельзя расшифровать. Он вообще не содержит "value". Пинг не может быть правильным или неправильным. Это просто пинг.

Спорить мы с вами можем очень долго. Я вам сказал свою точку зрения, повторю вам её ещё раз: правила игры в TCP для linux/windows одинаковы и миллиард устройств в мире работают по этим правилам. Трим5 - одно из этого миллиарда устройств. Правила для него абсолютно те же. И если сокет реально закрывается через 5 секунд, значит на этом же месте в этих же условиях сокет будет закрыт и любым другим компьютером или сервером в датацентре.

Если вы желаете продолжить диалог и по настоящему докопаться до правды, то вам нужно промониторить сетевой трафик и подтвердить, что показанное на скриншоте реально является именно пингом, а сообщение "illegal value" всего лишь ошибка программистов iologic.

Но, повторюсь, я уверен на 100%, что это не пинг (ICMP Echo-Request).

[I_m]

Сообщение от Arsie

На скриншоте я вижу пакет, который был расшифрован и отвергнут. На пинг не похоже. Пинг нельзя расшифровать. Он вообще не содержит "value". Пинг не может быть правильным или неправильным. Это просто пинг.

Я думал, что применив термин "пинг", Вы просто кавычки забыли поставить. Видимо, все гораздо серьезнее. Жду увлекательно рассказа, как можно направить icmp-запрос на конкретный (502-ой) порт TCP.

Сообщение от Arsie

"illegal value" всего лишь ошибка программистов iologic.

Это сообщение утилиты ananas32, которой фирма Moxa (производитель ioLogic в т.ч.) не имеет никакого отношения. Это так, к слову.

Сообщение от Arsie

Но, повторюсь, я уверен на 100%, что это не пинг (ICMP Echo-Request).

Да кто бы сомневался, я же не зря "пинг" в кавычки взял, мне бы и голову не пришло использовать этот термин в общеупотребительном смысле.

Ладно, оставим эти пустые споры. Что имеем в сухом остатке:

1. TRIM5 закрывает ранее открытое соединение через 5 секунд неактивности.

2. Стек протоколов TCP/IP и TCP конкретно к этому безобразному (кмк) поведению не имеет никакого отношения. Не его это дело.

3. Соединение закрывается на стороне сервера по запросу службы, ранее открывшей это соединение. Т.е. модуля поддержки протокола modbas/tcp (не могу знать, как там это правильно в вашей архитектуре называется). Больше некому.

4. Служба поддержки Secnetics утверждает, что этого не может быть, потому, что не может быть никогда.

Я ничего не упустил?

[Arsie]

Сообщение от I_m

4. Служба поддержки Secnetics утверждает, что этого не может быть, потому, что не может быть никогда.

Я ничего не упустил?

Сообщение от Arsie

Внутри этого контроллера linux. Вся работа с TCP идёт по правилам, принятым в linux.

Если TCP-стек linux'a сбрасывает соединение, значит в вашем случае сбросит соединение любой другой компьютер с этой операционной системой.

Я почему несколько раз написал слово linux - мы никак не вмешиваемся в работу базовых драйверов. Да и не думаю, что это вообще возможно без их перекомпиляции и изменения исходного кода.

Сообщение от Arsie

Спорить мы с вами можем очень долго. Я вам сказал свою точку зрения, повторю вам её ещё раз: правила игры в TCP для linux/windows одинаковы и миллиард устройств в мире работают по этим правилам. Трим5 - одно из этого миллиарда устройств. Правила для него абсолютно те же. И если сокет реально закрывается через 5 секунд, значит на этом же месте в этих же условиях сокет будет закрыт и любым другим компьютером или сервером в датацентре.

Если вы желаете продолжить диалог и по настоящему докопаться до правды, то вам нужно промониторить сетевой трафик

Это всё, что может сказать техподдержка на базе имеющейся информации.

У меня на столе Trim5 не закрывает соединение через 5 секунд. Значит у нас с вами разные условия и я не знаю и не имею возможности выяснить, почему стек Trim5 так себя ведёт в ваших условиях.

[I_m]

Сообщение от Arsie

У меня на столе Trim5 не закрывает соединение через 5 секунд. Значит у нас с вами разные условия и я не знаю и не имею возможности выяснить, почему стек Trim5 так себя ведёт в ваших условиях.

Ну, у меня он не на столе, а 9 штук в разных концах города. Все ведут себя абсолютно одинаково все. Что характерно, стоящие на тех же объектах другие контроллеры с поддержкой modbus/tcp, ведут себя адекватно. И ничего им не мешает.

Ладно, конструктива все равно не получается. На том и расстанемся.

[Arsie]

Сообщение от I_m

Ну, у меня он не на столе, а 9 штук в разных концах города.

Ладно, конструктива все равно не получается. На том и расстанемся.

Предложите ваш вариант конструктива. Что я могу сделать, если у меня на столе всё хорошо и я не могу добиться указанной вами ситуации?

[I_m]

Сообщение от Arsie

Предложите ваш вариант конструктива. Что я могу сделать, если у меня на столе всё хорошо и я не могу добиться указанной вами ситуации?

Для начала могу дать доступ извне к одному из контроллеров, по modbus/tcp, для начала.

Чтобы Вы могли убедиться в наличии проблемы. Или убедить меня в отсутствии таковой - я ничего не хочу исключать.

В дальнейшем мне нужно добро на более полный доступ к контроллеру со стороны разработчика. Думаю, что особых проблем не будет.

[Arsie]

Сообщение от I_m

Для начала могу дать доступ извне к одному из контроллеров, по modbus/tcp, для начала.

Чтобы Вы могли убедиться в наличии проблемы. Или убедить меня в отсутствии таковой - я ничего не хочу исключать.

В дальнейшем мне нужно добро на более полный доступ к контроллеру со стороны разработчика. Думаю, что особых проблем не будет.

Опишите, пожалуйста, почему закрывание порта стало для вас проблемой?

Величина этой проблемы достаточна, чтобы терять на неё ваше время?

Поясню. По опыту использования сетевого модуля PNA-025, который действительно безальтернативно закрывает сокет через 5 секунд неактивности, проблемы с 2009 года пока что возникали исключительно с встроенным сервером трейсмода. Остальные серверы не брезгуют переоткрыть коннект, теряя на этом 1-2 мсек. В худшем случае 0.5 сек, что на фоне более, чем 5-секундных пауз всего 10% и менее.

[I_m]

Сообщение от Arsie

Опишите, пожалуйста, почему закрывание порта стало для вас проблемой?

Да пока (подчеркиваю) проблемы особой нет. Может быть я бы и внимания даже не обратил, если бы тэги, получаемые с TRIM5, не были завязаны исключительно на отображаемые на страницах соответствующих объектов аналоговые значения. Т.е. данные с контроллера запрашиваются только тогда, когда активна страница объекта с данным конкретным контролером. А тут сразу стало заметно, т.к. SCADA тратит секунд 10-15 на восстановление связи с ушедшим в оффлайн устройством в/в. И в течении этого времени вместо значений отображается состояние #COM (ошибка коммуникации с устройством в/в). Если бы с TRIM5 опрашивались тэги, завязанные на алармы, например, то этого может быть даже бы и не заметили.

Однако в дальнейшем (на новых объектах) есть мысль получать всю необходимую информацию с TRIM5, раз уж он ее все равно собирает с SMH210 и ТРМ. Просто на этапе согласования проектов нам почему-то не было известно о наличии в стуктуре диспетчеризации такого устройства, как TRIM5. Обычная несогласованность, увы.

Поскольку уже сейчас общее кол-во тэгов превышает 1800, а время таймаута для TRIM5 очень мало, то возникает подозрение, что этих самых 5-и секунд может и не хватить от одного цикла опроса до другого. Такие вот общие соображения.

[Arsie]

Сообщение от I_m

т.к. SCADA тратит секунд 10-15 на восстановление связи с ушедшим в оффлайн устройством в/в.

Пилите настройки скады. Вот, к примеру, как в нормальных программах:



Самое первое - это три попытки. Второе - время на возобновление 1 сек, для эзернета это нормально.

Сообщение от I_m

Поскольку уже сейчас общее кол-во тэгов превышает 1800, а время таймаута для TRIM5 очень мало, то возникает подозрение, что этих самых 5-и секунд может и не хватить от одного цикла опроса до другого. Такие вот общие соображения.

Тайм-аут отсчитывается от последнего байта опроса, а не от установки соединения.

Если у вас просто разрывается соединение посреди передачи, это уже никакого отношения к тайм-аутам не имеет.

[I_m]

Сообщение от Arsie

Пилите настройки скады. Вот, к примеру, как в нормальных программах:

Мимо кассы. Все настройки, что на картинке показаны, есть. Только они к делу отношения не имеют совсем. Есть несколько другая настройка, позволяющая отчасти решить вопрос. К сожалению, она применяется для протокола (modbus/tcp) в целом, а не к конкретному устройству i/o.

Сообщение от Arsie

Тайм-аут отсчитывается от последнего байта опроса, а не от установки соединения.

Вот спасибо, а то я не догадался.

Ладно, хоть на 6-ой день обсуждения факт отвала после 5-и секунд простоя признали.

[Arsie]

Сообщение от I_m

Ладно, хоть на 6-ой день обсуждения факт отвала после 5-и секунд простоя признали.

Вы уже второй человек, который приписывает мне то, что я не говорил.

Пожалуйста, покажите конкретно мои слова, где я указал, что через 5 секунд никакого отвала нет. Может быть я неправильно выразился и буду формулировать свои мысли яснее?

[I_m]

Сообщение от Arsie

Пожалуйста, покажите конкретно мои слова, где я указал, что через 5 секунд никакого отвала нет.

Trim5 в нормальных условиях не сбрасывает соединение через 5 секунд.

С точки зрения слейва, тайм-ауты возможны только транспортные. Наши контроллеры не накладывают логических тайм-аутов.

Правила для него абсолютно те же. И если сокет реально закрывается через 5 секунд, значит на этом же месте в этих же условиях сокет будет закрыт и любым другим компьютером или сервером в датацентре.

^^^^^^^^^^^^^^^^^^^
Это вообще песня!

У меня на столе Trim5 не закрывает соединение через 5 секунд. Значит у нас с вами разные условия и я не знаю и не имею возможности выяснить, почему стек Trim5 так себя ведёт в ваших условиях.

И чем же закончилось?

По опыту использования сетевого модуля PNA-025, который действительно безальтернативно закрывает сокет через 5 секунд неактивности

Правда, я понятия не имею - что такое PNA-025 и имеет ли он какое-либо отношение к TRIM5. Если это действительно просто сетевая карта - могу поздравить с "удачным" выбором. Очень интеллектуальное устройство - вместо того, чтобы отрабатывать свой 16-ый номер, само что-то там решает, когда и что закрывать.

ЗЫ: судя по описанию, видимо, все же не "просто сетевая карта".

[Arsie]

Сообщение от I_m

Это вообще песня!

Какая конкретно из перечисленных фраз у вас вызвала ощущение, что я сказал "Трим5 никогда не закрывает соединение"?

Сообщение от I_m

Правда, я понятия не имею - что такое PNA-025 и имеет ли он какое-либо отношение к TRIM5.

Упоминание модуля PNA-025 было аналогией. Аналогии я использую для того, чтобы полнее донести смысл моих разъяснений.

Мне не больше использовать аналогии в разговоре с вами?


Добавлено через 10 минут

Сообщение от I_m

SCADA тратит секунд 10-15 на восстановление связи с ушедшим в оффлайн устройством в/в.

Сообщение от I_m

Мимо кассы. Все настройки, что на картинке показаны, есть. Только они к делу отношения не имеют совсем.

Я вас не понимаю. Вроде как настройка реконнекта в скаде у вас есть. 1 сек, по вашим словам, поставить можно.

Зачем вы даёте скаде тратить 10-15 секунд там, где можно потратить 1 сек?

Зачем вы не разрешаете скаде сделать 1-2 попытки реконнекта, прежде чем присвоить устройству статус "оффлайн"?

Как способ сокращения времени реконнекта может не иметь отношения к делу?

[New]

Вот это:

Сообщение от I_m

Правда, я понятия не имею - что такое PNA-025 и имеет ли он какое-либо отношение к TRIM5.

действительно просто песня

[I_m]

Сообщение от Arsie

Какая конкретно из перечисленных фраз у вас вызвала ощущение, что я сказал "Трим5 никогда не закрывает соединение"?

Trim5 в нормальных условиях не сбрасывает соединение через 5 секунд.

Этого недостаточно? Был задан вопрос - что такое "нормальные условия"?
Это когда контроллер опрашивают не реже 1 раза в 5 секунд? Не смешно, извините. И вместо внятного ответа пошла демагогия про линух, стек tcp/ip и т.п., непосредственно к делу не относящаяся.

Сообщение от Arsie

Мне не больше использовать аналогии в разговоре с вами?

Эта аналогия к обсуждаемой теме отношение имеет? Нет? Тогда не надо.

Сообщение от Arsie

Я вас не понимаю. Вроде как настройка реконнекта в скаде у вас есть. 1 сек, по вашим словам, поставить можно.

Зачем вы даёте скаде тратить 10-15 секунд там, где можно потратить 1 сек?

Зачем вы не разрешаете скаде сделать 1-2 попытки реконнекта, прежде чем присвоить устройству статус "оффлайн"?

Как способ сокращения времени реконнекта может не иметь отношения к делу?

Есть не настройка реконнекта, а настройка времени, по истечении которого проверяется связь с устройством i/o. По-молчанию 30 секунд, чего вполне хватает для всех. Кроме TRIM5, как выяснилось. Оно работает, но, как я уже говорил, эта настройка глобальная для протокола, т.е. для всех устройств i/o, работающих в modbus/tcp. А поскольку TRIM5 пока составляют менее трети от общего кол-ва modbus/tcp устройств, то желания уходить от настройки по-умолчанию нет, благо есть способ поддерживать соединения в живом состоянии выборочно, хоть это и требует минимального кодирования.

Параметр "Время возобновления опроса" с Вашей картинки мне не очень понятен и, думаю, в Citect SCADA не применим. Прямой аналогии, во всяком случае, не вижу. Опрос идет по требованию: нужны данные - опрашиваем, не нужны - не опрашиваем. Или кодируем, если уж сильно нужно отойти от стандартной схемы.

[Arsie]

Сообщение от I_m

Параметр "Время возобновления опроса" с Вашей картинки мне не очень понятен

Подскажите, пожалуйста, как мне построить диалог с вами, чтобы вы начали переспрашивать, если вы что-то не понимаете?