Windows NIO bug?

[Simone Bordet]

Alan,

On Fri, Jul 6, 2018 at 7:54 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:
> > What I expect is a TCP RST that the server sends to the client to
> > inform the client that the socket is closed on the server and that
> > further writes are pointless, and that RST is not emitted by the
> > server.
> >
> > On Linux it is always emitted, on Windows it is only emitted if I wake
> > up the selector.
>
> There has historically been a problematic area with both reliability
> issues and platform specific behavior. It has been re-implemented in JDK
> 11 so it is now reliable and also consistent on all platforms. When you
> try JDK 11 then you should see the connection will consistently remain
> open until the keys have been removed from all Selectors.

Can you please detail exactly what you mean by "connection
consistently remain open", because I tried this:

void test(SocketChannel c) {
  c.close();
  System.out.println(c.isOpen());
}

the code above prints false (assume c is non-blocking, registered with
a selector, etc.) - should it print true instead until the selector is
woken up?

> If there are
> clients reading they will read EOF. If there are clients writing then
> they will not see the RST until the key has been flushed from all Selectors.

Okay then.

Would be great if this behavior is specified in the Javadocs, although
I still find it strange.

Just to be clear, there is no need to wake up the selector when
calling SocketChannel.shutdownOutput(), right?
That would immediately tell the TCP stack to send the FIN to the other
peer, right?

In that light, I find it strange that calling SocketChannel.close()
delays the TCP stack from sending RST until the selector is woken up
to deregister the SelectionKey.

However, if that is documented behavior (although I could not find it
anywhere) we'll comply.

The only reference I found in the Selector javadocs is that the key
will remain in the cancelled-key set, which may be ok if you know that
the selector will be woken up eventually by something else.
However, there is no reference to the fact that a key remaining in the
cancelled-key set delays RST - FIN is not delayed.

Thanks!

-- 
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz