Любой хороший совет для форматирования TCP-пакетов?

Question

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

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

В начале я отправить строку в следующем формате:

##measurementTime#AccelerationX#AccelerationY#AccelerationZ 

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

Я думал о XML, но он добавляет большую нагрузку, которую я, конечно, хотел бы избежать (измерения отправляются каждые 100-250 мс).

Answer 1

Одна рекомендация посылает простые пары ключей/значений, если вам нужно полностью придерживаться потока текстового типа ASCII. Ключевое имя используется для описания имени поля, что каждое значение передает аналогично оригинальное предложение:

##keyName1=value1#keyName2=value2# 

В качестве альтернативы, вы можете отправить данные в двоичном формате тегированные, такие как это:

<tagCodeNum><lengthInBytes><tagValueAsBytes> 

где tagCodeNum, возможно, является байтом или словом, а длина - байтом или словом в зависимости от ваших потребностей. Идея этого формата заключается в том, что получатель может распознавать поля, которые он понимает по коду, а затем также пропускает теги, которые он не знает, как декодировать. Таким образом, кодирование становится расширяемым. Если вам нужно несколько тегов, сгруппированных в логические сообщения, я бы обернуть группу этих двоичных закодированных в общей иерархии сообщения:

<messageCodeNum><lengthInBytes><tag><tag><tag> 

Если выше тег является тиражированием предыдущей конструкции тега описан выше, и длина описывает длина байта всех тегов, объединенных вместе.

Примечание. Если вы думаете об этой структуре, то не намного отличающейся от структуры типа XML, но она намного более сжата и ограничена, поэтому ее почти тривиально расшифровывать.

Answer 2

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

Вы могли бы сделать что-то в той мере, в следующем:

п байт начинаются + размер
˝n˝ Время BYTE
2-8 байт х
2-8 байт у
2-8 байт z

Answer 3

думать о чем-то оптимизированном:
- отправить только разницу с предыдущим значением;
- время от времени отправьте полный кадр;
- не используйте xml, сделайте определение своей структуры;

Answer 4

Я хотел бы построить на InSciTek Jeff's answer немного. Это то, что известно более широко как кодировка длины тега. Идея - это первый код: тег, он рассказывает вам, как интерпретировать значение. Второй код: длина, в котором указано, сколько байтов в этом значении. Это отличный способ сделать расширяемую двоичную кодировку и много используется в кодировании MPEG.

Я хотел бы добавить в несколько более советы/требований на хорошем функциональном бинарного протокола:

1. включать номер версии в каждом сообщении, что государства версию протокола для сообщения
2. кодируют каждый мульти -байт в network byte order
3. внимательно рассмотрите размер каждого поля
4. рассмотрим возможность использования многобайтовой схемы кодирования для целых чисел: я не могу найти хорошую ссылку, но идея i s, что верхний бит равен 1, если больше байтов и 0, если это последний байт, а младшие семь бит в каждом байте содержат значение.
5. упаковать все на проволоке как байты и никогда структуры

Первый действительно важно. Более важно, чтобы вы планировали изменения и тщательно определяли, как изменится протокол. Клиенты не должны пытаться интерпретировать сообщение, если они не поддерживают номер версии. НИКОГДА!

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

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

Answer 5

Я думал об XML, но он добавляет много нагрузки

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