[zeromq-dev] Fundamentals of a REQ/REP

[Chuck Remes]

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).

cr