[zeromq-dev] discussion on the Lasy Pirate Client : lpclient.c

Laurent Alebarde l.alebarde at free.fr
Thu Jun 6 13:15:18 CEST 2013


Hi list,

Here are some thoughts about the lazy pirate client lpclient.c from The 
Guide. I would like please confirmations and comments.

It tries to send a request and get a response in some robust way, using 
up to REQUEST_RETRIES retries, and destroying/rebuilding the socket 
and/or resending the request as necessary. More precisely : The request 
resend can be performed in the main while (retries_left && 
!zctx_interrupted) without destroying/rebuilding the socket, or in the 
secondary while (expect_reply) with a destroying/rebuilding of the socket.

I question the criteria of the different conditional branches.

1) When the code is "Interrupted" (zmq_poll returns an error (-1) or an 
answer is there and we have the condition (!reply)), the code breaks to 
the main while, and exits from it thanks to the condition 
(!zctx_interrupted). But the socket is not destroyed, while the context 
is. Shall we not attempt here to destroy the socket ? Why not use this
(!zctx_interrupted) which is more self-explanatory instead of (rc == -1) 
or !reply) ? Can I have (rc == -1) or !reply) and not (!zctx_interrupted) ?

2) The condition (items [0].revents & ZMQ_POLLIN) is used when not 
satisfied to assess that "E: server seems to be offline, abandoning\n". 
 From the documentation, shouldn't it be the condition (rc == 0) instead 
(no error and no response) ? The condition used (items [0].revents & 
ZMQ_POLLIN) looks like a filtered response with ZMQ_POLLIN ?

3) If the reply is not erroneous but "malformed", the code polls again 
and again, indefinitely in the secondary while, and not respecting the 
send/receive/send/receive constraint of the REQ socket. Shouldn't it 
break to the main while in this case ?

4) Does the use of zmq_poll changes something to the 
send/receive/send/receive constraint of the REQ socket ?


To clarify my thoughts, I would have written it like this : 
http://pastebin.com/DCKXedQL
(not tested, I have not managed to build the examples with the build 
command yet)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130606/b22c970e/attachment.htm>


More information about the zeromq-dev mailing list