[Gel]

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

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

Совсем не логично.

Данные при использовании TCP разбиваются на пакеты (если надо) TCP/IP стеком отправителя, обратно собираются TCP/IP стеком получателя. Между отправителем и получателем в локальной сети данные ходят в виде Ehernet-фреймов, которые имеют MAC-адрес отправителя, MAC-адрес получателя, что-то и контрольную сумму этого чего-то.

Все, задача свитча взять MAC-адрес получателя и отправить в его сторону пакет или выбросить. В "что-то" свитч не лезет от слова совсем. На уровне Ehernet-фреймов никаких квитков нет и отправитель Ehernet-фрейма не в курсе, получил его кто-то или нет.

Буферов у свитча два типа: 1) для хранения базы MAC-адресов; 2) для очереди отправки пакетов. На эту очередь отправки плохая связь не влияет, потому что свитчу (как и сетевой карте) все равно, получил ли кто-то переданный пакет или нет.

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

Где такое написано?

Просмотр сетевого трафика Wireshark'ом подтверждает, что пакеты в свитч отправляются даже при отключенном модуле, при условии что ранее было установлено TCP соединение с этим модулем.

Пакеты отправляются, потому что сетевая карта и TCP/IP стек не знает, что получатель пропал или что-то с ним случилось.

Под ожиданием я подразумеваю не ожидание ответа на TCP запрос, а ожидание квитанции на фреймы.

Никаких квитанций на Ethernet-фреймы нет.

Плюс такие параметры даже простого промышленного свича вроде IEEE 802.3x flow control, back pressure flow control говорят(?) о том, что поток свичем контролируется.

Это контролируется скорость отправки, а не доставка данных. Это вообще другое.

Далее у нас часто повторяется ситуация - отключаются модули (снимаются вместе с частью оборудования).
При этом если продолжать отправлять запросы по MODBUS TCP при подключении модуля и попытке с ним сделать еще одно соединение модуль не отвечает. Что логично так как для этого мак адреса (или вообще) буфер забит. Физическое соединение компа со свитчем не нарушаем.

Тут я не понял. Отключили модуль и пытаетесь к нему подключиться, не получается, и вы вините в этом мифический буфер?

Так если модуль отключен, с чего вдруг с ним будет соединение?

Если, на самом деле, с модулем нельзя установить два соединения, то это особенность реализации TCP/IP стэка этого модуля. Вот такая простая реализация, что поддерживает только одно соединение. Возможно, устройство содержит "аппаратную реализацию" TCP/IP, например, в виде микросхемы W5500, которая имеет ограничение по количеству подключений.

Никакого отношения это к свитчу не имеет.

А 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.

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

"Modbus/TCP, Modbus/RTU and OPC supported." -- это что, про настройку свитча? Какое разница, как настраивается свитч?