[zeromq-dev] RFC: finer control of socket type / behaviour

Pieter Hintjens ph at imatix.com
Wed May 28 10:07:38 CEST 2014


This has been mooted before and I think it's a good idea in some ways.
Certainly to allow experimentation. However the current patterns do
kind of cover the sane use cases. It's hard to see what the point
would be, for instance, of blocking in a ROUTER socket when you can't
send a message. There's no real sense to that.

If you want to experiment with this, you can build custom socket types
on top of ZMQ_ROUTER and virtualize them, e.g. like the CZMQ zactor
model. Then if you get patterns that work well you've got arguments
for pushing this into libzmq.

-Pieter


On Fri, May 23, 2014 at 4:40 PM, Goswin von Brederlow <goswin-v-b at web.de> wrote:
> Hi,
>
> in ZeroMQ there are different kinds of sckets with different characteristics:
>
> From the zmq_socket manpage: e.g. REQ socket:
>
>     Summary of ZMQ_REQ characteristics
>     Compatible peer sockets     ZMQ_REP, ZMQ_ROUTER
>     Direction                   Bidirectional
>     Send/receive pattern        Send, Receive, Send, Receive, #
>     Outgoing routing strategy   Round-robin
>     Incoming routing strategy   Last peer
>     Action in mute state        Block
>
> While ZeroMQ has many different socket types it does not cover every
> sensible (or not so sensible) combination of characteristics. Most
> anyoing the "Action in mutet state" is dictated by the socket type
> while one might want different behaviour.
>
> I wonder how hard it would be to make the "Action in mute state" a
> socket option that could be modified seperately from the socket type.
> The socket type would still set different defaults for backward
> compatibility. But one could create a ZMQ_ROUTER socket and then
> change the "Action in mute state" to "Block" instead of "Drop".
>
>
> Probably more dificult would be to make all (the 3 defining ones)
> characteristic of a socket selectable from the start. Namely:
>
> * Incoming routing strategy
>   - Fair-qeueued
>   - Last peer (restricts send/receive pattern)
>   - None (unidirectional)
>   - Meta (unidirectional except for meta messages [subscription for XPUB])
>   - Single (only one connection allowed)
> * Outgoing routing strategy
>   - Round-robin
>   - Fan out
>   - Routed (peer address is first frame)
>   - Last peer (restricts send/receive pattern)
>   - None (unidirectional)
>   - Meta (unidirectional except for meta messages [subscription for XSUB])
>   - Single (only one connection allowed)
> * Action in mute state
>   - EAGAIN
>   - Block
>   - Drop
>
> A fourth characteristic is required to reflect the full range of socket types:
>
> * Identity handling
>   - Router (append on receive, strip on send)
>   - Dealer (no change to messages in or out)
>   - Last peer (strip all on receive, append all on send)
>
> The other charactestics can be derived from the incoming and outgoing
> strategies and not all combinations make sense.
>
> Note: strategy Single could be dropped. What is the point of ZMQ_PAIR
> anyway?
>
> Note 2: strategy Routed implies Router handling, maybe that could be
> merged with Last peer strategy. In both cases the peer is picked by
> its identity.
>
>
>
> So what do you think? Does it make sense to add a new function:
>
>    void *zmq_custom_socket(void *context, in_strategy in, out_strategy out, id_handling handling);
>
> and new socket option ZMQ_MUTE_STATE?
>
> MfG
>         Goswin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



More information about the zeromq-dev mailing list