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

[pvvx]

@cheblin - C новым, 2020 годом!
И подарочек: Рецензия к AdHoc (необходимо вписать в Redme.md на github ).

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

Абревиатура ‘Ad Hoc’ подразумевает способ решения специфической проблемы или задачи, которая не адаптируется для решения других задач. Т.е. AdHoc протокол не приспособлен для понижения нагрузки на реальные каналы связи и требует дополнительных ресурсов у обменивающихся устройств или блоков.

Единственная цель AdHoc – это перевод описания структур обмена на язык Java с последующим генератором кода кодека (парсера - синтактического анализатора преобразующего входные данные в структурированный формат, и кодировщика - обратное действие) на несколько языков высокого уровня с предоставлением лицензии на программное обеспечение по подписке (SaaS).

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

 

[pvvx]

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

 

[pvvx]

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

 

[pvvx]

И возвращаясь к теме подарочка на Новый Год для @cheblin :
Раз влипли и хотите сделать инструмент – необходимо учесть описанные выше подсказки. Ждем раздачи готовых подарочков (нормального инстрeмента) на новый Новый Год.

 

[cheblin]

И возвращаясь к теме

во-первЫх, спасибо за антиРецензию. Это всяко лучше любого никролога.

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

уважаемый pvvx за создаваемый Вами контент, и код респект Вам и Уважуха!

но когда Вы начинаете что либо писать про AdHoc - Вас буддто подменяют, создаётся ощущения что у Вас угнали аккаунт...

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

Обругать многочисленых пользователей Google Protocol Buffers, у которого ТОЧНО ТАКАЯ ЖЕ ИДЕОЛОГИЯ, дураками... аргументация так себе.
Ибо сразу возникает вопрос - а ты кто такой....

Отличие AdHoc от - Google Protocol Buffers - исключительно в имплементации.
В AdHoc, в качестве DSL НЕ JAVA выбрана, а JAVA ЯЗЫКОВЫЕ КОНСТРУКЦИИ ... с которыми знакомы значительное число пользователей, и которая имеет ЛУЧШУЮ поддержку в большинстве IDE. Значительно лучшею чем Protocol Buffers lang.

Рантайм AdHoc в десятки раз меньше Protocol Buffers, а а функционала больше.
Официальной С-ишной версии Protocol Buffers так и нет, неофициальные весии убоги, тяжеловесны и неэффективны.
Какое либо портирование Protocol Buffers на восьмибитные МК с 2к оперативы невозможно, в отличии от AdHoc.

Примеры рабочего кода, и ответы на вопросы ПО ТЕМЕ AdHoc ... всё будет .

 

[cheblin]

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

неправда

 

[cheblin]

Единственная цель AdHoc

лабуда

 

[cheblin]

очень большие проблемы в

бред

 

[cheblin]

начинающим программистам ещё не

ах-хаха

 

[pvvx]

Обругать многочисленых пользователей Google Protocol Buffers, у которого ТОЧНО ТАКАЯ ЖЕ ИДЕОЛОГИЯ, дураками... аргументация так себе.
Ибо сразу возникает вопрос - а ты кто такой....

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

Protocol Buffers

Время и прояснило, что это не метод.

 

[pvvx]

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

Вот так и будете дописывать поля в уже существующие типы записей... Процесс бесконечен и трудоемок. Раббота ради рабботы.
Как избавиться от этого в корне - описано ранее.

 

[pvvx]

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

В словах 'один раз' и кроются все проблемы.

При тех-же буферных протоколах есть плоские буферы. Они появились не случайно…
Всё это для обмена микросервисами, а не по физике каналов приемо-передач. Возникло от кривизны и специфики языков высокого уровня.
Притянуть это в сферу МК не выйдет. Там схема определена системой аналогичной кеш с общим буфером RAM для одновременного доступа многопроцессорного ядра системы, а каналы передачи не умеют передавать пару бит из-за кодов восстановления над блоком и аналогичной поблочной шифрации данных.

ах-хаха

Тут в точку попал
Кроме этого "ах-хаха" вам и ответить нечего и нечем.

 

[pvvx]

Справка из истории.

Modbus TCP уже являлся асинхронным и многопользовательским протоколом.

Для этого у него есть ID транзакции. Пока отрабатывается одна транзакция, в том-же канале (порту TCP) может отработать куча других.
Шлюз без проблем по номерку устройства определяет необходимый физический канал. Т.е. осуществляет роуминг.
Атомарность была ещё в Modbus RTU, но с ограничением объекта на максимальный размер пакета.

И всё это уже было при жестком формате протокола…

Как в AdHoc осуществляется роуминг и элементарная атомарность пары объектов?
В JSON это пара {}.

 

[pvvx]

Как я понял, описание полей геликоптеру в AdHoc не помогли - он сразу упал, т.к. координата, ускорение и показания магнитного компаса были сняты в разное время, как и позавчерашнее напряжение батареи, но пришли асинхронно в одно время в AdHoc формате.

 

[cheblin]

Время и прояснило, что это не метод.

время? подробнее плиз.

описание полей геликоптеру в AdHoc не помогли - он сразу упал

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

Как в AdHoc осуществляется роуминг и элементарная

с AdHoc построй себе свой modbus с блэкджэком.... и нифчём себе не отказывай.

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

 

[cheblin]

есть плоские буферы. Они появились не случайно…

??? дома также должны быть и мясные закуски!

 

[pvvx]

время? подробнее плиз.

Уже забыли что сами говорили про Google Protocol Buffers.

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

Разгребать поток будет раскаленный STM8 на форсаже?
Всё хорошо и понятно, более чем "ах-хаха" у вас доводов нет. На этом можно закончить разговор до следующей модификации AdHoc к новому Новому Году

 

[pvvx]

??? дома также должны быть и мясные закуски!

flat buffers

 

[cheblin]

flat buffers

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

что я должен понять? Ваш мега проект это собственно flat buffers? правильно?

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

но(!) пинают НЕ ИДЕЮ протобуфера, пинают имплементацию идеи от гугла,
и не просто пинают, или болеют модбасом, а создают альтернативы, на базе все тойже базовой идеи
DSL > кодогенерация > сериализация . вот гады, а!

раскаленный STM8 на форсаже

если для того чтобы работала Сишная конструкция switch на STM8 нужент форсаж - то да, на форсаже.
на самом деле нет.

 

[pvvx]

Ранее было написано такое предложение, вырванное из контекста:
При тех-же буферных протоколах есть плоские буферы. Они появились не случайно…
До этого предложения и после всё описано.
На данный обрывок, чтобы уйти от темы вы написали:
??? дома также должны быть и мясные закуски!
Вам ответил, плоские буфера – это по вашей теме и незнание что это перевод на русский flat buffers или название в других кругах. Это уже смущает и намекает на детсад по разбираемой тематике.
Далее, осознав, что гоните совсем пургу вы пишите:
ой спасибо... эта ссылка взята прям из моей документации по AdHoc протоколу..?? Но зачем?
я просто не поспеваю за такими такими прыжками мыслей, и это реально утомляет .
О каком разборе протоколов или как можно донести до вас что либо может идти разговор, если вы притворяетесь дебилом, когда вам указывают на недостатки и недоработки вашего AdHoC?
И так весь диалог.

Вот из последнего вашего ответа:
если для того чтобы работала Сишная конструкция switch на STM8 нужент форсаж - то да, на форсаже.
на самом деле нет.
Это указывает, что AdHoc рассчитан на поток до ста байт в секунду и этим ограничен? Ни о каких использованиях в современных системах или ранее сказанных – типа играх по сети где не хватает пропускной способности разговор уже не идет.
По заданному вами шаблону уклончивого дебила-коммерсанта никто с вами более диалог вести не собирается.
STM8 вы рекомендовали в начале всего разговора. Большее вам не удалось освоить на нем и остановились?
У вас есть уверенность что в него влезет приводимый вами код?
Я должен написать вам, что в роутер c потоком от 100 мбит/c мы поставим STM8... и долго ржать. Нет увольте.
Всё уже и так понятно.