Socket communication issues.

Thread view:

k2 - 25 Feb 2007 04:41 GMT

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

Signature

*****************************************
Please remove the killspam portion of
my return address if replying directly
*****************************************

Reply to this Message

angrybaldguy@gmail.com - 25 Feb 2007 07:40 GMT

> Hello,
> Scenario... Client connects to server socket, no problem sending
[quoted text clipped - 10 lines]
> 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.

Reply to this Message

Gordon Beaton - 25 Feb 2007 09:51 GMT

> 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

Signature

[ don't email me support questions or followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e

Reply to this Message

Richard Maher - 25 Feb 2007 11:15 GMT

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

> Hello,
> Scenario... Client connects to server socket, no problem sending
[quoted text clipped - 13 lines]
> thanks,
> K2

Reply to this Message

Socket communication issues.

Free Magazines