[zeromq-dev] What exact networking problems ZMQ does solve?

artemv zmq artemv.zmq at gmail.com
Thu Dec 12 17:46:12 CET 2013

hi Justin Karneges.

I finally got your point (and point from Justin Cook, he had expressed
earlier)  !! Thanks a lot.

You guys are talking about situation(s) when server side __is not capable__
to send FIN or RST. I reproduced situation of "broken connection and blind
client"  very easily with "iptables" command.  Before that I was using
"ifdown" -- and experienced "grievous mental confusion"  because couldn't
understand __how__ client socket knows that server abruptly exited. Until I
found that there's such thing as RST ... :)   So,  during   "ifdown"  or
"/etc/init.d/network stop" or abruptly killed server process  --  kernel
sends RST to client socket(s), making  them  aware that server gone
offline.  It appears that "iptables"  is very silent "connection killer" !

Now my question is going more to networking field. I want that kind of
situations when I can lose connection __but__ nor FIN, neither RST will be
generated . In other words I want to lose connection veyr silently (from
client perspective). Will be much appreciated for all that possible
scenarios.  Thanks in advance.


2013/12/11 Justin Karneges <justin at affinix.com>

> On 12/11/2013 11:07 AM, artemv zmq wrote:
> >  >> If the server goes down, and their is an established session, there
> > is no way to know that without further communication, or no response
> > where response is expected.
> >>>If there is, I would love to know about it.
> >
> > I found a solution. There's  a lib in java called "netty".  So they do
> > next:   in separate thread they poll existing channels  on read
> > operation (among others)   and during this poll __they can__ detect
> > that "socket was focibly closed by remote peer". Ok?  So they just poll
> > for read  and when things are connected polling on read returns an info
> > akin to "0 bytes was read", so essentially, appl. treat this like
> > "nothing was read but channel is alive!".   And that's it.   What it
> > gives?  Before write operation we may know the status of channel.  "0
> > bytes read" is an indicator that it's alive.  If got exception --
> > channel is closed, and all future operations on channel are cancelled.
> >
> > I'm wondering why ZMQ  can't do something similar or even better? o_O
> If you establish a TCP connection to a remote system with netty, and
> then do "ifdown" on the remote system, you will not receive any
> indication of this and any messages you send to the remote system will
> be lost. If the connection stays down long enough, maybe around 20
> minutes, then the local TCP stack will timeout the connection and netty
> will finally report an error to your application.
> TCP, and therefore any framework based upon it, does not instantly
> report delivery failure, and in general it is hard to figure out what
> was not delivered when you finally do receive an error. About the best
> you can do is use ioctl() with SIOCOUTQ to investigate your TCP queue.
> Your goal of knowing "instantly" if a message was not delivered is not
> possible without a very fast heartbeat system.
> One thing you can do is consider delivery to have failed if you don't
> have a TCP connection active (or if an attempt to establish a connection
> resulted in a "connection refused" error), but just be aware that this
> won't cover a case of the network dropping out, as in the case of
> "ifdown", or if someone accidentally unplugs a network cable.
> The short answer is that 0MQ does not solve your exact problem. It does
> solve a bunch of other problems though.
> Justin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131212/de2066bb/attachment.htm>

More information about the zeromq-dev mailing list