I didn’t even know that option (and its associated ZMQ_REQ_CORRELATE) were in 
the library! The library is moving so fast these days that I can’t even keep up 
(which is a good thing).

Those options are a superior solution to my proposal. Glad they are in the 
library.

cr

On Jul 29, 2014, at 9:15 AM, Pieter Hintjens <p...@imatix.com> wrote:

> Check ZMQ_REQ_RELAXED, which may do what you want.
> 
> On Tue, Jul 29, 2014 at 3:35 PM, Thomas Rodgers <rodg...@twrodgers.com> wrote:
>>> 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
>> 
> _______________________________________________
> 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

Reply via email to