What exactly happens when netty server calls disconnect()

[Daniel Ferber]

Hi,

I might be missing something about half-closed socket, therefore I would
like to ask for advices.

According to TCP specs, a socket could stay half-closed for a while: one
peer signaled that it has finished sending, but the other is still allows to
send. But I cannot reproduce the half-closed state with my netty experiment.

I have been experimenting with an old style blocking Java socket
application. This application receives chunks of byes and echos them back.
The netty server sends messages with random bytes and then expects to
receive them back. Eventually the server calls disconnect.

Reading code I discovered that the disconect event closes the nio socket
underneath the channel and propagates a disconnect event up the pipeline.
On the client application, the reading thread gets an "closed socket"
IOException on the InputStream.read() and cannot send any data anymore.

I suspect that if the netty server writes a message to the channel and
immediately calls disconnect, then then receiving client might be
interrupted with IOException before receiving all the message. And the
client will not be able to respond anymore. But I expected the netty server
to be able to receive these remaining bytes although it requested the
channel to disconnect.

Is that right? Or might my test be confusing me?

Best regards,
Daniel Felix Ferber
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20100827/d1b4dfe1/attachment.html