[zeromq-dev] Possible bug in ZMQ HWM handling?

[Luca Boccassi]

Yes that's correct, TCP's congestion control is part of the flow
managing just as HWM values are, and it's platform dependent, so it's
quite complex to document correctly and precisely. Feel free to send
PRs to update the docs with your findings.

On Tue, 2018-09-04 at 10:26 +0200, Francesco wrote:
> Hi all,
> Just to follow up on this: I discovered the reason why HWM were
> apparently
> not working on the setup I described on my first email.
> The reason is the following: in my setup the ZMQ proxy backend socket
> is a
> TCP socket.
> Now I discovered that when using the TCP transport, then if you set
> HWM=100
> on the socket, you cannot expect the zmq_msg_send() to block on the
> 101-th
> message: the reason is that the socket will block only if both ZMQ
> pipes
> and kernel TCP buffers are full. Depending on the size of the TCP
> buffer,
> that may happen after a lot more messages than 100.
> 
> Anyway I think that ZMQ HWM hanlding is not very clear and well
> documented.
> I found some tickets still in OPEN status about this:
>   https://github.com/zeromq/libzmq/issues/2724
>   https://github.com/zeromq/libzmq/issues/1373
> 
> So I spent some time extending existing HWM unit test and creating a
> new
> one to stress the ZMQ proxy when its HWM is reached.
> I just created a work-in-progress PR here:
>   https://github.com/zeromq/libzmq/pull/3242
> 
> If maintainers can take a look and let me know what they think, I can
> complete that PR and put it in a form where it can be merged...
> 
> Thanks,
> Francesco
> 
> 
> 
> 
> 
> 
> 
> 
> Il giorno ven 31 ago 2018 alle ore 19:36 Francesco <
> francesco.montorsi at gmail.com> ha scritto:
> 
> > I forgot to specify: this happens with ZeroMQ 4.2.3 on Linux.
> > 
> > Il giorno ven 31 ago 2018 alle ore 18:54 Francesco <
> > francesco.montorsi at gmail.com> ha scritto:
> > 
> > > Hi all,
> > > I spent quite a bit of time to look into a weird issue.
> > > Here's my setup:
> > >      1 PUB socket  connected to a STEERABLE PROXY FRONTED socket,
> > > using
> > > INPROC transport
> > >      1 SUB socket  connected to the STEERABLE PROXY BACKEND
> > > socket, using
> > > TCP transport
> > > 
> > > Before starting stuff (i.e. calling zmq_connect() or zmq_bind())
> > > I lower
> > > all HWMs (for both TX/RX) of all sockets to just "10".  Moreover
> > > I set
> > > ZMQ_XPUB_NODROP=1.
> > > Now my expected behaviour is that after 20 messages sent from the
> > > PUB
> > > socket, the zmq_send() on that PUB becomes blocking.
> > > You may argue that since I have the XPUB/XSUB sockets of the
> > > proxy in the
> > > middle, the value after it becomes blocking is 40. That's ok.
> > > 
> > > The experimental result I found is that the PUB NEVER becomes
> > > blocking.
> > > If I send 10000 messages from the PUB they all go through.
> > > In the SUB I sleep 1 second after EVERY message received. It
> > > takes a
> > > while but in the end the SUB receives all the 10000 messages...
> > > 
> > > Is there an explanation for this? Who buffered all those messages
> > > (against my will) ?
> > > 
> > > Thanks for any hint!
> > > Francesco
> > > 
> > > 
> > > 
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180904/fc5734c7/attachment.sig>