Comments 19
На git-е eclipsa лежат исходники клиента MQTT-SN с примерами.
Не могли бы вы предоставить ссылку?
Что мешало просто просыпаться, передавать 1 UDP пакет и засыпать?
Протокол, например, такой:
struct
{
int device_id;
int value;
}
Протокол, например, такой:
struct
{
int device_id;
int value;
}
Вы, видимо, не очень хорошо себе представляете конкретно протокол UDP и протоколы общения прикладного уровня вообще.
Для первого необходимо реализовать подтверждение доставки как минимум.
Для второго поверх UDP вам нужны ещё и механизмы аутентификации, иначе к вам начнут прилетать пакеты непонятно откуда, но вы им будете верить. Я уже не говорю о том, что сообщения явно бывают разные, и тут начинаются все прелести самописных протоколов.
Для первого необходимо реализовать подтверждение доставки как минимум.
Для второго поверх UDP вам нужны ещё и механизмы аутентификации, иначе к вам начнут прилетать пакеты непонятно откуда, но вы им будете верить. Я уже не говорю о том, что сообщения явно бывают разные, и тут начинаются все прелести самописных протоколов.
Я довольно хорошо представляю как устроен UDP. Если вы сомневаетесь в этом, прошу привести обоснованные аргументы.
Автор также использует UDP, и не ждет подтверждения доставки. Только вместо самописной структурки, что я привел как пример, он использует реализацию MQTT. Он вынужден использовать чужой брокер, вместо простейшего UDP сервера, который пишется за 10 минут.
Что касается аутентификации, то достаточно подписывать цифровой подписью данные в пакете. Если приватный ключ скрыт (а он будет скрыт в защищенной флеш-памяти STM), то никто не сможет подделать сообщения.
Автор также использует UDP, и не ждет подтверждения доставки. Только вместо самописной структурки, что я привел как пример, он использует реализацию MQTT. Он вынужден использовать чужой брокер, вместо простейшего UDP сервера, который пишется за 10 минут.
Что касается аутентификации, то достаточно подписывать цифровой подписью данные в пакете. Если приватный ключ скрыт (а он будет скрыт в защищенной флеш-памяти STM), то никто не сможет подделать сообщения.
Простейший Udp сервер реально пишется быстро. Простейший. А затем приходит очередь писать клиентов, да под разные платформы. Да интегрировать это всё. И встаёт вопрос — что выгоднее — свой протокол и вся инфраструктура или готовый протокол и готовая инфраструктура? Даже с учётом того что пришлось собирать rsmb — для меня ответ очевиден, подняв брокера я получаю доступ к куче готового софта ( на самостоятельное написание которого потратил-бы не один месяц ).
Согласен по поводу UDP, я пропустил пример его использования в статье.
Автор уже ответил по причинам выбора протокола MQTT, и я не могу его осуждать после того, как пришлось самому писать реализацию своего протокола. После анализа трудозатрат и выгоды я почти убедил менеджмент в отказе от него.
Автор уже ответил по причинам выбора протокола MQTT, и я не могу его осуждать после того, как пришлось самому писать реализацию своего протокола. После анализа трудозатрат и выгоды я почти убедил менеджмент в отказе от него.
Именно это я и сделал после сборки платы. Процесс написания своего тестового сервера и клиента доказал мне всю глупость ( по крайней мере в этом конкретном случае ) этой затеи.
Собственно передача с QoS -1 и подразумевает описанное действие — проснулся, обработал, отправил и заснул. Просто данные обёрнуты в пакет позволяющий использовать готовую инфраструктуру MQTT-SN.
Вы упомянули разницу UDP и TCP, и мне вот стало интересно, а насколько часты сейчас потери пакетов?
вроде бы все растет в сторону надежности.
вроде бы все растет в сторону надежности.
Для первого необходимо реализовать подтверждение доставки как минимум.
У автора как раз и используется UDP что бы не было заморочек с гарантированностью доставки, клиенты не ждут сервер — «дорого».
Аутентификация сигнала в таком контексте завершается на цифровой подписи, максимум.
Вопрос «обжимки» с непонятным устройством конечно более серьёзный
А CoAP рассматривали? http://coap.technology
Есть RFC: 7252. Нативно применяется UDP.
Есть RFC: 7252. Нативно применяется UDP.
Возник вопрос. Как по мне, то подъем GSM канала съедает столько энергии, что стоит ли уже, в этом случае, заморачиваться c передачей данных через UDP?
Зависит от модели использования.
Если поднимать канал раз в 24 часа и сбрасывать расходомер — большой роли TCP | UDP не играет. Включил питание модуля — отправил ( получил подтверждение если TCP ) — выключил питание модуля.
Если-же раз в минуту поднимать датчик давления 4-20, оцифровывать и отсылать — время нахождения модуля в активном режиме играет большую роль. Тогда чем дольше будет спать GSM-модуль — тем дольше проживёт устройство. Естественно в этом случае модуль не рубиться по питанию но отправляется в сон.
Если поднимать канал раз в 24 часа и сбрасывать расходомер — большой роли TCP | UDP не играет. Включил питание модуля — отправил ( получил подтверждение если TCP ) — выключил питание модуля.
Если-же раз в минуту поднимать датчик давления 4-20, оцифровывать и отсылать — время нахождения модуля в активном режиме играет большую роль. Тогда чем дольше будет спать GSM-модуль — тем дольше проживёт устройство. Естественно в этом случае модуль не рубиться по питанию но отправляется в сон.
А не ставили ли натурный эксперимент, по сравнению экономности работы комплекса в целом, при работе через UDP и TCP? Я, конечно, до сравнений и сам доберусь… Просто это будет много позже. А результат, как в известной рекламе про зайцев и батарейки, интересен уже ;)
Нет, поскольку для меня ответ очевиден. Может быть позже, когда соберу установочную партию.
UFO just landed and posted this here
Т.е. сначала тезируется отсутствие разницы — затем выражается возмущение о расположении сервера и связанными с этим задержками TCP? Это как? Для того мне и нужен UDP что-бы не думать о задержках подтверждения.
Из готового барахла — а продемонстрируйте-ка свою работу. Как одиночки а не части команды. Моя вот
Из готового барахла — а продемонстрируйте-ка свою работу. Как одиночки а не части команды. Моя вот
Sign up to leave a comment.
О пользе стандартизации