[zeromq-dev] Non-contiguous message thoughts

Brian Granger ellisonbg at gmail.com
Mon Mar 8 20:38:57 CET 2010


>> sock.send([msg1, msg2, msg3])
>> On the other side:
>> messages = sock.recv()
> One thing to be considered is keeping the case of single-part message as
> simple as possible (i.e. as simple as it is now) given that this will be the
> case in 99 times of 100.
> message = sock.recv() [0] just doesn't look right.

Yes, if I went this route, I would have sock.recv() return the actual
message if a message
group was not used.  So it would still look like msg = sock.recv() for
the non-group case.
The reason I think this is OK is that if you are expecting a message
group you need to
have extra logic anyways.  The extra logic would then look like:

msg = socket.recv()
if isinstance(msg, tuple):
    # handle message group
  # handle single message

The only thing I don't like about this is that the send_json/recv_json
methods in the Python bindings can
return messages that are tuples.  Thus, it would be difficult to
distinguish between a group and a message that is happens to be a

A different interface (in Python) would be something like:

for i in range(msgs):

The receive side is more difficult because you 1) either have to mess
up the return value of the non-group receive or 2) keep querying the
socket for end of group:

socket.recv() --> (False, msg)   # False indicates there are not more
in the group


while not socket.end_of_group():

Both are a little bit awkward...



> One additional issue to think about: In C API sending a multipart message
> involves passing a flag to send function, while receiving a multipart
> message requires checking a flag on message itself. That seems somewhat
> incoherent. Is there a better way? Is there a better way wthout making the
> API sucky?
> Martin

Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com

More information about the zeromq-dev mailing list