Разделять или не разделять в ZeroMQ

Я разрабатываю серверное приложение, которое будет говорить с ZeroMQ. Не вдаваясь в мельчайшие подробности, сервер будет хранить и обслуживать (из запросов) (eventid, eventstring) кортежей.

Мои вопросы касаются дизайна проводного протокола. Я хотел бы отправить свой кортеж с одного конца на другой. Я вижу два варианта:

  • Сериализуйте мой кортеж (используя protobuf или что-то еще) и отправьте его как одно сообщение.
  • Отправить мой кортеж как составное сообщение; первая часть содержит идентификатор события, а вторая содержит строку события.

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


zeromq
person Ztyx    schedule 18.07.2012    source источник

Ответы (2)


arrow_upward
2
arrow_downward

В Руководстве есть раздел, в котором обсуждается сериализация:

http://zguide.zeromq.org/page:all#Serializing-Your-Data

Ваш случай с двумя полями настолько тривиален, что IMO не имеет значения, какой формат вы используете, пока он работает.

person Pieter Hintjens    schedule 21.11.2012

arrow_upward
1
arrow_downward

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

Вы также можете определить макет байта и отправить свои данные в виде одного кадра. Вам нужно будет иметь дело с любыми проблемами с порядком байтов (если вы запускаете код на платформах с прямым и обратным порядком байтов), но с этим довольно легко справиться. Если не умеете, то используйте каркасную технику как Мажордомо.

Будет незначительная разница в производительности между использованием 1 кадра и нескольких кадров. Если вы не отправляете гигабиты в секунду, это вряд ли будет проблемой. Как всегда, проведите тест для измерения вашего конкретного случая, прежде чем «оптимизировать» и тратить кучу времени и усилий, чтобы сэкономить 200 наносекунд на сообщение.

person cremes    schedule 18.07.2012