[zeromq-dev] ZMQ spec update proposition / enhancement to core messaging

Bruno D. Rodrigues bruno.rodrigues at litux.org
Tue Dec 17 19:01:08 CET 2013


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 <artemv.zmq at gmail.com> 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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131217/c9ffa008/attachment.sig>


More information about the zeromq-dev mailing list