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

Goswin von Brederlow goswin-v-b at web.de
Fri May 23 16:40:12 CEST 2014


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

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?


More information about the zeromq-dev mailing list