Протокол для надёжной передачи больших (16-32Кибибайт) объёмов данных через ZigBee

Кибибайт

Тебя кто укусил?

стандарты

Ухо режет :) Фи! В документации к чему то да, смысл может и есть, но в обиходе нафик нада. Ибо под кило подразумеваются киби в любом случае ибо кило`,байтов в реальном мире не существует по сути, а если и так то кило выглядит универсальнее если к примеру мы обсуждаем двоичные и троичные системы к примеру не говрить же постоянно кибибайты и китрибайты или китетрабайты всё можно назвать билобайты и всё понятно )))

По теме ничего не скажу, сорян. Испаряюсь пшшш пук!

Modbus TCP подобный придумать, чтоб с заголовком и с CRC.

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

лучше кибибайты, китрибайты и китетрабайты. Иначе непонятно, сколько байтов в твоём билобайте: 1000, 1024 или 729 (или 625, если дойдём до пятеричной). Как тонна в США может быть 1000 кг, а может быть 907.

Нужно передать набор измерений через ZigBee, то, что в нормальных сетях передавалось бы по TCP

Вот это не то?

https://www.digi.com/resources/documentation/digidocs/90001537/references/r_t...

лучше кибибайты, китрибайты и китетрабайты

Ну, да, но… килобайтов же не существует, это всегда в контексте двойки когда говорим о байтах, а если что-то альтернативное будет то в контексте этой альтернативности всё будет.

Мы же все говорим «У меня давече был канал 2 Мегабита» а не «У меня был давече канал 1,90735 Мебибита»

Но! в доках конечно лучше писать точно. Тут, да. Спору нет и быть не может

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

Вот значит откуда у кибибайт ноги растут, ну тогда пожалуй ОК, пусть будут.

Вот значит откуда у кибибайт ноги растут, ну тогда пожалуй ОК, пусть будут.

Фанаты кибибайтов говорят что ло в килобайтах от слова лох :D

Я так не думаю.

килобайтов же не существует, это всегда в контексте двойки когда говорим о байтах

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

Ну, да, но… килобайтов же не существует, это всегда в контексте двойки когда говорим о байтах, а если что-то альтернативное будет то в контексте этой альтернативности всё будет.

В том-то и дело, что не всегда. Например, жёсткий диск, как правило, измеряется в килобайтах (которые 10^3) измеряется, также как и скорость в килобитах.

Мы же все говорим «У меня давече был канал 2 Мегабита»

И подразумеваем 2 миллиона битов в секунду, а не 2097152.

гига и терабайты.

Это привычно, это маркетинг. И это и так понятно что реальные числа соответствуют разрядности машины. Говорить кило универсальнее и правильно для любой системы в любой разрядности, говорить киби правильно только в отношении двоичных машин что по сути и правильно и быть так должно. Но сук как же это режет ухо бррррр. Было бы бикибайты, бимибайты во! было бы хоть прикольно ))

Но как бы я не бомбил киби это правильно

И правда… Чёйто я привязался к разрядности конечной машины. Проехали ничё ник то не слышал я ничё не говрил.! А то меня Антошки затролят :D

Хватит оффтопить! :)

Протоколы для надёжной передачи сообщений - JMS, AMPQ, MQTT (начиная с версии 5). Не знаю, что такое ZigBee, но оно маленькое и щупленькое, значит смотреть MQTT, который широко применяется в интернете вещей. Надёжность в этих протоколах достигается за счёт того, что клиент оповещает отправителя, что получил сообщение, а отправитель хранит сообщение, пока не получит это подтверждение. В MQTT это есть начиная с версии 5, но пока ещё наиболее распространена версия 3.1, в которой посылку подтверждения надо программировать самостоятельно.

Посмотрел, есть ли поддержка MQTT для ZigBee. Нашлась программа zigbee2mqtt (мост от ZigBee к MQTT), которую можно использовать для «координатора» ZigBee например CC2531, если его подсоединить по USB к устройству вроде Raspberry Pi (сгодится маленькое Raspberry Pi Zero W), на него установить какой-нибудь MQTT broker (сервер сообщений MQTT), например Mosquitto.

Если вместо Raspberry Pi уже есть устройство, на которое можно устанавливать программы, то узнать, есть ли для него MQTT broker-ы.

Забыл. Для популярных микроконтроллеров есть клиентские библиотеки MQTT, поэтому наверно не обязательно подсоединять «координатор ZigBee» к Raspberry Pi, а сервер MQTT может быть ещё где-нибудь.

Нужно передать набор измерений через ZigBee, то, что в нормальных сетях передавалось бы по TCP

Ну так и гоняй TCP/IP, в чём пробема-то? Посмотри на SLIP, сделай как там, только поверх своего ZigBee.

ЗЫ: за «киби"мерзость - луч кровавого поноса. Вместо того, чтобы вздрючить маркетологов, использующих 1000 вместо положенной в IT 1024, придумали какое-то мерзкое дерьмище.

Ну так и гоняй TCP/IP, в чём пробема-то?

память жалко :) оно на чем-то уровня Cortex M0 со 160КиБ оперативки будет гоняться с одной стороны. TCP в теории может влезть, но там есть чем другим полезным память занять, да и влом

Вместо того, чтобы вздрючить маркетологов, использующих 1000 вместо положенной в IT 1024, придумали какое-то мерзкое дерьмище.

Тебе было бы удобнее, если бы модем был не на 28,8 Kbps, а 28,125? Всё-таки, когда нужно прикинуть количество бит/байт, то на 1000 гораздо проще умножать, чем на 1024 (до тех пор, пока мы числа пишем в десятичной записи, а не в шестнадцатеричной).

Так что это IT'шники как американцы и британцы для тонны придумали свое собственное определение общеупотребимому термину. Поэтому и придумали «кибибайт», «бинарный килобайт», «программистский килобайт», ...

память жалко :)

Ну если достаточно адресации 802.15.4 в оставь только TCP. Запихивай TCP header + data в 802.15.4 пакеты. Оверхеда 20 байт, зато кучу готовых проверенных реализаций можно использовать. Плюс получишь возможность использовать номер порта для чего-нибудь типа разделения двух датчиков сидящих на одном ZigBee передатчике. Если порты не нужны, можно выкусить, сэкономишь 4 байта.

Тебе было бы удобнее, если бы модем был не на 28,8 Kbps, а 28,125?

Во-первых, не вижу никакой разницы между этими двумя совершенно не круглыми цифрами. какое-нибудь 433.92 меня совсем не напрягает, почему 28.125 должно?

А во-вторых, на самом деле, со скоростями в _битах_ множители изначально происходят от частот, а не от объёмов данных, и, в общем-то, для скоростей есть хотя бы какое-то реальное основание использовать 1000 в качестве множителя.

Но вот касаетельно объёмов данных в _байтах_ - это натуральное извращение. А чо тогда байт не сделать равным 10 битам? Ненуачо, 8 же как-то некругло, непонятно.

Всё-таки, когда нужно прикинуть количество бит/байт, то на 1000 гораздо проще умножать, чем на 1024 (до тех пор, пока мы числа пишем в десятичной записи, а не в шестнадцатеричной).

Ведь гораздо легче прикинуть сколько бит в 123 байтах, если байт это 10 бит, а не 8.

А сходу сообразить сколько будет 32 по 256 байт в этих ваших хипстерских килобайтах по 1000 байт - тоже проще?

Поэтому и придумали «кибибайт», «бинарный килобайт», «программистский килобайт», ...

А других килобайтов и не бывает. Тут всё насквозь пронизано степенью двойки, так что от этого никуда не денешься. В любом случае эта *би срань до сих пор не прижилась, и наверно никогда не приживётся, несмотря на старания.

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

То есть, предлагаешь для объёмов использовать с множителем 1024, а для скоростей в 1000? Типа для передачи 1 мегабайта по линии со скоростью один мегабайт в секунду требуется 1,049 секунды?

Тут всё насквозь пронизано степенью двойки

Не всё, а только хранение в оперативной памяти.

Запихивай TCP header + data в 802.15.4 пакеты

А что это будет за протокол? Явно же не TCP. Для того чтобы быть как TCP нужен как минимум хендшейк + секвенсы + еще куча всего.

Тогда уж лучше приклеивать UDP header и вручную контролировать ретрансмиты и дубли, будет хоть честный UDP. А может быть есть какой-то простенький reliable UDP, не надо будет пердолиться вручную

А что это будет за протокол? Явно же не TCP.

Очевидно, будет именно TCP. Просто TCP/ZigBee вместо TCP/IP. Никто же не запрещает TCP использовать поверх других протоколов вместо IP.

Для того чтобы быть как TCP нужен как минимум хендшейк + секвенсы + еще куча всего.

Ну так у тебя в TCP header как раз всё есть для этого. Берёшь любой понравившийся TCP/IP стек, выкидываешь оттуда всё, что относится к IP и оставляешь только TCP. TCP пакеты выдаваемые стеком просто запихиваешь не в IP а во фрейм ZigBee. И наоборот, из полученного ZigBee фрейма достаёшь TCP пакет и отдаёшь своему TCP стеку. Вот оно у тебя и хэндшейк, и секвенсы и всякие ACK c RST сделает. В итоге со стороны программы получишь банальный TCP сокет.

Тогда уж лучше приклеивать UDP header

Так тебе же нужен с гарантированной доставкой пакетов. Вот уровень TCP тебе его и обеспечит.

Никто же не запрещает TCP использовать поверх других протоколов

никто, но зигби обычно пихают на железки, которые TCP в принципе не потянут.

но если в данном случае потянут, то я бы завел 6lowpan вместо zigbee.

То есть, предлагаешь для объёмов использовать с множителем 1024, а для скоростей в 1000?

Для всего что байты - только 1024. Для всего остального - 1000.

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

Ты читать написанное умеешь? Я специально выделил _биты_ и _байты_. Скорость каналов связи - она традиционно в _битах_, вообще-то. И вот 10 мегабит = 10000000 бит в секунду даёт тебе максимум 1.192 нормальных мегабайта в секунду. На самом деле, для, например, TCP/IP через Ethernet добавляется ощутимый оверхед, и скорость передачи данных оказывается далеко не круглым образом связана со скоростью битового потока в канале, так что ты вряд-ли получишь 1.192, а скорее что-то типа «от 0.8 до 1 мегабайта в секунду».

Так что как ни считай, скорость передачи данных всё равно очень криво, а часто и вообще только приблизительно связана со скоростью канала.

Не всё, а только хранение в оперативной памяти.

Вообще-то практически всё, что имеет дело с байтами. От размеров блока на диске до размера трансфера DMA например.

никто, но зигби обычно пихают на железки, которые TCP в принципе не потянут.

Да с чего не потянут-то? Там вообще ничего сложного и никаких мегабайтов памяти не надо. Десяток флагов обрабатывать, считать пакетики, дожидаться/посылать ACK, можно даже без буфера и без упорядочивания пакетов обойтись, хотя с ними будет удобнее.

TCP очень простой протокол, размер TCP/IP стеков связан вовсе не с самим TCP, а с IP с его DHCP,DNS,маршрутизацией и прочей сопутствующей хренью.

но если в данном случае потянут, то я бы завел 6lowpan вместо zigbee.

А вот это как раз большой оверхед будет.

Берёшь любой понравившийся TCP/IP стек, выкидываешь оттуда всё, что относится к IP и оставляешь только TCP

TCP очень простой протокол

А. Ясно.

Для нынешних хипсторов 30 страниц крупным шрифтом, половина из которых в данном случае вообще не нужны, из RFC793 - это сложно?

Ну тады ой.

и правильного порядка

Отправляющий и получающий узлы связаны через сенсорную беспроводную сеть с множеством узлов?

TCP очень простой протокол, размер TCP/IP стеков связан вовсе не с самим TCP, а с IP с его DHCP,DNS,маршрутизацией и прочей сопутствующей хренью.

Если в добавок для экономии памяти ограничить буфер макс. размером одного пакета, то можно отбросить алгоритм подбора оптимального буфера передачи с учётом текущей потери пакетов. Также можно отбросить сортировку пакетов: любой пришедший вне очереди отбрасывается, т.к. его некуда сохранить. Тогда возникает вопрос: а в чём отличие от UDP с добавленным последовательным packet ID + ACK? На первый взгляд только отсутствием handshake. Но в зависимости от требований ТС, возможно, и без него удастся обойтись.

можно отбросить алгоритм подбора оптимального буфера передачи

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

О том и речь.

а в чём отличие от UDP с добавленным последовательным packet ID + ACK?

connection state. Для гарантированной доставки это полезно. Но это не главное. Выкинуть ненужное из готового исходника стека TCP несколько проще чем добавить это всё в UDP, да ещё и отладить потом.

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

Пока так и делаю (uIP из состава contiki-os), но памяти так мало, что вот-вот придётся отключить... TCP целиком. Т.к. устройство всё равно только в локалке используется.

Для нынешних хипсторов 30 страниц крупным шрифтом, половина из которых в данном случае вообще не нужны, из RFC793 - это сложно?

Там 85 страниц, и то только потому, что всякие RFC2018 и RFC5681 вынесены.

TCP очень простой протокол

                              +---------+ ---------\      active OPEN
                              |  CLOSED |            \    -----------
                              +---------+<---------\   \   create TCB
                                |     ^              \   \  snd SYN
                   passive OPEN |     |   CLOSE        \   \
                   ------------ |     | ----------       \   \
                    create TCB  |     | delete TCB         \   \
                                V     |                      \   \
                              +---------+            CLOSE    |    \
                              |  LISTEN |          ---------- |     |
                              +---------+          delete TCB |     |
                   rcv SYN      |     |     SEND              |     |
                  -----------   |     |    -------            |     V
 +---------+      snd SYN,ACK  /       \   snd SYN          +---------+
 |         |<-----------------           ------------------>|         |
 |   SYN   |                    rcv SYN                     |   SYN   |
 |   RCVD  |<-----------------------------------------------|   SENT  |
 |         |                    snd ACK                     |         |
 |         |------------------           -------------------|         |
 +---------+   rcv ACK of SYN  \       /  rcv SYN,ACK       +---------+
   |           --------------   |     |   -----------
   |                  x         |     |     snd ACK
   |                            V     V
   |  CLOSE                   +---------+
   | -------                  |  ESTAB  |
   | snd FIN                  +---------+
   |                   CLOSE    |     |    rcv FIN
   V                  -------   |     |    -------
 +---------+          snd FIN  /       \   snd ACK          +---------+
 |  FIN    |<-----------------           ------------------>|  CLOSE  |
 | WAIT-1  |------------------                              |   WAIT  |
 +---------+          rcv FIN  \                            +---------+
   | rcv ACK of FIN   -------   |                            CLOSE  |
   | --------------   snd ACK   |                           ------- |
   V        x                   V                           snd FIN V
 +---------+                  +---------+                   +---------+
 |FINWAIT-2|                  | CLOSING |                   | LAST-ACK|
 +---------+                  +---------+                   +---------+
   |                rcv ACK of FIN |                 rcv ACK of FIN |
   |  rcv FIN       -------------- |    Timeout=2MSL -------------- |
   |  -------              x       V    ------------        x       V
    \ snd ACK                 +---------+delete TCB         +---------+
     ------------------------>|TIME WAIT|------------------>| CLOSED  |
                              +---------+                   +---------+

                      TCP Connection State Diagram
                               Figure 6.

Обведи, пожалуйста, на этой диаграмме, что из этого просил ТС.

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

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

TCP очень простой протокол, размер TCP/IP стеков связан вовсе не с самим TCP, а с IP с его DHCP,DNS

Я не эмбедщик, но мне теперь любопытно - там прикладные протоколы, инкапсулированные в UDP, считаются частью IP-стека или это просто Stanson в ударе?

Обведи, пожалуйста, на этой диаграмме, что из этого просил ТС.

Эта диаграмма типа теперь сложно? Ты вообще какой-нибудь USB, который в каждом втором МК крутится видел? Или так, теоретик?

оставить просто синхронный ACK на каждую датаграмму.

Этого мало. Нужно ещё как-то обозначать начало и конец передачи и все возможные варианты обрыва связи.

И да, конечно, обязательно реализовать его через кастрацию TCP-стека, никак иначе.

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

Пипец у тебя советы.

Практические у меня советы.

Я не эмбедщик,

С этого и надо было начинать. Не эмбедщик, ни разу ничего не делал, что из себя на самом деле представляет TCP/IP стек ни разу не видел, но в педивикии прочитал, что TCP сложный протокол.

но мне теперь любопытно - там прикладные протоколы, инкапсулированные в UDP, считаются частью IP-стека или это просто Stanson в ударе?

Ты хоть в сырцы какого-нибудь uIP или lwip загляни, чисто для собственного развития. Может закончишь теоретизировать и до тебя дойдёт, например, что голый IP вообще мало кому нужен. К нему внезапно паровозом идёт ARP, DHCP и DNS как минимум, чтобы те самые IP как-то получать, анонсировать и резолвить в них имена.

Зачем zibee? Поставь ESP-шку с вайфаем и передавай через TCP/IP…

Если уж так хочешь странного - вот тебе: https://github.com/contiki-ng/contiki-ng

Не смог ответить, зачем ТСу все это непрошенное барахло и перешёл на личности? Урезонил так урезонил, я же, отрок зарвавшийся, компьютер на картинке только и видел.

Не смог ответить, зачем ТСу все это непрошенное барахло

Очевидно, для «надёжной передачи больших (16-32Кибибайт) объёмов данных». TCP предназначен именно для этого и является одним из старейших, популярнейших и проверенных временем протоколов.

и перешёл на личности?

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

компьютер на картинке только и видел.

Примерно так и есть. Слышал что-то про протоколы, возможно даже модель OSI вызубрил, а технически даже не представляешь, как на самом деле обстоят дела, и как это всё практически может выглядеть на какой-нибудь конкретной железке.

«Ссышься» только ты. Я просил тебя обвести те состояния, которые нужно реализовать для задачи ТСа. Но ты и сам знаешь, что не можешь, вот и бесишься.

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

Здорово, правда?

ЗЫ: за «киби"мерзость - луч кровавого поноса. Вместо того, чтобы вздрючить маркетологов, использующих 1000 вместо положенной в IT 1024, придумали какое-то мерзкое дерьмище.

Вообще как раз все правильно. ВЕСЬ МИР использует «кило» в значении 1000, и только айтишники с синдромом утенка требуют, что это было 1024

«Ссышься» только ты. Я просил тебя обвести те состояния, которые нужно реализовать для задачи ТСа.

Ты даже не понял о чём речь. ТСу не нужно ничего реализовывать, потому что это всё уже реализовано многократно. ТСу надо просто взять готовое.

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

Ошибка твоя в том, что знания твои чисто теоретические. Достаточно было твоего «но мне теперь любопытно - там прикладные протоколы, инкапсулированные в UDP, считаются частью IP-стека...». Сразу понятно, что слышал звон, да не знаешь где он. Отрыв теории от реальности и всё такое.

Ваше мнение очень ценно для нас. Мы обязательно примем его к сведению. Ждём ваших предложений по введению 10-битового байта, весь мир пользуется же десятичной системой счисления, и только айтишники с синдромом утёнка требуют чтобы в байте было 8 бит.

Что к чему? «Кило» - это десятичная приставка, «киби» - двоичная. Какая здесь может быть дискуссия?

Что к чему? «Кило» - это десятичная приставка

Ну так 1024 и есть 2^10. Всё более чем десятично.

«киби» - двоичная.

Это ваше «киби» придумано какими-то упорышами совсем недавно, исключительно чтобы отмазать мошенников-производителей HDD. Никому кроме этих упорышей и их безмозглых подпевал это «киби» нахер не упёрлось и никто его в здравом уме не использует.

Приставки от 210 до 260 (киби, меби, гиби, теби, пеби, эксби) были предложены шведским учёным Андерсом Тором и введены Международной электротехнической комиссией (МЭК) в 1999 году во второй поправке к стандарту IEC 60027-2

И прекрати хамить и истерить, пожалуйста.

Вообще-то, если Вы внезапно не в курсе, к 1999 году компьютерная индустрия насчитывала без малого 55 лет. И абсолютно всех устраивало, что «кило» применительно к байтам означало исключительно 2^10.

Зато как раз в это время пышным цветом расцвело мошенничество с объёмами жёстких дисков.

И тут, внезапно, высасываются из пальца и пропихиваются в стандарты все эти дебильные «*би». Лишь бы производителям HDD не пришлось платить неустойку обманутым покупателям.

И прекрати хамить и истерить, пожалуйста.

Если Вам что-то там показалось - креститесь, говорят, помогает.