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. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
