[zeromq-dev] zmq_poll question.

[Andre Caron]

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 <kennethadammiller at gmail.com> wrote:
> 
> 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 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
>> 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/20150312/7ca9294e/attachment.htm>