[zeromq-dev] Fundamentals of a REQ/REP

[Martin Sustrik]

On 10/01/2011 07:40 PM, Chuck Remes wrote:

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

Yes. This have been discussed before.

This kind of thing is useful for REQ ans REP sockets.

If you want to give it a try, go on!

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

This problem have been addressed already in 3.0+ versions each request 
and reply contains request-id field. If reply arrives at the requester 
with non-matching request-id it's discarded silently.

Martin