Le Tue, 12 Jan 2010 08:41:00 +0100, Laurent Cohen <[email protected]> a écrit :
> Hello all, > > Typically, a technique that I've implemented was using the fact that, > when the remote peer is disconnected for any reason, the > corresponding SelectionKey on the server becomes readable(). > It is possible to use this when you know for example that the > connection should be either idle or waiting for the server to send > something. In this case, you just need to add OP_READ to the > operations the key is interested in. > For instance, if an idle connection becomes suddenly readable - as in > SelectionKey.isReadable() - then it means it is disconnected. > For this to apply, you also need to keep some state attached to the > SelectionKey, so that you know that it is readable when it shouldn't. > This technique covers the cases when you are not actively performing > I/O on the channel. In the other cases, an IOException will be thrown > as soon as you try to read from or write to the channel, so that's > easier to handle. > Unfortunately, I do not know if there is a way to emulate this > behavior using Mina. Is it possible at all ? > > Thanks, > -Laurent > > On 12/01/2010 03:49, hakan eryargi wrote: > >> As far as I understand the way NIO works, when the clinet has > >> brutally closed the connection (ie, no FIN), the selector won't be > >> informed about any modification regarding this socket, so its > >> SelectionKey will never be returned on a select() operation. > >> > >> > > just for curiosity, is this different from a blocking socket > > connection ? i mean, is there something different for NIO that it > > cant detect a disconnected client but a blocking server can ? > > > > On Tue, Jan 12, 2010 at 4:17 AM, Emmanuel > > LŽcharny<[email protected]> wrote: > >> Patrick Sansoucy a écrit : > >> > >>> Sorry to jump on the thread, but I'm a bit surprised by (and > >>> curious about) the behavior exposed here and the fact that Mina > >>> does not detect it ... > >>> > >>> Is the connections between your 2 boxes direct (ie no proxy or > >>> firewall) because I witnessed a couple of years ago the exact > >>> same behavior with one of our application and we found out that > >>> the issue was that a proxy was leaving the socket hanging there > >>> making the client or server think it was still active. > >>> > >>> From what I remember from our diverse implementation at work (I > >>> am not familiar with Mina's inner working). I think the poll > >>> would indicate something occurred and a read confirm the socket > >>> closing (cleanly or not). > >> As far as I understand the way NIO works, when the clinet has > >> brutally closed the connection (ie, no FIN), the selector won't be > >> informed about any modification regarding this socket, so its > >> SelectionKey will never be returned on a select() operation. > >> > >> I any case, we don't poll. > >> > >> Am I missing something ? > >> > > Well MINA already detect TCP FIN (read returning -1) for session closed and provide read idle time for dead connections which didn't negotiate the end of the TCP connection. -- Julien Vermillard Archean Technologies http://www.archean.fr
signature.asc
Description: PGP signature
