db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samuel Andrew McIntyre <fuzzylo...@nonintuitive.com>
Subject Re: Help detecting client disconnects for network server
Date Sat, 09 Oct 2004 08:58:06 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Oct 8, 2004, at 4:41 PM, Kathey Marsden wrote:

> Reading a little about this it seems the only way to really detect if
> the socket is active is to attempt a write. This of course is not an
> option since it will mess up the drda protocol.  Other things I have
> looked at are Socket.setSoTimeout, which seems no good because the
> client might in fact just be sitting there doing nothing for a long  
> time.
>
> Any ideas?

I looked around and unfortunately it appears that attempting a write is  
the only way to conclusively determine that the connection is no longer  
active. It appears that this is a consequence of the design of TCP and  
is not a Java-specific problem. Check out:

http://forum.java.sun.com/thread.jsp? 
forum=11&thread=539297&start=0&range=15&tstart=60&trange=15

As evidence that this is not a Java-specific problem, see:

http://lists.gnu.org/archive/html/bug-commoncpp/2004-01/msg00027.html

Unfortunately, since the problem for the server occurs on the reading  
side of the transaction, it doesn't seem like there's anything the  
server can do to test the connection, like attempting to write the next  
few bytes of the transaction to the socket. Only the client would be  
able to tell that the connection had been lost. It would appear that  
implementing some sort of timeout is the only way around the problem,  
short of altering the DRDA specification to allow a way for the server  
to probe the state of the connection within the boundaries of the  
protocol. :)

If it was decided to implement some sort of timeout, obviously it would  
be nice to be able to set the length of the timeout on the server side  
so that individual application developers could decide what the length  
of an acceptable timeout for a client should be, along with similar  
functionality on the client side so that a particular transaction could  
be attempted again once the connection is again available. Also, in the  
interest of recoverability for the transaction, would it be possible  
that the server could invalidate the entire transaction initiated by  
the client once the timeout is reached, and, once the client regains  
connectivity, that the client could once again attempt the entire  
transaction?

Not sure that helps, but it's my 2 cents,
andrew
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBZ6g/DfB0XauCH7wRAjN0AJ9AULQSuMMqgvASKEa06oi1+J1jZgCfVVjz
W8NXltNQewsAnd3ZMoE4/ao=
=H/6O
-----END PGP SIGNATURE-----


Mime
View raw message