Протокол ответа IoT-запроса

Ответ 1

^{" one-size-fits-all" может звучать как "умный" слоган для футболок, но вызывает кошмар для попыток ex-post, чтобы исправить плохо спроектированные архитектуры - как только масштаб реализаций реального мира}
_{стратегии для достаточно-достаточного дизайна имеют гораздо лучший шанс пережить шкалы IoT и поддерживать приемлемую стоимость адаптации (возьмите только масштабы недавнего обновления прошивки VW для глобального устройства, ожидаемого примерно -2,5 % -3,0% неблагоприятное воздействие ВВП на Германию и автомобильные цепи поставок в Венгрии и бывших регионах Чехословакии - Да, co $t $имеет значение в домене IoT больше, чем просто тривиальное число $.) < суб >}

Интеллектуальный инструмент для специфической для домена архитектуры IoT является обязательным

Первое, что следует иметь в виду, - это тот факт, что IoT-домен на несколько порядков отличается от шкал классических архитектур устаревших вычислений. Минимизированные локальные ресурсы (по дизайну, также упомянутые выше), массовые шкалы/счета с неконтролируемым concurrency, огромные сложности синхронизации для true parallelism (if такой дизайн системы необходим), ref.: a PARALLEL v/s CONCURRENT SEQUENTIAL Ссылка на неоднозначность.

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

В то время как AMQP и другие инструменты power-MQ отлично подходят для брокерских (если хорошо спроектированы, центральный MQ-брокер не должен быть одиночной точкой отказа и остается "просто", узкое место в производительности) накладные расходы для архитектур с IoT-устройствами должны быть тщательно проверены, насколько это возможно.

Безредукторный ZeroCopy, ZeroSharing, ZeroBlocking, ZeroLatency _{(... почти)}

Пока AMQP открыл двери для брокерских полномочий хорошо известного ZeroMQ, то же самое произошло еще дальше, когда Martin SUSTRIK переопределил правила и пришел с nanomsg.

nanomsg, помимо того, что переносимость и легкая масса или просто достаточная весовая нагрузка создают хороший кандидат, готовый для моделей IoT, предоставляя вам Проект гораздо больше, чем запрошенный REQ/ REP _{, где необходимо} - более продвинутое поведение, равно как SURVEY _{один запрос, все голоса}
BUS _{децентрализованная маршрутизация}
или PIPE _{направленная односторонняя труба} особенно привлекательна в распределенных композициях процесса в массивных сенсорных сетях и прекрасный пример

Ответы для ad-hoc добавлены вопросы:

A1: Да, если требуется архитектура проектирования, RPC может использовать одну и ту же единую сигнальную структуру (не изобретать колесо или добавлять только один-распределенный слой только для Remote Proceducer Call

A2: Да, ZeroMQ и аналогичная без посредников платформа с нулевой задержкой nanomsg от Martin SUSTRIK хорошо подходят для межсетевых обменов/служб сигнализации. Дизайн вашего верхнего уровня решает, будут ли эти силы использоваться в любом месте, где бы они ни находились, с полным потенциалом ^{(ужасно magnific)} или терялись в неэффективных шаблонах использования. Чтобы иметь представление об их ограничениях, потоки событий FOREX выполняют ложные взрывы события с тиснением времени меньше микросекундного разрешения. Там вам действительно нужна фреймворк, то есть robust _{(для обработки таких взрывов)}, fast (чтобы не добавлять ненужные задержки), эластично linear-scaleable (с внутренними способностями балансировка нагрузки по требованию во многих случаях). После практического опыта я могу подтвердить, что мое собственное творческое творчество (хотя оно высоко оценено и проверено на местах с многолетним успешным достижением проекта в списке) очень ограничивающий фактор для пользователей, а не интеллектуальные структуры ZeroMQ/nanomsg.

A3:Да, в течение нескольких лет уже используется ZeroMQ (в настоящее время выполняются адаптеры DLL/LIB для порта nanomsg) для удаленного (сбалансированного по нагрузке) центрального ведения журнала (минимальное время ожидания с минимальным временем ожидания, возможности распределенных агентов). Если ваш системный диапазон не растет в пространстве (где задержки в оба конца легко за считанные минуты) этот modus operandi - это умный и рядом с "just- достаточно" идеалов.

Ответ 2

В соответствии с вашим требованием к протоколу запроса/ответа с легким весом для IoT, CoAP (http://coap.technology/), стандарт IETF может быть полезно. Это легкий вес, и вы можете создавать сервисы RESTful поверх него.

Другая вещь, которую стоит рассмотреть, - это "модель данных" и "служебные интерфейсы" для вашего сервера. Выбор стандартного протокола связи, такого как HTTP, MQTT, CoAP, важен, но не менее важно выбрать стандартную модель и интерфейсы данных совместимых датчиков, чтобы ваше приложение могло взаимодействовать и не требовалось беспокоиться, что он скоро устареет. Возможно, будет рассмотрен открытый API-интерфейс Geospatial Consortium (OGC) SensorThings (http://ogc-iot.github.io/ogc-iot-api/). Это открытый стандарт, и эта модель данных основана на ISO 19156 Observation and Measurement.

Ответ 3

Я мог бы предложить использовать AMQP, если одно из ваших требований - шаблон запроса/ответа. Протокол AMQP поддерживает этот шаблон изначально с помощью механизма корреляции между ответом на запрос. В вашей среде вы можете попытаться использовать Apache Qpid Proton в C, в конечном итоге, все доступные языковые привязки, такие как Java (для Android-системы).

Ответ 4

Для тех, кто уже использует связь MQTT и хочет получить запрос/ответ по своей службе, вы можете попробовать ответчик (https://github.com/netbeast/replyer), которая является стратегией по структуре и протоколу MQTT, а не новой.

Ответ 5

Я бы посоветовал не создавать собственный протокол, но использовать протокол LoraWAN, который уже содержит протоколы join/accept (то же, что и запрос/ответ).

Здесь спецификация протокола LoraWAN - страница 47 описывает join/accept.

Ответ 6

В принципе, rpc и передача сообщений функционально эквивалентны, поскольку я считаю, что это было официально доказано профессором Нидхемом в Кембридже еще в 70-х годах. Как вы говорите, MQTT обладает некоторыми хорошими транспортными свойствами, предназначенными для небольших расстояний, с перебоями с подключением.

Точка о RPC - это то, что позволяет использовать синхронный однопоточный стиль программирования. Однако, если вы используете Android, маловероятно, что вы действительно будете готовы к пользовательскому интерфейсу, чтобы синхронно ждать завершения RPC. Поэтому мое личное мнение заключается в том, что мне проще использовать систему прямых сообщений, такую ​​как MQTT, и отслеживать состояние транзакции, как вы хотите, (конечный автомат, переменная состояния и т.д.).

Что касается не игрушечных примеров пользовательского интерфейса на основе MQTT, вы можете проверить нашу платформу http://www.thingstud.io. При использовании нескольких устройств MQTT это не проблема, так как пользовательский интерфейс даже не знает, разговаривает ли он с одним или несколькими устройствами.

Mike

Ответ 7

Невозможно говорить с другими протоколами, но MQTT имеет некоторые функции, которые вы можете захотеть изучить:

Если вы просто пытаетесь выяснить, подключено ли устройство или нет, вы можете использовать функцию 'last will' для отправки предопределенное сообщение о тайм-ауте или отключении. Используя это и Уровни качества обслуживания, вы должны иметь возможность отслеживать состояние устройства достаточно, чтобы узнать, принимаются ли ваши сообщения или нет, а затем отслеживать каналы публикации с устройств для обработки ответов.

Ответ 8

Если вам нужен только протокол запроса/ответа, вы можете пойти для CoAP (http://coap.technology/), это похоже на HTTP и имеет HTTP-глагол поддержка.

MQTT попадает под паб-югу. Идеальный разговор требует третьей машины, на которой работает брокером MQTT.