[zeromq-dev] resetting REQ/REP state machines

[Pieter Hintjens]

Yes, it's moving fast :-) There's a SOCKS5 proxy option I've not
played with, GSSAPI security (Kerberos), SCTP on a branch somewhere
along with fully pluggable transports.

On Tue, Jul 29, 2014 at 4:23 PM, Charles Remes <lists at chuckremes.com> wrote:
> 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 <ph at imatix.com> wrote:
>
>> Check ZMQ_REQ_RELAXED, which may do what you want.
>>
>> On Tue, Jul 29, 2014 at 3:35 PM, Thomas Rodgers <rodgert at 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 <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
>>>
>>>
>>>
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev