Цитата:
Сообщение от Gel
Кроме этого, свитчи (во всяком случае, обычные), не в курсе ни про какой TCP/IP и не занимаются ожиданиями, TCP-подключениями или чем-то подобным. Задача свичка -- получить Ethernet-пакет с одного порта и тупо переслать его на другой порт или порты.
|
Я попробовал разбираться с этим, получил информацию, что пакеты дробятся на фреймы, перемешиваются, отправляются в случайном порядке при приеме оправляется квитанция, если фрейм не получен, он повторяется далее фреймы склеиваются назад в пакеты. Получается логично если связь от свича к модулю плохая у него должен забиваться буфер. Так же прямо написано, что если нет физического коннекта так же данные будут попадать в буфер. Просмотр сетевого трафика Wireshark'ом подтверждает, что пакеты в свич отправляются даже при отключенном модуле, при условии что ранее было установлено TCP соединение с этим модулем.
Под ожиданием я подразумеваю не ожидание ответа на TCP запрос, а ожидание квитанции на фреймы. Подробно долго было расписывать. Вам, как специалистам режет глаз.
Плюс такие параметры даже простого промышленного свича вроде IEEE 802.3x flow control, back pressure flow control говорят(?) о том, что поток свичем контролируется.
Далее у нас часто повторяется ситуация - отключаются модули (снимаются вместе с частью оборудования).
При этом если продолжать отправлять запросы по MODBUS TCP при подключении модуля и попытке с ним сделать еще одно соединение модуль не отвечает. Что логично так как для этого мак адреса (или вообще) буфер забит. Физическое соединение компа со свичем не нарушаем.
Как только подаем запрос закрыть ТСP соединение с этим модулем, с этого же компьютера или с другого а затем подаем запрос на новое ТСР соединение, оно всегда выполняется и данные начинают поступать на запросы. Из чего у меня получается только один вывод Свич чуть умнее, и контролирует уже часть 3 уровня. Попытки разобраться заводят в конкретные дебри.
А managed свичи уже прямо пишут Typically the switch detects and recovers from a copper link failure within approximately 20 ms – for the majority of applications a seamless process. Modbus/TCP, Modbus/RTU and OPC supported. При этом считают свичем 2 уровня.
Упрощенное представление в итоге ответ не дает. Но способ работает. даже единичные сбои полностью прекратились после реконнекта при любой ошибке и использования поля Transaction ID в MODBUS TCP.
Вы предлагаете такой же способ. Все должно быть нормально, если ненормально реконнект. В этом пункте я с Вами заранее был согласен.
Но не все так делают.
Много текста, если прореживать, становится непонятно.
Добавлено через 12 минут
Цитата:
Сообщение от ATS
Может это пригодится?
Там и ещё есть на что посмотреть.  |
Спасибо, но конечно же не мог не видеть.