[zeromq-dev] Survey: use of 0MQ request reply

[Martin Sustrik]

On 06/19/2011 05:27 PM, Fabien Niñoles wrote:
> 2011/6/19 Martin Sustrik<sustrik at 250bpm.com>:
>> To build patterns on top of basic functionality, you need access to quite a
>> lot of underlying functions/events. Connection events, disconnection events,
>> queue depths, dropping of pending messages, explicit removing peer from the
>> socket, routing to a particular peer, signaling POLLIN and POLLOUT etc.
>
> Aren't the same thing already happening right now, except exposed in
> somewhat different way.  In fact, it seems like the requests are
> mostly like modifying a particular behavior of a socket (direction,
> send/recv pattern, routing strategy, back pressure behavior) without
> touching the other elements.  Having to create a new socket type for
> each of the possible combinaison seems to me a recipe for bloating the
> library or accumulating fork if there is any dissention on the
> usefulness of the new socket type.

That's how it looks at the first sight. A pretty easy job. Once you 
start getting inside the code you'll realise there a large number of 
small and tricky differences between the patterns you have to account for.

>> These functions/events have to be made available via API, which will over
>> time offer more and more functionality. Ultimately, the API would be
>> functionally equivalent to BSD sockets. At that point the "basic" layer can
>> be dropped and replaced by BSD sockets. Which will bring us from where we
>> wanted to get (BSD sockets + basic messaging layer + patterns) to where we
>> are now (BSD sockets + patterns).
>
> May be we are just talking about the same thing here: For me, I see
> ZMTP has the basic messaging layer.  It could been augment to allow
> more distinction between messages, including control vs application
> message (the LABEL flag is just a step toward this), most of the
> current pattern would then be able to be implement over this.

This is protocol layering. There's framing layer, hop-by-hop 
pattern-specific layer (such as idenity stack in req/rep) and end-to-end 
pattern-specific layer (such as stack delimiter in req/rep).

However, protocol layering doesn't map 1:1 to API layering. For 
instance, there's no API equivalent to framing layer. You could 
implement such a layer, but the added value of it would pretty small.

> Just for example, let the socket layer only specify the back pressure
> behavior (drop/non-drop) and out routing strategy (fq/dist), and allow
> access to direct peer message addressing (both on reception and
> sending). Everything else could then be implement in the top layer
> with control message without having to divert the upper layer "pattern
> sockets" out of there normal use case, lowering the risk of
> incompatibility at the same time.  Even connection events could be
> handle using "control" messages and timeout.

That's a first-sight point of view. I suggest you dig into the code and 
try to cleanly separate the "basic" layer and "pattern" layer. You'll 
find out that the API between the two will be extremely complex.

> Let me know what you think about it.  Right now, I'm a bit confused
> for what I see as a dual-purpose design and have a hard time to
> specify correctly the collector pattern (and even an LRU pattern)
> without a clearer view on the future of ZMQ.

As for the new pattern, I would start by writing the exact semantics 
down, including behaviour of the middle nodes, scalability aspects etc.

Once the semantics are clear, you can specify how the functionality can 
be accessed from 0MQ API.

Up to that point you don't even have to care about actual 0MQ 
implementation.

Martin