Сериализация данных для реализации протокола

Question

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

bytes 1-2         -> stx bytes
bytes 3           -> mesg type
bytes 4-5         -> size of pay load
bytes 6-...       -> pay load bytes (unsigned bytes)
bytes ... - ...+1 -> checksum from byte 3 - ...
bytes ...+2       -> end byte

. Пример выше - переменный размер полезной нагрузки, но некоторые сообщения также имеют фиксированный размер.

Я проверил библиотеку сериализации, а именно «буферы протокола» для этой цели, но я пришел к выводу, что protobuf не вызывает претензий, поскольку используемые типы вариантов изменяют сериализацию данных. подобные библиотеки существуют, но я не уверен, что их можно использовать для этой цели (плоские буферы, cap'n proto).

Итак, есть ли рамки для определения структур интерфейса и генерации соответствующего кода ( структуры данных + синтаксический анализатор + сериализатор, с поддержкой нескольких языков, если это возможно ) для определенного интерфейса?

Или какой наилучший подход вы бы предложили для этой цели?

Answer 1

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

Если вы можете, лучше начать со схемы для протокола (например, файл .proto для буферов протокола Google или файл .asn для ASN.1, et c. многие из них на выбор), определяя сообщения, которые вы хотите обменять, а затем используйте выбранные вами средства технологий сериализации (например, protoc для GPB, asn1c для ASN.1, et c) для генерации кода.

Эта схема будет определять содержимое байтов "полезной нагрузки" в вашем примере, и вы оставите это на усмотрение GPB или чего-либо еще, чтобы решить, как передать тип сообщения, размер и длину для вас. Различные технологии сериализации имеют разные возможности в этом отношении. В GPB вы бы использовали структуру oneof, чтобы объединить все различные типы контента, который вы хотите отправить, в одну структуру, но GPB не разграничивает различные сообщения в сети (вы должны добавить это самостоятельно, возможно, с помощью отправка сообщений с использованием ZeroMQ). Несколько форматов проводов ASN.1 делают разграничение между различными сообщениями, избавляя вас от беспокойства (полезно при необработанном соединении потока) XML также разграничен. Я не думаю, что Cap'n Proto делает разграничение.

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