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

cheblin

Member
Продолжаем развивать проект. Произошел небольшой ребрендинг.
Сменилось название на 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

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

собственно и необходимость в HTTP, по сути , НЕТ, если б не повсеместное распространение браузеров как универсальное средство доступа к информации.
Либо вообще отказаться от HTTP.
Где альтернатива?
если хватает соображалки сделать специализированного клинета, то и хорошо.

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

pvvx

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

собственно и необходимость в HTTP, по сути , НЕТ, если б не повсеместное распространение браузеров как универсальное средство доступа к информации.
Про это и разговор - где альтернатива?
Из наблюдающегося пока растет только Web Bluetooth.
вот этого не понял.
Это относится к возможным применениям "AdHoc бинарный протокол".
Если не понятно, то значит "AdHoc бинарный протокол" - это типа игры в java у её фанатов, без разбора реальностей применения. ;):)
 

cheblin

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

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

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

pvvx

Активный участник сообщества
вот тут статья по теме
только не зацикливайтесь на выносе интерфейсов, как это со всеми происходит.
По поводу зачем и что мысли почти правильные в указанной статейке...
Но вот ответ индустрии:
upload_2019-12-9_0-15-16.png
И в дальнейшем каждый обычный выключатель света и т.д., может иметь на борту сенсорный монитор с датчиками приближения и прочего...
понятнее не стало. причём тут java? использование её
cheblin/AdHocLessons :
"Открыв среду разработки необходимо придумать название и создать новый JAVA проект. Определившись c пространством имен, создадим в папке исходников проекта соответствующую иерархию. Затем, в этой иерархии, в кодировке UTF8 создадим обычный java файл с информативным названием."
 

pvvx

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

На таком уровне я разговаривать не собираюсь :)
Рассмотрите области применения.
 

cheblin

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

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

cheblin

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

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

pvvx

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

pvvx

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

cheblin

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

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

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

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

pvvx

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

cheblin

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

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

pvvx

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

cheblin

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

pvvx

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

cheblin

Member
А я за применимость.
да банальный вездесущий 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.​
 
Сверху Снизу