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)
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
