Java Socket issue with DSL

[Ajit]

I have client-server model , where different client runs in different
types of connnection over the internet.

My server is a java socket server , where as client is swing.

Problem iam facing is some what interesting, all clients can send and
recive data properly where as my client running on DSL connection has
some problem , it simply stops sending and reciving data after some
time, even if connection is alive. So is there any way we can tune
socket to work on this type of unstable connection.

Did anyone solve such a problem?

Thanks in advance

Ajit

 

[Matt Humphrey]

I have client-server model , where different client runs in different
types of connnection over the internet.

My server is a java socket server , where as client is swing.

Problem iam facing is some what interesting, all clients can send and
recive data properly where as my client running on DSL connection has
some problem , it simply stops sending and reciving data after some
time, even if connection is alive. So is there any way we can tune
socket to work on this type of unstable connection.

Did anyone solve such a problem?

How do you know the connection is alive if you're not receiving data? TCP/IP
has a timeout value (socket timeout) such that if it doesn't receive any
data after that time it will throw an exception. This value defaults to
something like 4 hours. This means that if your connection fails (TCP/IP is
still trying to make it work) you won't know for 4 hours. What is your
socket timeout? If you normally expect fast response, you can lower the
timeout and get faster notice that the connection has failed. You can then
build some fault-tolerance and recovery into your client and server. Also,
TCP/IP is very robust, so maybe you should ask if there's a problem with
your client's ethernet adapter.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[Esmond Pitt]

How do you know the connection is alive if you're not receiving data? TCP/IP
has a timeout value (socket timeout) such that if it doesn't receive any
data after that time it will throw an exception. This value defaults to
something like 4 hours.

No, sorry, this is misinformation. TCP/IP has a 'keepalive' timer that
is off by default, that when on defaults to 2 hours system-wide, that
can generally only be changed by the sysadmin, and that isn't required
to be implemented by the platform at all.

The OP should undoubtedly be using a TCP *read* timeout in his server,
of an order of minutes not hours, and if it occurs should just close the
socket. If not set the default for the read timeout is infinite.