Андрей Власовских

Блог Андрея Власовских

Protocol Buffers и XDR

12 комментариев

Google Open Source Blog:

Protocol Buffers позволяет Вам определять простые структуры данных на специальном языке определений, затем компилировать их с целью создания классов, представляющих эти структуры в языке по Вашему выбору. Эти классы идут вместе с сильно оптимизированным кодом для разбора и сериализации Вашего сообщения в очень компактный формат.

Я пролистал документацию по мотивации, формату и API для Protocol Buffers. Формат очень напоминл мне XDR в ONC RPC. Стоило ли преподносить его с таким шумом? Шум, наверное, можно списать на резонанс в блогосфере. Меня удивила довольно небольшая доля постов, в которых вспоминают XDR или ASN.1.

Вот несколько различий между PB и XDR, которые сразу пришли мне в голову при листании доков:

  • XDR создан в Sun Microsystems в рамках Sun RPC (ONC RPC) в середине 1980-х, а PB — в Google в середине 2000-х
  • Библиотеки XDR есть практически для любого языка по разным лицензиям, а PB — только одна реализация от Google для Java, C++ и Python по Apache License 2.0
  • В IDL PB есть указатели обязательности полей сообщений, что полезно для обратной совместимости, а в XDR — нет, но есть пары «имя-значение» и объединения (unions), решающие похожие задачи
  • В XDR есть версии программ (интерфейсов) RPC, а в PB — нет
  • В PB есть строковый тип, а в XDR — нет, только массивы байтов без информации о кодировке
  • Библиотека PB (вроде бы) предполагает только генерацию кода разбора и сериализации, а для XDR есть как генераторы, так и библиотеки динамической работы сообщениями

Кажется, что оба формата сериализации одинаково эффективны с точки зрения быстродействия и пропускной способности, что оба IDL обладают близкой выразительной силой и простотой. Но XDR намного более широко известен и поддержан библиотеками. Так что всем, кто хочет использовать передачу сообщений в распределённых системах, но отвергает архитектуру распределённых объектов типа CORBA или Java RMI в пользу чистого RPC или обмена документами, а также игнорирует XML и JSON по некоторым причинам, могу посоветовать вспоминть XDR и почитать про Protocol Buffers.

Реклама

Written by vlan

2008-07-16 в 04:21

Опубликовано в Uncategorized

Tagged with , , , , , , ,

комментариев 12

Subscribe to comments with RSS.

  1. > В XDR есть версии программ (интерфейсов) RPC, а в PB — нет

    Наверное, потому что PB — формат сериализации, которая МОЖЕТ использоваться для RPC. А может использоваться для несвязанных с интерфейсами целей. В PB есть версий полей, для сохранения совместимости.

    > Библиотека PB (вроде бы) предполагает только генерацию кода разбора и сериализации, а для XDR есть как генераторы, так и библиотеки динамической работы сообщениями

    Это как в Thrift, встроенный TCP и HTTP сервер еще?

  2. Наверное, потому что PB — формат сериализации, которая может использоваться для RPC. А может использоваться для несвязанных с интерфейсами целей.

    XDR — это тоже формат, который может использоваться и для других целей, например, для хранения данных или как формат сериализации в протоколах, не связанных с моделью RPC.

    В PB есть версий полей, для сохранения совместимости.

    Насколько я понимаю, там есть численные идентификаторы полей, а версий всё же нет.

    Это как в Thrift, встроенный TCP и HTTP сервер еще?

    Я не очень понял, почему Вы упомянули TCP и HTTP сервер. XDR — это просто формат данных. Для работы с ним можно как написать генератор функций сериализации/десериализации на основе описания интерфейса на языке IDL XDR, так и непосредственно в коде создавать сообщения вручную, динамически формируя блоки байтов XDR произвольного формата. См. например xdrlib из Python.

    vlasovskikh

    2009-03-19 at 01:17

  3. > XDR — это тоже формат, который может использоваться и для других целей, например, для хранения данных

    именно поэтому я и не понял, почему от формата сериализации ожидаются какие-то версии интерфейсов, которые частный случай применения этого формата, а не общий. Как вот в HTTP есть Content-Length, но нет Content-Xml-Version.

    > Насколько я понимаю, там есть численные идентификаторы полей, а версий всё же нет.

    Численный идентификатор от версии отличается чем?

    > Я не очень понял, почему Вы упомянули TCP и HTTP сервер.

    Извините, это потому что я не понял что такое «библиотека динамической работы сообщениями». Типа с помощью PB нельзя в рантайме сформировать новый вид сообщения? Так вроде ж ничего не мешает.

  4. Видимо, нужно определиться с тем, что такое версия. Под версией я понимаю монотонно возрастающий порядковый номер, по которому можно узнать один и тот же, но модифицированный объект. В формате PB есть идетификаторы полей, т. е. уникальные имена разных полей, а не возрастающие версии одного и того жеполя.
    Формат сериализации может иметь версии для обратной совместимости. Вспомните, например, <?xml version="1.0"?>. Вообще, версия протокола — это версия способа обмена данными, а не версия вида данных (хотя вид данных между версиями протокола тоже часто меняется).
    Т. к. в спеках Protocol Buffers определён бинарный формат PB, то формально ничто не мешает генерировать его динамически. Однако поставляемые библиотеки это сделать не позволяют, т. к. являются только генераторами. Для XDR, напротив, характерны библиотеки, позволяющие работать динамически.

    vlasovskikh

    2009-03-19 at 08:07

  5. Вот http://code.google.com/apis/protocolbuffers/docs/proto.html#updating доходчиво объясняют как использовать новые версии протокола. И старые работают, и новые. Это благодаря уникальным именам разных полей.

    А еще в git (система контроля версий) используются sha1 хэши в качестве «имен ревизий». Тоже не монотонно возрастающее. Просто число. В каждой ревизии разное.

    Я, кажется, начинаю понимать чего вы хотите. Вы хотите циферку version: 1.0 как в XML, в заголовке каждого сообщения PB. Так вот эта циферка бессмысленна. Если ваш код в принципе способен прочитать пришедшее сообщение, потому что написан под одну из версий .proto, то всё будет нормально. Если ваш код настолько старый, что ругается на новое сообщение… ну блин, да, он не будет работать. И знание версии не поможет ему магически обновить код, чтобы понимать новые поля в сообщении.

    А что значит работать динамически я так до сих пор и не пойму, объясните, пожалуйста, на примере.

  6. Вот щас понял как это по-умному называется, когда с версиями не заморачиваются. duck typing: http://en.wikipedia.org/wiki/Duck_typing

  7. А еще в git (система контроля версий) используются sha1 хэши в качестве «имен ревизий». Тоже не монотонно возрастающее. Просто число. В каждой ревизии разное.

    Да. В более общем смысле версия — это разновидность, вариант чего-то. Тогда монотонность ни к чему. Однако чаще всего в ИТ версии используются именно монотонно возрастающие, отсюда и некоторая путанница у меня и Вас. В управлении исходном кодом, возможно, поэтому используется другой термин «ревизия», хотя опять же, вроде смысл один и тот же.

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

    Да, конечно в PB можно модифицировать формат сообщений протокола. Однако явных обязательных идентификаторов версии сообщения там нет. Такие идентификаторы версии есть в XDR как основная форма версионирования форматов сообщений. Видимо, для многих случаев вариант версионирования из PB лучше.
    Опять же, подчеркну, что я не хочу сказать, что какая-то из этих схем версионирования — явная с номерами версий или неявная через развитие формата — лучше или хуже в общем. Всё зависит от обстоятельств. Обе можно с разной степенью успешности применять и в XDR, и в PB.

    Вот щас понял как это по-умному называется, когда с версиями не заморачиваются. Duck typing.

    При утиной типизации не работают с версиями, однако это только частный случай игнорирования версий для методов ОО языков программирования с динамической типизацией. В Protocol Buffers версии тоже в некотором смысле игнорируются, но речь об утиной типизации там не идёт.

    vlasovskikh

    2009-03-19 at 16:07

  8. В управлении исходном кодом, возможно, поэтому используется другой термин «ревизия», хотя опять же, вроде смысл один и тот же.

    Нет общего «в управлении исходным кодом». Во SVN, hg, во всех известных мне системах управления версиями, как раз используются монотонные номера ревизий.

    Видимо, для многих случаев вариант версионирования из PB лучше.

    А для каких хуже? Была циферка, заявление такое, вот у нас версия, есть тыща примеров где это работает. Нет циферки, просто используйте данные, есть тыща примеров где это работает. Работают оба подхода. Зачем циферка?

  9. Нет общего «в управлении исходным кодом».

    Чего общего? Я говорил о том, что в этой области используется слово «ревизия» вместо «версия».
    Насчёт Mercurial Вы заблуждаетесь. Там ревизии тоже именуются по хэшу SHA1.

    А для каких хуже?

    Например, где изменяется не только формат данных, но и протокол, поэтому важна уникальная версия всей процедуры обмена данными. Или если не требуется сохранять обратную совместимость на основе той же кодовой базы.
    Пожалуй, это всё для данного обсуждения.

    vlasovskikh

    2009-03-19 at 23:37

  10. Чего общего? Я говорил о том, что в этой области используется слово «ревизия» вместо «версия».

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

    Насчёт Mercurial Вы заблуждаетесь. Там ревизии тоже именуются по хэшу SHA1.

    Да, я им не пользуюсь, как-то читал там про централизованные номера ревизий и, видимо, ошибочно прочитал числа по порядку.

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

    Это как в HTTP, который в версии 1.1 может отдавать данные по кусочкам… совершенно с вами согласен, протокол утиным способом версионировать никак нельзя. Только поправьте меня, ни XDR, ни ASN, ни PB не описывают протокол, правда? Заголовок протокола конечно, можно закодировать в любой из этих форматов. Но это обычное сообщение.

    Или если не требуется сохранять обратную совместимость на основе той же кодовой базы.

    Ну это более общий случай «требуется», поэтому то, что работает с сохранением совместимости, будет работать и без сохранения. Циферка никак не упростит несовместимый формат.

    И что значит динамическая работа с сообщениями-то? На лету создать новый вид сообщения?

  11. Да, сами XDR, ASN.1, Protocol Buffers, XML и т. д. не описывают протокол. Но разработчики некоторых из них явно намекали на то, для описания форматов чего они разрабатывали эти стандарты. В частности, именно в формате кадра обычно переносится в случае её наличия версия протокола. Так что это связанные вещи.
    Да, под динамическической работой с сообщениями я понимал именно это. Посмотрите на toolkit для XDR и ONC RPC. Там есть как утилита для генерации сериализаторов по IDL, так и API для формирования своих форматов на лету. PB наверняка это не запрещает, но и не приветствует. В доках были только варианты статического использования.

    vlasovskikh

    2009-03-20 at 03:38

  12. В частности, именно в формате кадра обычно переносится в случае её наличия версия протокола. Так что это связанные вещи.

    В смысле, обычным кадром сообщения, как и любое другое в сессии? Ну так и можно ж в любом из этих форматов закодировать сообщение типа {ProtocolVersion: 1.1}. Это ж не касается способа версионирования внутри формата.

    Да, под динамическической работой с сообщениями я понимал именно это. Посмотрите на toolkit для XDR и ONC RPC. Там есть как утилита для генерации сериализаторов по IDL, так и API для формирования своих форматов на лету. PB наверняка это не запрещает, но и не приветствует. В доках были только варианты статического использования.

    Да, я так предполагаю, PB именно запрещает формирование сообщений на лету. Но. Посмотрим на это с другой стороны. Что такое формирование на лету? Это декларация формата в коде. Мне лично звучит неприятно. Если для чего-то это б и понадобилось, я б на лету создал .proto файлик, скомпилял его и поработал с новым динамическим форматом. Медленно, конечно. Но учитывая, что я не могу придумать зачем нужно динамическое описание формата, в качестве костыля сойдёт. :)


Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: