-----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-----
