Цель данной статьи — познакомить читателя с различными сетевыми протоколами прикладного уровня, которые используются в GPS-трекерах. Практически каждый производитель оборудования для GPS-мониторинга считает своим долгом изобрести новый протокол для взаимодействия между устройством и сервером мониторинга. Часто при разработке оных инженеры прибегают к изощренным решениям для экономии трафика или упрощения жизни разработчикам прошивки устройств.
На транспортом уровне в большинстве случаев используется TCP и иногда UDP. Сами же протоколы прикладного уровня можно разделить на две большие группы: текстовые и бинарные. В текстовых протоколах информация передается в виде ASCII кодов, и после преобразования в строку достаточно часто можно распарсить данные даже при отсутствии документации. Текстовые протоколы содержат достаточно большое количество избыточной информации, поэтому некоторые производители используют бинарные протоколы, в которых данные передаются в big-endian или little-endian бинарном формате.
В случае использования TCP перед декодированием сообщений, необходимо разбить поток данных на отдельные кадры (frame). Стандартом для текстовых протоколов считается разбиение сообщений с помощью одного или нескольких специальных символов. Самым распространенным символом, используемым в качестве разделителя, является символ перевода строки (ASCII код 0x0A). Сообщения бинарных протоколов обычно содержат заголовок фиксированной длины, который включает поле длины пакета, указывающее на размер данных, или размер всего сообщения.
Теперь рассмотрим несколько наиболее интересных нестандартных случаев.
В старой версии протокола компании Shenzhen Xexun Technology Co следом за текстовыми данными передается контрольная сумма в бинарном формате. Проблема также усложняется тем, что отсутствует какой-либо символ-разделитель. После преобразования в текст сообщение выглядит примерно следующим образом (бинарные данные обозначены символом ):
Для извлечения данных в данном случае пришлось воспользоваться избыточностью тектового формата и искать метки (длиной больше 2 символов): GPRMC и imei.
Таких протоколов достаточно много, но в большинстве случаев логика декодирования достаточно проста. Например, все сообщения могут быть фиксированной длины или длина может однозначно определяться по типу сообщения (тип сообщения содержится в фиксированном заголовке). В данном случае отличилась тайваньская компания Orion Technology, которая описывает свой протокол с помощью следующей грамматики:
Приведена только небольшая часть документа, из которой видно, что для определения длины кадра с GPS данными (TRACKING) необходимо сначала посмотреть тип всего сообщения, затем из заголовка данных взять количество различных записей (USER-LOG) и, наконец, прочитать заголовок каждой записи и просуммировать длины.
Компания Ulbotech решила, что хорошей идеей будет использование специального кода (0xF8) для разделения пакетов. Видимо, осознав позже, что в бинарных данных также может иногда встречаться данный код, они решили заменить каждое его вхождение на код из двух байтов (0xF7 0x0F). Проблема в том, что и этот код может встретиться в бинарных данных, и поэтому код 0xF7 заменяется на очередной код из двух байт (0xF7 0x00).
Для примера, если трекер присылает следующую последовательность:
то после декодирования мы получаем (разделитель удален):
Некоторые протоколы, используемые в GPS-трекерах, содержат как бинарные, так и текстовые сообщения. Примеров достаточно много, в большинстве случаев данные о местоположении передаются в текстовом виде, а в бинарном виде передается keepalive-сообщения для индикации активного соединения между сервером и клиентом.
Примером может послужить протокол под названием WondeX от тайваньской компании Wonde Proud. Keepalive-сообщение выглядит следующим образом (little-endian):
В данном случае по первому байту сообщения (код 0xD0 не может встречаться в текстовых данных) можно определить тип и дальше, в зависимости от типа определить размер кадра. В случае бинарного сообщения WondeX кадр имеет фиксированную длину, а текстовые сообщения используют перевод строки в качестве разделителя.
Определение длины кадра — это только начало. После этого необходимо расшифровать сами данные, и тут можно встретить еще больше инновационных решений. Сначала я хотел включить все в одну статью, но после написания части про фрейм-декодеры я решил, что этой информации уже достаточно для одной статьи. Буду рад услышать отзывы и узнать, имеет ли смысл писать продолжение.
Вся информация в статье была накоплена по ходу работы над сервером GPS-мониторинга. Проект Open Source, и если кому-нибудь интересно, то исходный код с реализацией протоколов можно найти на GitHub.
Также кого-то может заинтересовать коллекция протоколов для GPS-трекеров.
На транспортом уровне в большинстве случаев используется TCP и иногда UDP. Сами же протоколы прикладного уровня можно разделить на две большие группы: текстовые и бинарные. В текстовых протоколах информация передается в виде ASCII кодов, и после преобразования в строку достаточно часто можно распарсить данные даже при отсутствии документации. Текстовые протоколы содержат достаточно большое количество избыточной информации, поэтому некоторые производители используют бинарные протоколы, в которых данные передаются в big-endian или little-endian бинарном формате.
Фрейм декодеры (frame decoders)
В случае использования TCP перед декодированием сообщений, необходимо разбить поток данных на отдельные кадры (frame). Стандартом для текстовых протоколов считается разбиение сообщений с помощью одного или нескольких специальных символов. Самым распространенным символом, используемым в качестве разделителя, является символ перевода строки (ASCII код 0x0A). Сообщения бинарных протоколов обычно содержат заголовок фиксированной длины, который включает поле длины пакета, указывающее на размер данных, или размер всего сообщения.
Теперь рассмотрим несколько наиболее интересных нестандартных случаев.
Бинарные данные в текстовом протоколе
В старой версии протокола компании Shenzhen Xexun Technology Co следом за текстовыми данными передается контрольная сумма в бинарном формате. Проблема также усложняется тем, что отсутствует какой-либо символ-разделитель. После преобразования в текст сообщение выглядит примерно следующим образом (бинарные данные обозначены символом ):
111111120009,+1234,GPRMC,204530.4,A,6000.000,N,01000.6288,E,0.0,0.00,230713,0.0,E,A*3C,F,imei:123456789012345,00,,F:3.88V,0,125,,262,01,224CE1,379BДля извлечения данных в данном случае пришлось воспользоваться избыточностью тектового формата и искать метки (длиной больше 2 символов): GPRMC и imei.
Бинарные сообщения без длины в заголовке
Таких протоколов достаточно много, но в большинстве случаев логика декодирования достаточно проста. Например, все сообщения могут быть фиксированной длины или длина может однозначно определяться по типу сообщения (тип сообщения содержится в фиксированном заголовке). В данном случае отличилась тайваньская компания Orion Technology, которая описывает свой протокол с помощью следующей грамматики:
GPRS-PACKET := PKT-HEADER PKT-BODY PKT-NO PKT-CRC
PKT-BODY := (USERLOG-DATA | SYSLOG-DATA)
...
USERLOG-DATA := USERLOG-HDR USERLOG-COMMON USER-LOGS
USER-LOGS := 1*N (USER-LOG)
USER-LOG := (SPEED-ALERT | TRACKING | ...)
...
SYSLOG-DATA:= SYSLOG-HDR UNIT-ID SYSLOG-LEN ...
...Приведена только небольшая часть документа, из которой видно, что для определения длины кадра с GPS данными (TRACKING) необходимо сначала посмотреть тип всего сообщения, затем из заголовка данных взять количество различных записей (USER-LOG) и, наконец, прочитать заголовок каждой записи и просуммировать длины.
Бинарный протокол с символом-разделителем
Компания Ulbotech решила, что хорошей идеей будет использование специального кода (0xF8) для разделения пакетов. Видимо, осознав позже, что в бинарных данных также может иногда встречаться данный код, они решили заменить каждое его вхождение на код из двух байтов (0xF7 0x0F). Проблема в том, что и этот код может встретиться в бинарных данных, и поэтому код 0xF7 заменяется на очередной код из двух байт (0xF7 0x00).
Для примера, если трекер присылает следующую последовательность:
0xF8 0x00 0xF7 0x00 0xFF 0xF7 0x0F 0xF8то после декодирования мы получаем (разделитель удален):
0x00 0xF7 0xFF 0xF8Смешанные протоколы
Некоторые протоколы, используемые в GPS-трекерах, содержат как бинарные, так и текстовые сообщения. Примеров достаточно много, в большинстве случаев данные о местоположении передаются в текстовом виде, а в бинарном виде передается keepalive-сообщения для индикации активного соединения между сервером и клиентом.
Примером может послужить протокол под названием WondeX от тайваньской компании Wonde Proud. Keepalive-сообщение выглядит следующим образом (little-endian):
0xD0 0xD7 0x1A 0x01 0xC7 0x54 0x44 0x3CВ данном случае по первому байту сообщения (код 0xD0 не может встречаться в текстовых данных) можно определить тип и дальше, в зависимости от типа определить размер кадра. В случае бинарного сообщения WondeX кадр имеет фиксированную длину, а текстовые сообщения используют перевод строки в качестве разделителя.
Заключение
Определение длины кадра — это только начало. После этого необходимо расшифровать сами данные, и тут можно встретить еще больше инновационных решений. Сначала я хотел включить все в одну статью, но после написания части про фрейм-декодеры я решил, что этой информации уже достаточно для одной статьи. Буду рад услышать отзывы и узнать, имеет ли смысл писать продолжение.
Вся информация в статье была накоплена по ходу работы над сервером GPS-мониторинга. Проект Open Source, и если кому-нибудь интересно, то исходный код с реализацией протоколов можно найти на GitHub.
Также кого-то может заинтересовать коллекция протоколов для GPS-трекеров.