[zeromq-dev] trying to understand zeromq high water mark behaviour

[Shaobo Hou]

Thanks Pieter,

I had another look at the output, and it does look like maybe the TCP
buffer is involved somehow, the messages received by the slow worker were
all from the beginning of the test sequence, so presumably they were sent
out before the sockets started blocking due to HWM.

Shaobo


On 27 January 2014 16:01, Pieter Hintjens <pieterh at gmail.com> wrote:

> It's not irrelevant but first, it defaults to 1000 and secondly there are
> buffers both at the sender and the receiver, as well as in TCP.
> On Jan 27, 2014 4:37 PM, "Goswin von Brederlow" <goswin-v-b at web.de> wrote:
>
>> On Mon, Jan 27, 2014 at 07:15:03AM -0600, Pieter Hintjens wrote:
>> > Hi,
>> >
>> > The dealer socket distributes messages equally to all its peers, and
>> > the HWM isn't relevant here. Even busy workers will receive messages.
>> > You want some form of load balancing. The Guide has examples of this
>> > (load balancing brokers).
>> >
>> > -Pieter
>>
>> Is it completly irelevant?
>>
>> I naively thought the dealer would send equally to all sockets untill
>> they block. And on the other side the socket would read ahead until
>> its recv HWM is met. So at least recv HWM messages get queued up and
>> then whatever fits into the send and recv buffers the kernel has for
>> the sockets and whatever remains of the last message is buffered in
>> zmq internally. Or is that completly wrong?
>>
>> MfG
>>         Goswin
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140127/5601f2d3/attachment.htm>