Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Socket communication issues.

Reply
Thread Tools

Socket communication issues.

 
 
k2
Guest
Posts: n/a
 
      02-25-2007
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

--
*****************************************
Please remove the killspam portion of
my return address if replying directly
*****************************************
 
Reply With Quote
 
 
 
 
angrybaldguy@gmail.com
Guest
Posts: n/a
 
      02-25-2007
On Feb 24, 8:41 pm, k2 <(E-Mail Removed)> wrote:
> 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.

 
Reply With Quote
 
 
 
 
Gordon Beaton
Guest
Posts: n/a
 
      02-25-2007
On Sat, 24 Feb 2007 20:41:15 -0800, k2 wrote:
> 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

--
[ 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 With Quote
 
Richard Maher
Guest
Posts: n/a
 
      02-25-2007
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

"k2" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>
> --
> *****************************************
> Please remove the killspam portion of
> my return address if replying directly
> *****************************************





 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use') Steve Holden Python 1 02-03-2009 06:20 AM
Re: socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use') Steve Holden Python 0 02-01-2009 12:45 PM
Re: socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use') Laszlo Nagy Python 0 02-01-2009 07:37 AM
socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use') Laszlo Nagy Python 1 01-27-2009 05:05 PM
Re: socket.unbind or socket.unlisten? - socket.error: (48,'Address already in use') Jean-Paul Calderone Python 0 01-27-2009 01:41 PM



Advertisments