socket connected??

[manuel aldana]

i wrote a program where a client socket communicates with a server
socket in just one direction (i.e. i only use a server input stream from
a client).

apart from getting an IOException when writing to streams how do i know
from the view of the server that the client socket isn't running anymore
(shutdown from winXP or unplugging ethernet cable etc. etc.)?
tried to figure that out from catching other exception but no success.
no success in using Socket.isConnected() either. it seems to just test
if it was connected at the beginning.

maybe it is the only solution to establish another stream, where the
server pings the client every 10 seconds to know if it's still there??

thnx in advance!

 

[Matt Humphrey]

i wrote a program where a client socket communicates with a server
socket in just one direction (i.e. i only use a server input stream from
a client).

apart from getting an IOException when writing to streams how do i know
from the view of the server that the client socket isn't running anymore
(shutdown from winXP or unplugging ethernet cable etc. etc.)?
tried to figure that out from catching other exception but no success.
no success in using Socket.isConnected() either. it seems to just test
if it was connected at the beginning.

maybe it is the only solution to establish another stream, where the
server pings the client every 10 seconds to know if it's still there??

Because of the nature of the socket protocol, there is no way to determine
if a particular socket is working unless you actually try it out. Because
packets may take different routes it is even possible (though highly
unlikely) for a second socket to report ok while your main one fails.
Pretty much everyone that codes a custom TCP/IP protocol includes an "are
you there" embedded request/response. Of course, when it comes right down
to it, having received an "are you there" reply is no guarantee that the
server will still be available even on the next immediate request. Every
message sent is an implicit test for connectedness that is confirmed by
receiving the reply.

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

 

[manuel aldana]

Because of the nature of the socket protocol, there is no way to determine
if a particular socket is working unless you actually try it out. Because
packets may take different routes it is even possible[...]

java.net.Socket implements the TCP transport layer. thought with TCP the
packages always use the same route?

seems that there is no java-method to simply check my requirement. i
think i just implement a ping from server to client to check if it is
still there.

thanks for the answer!

 

[Michael Borgwardt]

Because
packets may take different routes it is even possible[...]

java.net.Socket implements the TCP transport layer. thought with TCP the
packages always use the same route?

First, it would be a *different* TCP connection. Second, TCP has nothing
whatsoever to do with routing, that's what IP does. And having alternative
routes is a major feature of IP.

BTW, the TCP standard already does what you want via the SO_KEEPALIVE
option; unfortunately, the standard does not include setting the
keepalive interval, and neither does, apparently, Sun's implementation.

 

[Manolis Wallace]

and neither does, apparently, Sun's implementation.

I agree with everything else you said. Just a minor note: sun does not
implement tcp, it just uses it. The OS implements tcp

--
Manolis Wallace
http://www.image.ece.ntua.gr/~wallace/
Image, Video & Multimedia Systems Laboratory
Department of Computer Science
School of Electrical & Computer Engineering
National Technical University of Athens

 

[Mason Bryant]

Can you just set a timeout on the socket?

eg:

http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html#setSoTimeout(int)

This way if the client takes more than the timeout that you set,
you'll get a java.net.SocketTimeoutException.

 

[Michael Borgwardt]

Can you just set a timeout on the socket?

eg:

http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html#setSoTimeout(int)

This way if the client takes more than the timeout that you set,
you'll get a java.net.SocketTimeoutException.

Timeout only occurs when there is a blocking operation being done.
There is no timeout when both sides of the connection are silent.

 

[manuel aldana]

Timeout only occurs when there is a blocking operation being done.
There is no timeout when both sides of the connection are silent.

thanks, i did it this way yesterday already and it works.
before my questions, i thought that there is always a execption in
read() thrown when the client passes away. now i understood the meaning
of tcp much better.

 

[Steve Horsley]

i wrote a program where a client socket communicates with a server
socket in just one direction (i.e. i only use a server input stream from
a client).

apart from getting an IOException when writing to streams how do i know
from the view of the server that the client socket isn't running anymore
(shutdown from winXP or unplugging ethernet cable etc. etc.)?
tried to figure that out from catching other exception but no success.
no success in using Socket.isConnected() either. it seems to just test
if it was connected at the beginning.

There is no way to know the connection is broken until you try to
write something. Then the TCP stack can eventually decide that the
connection is broken if it never gets an acknowlegement of that
sent data. But if you don't send something, you cannot know the
other end has gone away. It's like wanting to know if someone is
still on the other end of the phone but without either of you
speaking. It can't be done.

A sender can always detect a broken connection by sending data -
the TCP stack notices the lack of a TCP ACK and reports the
exception.

A silent listener may never discover a broken connection though.

Some kind of application-level keepalive message might be a solution.
Oddly, the application need only periodically send messages that the
application at the other end will ignore. This is enough to trigger
an IOException on write() eventually.

You are right, isConnected() only tells you if the socket ever was
connected - it doesn't return false after a disconnect.

maybe it is the only solution to establish another stream, where the
server pings the client every 10 seconds to know if it's still there??

Opening another stream won't tell you anything of interest about this
stream.

Steve

 

[Roedy Green]

Timeout only occurs when there is a blocking operation being done.
There is no timeout when both sides of the connection are silent.

What you can do is send a dummy heart beat packet every X seconds if
there is no other traffic. Then when you die on read timeout, you
know there is real trouble, not just nothing to say.

TCP/IP is quite different from modem traffic. There is no carrier to
your destination when nothing is being said. It is just a silent
absence of packets. So you can't really tell if the other end has gone
away until you probe them. Someone said TCP/IP now has an ability to
automatically send dummy heartbeat packets to detect disconnect
sooner. I don't know what you do to turn it on, or control the probe
frequency. Your app would be unaware of them.


This is the technique I use in Harvest and CyberView Plus.

Other "heartbeat" like packets are" "request shutdown" to tell the
other end to save, etc to close up shop gracefully, and "shutdown" to
acknowledge the request and say it is all clear to close the socket.

 

[Michael Borgwardt]

away until you probe them. Someone said TCP/IP now has an ability to

RFC 1122 ain't exactly new. Actually now that I checked it, I see that
it's not a required feature.

automatically send dummy heartbeat packets to detect disconnect
sooner. I don't know what you do to turn it on, or control the probe
frequency.

Java allows you to turn it on via Socket.setKeepAlive(). Unfortunately,
it does not allow you to set the frequency, which makes it rather useless.

Your app would be unaware of them.

I suppose you'd get a SocketException somewhere if there is no answer.