[zeromq-dev] Notes from a hackathon

Joe McIlvain joe.eli.mac at gmail.com
Fri Feb 6 10:11:42 CET 2015

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.

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

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