> > 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 <li...@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@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
