web-dev-qa-db-fra.com

Tampons de protocole ZeroMQ +

ZeroMQ FAQ page suggère d'utiliser --- protobuf de Google pour sérialiser le contenu des messages.

Quelqu'un a-t-il vu un bon exemple d'utilisation?

J'ai également besoin d'obtenir la réponse à "Quel est le plus grand avantage de la sérialisation des messages?" - si c'est quelque chose dont je peux vivre sans et profiter d'un pipeline plus mince.

J'aime bien l'idée de .proto fichiers et le compilateur protoc.

De plus, il semble qu'un autre excellent outil à lancer sur le terrain de jeu serait libev, tous les commentaires sont les bienvenus :)

protocolsnetwork-protocolszeromq
31
errordeveloper

Si vous êtes sûr à 100% que les programmes qui vont communiquer via ZMQ seront à tout moment capables de comprendre le format binaire de l'autre (par exemple parce qu'ils sont toujours distribués ensemble et ont tous été compilés avec les mêmes options de compilation de toute façon) je ne vois pas bénéficier de la surcharge ajoutée par la sérialisation.

Dès que la condition ci-dessus ne peut pas être satisfaite (comme les programmes partenaires fonctionnant sur différents types d'hôtes, les programmes écrits dans différentes langues ou même les programmes partenaires qui peuvent évoluer indépendamment dans le temps - ce qui peut provoquer des incompatibilités dans leurs structures binaires brutes), la sérialisation devient très probablement un doit.

Il semble que de nos jours, tout le monde et son frère créent des solutions de sérialisation, ce qui peut indiquer qu'il n'y a pas de solution unique. Cette page contient une analyse comparative assez approfondie du temps de sérialisation, du temps de désérialisation et des tailles pour 27 (!!) différents systèmes de sérialisation. Ne sautez pas le premier paragraphe de cette page, il dit "Attention, les repères peuvent être trompeurs". Votre application, vos données sont ce qui compte pour vous, mais les données qui y sont présentées peuvent vous aider à affiner les choix que vous souhaitez étudier en détail.

22
fvu

Voici un exemple qui envoie et reçoit des messages via Java et en C++:

Sérialisation en Java:

Person person = Person.newBuilder().setName("chand")
    .setEmail("[email protected]").setId(55555).build();
socket.send(person.toByteArray(), 0);

Désérialiser en Java:

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

Sérialisation en 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);

Désérialisation en 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());
15
Chand Priyankara

Je ne suis pas sûr que PUB/SUB dans 0mq fonctionnera avec protobuf, car 0mq attend un sujet de chaîne à la tête du msg .. mais protobuf met d'abord un descripteur de champ.

en fait voici un lien avec une solution.

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

à votre santé

3
jaybny

Vous devez toujours sérialiser lors de la communication. Les structures sont à accès aléatoire. Les couches de communication, comme ZeroMQ, sont en série.

Vous pouvez utiliser la "sérialisation par défaut" fournie avec votre langue.

Par exemple, en C++, une structure sans pointeurs aura une certaine disposition binaire qui peut être directement transformée en un tableau d'octets. Cette disposition binaire est, indirectement, votre couche de sérialisation, et est à la fois spécifique au langage et au compilateur.

Tant que vous vous limitez aux structures qui n'ont pas de pointeurs et qui utilisent le même compilateur et le même langage aux deux extrémités du canal ... n'hésitez pas à éviter une bibliothèque qui effectue une sérialisation supplémentaire en plus de la disposition par défaut fournie.

1
Erik Aronesty