If I understand correctly, checking for ZMQ_POLLOUT on a router socket is mostly useless because it's holding independent queues for each peer and the zmq_poll() call doesn't accept a routing identity. This is in contrast to a dealer socket on which The POLLOUT flag would tell you if there is at least one peer to which the message can be sent without blocking.
André > On Mar 11, 2015, at 11:45 PM, Kenneth Adam Miller > <[email protected]> wrote: > > I have replied inline. > >> On Wed, Mar 11, 2015 at 8:09 AM, Riskybiz <[email protected]> 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 fromfd 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 tofd 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() 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 >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
