[zeromq-dev] Fundamentals of a REQ/REP

[Matthias Wächter]

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 flag somewhere....
>
> Daniel,
>
> 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 "in time."
>
> 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.

– Matthias