Modbus/TCP ошибочный пакет

[juvf]

Ктонибудь реализовывал протокол Modbus/TCP? Что делать слэйву, если пакет с ошибкой?

В Modbus RTU всё понятно. Если адрес не тот, или CRC не совпал, то молчим. А если не то значение или не допустимые данные, то отвечаем исключением. А как в Modbus/TCP ?

В спецификации протокола MODBUS/TCP описан следующий формат:

Запрос и ответ предваряются шестью следующими байтами:
байт 0: идентификатор транзакции – копируется сервером – обычно 0
байт 1: идентификатор транзакции – копируется сервером – обычно 0
байт 2: идентификатор протокола = 0
байт 3: идентификатор протокола = 0
байт 4: поле длины (старший байт) = 0 (так как все сообщения меньше 256)
байт 5: поле длины (младший байт) = количество следующих байтов
байт 6: идентификатор устройства (раньше «адрес SLAVE»)
байт 7: код функции MODBUS
байт 8:  данные, если требуется

Существует транспорто-зависимый префикс, который в случае MODBUS/TCP включает в себя семь байт:
ref ref 00 00 00 len unit
«ref ref» – два байта «смещения транзакции» - число, которое не имеет значения на сервере, но копируется дословно от запроса к ответу для удобства клиента. Простые клиенты обычно оставляют эти значения нулевыми.

Слэйв получит пакет по TCP, в котором транспорто-зависимый префикс будет с ошибкой, например идентификатор протокола не будет равен 0, или поле длины будет равно 1234, при допустимом 255 - что делать? Разрывать соединение? или игнорировать пакет(молчать), или ответить исключением с кодом ошибки?

[kuzulis]

А если не то значение или не допустимые данные, то отвечаем исключением. А как в Modbus/TCP ?

аналогично

см п 4.4.2.1 в MODBUS Messaging on TCP/IP Implementation Guide V1.0b

[kuzulis]

вот еще:
---
Операционные системы и языки программирования, которые
поддерживают многопоточность, например JAVA, могут использовать
многопоточную стратегию, описанную здесь:
Используйте listen() для ожидания входящего соединения на TCP порт
502. Когда запроса нового соединения получен, используйте accept()
для его подтверждения и создайте новый поток для управления
соединением.
В новом потоке выполняйте следующий бесконечный цикл:
Выдайте recv(6) запрос для 6 байт MODBUS/TCP заголовка. Не
выставляйте здесь время ожидания, а ожидайте, пока запрос не
пройдет или соединение не закроется. Обе ситуации автоматически
известят поток.
Проанализируем заголовок. Если он окажется нарушенным, например,
поле протокола ненулевое или длина сообщения более 256, тогда в
одностороннем порядке закройте соединение. Это надлежащий ответ
сервера, если возникла ситуация, предполагающая неправильное TCP
кодирование.
Выдайте recv() для оставшихся байтов сообщения, длина которых
известна. Помните, что в отдельных случаях, при выдаче recv() с
подобным ограничением по длине допускает клиентов, требующих
«конвейерных» запросов. Любые подобные конвейерные запросы будут
оставаться в буферах TCP сервера или клиента, и будут обработаны
позже, когда существующие запросы завершатся.
Теперь обработайте входящее MODBUS сообщение, если необходимо,
приостановив текущий поток, пока правильный ответ не будет
подсчитан. В итоге у вас будет либо действительное MODBUS
сообщение или сообщение исключения EXCEPTION для использования в
качестве ответа.
Сформируйте MODBUS/TCP префикс для ответа, путем копирования байт
0 и 1 поля «идентификатора транзакции» запроса, и пересчитав длину
поля. Подтвердите ответ, включая MODBUS/TCP префикс, как один
буфер для передачи по соединению, используя send()
Вернитесь и ждите следующих 6 байт префикса записи.
В конечном счете, когда клиент решит закрыть соединение, команда
recv() 6 байт префикса не сработает. Правильное закрытие обычно
возвращает в команде recv() нулевое количество байт.
Принудительное закрытие может вызвать ошибочный результат команды
recv(). В любом случае, закройте соединение и существующий поток.
----

[juvf]

Проанализируем заголовок. Если он окажется нарушенным, например,
поле протокола ненулевое или длина сообщения более 256, тогда в
одностороннем порядке закройте соединение. Это надлежащий ответ
сервера, если возникла ситуация, предполагающая неправильное TCP

Это приложение спецификации OPEN MODBUS/TCP SPECIFICATION от 1999 года, в которой не оговариваются чёткие рамки, а просто предлагается некая реализация сервера. 

Однко в MODBUS Messaging on TCP/IP Implementation Guide V1.0b от 2006 года говорится

The MODBUS PDU Checking function consists of first parsing the MBAP Header. The Protocol Identifier field has to be checked :
       If it is different from MODBUS protocol type, the indication is simply discarded.

 is simply discarded - я это понял так  "просто бракуется (отвергается)". Т.е. если в транспорто-зависимом префиксе (заголовоке) ошибка, то соединение не разрывается, а просто эта посылка бракуется, игнорируется.

ps Но мне кажется, что разорвать соединение - это более правильно. имхо. Дилемма ((

[kuzulis]

ps Но мне кажется, что разорвать соединение - это более правильно. имхо. Дилемма ((

Ну да! Я тож считаю что так и нужно делать (разрывать), т.к PID отличный от нуля НЕ есть PID модбаса - а PID како-го то иного протокола.. а ваш сервер ведь МОДБАС! так какой ему резон поддерживать подключение - если ему шлют НЕ МОДБАС ADU ! т.е. нужно рвать..

ЗЫ: Вы когда слышите уругвайское наречие - вы разве пытаетесь понять что там говорят? НЕТ! Вы просто говорите им : "пошли Вы нафик" 

[alex12]

Я много работал и программировал Modbus. И RTU и TCP.

Мое мнение: если пакет ошибочен -- сразу надо разрывать связь (закрывать сокет). Ошибочный пакет - значит все - что-то накрылось. Где-то произошел сбой и единственный метод разрулить эту ситуацию - закрыть сокет.

Еще интересный момент: тайм-аут. Сам TCP не отслеживает ситуацию, когда пакеты просто перестали идти. Напритер где-то накрылся канал. Открытый TCP сокет на сервере будет бесконечно ждать нового запроса, который физически уже не может прийти в данной сессии. Поэтому нужно на сервере делать тайм-аут по неактивности клиента. Со стороны клиента, кстати, тоже возможна ситуация, когда клиент послал запрос, и в этот момент линия отвалилась. Без таймаута он будет ждать ответа бесконечно.

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