[zeromq-dev] Notes from a hackathon
Joe McIlvain
joe.eli.mac at gmail.com
Fri Feb 6 10:11:42 CET 2015
Pieter,
Integer routing ids sounds nice to me, quite honestly.
I wouldn't mind having the routing ids being semantically separated
from the content frames by more than just the empty "delimiter", so
representing them with separate accessors as integers is a possibly
appealing id. Arguably, it adds more complexity to the API, but that
may be outweighed by increased separation of concerns.
Doron,
If you or others are interested in multi-hop support for zproto, I'm
happy to share what I've been doing. It's not terribly efficient
though, I'm afraid, although in my application I am not really pushing
the speed limits of zeromq at all so speed is not my biggest concern.
I only wanted to maintain a patch of the message codec generator gsl
script (and not of the client or server generators), so I needed a
scheme that only alters that. Because the zproto server expects a
single zframe for a "routing_id", in the message object when the
"routing_id" is requested I am serializing all of the frames of the
envelope into a single frame and making this accessible on the message
object as the "routing_id", but I also provide the original group of
frames accessible on the message object as the "envelope". I also
provide a few other helper methods to do various operations on the
envelope.
Again, this strategy is not really ideal for high-throughput systems
so I didn't want to weigh down zproto for others by merging my patch
in. However, if there is enough interest, perhaps we could find a way
for zproto users to opt-in to this kind of behavior. For now, I'm
happy to maintain it privately until I'm nudged enough by interested
parties to share it.
More information about the zeromq-dev
mailing list