[zeromq-dev] Survey: use of 0MQ request reply
Martin Sustrik
sustrik at 250bpm.com
Sun Jun 19 17:48:53 CEST 2011
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
More information about the zeromq-dev
mailing list