Re: New SocketChannel test that requires testing

[Casey Marshall <csm at gnu dot org>]

Jeroen Frijters wrote:
> Casey Marshall wrote:
>> Jeroen Frijters wrote:
>>> Casey Marshall wrote:
>>>> Maybe we are wrong for returning true for `isConnected' that 
>>>> early after trying to establish the connection; the test 
>> we're using
>>>> is whether or not the socket has a remote address or not, which may
>>>> not be the criteria we're interested in.
>>> Yes, I believe that's incorrect. I think you can only 
>> transition into
>>> the connected state by calling finishConnect (if connect 
>> was called in
>>> non-blocking mode).
>>>
>> That's not necessarily true; on some systems, even a non-blocking call
>> to connect() can succeed immediately, if you are connecting 
>> to the local machine. It doesn't sound right that you get this
>> condition even when the server process hasn't pulled the connection
>> off the queue, but that may be how it works.
> 
> I don't think it has nothing to do with the underlying socket mechanics,
> it is simply an invariant of the SocketChannel API.
> 

Nope:

"If this channel is in non-blocking mode then an invocation of this
method initiates a non-blocking connection operation. If the connection
is established immediately, as can happen with a local connection, then
this method returns true. Otherwise this method returns false and the
connection operation must later be completed by invoking the
finishConnect method." [1]

1.
http://java.sun.com/j2se/1.4.2/docs/api/java/nio/channels/SocketChannel.html#connect(java.net.SocketAddress)