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 <[email protected]> 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 <[email protected]> wrote: > >> Check ZMQ_REQ_RELAXED, which may do what you want. >> >> On Tue, Jul 29, 2014 at 3:35 PM, Thomas Rodgers <[email protected]> >> 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 <[email protected]> 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 >>>> [email protected] >>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >>> >>> >>> _______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
