[zeromq-dev] What exact networking problems ZMQ does solve?
Justin Karneges
justin at affinix.com
Wed Dec 11 20:53:03 CET 2013
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
More information about the zeromq-dev
mailing list