I’ll ask again, isn’t this what the IMMEDIATE does? With this on, send fails right away if the connection is not yet established (for the relevant socket types of course)
On Dec 17, 2013, at 17:35, artemv zmq <[email protected]> wrote: > hello there, > > I have a proposition to the core of ZMQ: a socket_option which would > prohibit in-mem msg queueing upon certain info obtained from remote peer. > > To make it more clear, let me call out two things. > First one, how things work so far: ZMQ keep placing messages in a queue > before .send() occurs. If remote peer is down, no-accessble, and etc. the > queue will keep growing until HWM. So this renders one of the strengths of > ZMQ. > Second one, how one could benefit from not using msg queue. Imagine client > DEALER) connected to server (ROUTER). During some period they are connected > and messages keep flying between them. > Now, imagine, server shuts down, for example via "ifdown eth0". OS sends to > client RST packet and client now recognizes that server became unresponsive. > A this point I think would be very-very great to have an socket_option > standing for "if socket reveals during runtime that remote peer is not > responsive -- don't queue a msg and raise error" . > > What do you think devs? > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
