Socket communication issues.

[k2]

Hello,
Scenario... Client connects to server socket, no problem sending
transmission packs back and forth...
Somewhere during this communication the server socket closes for any
number of reasons.
Currently, the client has no idea this event has happened, so it will
attempt to write to the outputstream and then wait for an excruciatingly
long time for the reply on the inputstream before finally timing out.
Shouldn't there be some indication that the socket has died on the
server? Client socket check for isConnected is still true after this
event, so it carries on as if there's something listening on the other
end when in fact it isn't. Is there some basic cleanup that the server
should be performing during its shutdown process in order to cleanly
sever the communication?

thanks,
K2

 

[angrybaldguy]

Hello,
Scenario... Client connects to server socket, no problem sending
transmission packs back and forth...
Somewhere during this communication the server socket closes for any
number of reasons.
Currently, the client has no idea this event has happened, so it will
attempt to write to the outputstream and then wait for an excruciatingly
long time for the reply on the inputstream before finally timing out.
Shouldn't there be some indication that the socket has died on the
server? Client socket check for isConnected is still true after this
event, so it carries on as if there's something listening on the other
end when in fact it isn't. Is there some basic cleanup that the server
should be performing during its shutdown process in order to cleanly
sever the communication?

isConnected will return true any time after connect() has been
called. Don't use it to check if the socket is actually usable -- the
ONLY way to determine that is to try to use it.

Each side of a TCP conversation has to close the socket separately: if
the server closes its half, the client is still allowed, by the TCP
spec, to send data; the server may not send any data back because its
half is closed. You need to design shutdowns into your protocol.

For example, IRC clients send QUIT :reason and then close their half
of the socket, and the IRC server responds to QUIT by closing its half
of the connection. HTTP 1.0 clients send an HTTP request and close
their half immediately, and the server closes its half at the end of
the response.

 

[Gordon Beaton]

Somewhere during this communication the server socket closes for any
number of reasons. Currently, the client has no idea this event has
happened, so it will attempt to write to the outputstream and then
wait for an excruciatingly long time for the reply on the
inputstream before finally timing out.

Do you mean the server closed the Socket, or the ServerSocket? The
ServerSocket has no relevance for existing connections, so closing it
should have no effect on the client whatsoever.

If the server really has closed the Socket, then the client's
subsequent attempt to read or write will cause EOF to be indicated
with either an exception or a special return value (which depends on
the specific methods used).

Post a simple code example that shows the behaviour you're describing.

Shouldn't there be some indication that the socket has died on the
server? Client socket check for isConnected is still true after this
event, so it carries on as if there's something listening on the other
end when in fact it isn't.

isConnected() and friends don't tell you anything about the underlying
connection, they only tell you what methods you've called on the
Socket object itself.

/gordon

 

[Richard Maher]

Hi K2,

Currently, the client has no idea this event has happened, so it will
attempt to write to the outputstream and then wait for an excruciatingly
long time for the reply on the inputstream before finally timing out.

I found setSoTimeout (won't help your writes) and setKeepAlive but no
tcpProbeIdle tcpDropIdle or soFullDuplexClose. Curious.

The demo example I'm currently knocking up doesn't check for -1 on the Write
but nonetheless it completes immediately when I kill the server process. And
the subsequent Read reports an immediate error. My server is not Java and I
do have the FullDuplexClose option set their.

Regards Richard Maher