caxapa.ru :: А что критиковать? В первых абзацах (втором и четвертом) - должен и должен. Т.е. самое интересное

Скрипач, пророк (05.02.2020 00:01 - 00:10, просмотров: 378) ответил Evgeny_CD на [Универсальный код для передачи по байтовым и более широким каналам связи. Часть 1] Итог многих лет моих размышлений.

А что критиковать? В первых абзацах (втором и четвертом) - должен и должен. Т.е. самое интересное - где-то далеко за скобками. Остальное... ну, вы - художник, вы видите это так. Я, для себя, разделяю все возможные протоколы связи на три класса: - обмен командами - обмен данными - файловый обмен. Вы, как я понял, видите себе универсальный комбайн? А он вам такой действительно нужен? (мне - нет) Сыр-бор из-за файлового обмена? А может проще от него отказаться? (заменить пересылкой данных, атомарных?) Ближайший реальный файловый обмен - вычитка архивов из устройств по Modbus. Видел нестандартные реализации. Грубо, маппинг файлов на адресное пространство регистров. Не сказать что чем-то объективно лучше-хуже. Но как подход - передача сложных сущностей поверх более простых, мне кажется разумным.

... но не любой ценой.

Ответить

- Спасибо! Здесь тот же подход. Вопрос в выборе набора "базовых сущностей", поверх которых будет жить все остальное. Вот это важно обсудить. - Evgeny_CD(05.02.2020 00:14)
  - Отсутствие понятия приостановление/возобновление потока мне кажется существенным отличием. Просто высокоуровневые потоки живут в другом измерении, по отношению к низкоуровневым. Скрипач(388 знак., 05.02.2020 00:26 - 00:34)
    - Предельная эффективность - 87.5% от полосы. Это разумная плата за детерминизм. Можно сравнить с идеей "маскирования" байтов. Evgeny_CD(303 знак., 05.02.2020 00:53)
      - А каковы основания считать что эффективность: предельна; как-то связанна? Скрипач(59 знак., 05.02.2020 08:55)
        
        Хороший вопрос, ответ на него долгий. - Evgeny_CD(05.02.2020 16:33)
        
        То что цифра с потолка - я понял. Но она сильно авышена. Скрипач(152 знак., 05.02.2020 18:07)
        
        Спасибо! Правильный вариант - перед обсуждением протокола нарисовать граф - что будем обсуждать. И вносить в него регулярно основные итоги обсуждения. Так и стоит поступить. - Evgeny_CD(05.02.2020 18:30)
        
        Задачи протокола для скоростного (на пределе канала) потока данных и протокола управления существенно разнятся, нужно сразу определиться. - VLLV(05.02.2020 20:10)
        
        +1, но там все зависимости нелинейны. Evgeny_CD(163 знак., 05.02.2020 21:17)
        
        +1 - Скрипач(05.02.2020 20:28)
      - Но есть минимальная предельная латентность из-за наличия буферов. Evgeny_CD(362 знак., 05.02.2020 00:58)
        
        А вы продумали как именно будут конкурировать высокоприортетные сообщения? Приоритеты, контроллер прерываний? :) Скрипач(80 знак., 05.02.2020 10:06)
        
        Kaк вариант -- тупо вставляется поверх низкоприоритетного (частично затирая последний). Парсер на приёмной стороне должен разобраться. - fk0(06.02.2020 11:35)
        
        Машина состояний - это хорошо, пока машина состояний не определена, разговор в общем то ни о чем, не зря описание приличных протоколов содержит графы для хоста и слейва. - VLLV(05.02.2020 02:39)
        
        Ясен пень, что это надо описывать. Но пока идет синтез идей. Evgeny_CD(66 знак., 05.02.2020 03:07)
        
        Потому, что у тебя в кучу смешались разные слои, от сериализации до канального уровня. - fk0(06.02.2020 11:36)
        
        Значит, протокол не простой. И вообще 7 уровней не зря придумывали, нужно или сливать уровни, или продумывать весь стек с инкапсуляцией и сервисом. Пока в Ваших соображениях ничего этого не нашел, а микс/спагетти не прокатит. - VLLV(05.02.2020 03:23)
        
        Да, я и сам понял, что пока все смешалось. Evgeny_CD(160 знак., 05.02.2020 03:39)
        
        Не думаю, что авторы hdlc легко с этим согласятся - VLLV(05.02.2020 05:45)
        
        HDLC нервно курит в части эффективности кодирования -> Evgeny_CD(537 знак., 05.02.2020 16:17, ссылка)
        
        Ты думаешь дураки HDLC изобретали? А я думаю, дураки те, кто не понимает, почему 0x7E. Потому, что если у тебя по-настоящему последовательный канал передачи данных, где не байты 8-битные атомарно идут, а отдельные биты, начиная с младшего и до fk0(662 знак., 05.02.2020 23:44)
        
        1) Про дураков ничего не писал 2)Хочется сделать универсального для любого канала шириной 1 байт 3)Спасибо! Столь тонкая оптимизация была оставлена на потом. Именно поэтому идея табличного кодера и декодера - чтобы можно было мапить на любые коды. Evgeny_CD(149 знак., 06.02.2020 02:30)
        
        Кстати я не прав. В PPP в качестве заголовка кадра используется последовательность 7E FF и не просто так: в бинарном виде это o01111110Po11111111P, где o -- нулевой старт-бит, P -- единичный стоп-бит. Можно показать, что 7E при любых сдвигах fk0(3987 знак., 06.02.2020 11:16 - 11:22)
- Интересно, ставил ли кто подобные задачи и как он их решал... - Evgeny_CD(05.02.2020 00:04)
  - Инкапсуляция (в пакет данных "короткого" протокола вставляется кусок файла - в моем случае строка хекс файла для обновления прошивки). Если получен корректный ответ, указатель увеличивается. - VLLV(06.02.2020 07:24)
  - Ближайшее что делал - получение отладочной информации поверх Modbus. Реализовывал через пару регистров <вирт.адрес+данные> Скрипач(248 знак., 05.02.2020 00:14 - 00:27)

Средства и методы разработки