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

Charles Remes lists at chuckremes.com
Fri May 23 18:14:29 CEST 2014


I don’t think it’s a bad idea, however I would suggest using the existing zmq_setsockopt() and zmq_getsockopt() calls to get/set socket options.

cr

On May 23, 2014, at 9:40 AM, 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