3 hours ago, Polydone said:

Someone has too much spare time for their own good:)

Nyaha! Yo wazzup Polydone, I just want to create an Interchangeable network library the reason I want to test all possible scheme ^_^y

Here's my simple conclusion and understanding on Accepting client using TCP based onthe (3)Three schemes ive implemented on accepting clients.

AsyncIOCP:

* A Non-Blocking acceptor implementation for accepting and listening to connecting players
  using I/O Completion Ports(IOCP) model in conjunction with a pre-allocated thread pool.
* This is good for minimum clients or when you will terminate accepting client once your
  desired numbers of players connected.
* Recursively fire immeadiately another async listener inside your async callback method
  before adding the connectiong client to your player collection.
* Just don't do any other thread related stuff like sleep inside your callback or heavy
  computation and validation and your good to go ^ _^y

AsyncOVERLAPPED:

* A Non-Blocking acceptor implementation for accepting  and listening to connecting players
  using OVERLAPPED I/O model in conjunction with a pre-allocated thread pool.
* Just like the AsyncIOCP it's good for minimum clients or when you will terminate accepting client
  once your desired numbers of players connected.
* Recursively fire immeadiately another async listener inside your completion method
  before adding the connectiong client to your player collection or doing some validation.
* Again just don't do any other thread related stuff like sleep or heavy compulation and validation
  inside your completion method and your good to go ^ _^y

SyncThread:

* A Non-Blocking acceptor implementation for accepting and listening to connecting players
  using Synchronous model in conjunction with it's own kernel dedicated thread.
* If your application requires massive connecting clients or continously accepting clients
  until your application ends this is a good candidate.
* The only caveat of this implementation is it has it's own kernel thread unlike AsyncIOCP
  and AsyncOVERLAPPED that uses a pre-allocated thread pool.

The Receiver scheme, maybe some other time ^_^y or I'll journal it.

Thanks for everyone's contributions to the conversation.

One thing I noticed on Windows 10 is that if my initial SOCKET is set to non-blocking using ioctlsocket(), the SOCKET gotten from accept() is also set to non-blocking automatically, so that future calls to recv() are non-blocking as well. Is this standard behaviour?

The code is up at https://github.com/sjhalayka/tcpspeed

1 hour ago, Polydone said:

I expect receive/send performance is the most important part for a game server, where clients are typically staying connected for several minutes/hours?

Exactly, but the OP's inquiry is regarding Listening and Accepting.

Cheers ^_^y

I'm going the SyncThread route. Thanks all.

1 hour ago, hplus0603 said:

What matters in the end is not which particular API you call (well, select() is slow for hundreds of people ...) but instead how your game design interacts with the networking mechanism you choose.

Well said Sir ^ _^ y