[zeromq-dev] 0MQ/2.0-alpha3 available

Aamir M intuitionist at gmail.com
Tue Sep 29 18:29:08 CEST 2009

Hi Martin,

> Right. Let's design new socket types to support your use case. As far as I understand it's pretty similar to the "butterfly" scenario described here:
> http://www.zeromq.org/tutorials:butterfly

Yes the problem is described exactly by the butterfly scenario.

> 1. Do we want to route the replies back to the sender or do we just want to propagate them further on? In former case some kind of route-back mechanism mas to be involved.

I would say that we do want the ability to route back replies ... I
imagine that many people are  forced to "reinvent" this wheel right

In practice, an application is probably not going to be as simple as
sending replies back to the sender. In a typical grid application,
there is a cluster of a "worker nodes" that are "always on" and are
always listening for requests. On the other hand, the client program
(which sends requests to the worker nodes) is not "always on" ... it
can connect, disconnect, and reconnect at different times. So we have
a problem with the application start-up sequence ... the workers must
know where the client is, but the client may not be online when the
worker nodes are being started up.  So I think an intermediate
"forwarded" is always required. The worker nodes connect to the
forwarder. The worker nodes receive requests from the forwarder and
send replies to the forwarder. The forwarder must collect requests
from a client, load-balance those requests, and send replies back to
the client.

The forwarder device must be able to deal with the situation where a
client aborts in the middle of a computation ... typically some kind
of clean-up is required, so that the client can cleanly reconnect and
resume where it left off. This adds some complexity to the forwarder
device. If the client abort a calculation and then reconnects then the
forwarder has to be some way of preventing "stale" messages from being
sent to the client and the worker nodes ... here "stale" message is
defined as any request or reply that was sent before the calculation
was aborted.  Furthermore, if we allow for more than one client
operating at any given time then the forwarder becomes a more complex
device. Now the forwarder must sort out which replies go to which
client, which keeping in mind that clients can appear and disappear
from anywhere at any time.

But I think that if we had a way to asynchronously route-back replies
then that would be sufficient to implement a forwarder device by
simply combing two "async requesters" (in in the forwarder device and
one in the client program).

> 2. Do we want to reorder replies so that sequence of requests is matched? If so, message numbering should be added.

Ideally, the would replies would be reorder. In fact in my own code I
currently I have to add message numbers for exactly this reason.

How would the 0MQ library add message numbering? I guess message
headers have to be used?

Besides the sequence of the of messages, there is also the issue of
the number of messages. Simply put, if we sent 100 requests and
receive back 101 replies then we have a serious problem. I don't know
if whether library should check this or the user code.

> My intuition is that there we are probably having two distinct use cases here, one for streamlining messages forth, the other one for routing the replies back to the requester ("anyc requester").

I tend to agree, although it's possible that someone using the
pipelining model would also also have a need for eventually having
replies routed back to the requester once the the request has been
processed through the pipeline. I would suggest that the two use cases
can be treated separately and then later made compatible with each
other if we want a fully generalized "butterfly" solution.


More information about the zeromq-dev mailing list