Поддержка Modbus UDP

[Валенок]

..Групповые сообщения (multicast) по TCP?

1.Если что, там еще речь была о инициирующей отправку данных стороне.
2.А зачем нужна ненадежная форма отправки задач в промышленном оборудовании ?

Использование протокола TCP ну никак не спасает и не страхует от ошибок в коде к.

Проще логика (см. в конце поста) - проще сразу выявить все ошибки. Удивляет, да ?

А вот если какой-то пакет с телеметрией потеряется и TCP начнёт процедуру отсчёта таймаута, затем повторную передачу потерянного пакета,...

Можно с этого места поподробней ? Вы же разбираетесь с протоколами как я понял.

до данные в этом пакете уже протухнут и, по-хорошему, надо бы уже запрашивать более свежие.

Кто и как протухнет в TCP-потоке - интересуют подробности.
И главное - как на фоне этого UDP сохраняет свежесть ?

..это приемлемо...уже неприемлемо.

Определимся с "приемлимостью" ? Это что ?

о восстановление TCP соединения в некоторых случаях может задержатся ещё на 5с..

Т.е. присутствуют проблемы (физические/внешние на линии/местные внутрисистемные/...) приводящие к задержкам.
А UDP приносят голуби и их это не касается ?

..
В протоколе MODBUS есть специальное поле идентификатора транзакции...

Для Модбас-TCP оно избыточно если что. Не ?

..
В протоколе MODBUS есть специальное поле идентификатора транзакции, которое как раз и нужно для таких случаев в том числе. И должно оно обрабатываться всегда независимо от транспортного протокола, который может и сам умеет отслеживать и дубликаты, и неверный порядок.

Так я же и просил Вас написать для вышеизложенного (с Модбас-UDP) простенький алгоритм обработки.
Вот например для Модбас-TCP:
1.Открыл коннект
2.Отправил запрос
3.Получил норм ответ - goto 2, таймаут/мусор - goto 4
4.Закрыл коннект
5.goto 1