0

Possible Duplicate:
How to get an acknowledgement for the client socket from server?

I have implemented a comet message server using netty which keeps connections open for a long time. It works fine, but I fail to detect the following:

Sometimes a client connection has been "unexpectedly" closed, like someone cut the cable. After this happened I can still write to that channel (server side) without getting an error or being able to detect that anything is wrong.

So: How can I detect whether data I sent from my netty server to the client was actually received?

In "old" java.io this is (afaik) done on the socket level. I cannot sense if a connection drops (without keepalives), but in the moment I try to write data to the OutputStream it fails if the connection had dropped meanwhile. However, with netty this does not happen any more and I wonder whether I can still get that information somehow (information = underlying connection has dropped meanwhile, could not deliver data)

Basically: the underlying TCP has run into a timeout because no ACKs were received. How is this surfaced in java.nio / Netty? Currently I can continue to write into a dead connection.

Community
  • 1
  • 1
Daniel
  • 2,087
  • 3
  • 23
  • 37
  • thanks brian. My question is different. I do not want to receive or access the ACK responses themnselves, I just want to know whether the data "went through". AFAIK in "old" java.io if you write data to a socket then it fails in that moment if the connection has dropped meanwhile. This is not the case with netty (or even java.nio)? – Daniel Oct 17 '12 at 01:17
  • I have changed the last paragraph to make it more clear. Hope that helps. – Daniel Oct 17 '12 at 01:21
  • In 'old' `java.io` you can detect a deliberately reset connection immediately, but you can only detect a failed connection with a write if enough time has elapsed for the preceding writes, retries etc to have failed at the TCP level, which can take many seconds. Maybe your timing is different now. – user207421 Oct 17 '12 at 01:24
  • exactly. in the old world I would write and if it does not go through the operation blocks for some seconds before it fails (probably after some retries internally). Netty even allows me to register a ChannelFutureListener on the write operation, but it always returns a success. – Daniel Oct 17 '12 at 01:29
  • No. If a write/send blocks, it is because the send buffer is full, not because it is retrying. All write/send do is copy the data into the socket and buffer and return. Data in the send buffer is written asynchronously to the network, including all retries. In non-blocking mode, the only difference is that instead of blocking, write/send will copy what fits and return that count, leaving it up to you to write the rest when possible. – user207421 Oct 17 '12 at 02:14
  • 1
    @Daniel, the _only_ way to know if it "went through" (as in all the way to the other end) is to get an ACK for the data, which you cannot know at the application layer when using common operating systems. Also, the connection can only fail the moment you try to write is if the other side is still around and has previously closed or reset the connection, which does not fit with "like someone cut the cable". Or previous transmits have caused a TCP connection timeout due to lack of ACKs coming back. – Brian White Oct 17 '12 at 02:48
  • well that is exactly the point: "transmits have caused a timeout due to the lack of ACKs". I don't get that timeout in netty. I can write to that dead connection for hours and it "feels" like it's all good. – Daniel Oct 17 '12 at 18:34
  • You can write how much data to the dead connection? How is it dead? Cable pulled? – user207421 Oct 17 '12 at 22:30
  • It's dead by Android going to sleep in my case. Could be a pulled cable too though. Haven't checked how much data I can still write yet (I'm sending a few bytes every some seconds) but that works for a long time (hours) after the connection is gone. – Daniel Oct 18 '12 at 00:18
  • @Daniel The observed facts suggest that TCP doesn't consider the connection dead. Maybe Android TCP keeps working while asleep? – user207421 Oct 18 '12 at 21:00
  • hmm, nasty but that could explain it. – Daniel Oct 19 '12 at 04:42

0 Answers0