[zeromq-dev] Queueing outgoing messages

Ilja Golshtein ilejn at yandex.ru
Thu Jul 22 13:17:23 CEST 2010


Martin,
thank you.


What is the purpose of HWM for ZMQ_REQ? Is it possible to have more than one message sent, having in mind Send/Receive nature of these sockets?

What is expected for ZMQ_XREQ if HWM hit? From my observation it looks like Drop, right?

Could you please correct the description for XREQ/XREP (which obviously requires correction)

==
ZMQ_XREQ
^^^^^^^
A socket of type 'ZMQ_XREQ' is used by a _client_ to send requests to and
receive replies from a _service_. This socket type allows any
sequence of _zmq_send(request)_ and _zmq_recv(reply)_ calls. Each
request sent is load-balanced among all _services_, and each reply received is
matched with the last issued request.

When a 'ZMQ_XREQ' socket enters an exceptional state due to having reached the
high water mark for all _services_, or if there are no _services_ at all, then
then any messages that would be sent shall instead be dropped until the exceptional 
state ends.

[horizontal]
Summary of ZMQ_XREQ characteristics
Compatible peer sockets:: 'ZMQ_XREP'
Direction:: Bidirectional
Send/receive pattern:: any order
Outgoing routing strategy:: Load-balanced
Incoming routing strategy:: Last peer
ZMQ_HWM option action:: Drop


ZMQ_XREP
^^^^^^^
A socket of type 'ZMQ_XREP' is used by a _service_ to receive requests from and
send replies to a _client_. This socket type allows any
sequence of _zmq_recv(request)_ and _zmq_send(reply)_ calls. Each
request received is fair-queued from among all _clients_, and each reply sent
is routed to the _client_ that issued the last request.

When a 'ZMQ_XREQ' socket enters an exceptional state due to having reached the
high water mark for all _services_, or if there are no _services_ at all, then
then any messages that would be sent shall instead be dropped until the exceptional 
state ends.

[horizontal]
Summary of ZMQ_XREP characteristics
Compatible peer sockets:: 'ZMQ_REQ, ZMQ_XREQ'
Direction:: Bidirectional
Send/receive pattern:: any order
Incoming routing strategy:: Fair-queued
Outgoing routing stratagy:: Last peer
ZMQ_HWM option action:: Drop
==

Notice for googlers/occasional readers: the description above is definitely wrong.



22.07.2010, 13:39, "Martin Sustrik" <sustrik at 250bpm.com>:
> Ilja,
>
>>  I am sorry - client blocks on recv.
>>>  Hello!
>>>
>>>   Playing with "A simple client/server application" from Cookbook I've found out client blocks if no server run.
>>>
>>>   Knowing from zmq_setsockopt(3), "The default 'ZMQ_HWM' value of zero means "no limit"",
>>>   I'd expect different behavior.
>>>
>>>   Could someone please explain?
>
> HWM is the limit on pipe to particular peer. So if you have 2 peers and
> HWM is set to 100, there can be 200 messages in-flight.
>
> When you have no peers, there's no pipe to apply HWM on and the
> behaviour is defined by the messaging patters (in short, drop message
> for pub/sub, block for other patterns).
>
> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
--
Best regards
Ilja Golshtein



More information about the zeromq-dev mailing list