[zeromq-dev] resetting REQ/REP state machines

[Thomas Rodgers]

>
> The difficulty may come in dealing with late message arrivals but that can
> probably just be pushed onto the user to detect and handle.


Would that be the lesser of the 'evils' in question here?  To me, throwing
away the socket on a hard failure (e.g. timeout of the remote endpoint)
makes a clean break with the endpoint and keeps the protocol cruft to
detect other failures down.


On Tue, Jul 29, 2014 at 7:49 AM, Charles Remes <lists at chuckremes.com> wrote:

> Does anyone think it’s worthwhile to provide a zmq_setsockopt() to allow
> for resetting the statemachine for a REQ or a REP socket?
>
> One of the biggest stumbling blocks for new users is the lock-step
> send/reply/send/reply sequence enforced by a pair of REQ/REP sockets. If a
> message gets lost, we now force the user to close the socket(s) and create
> a new one. This essentially resets the statemachine for the socket.
>
> Wouldn’t it be better to allow the user to force reset the state?
>
> e.g. (pseudo-code)
>
> req = zmq_socket(ZMQ_REQ);
> rc = zmq_send(req, buf);
>
> // some timeout expires
> rc = zmq_setsockopt(req, ZMQ_RESETSTATE);
>
> rc = zmq_send(req, buf);
>
> I haven’t looked at the source in a while but I can’t imagine this would
> be all that difficult. The difficulty may come in dealing with late message
> arrivals but that can probably just be pushed onto the user to detect and
> handle.
>
> Thoughts?
>
> cr
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140729/1d8ee270/attachment.htm>