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

[Fabien Niñoles]

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.

> 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.

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.

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.

Fabien