Request response MQTT5: связать ответ с нужным запросом

Запросить

Диспетчер одновременно запрашивает диагностические сведения у нескольких шлюзов. Ответы приходят в другом порядке, а часть может задержаться после переподключения. Если связывать их только по очередности, приложение покажет результат чужой операции. Нужен явный контракт запроса и ответа с проверяемой корреляцией и сроком ожидания.

Описать используемые свойства

MQTT5 предусматривает Response Topic и Correlation Data для соответствующего обмена. (OASIS — MQTT Version5.0, Standard2019-03-07) Поддержку свойств проверьте в обеих библиотеках и на промежуточном пути. Само наличие полей не создаёт готовую службу ответов: прикладной получатель должен реализовать согласованное поведение.

Определите, что означает ответ: получение запроса, завершение чтения или выполнение действия. Для статьи используйте безопасное чтение диагностики. Управляющая команда требует отдельного проектного контракта и не должна становиться обычным тестовым пакетом при проверке корреляции.

Создать различимые запросы

На учебной системе отправьте два запроса с собственными неповторяющимися в нужной области идентификаторами. Сохраните адресата, ожидаемый ответ и момент окончания ожидания. Не используйте краткий счётчик процесса без определения поведения после его перезапуска и возможного повторного использования значения.

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

Два условных запроса А и Б получают ответы в порядке Б, затем А. Перекрёстные связи сопоставляют каждый ответ с исходным запросом по Correlation Data. Отдельно проверяются источник, смысл результата, срок ожидания, поздний ответ, дубликат и поведение при restart инициатора.
Учебное сопоставление не зависит от очередности доставки. Корреляция работает вместе с идентичностью отвечающего компонента и определённым смыслом ответа; поздний или повторный результат не закрывает новую операцию автоматически.
Увеличить схему
Два условных запроса А и Б получают ответы в порядке Б, затем А. Перекрёстные связи сопоставляют каждый ответ с исходным запросом по Correlation Data. Отдельно проверяются источник, смысл результата, срок ожидания, поздний ответ, дубликат и поведение при restart инициатора.

Обработать поздний и повторный ответ

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

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

Проверить права и наблюдаемость

Для темы ответа подтвердите необходимые права публикации и подписки в своей реализации. Не выдавайте всем узлам широкие полномочия ради удобства теста. В журнале достаточно корреляции и статусов без секретов доступа; исходные технические события сохраняйте с происхождением времени.

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

Все разборы