> The methods are poorly named, but they do work as documented.
The docs are a bit lacking in that respect - they need to make the
distinction between "is currently connected" and "has connected at
some moment in the past" clear for new programmers, but I accept your
point.
> I recognized the question, and the asker...
I guess I should worry about that in my spare time! {:v)
> Note too that the remote may have closed while you have remaining
> unread data, in which case you don't actually reach EOF until you've
> read to the end of the data stream.
That's a very valid point. My initial problem was that available() on
the BufferedInputStream() returns 0 even when disconnected, which is
fairly logical but not helpful - this prompted me to look more
closely.
> If you don't want to risk blocking, use a Selector. It provides the
> necessary test, and will tell you when you can safely read *without*
> blocking.
Unfortunately that doesn't help - I'm assuming that's similar to
available(), which as mentioned above returns 0 for the disconnected
case (technically, there are 0 bytes you can read from a closed socket
without blocking), which doesn't hint that the connection has been
lost.
I did eventually realise, however, that I can use setSoTimeout() on
the socket to minimise blocking time.
Thanks for your thoughts.
Gordon Beaton - 03 Oct 2007 13:57 GMT
>> If you don't want to risk blocking, use a Selector. It provides the
>> necessary test, and will tell you when you can safely read *without*
[quoted text clipped - 5 lines]
> socket without blocking), which doesn't hint that the connection has
> been lost.
A Selector can tell you when it's safe to read without blocking.
Actually reading is still necessary to tell you whether there was data
to read, or you're at EOF. A single Selector can be used to monitor
many existing and arriving connections simultaneously for connecting,
accepting, reading or writing, according to which SelectionKeys you've
registered interest in.
InputStream.available() tells you how much data has arrived and is
waiting to be read on a single InputStream. It can't tell the
difference between EOF and "currently no data", so reading might still
block.
/gordon
--
JTeagle - 03 Oct 2007 14:06 GMT
> A Selector can tell you when it's safe to read without blocking.
> Actually reading is still necessary to tell you whether there was data
[quoted text clipped - 7 lines]
> difference between EOF and "currently no data", so reading might still
> block.
OK... I'll look into trying a Selector. Thanks.
Lew - 03 Oct 2007 14:36 GMT
>> The methods are poorly named, but they do work as documented.
>
> The docs are a bit lacking in that respect - they need to make the
> distinction between "is currently connected" and "has connected at
> some moment in the past" clear for new programmers, but I accept your
> point.
Blame the docs, blame the language, but by no means blame yourself.
Here's what the docs say:
> true if the socket successfuly connected to a server
We look at your code and see that the socket successfully connected to a
server. Working as advertised. Nothing there says the socket still has to be
connected. Yep, still working as advertised.

Signature
Lew
Thomas Schodt - 03 Oct 2007 15:26 GMT
>>> The methods are poorly named, but they do work as documented.
>>
[quoted text clipped - 4 lines]
>
> Blame the docs
Rather than blaming the docs, suggest an improvement.
bool Socket.isConnected()
Indicates if connect() has been called on this socket.
Initially this method returns false. After a connection is established,
this method method returns true. It will never change back to false for
any reason (like the connection failing).
bool Socket.isClosed()
Indicates if close() has been called on this socket.
Initially this method returns false. After Socket.close() is invoked
this method returns true. It will not return true for any other reason
(like the connection being closed by the remote end).