[zeromq-dev] zmq_poll question.

Kenneth Adam Miller kennethadammiller at gmail.com
Thu Mar 12 04:45:00 CET 2015


I have replied inline.

On Wed, Mar 11, 2015 at 8:09 AM, Riskybiz <riskybizlive at live.com> wrote:

> If I an application uses zmq_poll() before sending or receiving messages
> to check socket(s) for these events;
>
>
>
> *ZMQ_POLLIN*
>
> For ØMQ sockets, at least one message may be received from the *socket* without
> blocking. For standard sockets this is equivalent to the *POLLIN* flag of
> the *poll()*system call and generally means that at least one byte of
> data may be read from*fd* without blocking.
>
> *ZMQ_POLLOUT*
>
> For ØMQ sockets, at least one message may be sent to the *socket* without
> blocking. For standard sockets this is equivalent to the *POLLOUT* flag
> of the *poll()*system call and generally means that at least one byte of
> data may be written to*fd* without blocking.
>
> Does it imply that a check has been made which will ensure that the HWM
> (high water mark) of a sending or receiving socket will not be exceeded?
>

How does a check ensure what will or not happen? Neither of the quoted
documentation segments reference high water marks. Just to be clear here,
the HWM is supposed to represent a threshhold limit that, when surpassed
implies message loss. Nothing says the HWM won't be exceeded, and no system
should try to guarantee that because they can't; when a recipient is sent
more messages than can be received, some will be lost, and this is why
there reliability mechanisms in place in the IoT at large. When things fail
in the internet, messages are lost.


>
>
> So that for example;
>
> Consider a DEALER-ROUTER connection where the ZMQ_ROUTER has reached a
> mute state and is dropping messages.  Is it the case that by checking for
> ZMQ_POLLOUT on the ZMQ_DEALER before sending to the ZMQ_ROUTER that it
> would prevent a message from being sent and consequently dropped by the
> ZMQ_ROUTER.
>
>
>
>   Additionally the ZMQ_ROUTER could be set up using zmq_poll() to check
> for ZMQ_POLLIN & ZMQ_POLLOUT which would prevent exceeding its HWM by not
> accepting further inbound messages when in the mute state; so that whilst
> the socket may be full to the HWM it will not drop any messages?
>

The high water mark is not a solution to message loss; it is just a toggle
switch after you've reigned in the bad stuff *algorithmically* that you can
play with to either make your applications more efficient or more reliable,
and it allows you to tune ZMQ to your needs. In sum, I think that you're
doing a lot of thinking about HWM business that doesn't actually solve the
underlying problem at hand. Instead of HWM, doing an application message
loss failback mechanism and late message redundancy check might go hand in
hand to resolve whatever underlying issue you have by providing the
reliability that you want.


>
>
>
>
> When considering the zeromq api entry for zmq_poll()
> <http://api.zeromq.org/4-1:zmq-poll> I see that;
>
> *ZMQ_POLLIN *For ØMQ sockets, at least one message may be received from
> the *socket* without blocking.
>
> *ZMQ_POLLOUT *For ØMQ sockets, at least one message may be sent to the
> *socket* without blocking.
>
>
>
> May I ask, how does this relate to multi-part messages?  Is it that a
> single zmq_msg_t message frame could be sent or received? Would an single
> entire multi-part message be OK?  I intend to be using the ‘clone’ pattern
> and it could be the case that a single very large multi-part message
> carrying the ‘state’ could be the next to be sent.
>

I'm not sure I have the expertise to answer this question, but I think that
my previous answers may or may not spurn some rethinking of how to approach
things.


>
>
> I would like to minimise the possibility that my code could cause messages
> to get dropped by considering the implications of acting to send & receive
> only on satisfactory poll events?
>

This is not a question and I therefore do not know how to respond. Please
read what I wrote above.


>
>
> Any elaboration on these subjects is much appreciated.
>
>
>
> With thanks,
>
>
>
> Riskybiz.
>
>
>
>
>
> _______________________________________________
> 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/20150311/1bf97c08/attachment.htm>


More information about the zeromq-dev mailing list