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. BR -artemv 2013/12/11 Justin Karneges <[email protected]> > 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
