Sparkplug seq: пропуск номера нужно отличать от задержанного сообщения
Фотография конкретного исполнения не приложена.
Сообщения одного Edge в Sparkplug имеют последовательность seq, общую для соответствующего потока, а не отдельную для каждой DATA-темы. После 255 счётчик переходит к нулю. Такой переход не следует автоматически считать потерей или перезапуском узла.
Из-за разных тем и реализации брокера сообщения могут прийти не по порядку. Спецификация предусматривает настраиваемое окно Reorder Timeout: при получении 1, 2, 4 Host ожидает 3. Если пропуск не закрыт, требуется восстановление сеанса через Rebirth по описанным правилам.
Размер окна выбирают для реальных задержек сети и инфраструктуры. Для архива и для механизма правил могут требоваться разные политики использования запоздалых данных. Их нужно согласовать явно, а не просто сортировать всё по времени получения.
В приёмке проверяют перестановку, окончательный пропуск и переход 255→0. Ожидаемый результат — корректная обработка последовательности без ложного восстановления на каждом запоздании. Успешная передача по одной теме не подтверждает порядок всего Edge-потока.
Основание — Eclipse Sparkplug Specification 3.0.0, 2022-11-16, физические страницы PDF 44, 52, 53, 74. Пример описывает проектную проверку; конкретные broker, gateway и Host не испытывались. Поддержка этой версии каждой реализацией требует подтверждения.
Запросы отправляются на наш e-mail из вашей почтовой программы.
