Re: Fundamentals of a REQ/REP
Matthias Wächter <matthias <at> waechter.wiz.at>
2011-10-01 18:08:30 GMT
On 01.10.2011 19:40, Chuck Remes wrote:
> On Oct 1, 2011, at 7:13 AM, Daniel Hyams wrote:
>> Ah, I see, that indeed works!
>> Can I suggest, though, an API that isn't quite so clumsy (zmq_reset(), say?). It's certainly not the end
of the world to have to close and reconnect, but that does mean that you have to carry along all of the socket
setup information and redo it. It seems that just having a zmq_reset call to reset the communication
pattern to its initial state would be appropriate for this rather common use case. I assume that it's just a
> this is indeed clumsy. There has been discussion on this list about adding a timeout for
zmq_send()/zmq_recv(). Obviously that would be a better way of detecting that a response has not arrived
> However, it isn't as simple as just resetting the internal FSM. What if the timeout occurs, resets itself
to *only* allow a send, and then the response arrives late? Right now that would probably cause a EFSM
error. Alternately, perhaps it could just queue the message so the next call to zmq_recv() will return it
and any "duplicate" response would just get dropped.
> Anyway, just wanted to point out that there are still complexities to be addressed even if there were such a
thing as a timeout (or a zmq_reset() function).
I think, what Daniel wants to say is that requiring the user code to keep track of all the setup
details while this is all known to the library, is clumsy. A simple zmq_reset() could use all known
socket connection setup and simply re-establish the connection based on this information.
zeromq-dev mailing list
zeromq-dev <at> lists.zeromq.org