Обсуждение AdHoc бинарный протокол.

[cheblin]

Продолжаем развивать проект. Произошел небольшой ребрендинг.
Сменилось название на AdHoc protocol. Полностью переписан код. Добавлено куча новых фич. Теперь поддерживается кодогенерация обработчика AdHoc протокола на C, C++, Rust, C#, Kotlin, Typescript языках.

А это значит что теперь можно организовать эффективный обмен между микроконтроллером, код для которого будет сгенерирован на C, C++ или Rust и клиентом, код для которого будет например на Typescript для работы в браузере.

Не нужно больше тратить ресурсы и память микроконтроллера на HTTP сервер - достаточно его минимальной иммитации для переключением в websocket и дальше полностью бинарный протокол.
Либо вообще отказаться от HTTP.

Документация и пошаговая инструкция в процессе написания.
Проект обзавелся AdHocAgent - аплодером описания протокола, поддерживается 3 типа протокола.
Система уже развернута и готова к работе.
На возможные глюки и сбои постараемся быстро реагировать.
Будут вопросы пишите тут, пишите там.

 

[pvvx]

Не нужно больше тратить ресурсы и память микроконтроллера на HTTP сервер - достаточно его минимальной иммитации для переключением в websocket и дальше полностью бинарный протокол.

Каким образом HTTP жрет ресурсы? Это не HTTPS.
Ресурсы выедает стек TCP/IP, а не HTTP.
Минимальный стек TCP/IP для включения устройства в глобальный инет без внешнего брандмауэра только на удержание TIME_WAIT составляет от сотен кбайт. А ещё буфера самого стека + сокетов.. и IPv6
В итого - реализация обработки минимальных HTTP запросов затрачивает не более 1..5% ресурсов.
И вы с этими долями процентов боритесь?

Либо вообще отказаться от HTTP.

Где альтернатива?
------
Для BLE mesh AdHoc пока годится только для мигания одним светодиодом... При наличии то в пакете всего десятка свободных байт лишняя кодировка ещё уменьшает объем и, следовательно трафик и возможности.
Для маяков, где нет обратной связи нужен протокол с синхронизацией и защитой шифром...

 

[cheblin]

Каким образом HTTP жрет ресурсы?

а когда приходится при приёме строки в целевые циферки парсить...а при отправки наоборот...
а когда необходимо лепить все эти заголовки в соттветсвии стандарту
и память под кода поддержки всего этого хозяйства не ресурс?

собственно и необходимость в HTTP, по сути , НЕТ, если б не повсеместное распространение браузеров как универсальное средство доступа к информации.

Либо вообще отказаться от HTTP.
Где альтернатива?

если хватает соображалки сделать специализированного клинета, то и хорошо.

Для BLE mesh AdHoc пока годится только для мигания одним светодиодом... При наличии то в пакете всего десятка свободных байт лишняя кодировка ещё уменьшает объем и, следовательно трафик и возможности.
Для маяков, где нет обратной связи нужен протокол с синхронизацией и защитой шифром...

вот этого не понял.

 

[pvvx]

а когда приходится при приёме строки в целевые циферки парсить...а при отправки наоборот...
а когда необходимо лепить все эти заголовки в соттветсвии стандарту
и память под кода поддержки всего этого хозяйства не ресурс?

Уже указал - это всё не превышает 1% от ресурсов идущих на TCP/IP стек.
К примеру - пока ни один ESP не в состоянии поддерживать рабочий (строго по спекам) TCP стек. Оно просто в него не лезет.

собственно и необходимость в HTTP, по сути , НЕТ, если б не повсеместное распространение браузеров как универсальное средство доступа к информации.

Про это и разговор - где альтернатива?
Из наблюдающегося пока растет только Web Bluetooth.

вот этого не понял.

Это относится к возможным применениям "AdHoc бинарный протокол".
Если не понятно, то значит "AdHoc бинарный протокол" - это типа игры в java у её фанатов, без разбора реальностей применения.

 

[cheblin]

это всё не

остаётся верить

Про это и разговор - где альтернатива?

специализированные под задачу клиенты. сетевые приложения иначе говоря.

игры в java у её фанатов, без

понятнее не стало. причём тут java? использование её

 

[pvvx]

вот тут статья по теме
только не зацикливайтесь на выносе интерфейсов, как это со всеми происходит.

По поводу зачем и что мысли почти правильные в указанной статейке...
Но вот ответ индустрии:

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

понятнее не стало. причём тут java? использование её

cheblin/AdHocLessons :
"Открыв среду разработки необходимо придумать название и создать новый JAVA проект. Определившись c пространством имен, создадим в папке исходников проекта соответствующую иерархию. Затем, в этой иерархии, в кодировке UTF8 создадим обычный java файл с информативным названием."

 

[pvvx]

понятнее не стало. причём тут java? использование её

Ну не мне же вам писать инструкцию: Сериализация и десериализация данных используется для обмена между узлами (хост/узел/устройство/блок)…
Для создания кода вам потребуется изучить JDK 8, Intellij IDEA, ...
На таком уровне я разговаривать не собираюсь
Рассмотрите области применения.

 

[cheblin]

cheblin/AdHocLessons :
"Открыв среду разработки необходимо придумать название и создать новый JAVA проект. Определившись c пространством имен, создадим в папке исходников проекта соответствующую иерархию. Затем, в этой иерархии, в кодировке UTF8 создадим обычный java файл с информативным названием."

теперь понятно. java искользуется как DSL исключительно, ну и ещё есть либа при кодогенерации в Kotlin.
всяко получше чем XML править, как некоторые... да и все удобства IDE сразу на борт. рафакторинг, навигация...ля-ля

Но вот ответ индустрии:

всё так. только код писать всё равно придётся.

 

[cheblin]

Ну не мне же вам писать инструкцию: Сериализация и десериализация данных используется для обмена между узлами (хост/узел/устройство/блок)…
Для создания кода вам потребуется изучить JDK 8, Intellij IDEA, ...

Для создания кода ОПИСАНИЯ ПРОТОКОЛА.

не нужно изучать JDK 8. её нужно установить. и JAVA учить не нужно, если только не планируете писать под android
не нравится IDEA - используйте любой любимый редактор кода. notepad/vim ...etc

 

[cheblin]

вот тут сгенерированные сишные исходнирки первого урока, java там не наблюдается. там же рядом C++ и Rust

 

[pvvx]

всё так. только код писать всё равно придётся.

Но у каждого современного устройства уже есть готовый протокол. Для BLE туда уже входит ID номер и стек. (В основном стек при соединении...). Следовательно ID устройства в протоколе AdHoc - это лишняя информация. И так по многому.
Моду, какой протокол будет задаем не мы, а крупные корпорации и наличие дешевых микросхем на рынке...
На сегодня для сферы "для дома, для быта" развивается BLE mesh. У него лимитированные по размеру сообщения. Как и любых BLE маяков.
AdHoc имеет динамическую длину пакета, что не очень-то согласуется с такими протоколами... Ну и городить свой надпротокол...
Основная проблема со всем этим - не кодировка пакетов, а стандарт связей. Пока ни один роутер не умеет связывать BLE с инетом и полное отсутствие интерфейса для этого...

 

[pvvx]

вот тут сгенерированные сишные исходнирки первого урока, java там не наблюдается. там же рядом C++ и Rust

Вы наверно опять не поняли. На данном форуме 90% не могут поставить Arduino и выясняют какая нужна версия чтобы по нажатию единственной капы вылезло не "ЕГГОГ".
Понять и использовать то, про что вы пишите смогут от силы десяток участников данного форума.
Мне без разницы какой язык программирования (и сленг ) - я в этой теме ещё до 1980 года...

 

[cheblin]

Следовательно ID устройства в протоколе AdHoc - это лишняя информация. И так по многому.

это не ID устройства, это ID пакета

Моду, какой протокол будет задаем не мы, а крупные корпорации и наличие дешевых микросхем на рынке...

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

На сегодня для сферы "для дома, для быта" развивается BLE mesh. У него лимитированные по размеру сообщения. Как и любых BLE маяков.
AdHoc имеет динамическую длину пакета, что не очень-то согласуется с такими протоколами... Ну и городить свой надпротокол...

этот мир не ограничен одним BLE mesh

AdHoc имеет динамическую длину пакета, что не очень-то согласуется с такими протоколами... Ну и городить свой надпротокол...

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

Ну и городить свой надпротокол...

каждый производитель железок с дистанционным управлением вынужден например

 

[pvvx]

вот тут сгенерированные сишные исходнирки первого урока, java там не наблюдается. там же рядом C++ и Rust

Как хорошо всё начиналось - для устройств с малыми ресурсами, и на тебе - C++ и Rust и ещё сотни кило -> Сразу отрежем все BLE на много лет вперед...

 

[cheblin]

не могут поставить

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

я в этой теме ещё до 1980 года...

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

 

[pvvx]

этот мир не ограничен одним BLE mesh

В курсе - последние 27 лет занят пром.контроллерами...
Не вижу там AdHoc.
Вижу специально не совместимые ни с кем проприетарные протоколы... и , всеудовлетворяющий 'досихпор' Modbus во многих реинкарнациях...

 

[cheblin]

ну да, AdHoc протокол по вертикали интересен не только электронщикам, но и тем кому к примеру в web, gson на что нибудь поприличнее нужно заменить.
а Modbus - это та самая, жопа-соловей на бесптичи. ах, да....и ещё MQTT

 

[pvvx]

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

А я за применимость.
USB так-же подходит для сериализации... и там так-же фиксированная длина пакета (при уменьшении - бесполезные потери времени и трафика)

 

[pvvx]

и ещё MQTT

Это мертворожденный промежуточный выкидыш со скоротечным жизненным циклом...
Но роутеры c BT (детские примеры) уже используют именно его для связи сетей.

 

[cheblin]

А я за применимость.

да банальный вездесущий UART. это ж очевидно. под это дело в AdHoc и специальный канал сделан

To transmit data via the radio channel / raw UART, use AdvChannel type entity. It builtin byte stuffing framing to fast recover after channel failure and CRC.
If data are sending over secure transport or if AdHoc used as a serialization tool of the program data in a file, the StdChannel type is using.​