Sorry, but it is you who are wrong.  Look in your help or man pages
for the description of the "accept" call.

You may be thinking that sockets can be shared and multiplexed - which
is true - but that's not how the accept call works.

<QUOTE> from FreeBSD man page accept(2)
Accept removes the next connection request from the queue (or waits
until a connection request arrives), creates a new socket for the
request, and returns the descriptor for the new socket.  Accept only
applies to stream sockets (e.g., those used with TCP).
<\QUOTE>

<QUOTE> from Linux man page accept(2)
The accept() system call is used with connection-based socket types
(SOCK_STREAM, SOCK_SEQPACKET). It extracts the first connection
request on the queue of pending connections, creates a new connected
socket, and returns a new file descriptor referring to that socket.
The newly created socket is not in the listening state. The original
socket sockfd is unaffected by this call.
<\QUOTE>

<QUOTE> from Winsock2 SDK
The accept function extracts the first connection on the queue of
pending connections on socket s. It then creates and returns a handle
to a new socket. The newly created socket is the socket that will
handle the actual connection; it has the same properties as socket s,
including the asynchronous events registered with the WSAAsyncSelect
or WSAEventSelect functions.
<\QUOTE>

I don't have an AT&T Unix derivative handy to quote from its man page.
The basic TLI calls are similar to BSD in that t_listen sets the
connection point to passive mode and t_accept creates and returns a
new stream endpoint.  The details are different because TLI allows
compositions of streams and filters in a way that's very similar to
the way Java handles streams.

In 20+ years I've worked with a half dozen versions of Unix, with
Linux, with MacOS (before the Unix versions), with every version of
Windows and with three different RTOS's.  I've never encountered any
TCP implementation in which accept did not create a new socket.

George
--
for email reply remove "/" from address

Not at all.  NIO is merely another way to talk to the IO subsystem of
the local host OS.  Between hosts, it's all TCP/IP.

Once a sequence of bytes has been handed off to the OS to transmit over
a socket, there is nothing in that sequence of bytes identifying how it
was handed over; the stream {0x00, 0x01, 0x02, 0x03, ....} will look
identical to the receiver regardless of whether you use NIO to write it
or a Socket. What NIO does get you is the ability to multiplex IO
operations on a single thread.  For applications with non-trivial
numbers of IO handles open at a time this matters; for programs that
only have one or two sockets, using a thread per socket is fine and
probably easier to read (if, possibly, harder to make thread-correct).

A client connecting to an NIO-based server would look identical to a
client connecting to any other server: new Socket ("192.168.0.1", 2700);

An NIO-based server accepting connections from a non-NIO client would
look identical to a server accepting connections from an NIO client:
someServerSocketChannel.accept ();

-o