Советы по построению байтового протокола

Question

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

Какие-нибудь советы при построении протоколов на низком уровне? .. Например:

• Используйте 2-байтовый заголовок, чтобы отправить длину сообщения перед байтами данных.
• Использовать схему проверки CRC / данных. (Как мне это сделать? Какие-нибудь простые контрольные суммы?)

Answer 1

Это зависит от характеристик QoS (качества обслуживания) базового транспортного уровня.

Если базовый канал является надежным, то CRC, вероятно, является избыточным (при условии, что некоторая форма проверки целостности выполняется на нижнем уровне протокола).

Если вы спрашиваете от как до отделить вашу полезную нагрузку от потока байтов, то есть несколько возможностей, одна из которых может быть просто BASE64 кодировать / декодировать ваш поток. Опять же, в зависимости от ваших требований, BASE64 может привести к слишком большим накладным расходам.

Конечно, вы всегда можете использовать HEADER (уникальная последовательность + длина полезной нагрузки + CRC) с низкой вероятностью появления в вашей полезной нагрузке, но затем вам нужно применить скремблер к своей полезной нагрузке, чтобы минимизировать вероятность дублирования вашего заголовка и т. Д.

---

Если вы хотите создать протокол для ненадежного ориентированного на поток байтов прокотола, то зачем изобретать велосипед? Почему бы не использовать что-то вроде PPP?

Answer 2

1. Подумайте разумно и обо всех случаях, прежде чем устанавливать структуру.
2. Сделайте заголовок немного больше, даже если отправите в нем ноль байтов.
3. Разделите заголовок на несколько частей. Это, конечно, зависит от ваших требований, например, байта управления, байта длины сообщения, байта формата ... и т. Д.

О контрольной сумме, зависит от базового протокола. Но вы можете реализовать его самостоятельно. Encrypt, Hash, Crunch, Flip, 2s Дополнить сообщение и сохранить результат в одном контрольном байте

Answer 3

Значительная часть зависит от того, что предусмотрено на нижних уровнях . Вот примеры, объясняющие, почему я считаю значительным:

• Однажды я принимал участие в реализации протокола ITU H.223. Хуже всего было то, что поток данных мог быть основан даже на байтовом или битовом потоке, а нижние уровни НИЧЕГО не обеспечивали, кроме необработанных битов. Протокол имеет несколько возможных уровней в зависимости от требований к надежности и функциональности транспорта для верхних уровней.

• Другим примером является протокол ITU H.225 по TCP, где передача была надежной, но это был поток байтов. Так что ДОЛЖНА быть реализована хорошая логика разграничения сообщений.

• Ну, SIP на основе UDP. Дейтаграммы. Очень полезно. Но много проблем было связано с надежностью обмена сообщениями. Таким образом, последовательность и отслеживание запросов / ответов (транзакция, этап ...) были очень значительными.

• ОК, по некоторым причинам мы использовали протокол RPC. Хорошо, если ты ленивый. Некоторые ограничения связаны с логикой приложений, но я бы посоветовал взглянуть на это даже для изучения.

• НАСА IPC - это то, на что я смотрел не так давно. Хорошо, очень просто связано с верхними слоями. Но это централизованно, что является ограничением.

Еще один ключевой момент: Вы должны разработать протокол, исходя из своих потребностей ( проанализировать требования верхнего уровня ). Что бы вы дали со знанием CRC-32 - лучший способ защитить целостность данных, а не анализировать, если вам действительно нужно это сделать (как пример)?

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

Answer 4

Подумайте внимательно, можете ли вы иметь удобочитаемый протокол
Тогда подумайте, можете ли вы использовать сжатие вместо необработанного bianry