ZeroMQ + протокольные буферы - PullRequest
Новая
       23

ZeroMQ + протокольные буферы

31 голосов
/ 12 сентября 2011

ZeroMQ FAQ страница предлагает использовать protobuf от Google в качестве способа сериализации содержимого сообщения.

Кто-нибудь видел хороший пример использования?

Мне также нужно получить ответ на вопрос «Что является самым большим преимуществом сериализации сообщений?»- может ли это быть чем-то, без чего я могу жить и воспользоваться преимуществом более тонкого конвейера.

Мне очень нравится идея файлов .proto и компилятора protoc.

Кроме того, этоКажется, что еще один замечательный инструмент, который можно бросить на игровой площадке, будет libev, любые комментарии приветствуются:)

Ответы [ 4 ]

22 голосов
/ 12 сентября 2011

Если вы на 100% уверены, что программы, которые будут обмениваться данными через ZMQ, будут всегда способны понимать двоичный формат друг друга (например, потому что они всегда распространяются вместе и все равно были скомпилированы с одинаковыми параметрами компилятора) Я не вижу никакой пользы от накладных расходов, добавляемых сериализацией.

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

Кажется, что в настоящее время каждый и их брат создают решения для сериализации, что может свидетельствовать о том, что не существует единого решения, подходящего для всех решений. Эта страница содержит довольно тщательный сравнительный анализ времени сериализации, времени десериализации и размеров для 27 (!!) различных систем сериализации. Не пропустите первый абзац этой страницы, там написано: «Внимание, тесты могут вводить в заблуждение». Ваша заявка, ваши данные - это то, что вам нужно, но представленные там данные могут помочь вам сузить выбор, который вы хотите изучить подробно.

15 голосов
/ 19 февраля 2013

Вот пример, который отправляет и получает сообщения через Java и в C ++:

Сериализация в Java: 

Person person = Person.newBuilder().setName("chand")
    .setEmail("chand@test.com").setId(55555).build();
socket.send(person.toByteArray(), 0);

Сериализация в Java: 

byte[] reply = socket.recv(0);
Person person2 = Person.parseFrom(reply);

Сериализация в C ++: 

Person p = Person();
std::string str;
p.SerializeToString(&str);
int sz = str.length();
zmq::message_t *query = new message_t(sz);
memcpy(query->data (), str.c_str(), sz);
socket->send (*query);

Сериализация в C ++ 

zmq::message_t resultset(100);
socket->recv (&resultset);

Person p = Person();
p.ParseFromArray(resultset.data(), resultset.size());
printf("\n Server : %s", p.name().c_str());
3 голосов
/ 02 октября 2012

Я не уверен, что PUB / SUB в 0mq будет работать с protobuf, потому что 0mq ожидает строковую тему в начале сообщения ... но protobuf ставит дескриптор поля первым.

на самом деле здесь ссылка с решением.

http://www.dotkam.com/2011/09/09/zeromq-and-google-protocol-buffers/

ура

1 голос
/ 09 февраля 2018

При общении всегда нужно сериализоваться. Структуры произвольного доступа. Уровни связи, такие как ZeroMQ, являются последовательными.

Вы можете использовать сериализацию по умолчанию, которая поставляется с вашим языком.

Например, в C ++ структура без указателей будет иметь определенную двоичную разметку, которая может быть непосредственно преобразована в байтовый массив. Этот двоичный формат косвенно является вашим уровнем сериализации и зависит от языка и компилятора.

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

...