я работаю

Большие накладные расходы. Плохо подходит для случая с большим количеством параметров

что такое «большое количество параметров»?

Насчёт большого количества параметров не понял. Суйте в paiload хоть картинки

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

передать один бит — это сильно

Если у меня 200-500 параметров, то биты складываются в байты

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

Кому? Всем подписчикам? Одному? Ждать подтверждения? Ну и от кого то же было бы неплохо знаиь

ну и да, что такое «прошлый раз?»

В предыдущем блоке данных

MQTT не специфиицирует формат передаваемых данных

передавай свои битмаски, в чем проблема

Кто работает под clion?

чувак

Я работаю

я работаю

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

Ааа! Я понял. Вы хотите от протокола транспортного уровня решения для протокола уровня приложения.

Чем тогда его преимущество перед TCP? Там я и передаю что мне нужно

в том, что протокол реализует Pub/Sub, контролирует фрейминг, соединение и QoS

Чем тогда его преимущество перед TCP? Там я и передаю что мне нужно

Большое количество накладных расходов у tcp

Большое количество накладных расходов у tcp

А mqtt передается силой мысли?

поверх tcp

А mqtt передается силой мысли?

:) разница будет ощутима если у вас 40 подписчиков в разных сетях

поверх tcp

Точнее поверх ip

Ну и еще вопрос, часто ли вы встречали случай с несколькими подписчиками? И правильно ли я понял, чо в случае с несколькми подписчиками устройство передает данные всем подписчикам. особенно это будет удобно при медленной связи

Точнее поверх ip

Или все-таки TCP/IP?

Ну и еще вопрос, часто ли вы встречали случай с несколькими подписчиками? И правильно ли я понял, чо в случае с несколькми подписчиками устройство передает данные всем подписчикам. особенно это будет удобно при медленной связи

Этим занимается брокер. Отдельно с стоящий сервер.

QoS для IOT надо делать на стороне оператора сети, а не протокола.

короче, основная тема mqtt в том, что ты подписываешься, а потом у тебя дергается callback когда данные приходят. Ну и на другой стороне ты просто отправляешь данные и они доходят всем заинтересованным. + есть брокер, который умеет роутить сообщения

Ну и еще вопрос, часто ли вы встречали случай с несколькими подписчиками? И правильно ли я понял, чо в случае с несколькми подписчиками устройство передает данные всем подписчикам. особенно это будет удобно при медленной связи

любой случай, когда к серверу подключено больше одного устройства

QoS для IOT надо делать на стороне оператора сети, а не протокола.

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

это и делается на стороне оператора

да с чего бы

вот у тебя девайс, у него очередь на отправку, у него дернулись две публикации, какой пакет ему первым в очередь ставить?

Обе вместе. В одной публикации. Т.е. накладные расходы будут больше данных

ну окей. В очереди висит 10 сообщений, отправляются примерно раз в секунду. Появилось еще одно сообщение с большим приоритетом. Их тоже все вместе отправлять?

«оба вместе» приоретизация так не работает

и о каких накладных расходах ты все время говоришь

Или все-таки TCP/IP?

Да, ты прав. Че-то меня переклинило. Но mqtt все равно лучше для маааленьких букашек

было бы еще в MQTT еще RPC

я понимаю, что это Telemetry Transport

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

Все это заливается на сервер. На сервере есть возможность смотреть графики, делать экспорт в CSV итд.

главное, не забывать цепь смазывать периодически

вы реально этими битовыми масками-то сколько сэкономили?

Раза 4 минимум.

я так понимаю, большая чать полей — это 1-4 байта

Где-то так. До 8

а сколько типов полей?

Фиг знает.. Штук 30-50

и сколько данных за раз передается?

всмысле сколько типично полей обновляется за квант передачи

Зависит поведения системы. В покое может почти ничего не меняться (10%), в динамике процентов 50%.

а как вообще параметры группируются? Есть какой-то таймер, который смотрит, что поменялось и отправляет пачку?

Просто раз в секунду или реже. Параметры могут приходить, например раз в 10 мс. Но отправляем реже.

ну то есть у вас раз в секунду отправляются около 20-и параметров в среднем по 4 байта, т.е. около 80 байт. Если бы вы запаковали это во что-нибудь стандартное типа протобуфера или msgpack, то получилось бы порядка 200 байт. Точно ради экономии 100 байт стоило писать велосипед?

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

окей, msgpack для вас идеальный вариант

как раз для динамических данных

Получится сложнее и медленнее.

все ясно

Объясняю. Проблема 1. Надо передавать не только данные но их отсутвие.

у вас соединение висит, запили keepalive какой-нибудь и будет уверенность, что данных нет

Надо уметь быстро извлекать конкретное поле из фрейма. В случае msgpack надо будет распарсить все даныне с начала фрейма. У меня можно на основе битовой маски

ERROR: S client not available

так а что в битовой маске лежит, как из нее достать смещение поля?

Это другое. Вот есть у меня температура ОЖ, количество бензина и заряд батарейки. В каждую секнду может поменяться любой парметр. Но меняются они редко. Поэтому, если не менялись, то и не предаются.

да, это понятно

Для этого и битовая маска. В ней для отсутвующих полей ставится ноль.

и это тоже понятно

но как из флага в битмаске получить позицию параметра в посылке?

В случае msgpack все равно придется передавать признак.

в msgpack это будет map и каждому параметру свой ключ соответствует

Есть массив размеров полей. Придется в цикле просумировать.

я согласен, что msgpack линейно парсится, но там парсинг не сильно дольще будет, чем расчет смещения циклом по массиву размеров полей

ну и да, парсится-то это все на сервере

Серверу тоже тяжело

у вас миллион пользователей?

вангую что это шина данных между мозгами автомобиля

Например, пользователь может попросить построить график по параметру за неделю. Надо будет распарсить 500 000 записей

вангую что это шина данных между мозгами автомобиля

Между мозгами там другое. Но это тоже делаем

но они же уже были переданы на сервер и лежат в бд, при чем тут протокол?

В бд раскладывать не хочется. Это ещё тормознее

Либо во что-то колоночное

и где у вас данные в итоге лежат?

Сейчас в виде отдельных файлов. И сервак который их отдает. Агрегаты в базе

у меня всё…

Будем переделывать. Набираем разработчика

https://habrahabr.ru/company/oleg-bunin/blog/329062/

Я в курсе. Но есть и минусы этих подходов.

Друзья. Тут кто-то хотел много интересных докладов на встрече и все такое.

Я что-то не наблюдаю желающих докладики докладывать.

Друзья, готова программа докладов на встречу в рамках ITGM #11: 28 октября, Петербург. 12:00 - 12:45 Кирилл Тихонов (Navico) - "Вычисления на этапе компиляции для микроконтроллерного кода." Кирилл покажет как можно было раньше и можно теперь переносить часть дорогостоящих вычислений из микроконтроллера на персональный компьютер на этапе компиляции. 45 минут 13:00 - 13:45 Павел Курочкин (GenRnD.ru) - "Рассказ про новинки с Embedded Linux Conference Europe 2017 " Павел поделится впечатлениями от выставки Embedded Linux Conference Europe 2017, расскажет о новинках и тенденциях в разработках встраиваемых систем. 45 минут 15:00 - 15:45 Строков Андрей (2600) - "Избавиться от проводов за 60 минут" Мастер-класс с антеннами, кабелями и нескучными картинками, чтобы почувствовать запах эфира, разобраться, почему большая антенна — не всегда хорошо, а маленький импеданс — не всегда непонятно. Как разводить платы, чтобы запеленговать самолет и как принять вайфай из соседнего города. 45 минут 16:00 - 16:45 Круглый стол - "Тендеции развития IoT" 45 минут Полная программа и регистрация: http://embedded.group/

Где вас можно посмотреть в онлайне?

Научно-технический центр “Протей”, Санкт-Петербург, инженер-программист C++, зарплата от 90к на руки Ищем инженера-программиста в отдел, занимающийся программной поддержкой железок собственной разработки (http://protei-st.ru/products/mks/): реализация высокоуровневого API, системных утилит, драйверов. Область деятельности: телефония традиционная, нетрадиционная и VoIP. Минимальные навыки: - C++ (в т.ч. C++11) и C, системы контроля версий (работаем с svn, mercurial и git) - понимание сетевой модели OSI и умение работать с сокетами через POSIX API - эксперт в администрировании локалхоста Будет плюсом: - python - опыт написания юнит-тестов - опыт работы с микроконтроллерами/DSP - знания в области цифровой обработки сигналов - опыт работы с alsalib Условия: - команда 3-4 человека - белая зарплата по ТК РФ с регулярным пересмотром - ДМС, полностью оплачиваемый больничный - гибкий график О компании: - разработка и производство аппаратно-программных телекоммуникационных решений (x86, arm, fpga) - 250+ сотрудников, 15 лет на рынке - средний возраст сотрудников компании - 28 лет - офис в 10 минутах от метро «Выборгская» - у большинства разработчиков в компании Linux на десктопе (в команде - у всех), да и разрабатываем под Linux Резюме слать сюда: physical_ci@protei.ru. Могу ответить на любые вопросы и в личку (@picokun) или даже тут (я рядовой программист в отделе). P.S. В отделе с секретами не работаем, форм допуска ни у кого нет, так что можно свободно выезжать заграницу :)

Но что такое «нетрадиционная телефония»?