Обработка протоколов
От: удусекшл  
Дата: 13.11.19 08:19
Оценка:
Здравствуйте!

Есть куча всякой периферии. Общение идет по CAN, RS232/UART, RS422/485, TCP, UDP и тп. Протоколы обычно совсем разные, но иногда — схожие, отличающиеся только нюансами способа передачи. Бывает peer-2-peer, бывает один-ко-многим. Один-ко-многим подразумевает мастера, слейвы только отвечают. Если peer-2-peer, или, как в CAN — коллизии разруливаются аппаратно — тогда слейвы могут асинхронно генерить сообщения.

Да, у протоколов может быть, а может не быть — адресация. Там, где транспорт обязывает иметь адрес для каждого пакета CAN/UDP, протокол пользуется средствами транспорта. Если это что-то типа RS232/UART, RS422/485, то адрес добавляется в посылку данных. peer-2-peer соединения могут быть установлены с использованием адреса один раз, и далее какая-либо адресация пропадает. Или не пропадает.

Хочется как-то более менее универсально описать всё это так, чтобы для добавления нового протокола (или способа использования существующего поверх другого транспорта) нужно было бы дописать самую малость — чтобы как из кубиков составлялось — просто заменил парочку и всё работает. Ну, и хочется, чтобы ранее написанный код от такой подмены не переставал работать, а без вопросов переехал бы на новый протокол/транспорт.

В принципе, кое-какие мысли есть, но буду рад всем идеям.

Пока затык вот такой сейчас. Как бы задание адреса сделать? Варианты примерно такие (терминологию/имена взял из API сокетов)
  1. sendTo, recvFrom и адрес куда/откуда
  2. send, recv — без адреса
  3. sendTo, recvFrom и опциональный адрес
  4. адрес отправки и адрес, откуда пришло — задавать/получать условно перед/после отправкой/приемом через опции сокета
  5. UPD — в перечисленных случаях подразумевалось, что полезная нагрузка — сообщение — передается туда-сюда как набор байтов. Есть еще вариант оперировать объектами Message, предоставляющими интерфейс IMessage, который в себе инкапсулирует и адрес и данные, и черта в ступе по желанию. Но это как-то не очень удобно начинает получаться, на мой взгляд
  6. UPD2 — адрес можно передавать вместе с данными — байтовый массив — префикс длинной N, где N зафисит от конкретного протокола
  7. еще варианты?

В целом, конечно, предлагаю обсудить не только описанный нюанс, но и вообще подобную архитектуру в комплексе

UPD По поводу адресов. Обычно это однобайтные значения. Но, если транспортом будет UDP, там уже как минимум 4х-байтный IPv4, а вообще адрес может быть произвольного размера. И тут не совсем понятно, то ли делать как в сокетах — гибко, но неудобно, то ли использовать только 32битное целое и считать, что его хватит всем, то ли совместить оба подхода перегрузками.
Отредактировано 13.11.2019 12:06 удусекшл . Предыдущая версия . Еще …
Отредактировано 13.11.2019 9:00 удусекшл . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.