Someone has too much spare time for their own good:) That's dedication for sure.
Do you have any conclusions you feel like sharing?
TCP/IP server, multithreaded?
Developer journal: Multiplayer RPG dev diary
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
QuoteIs this standard behaviour?
Yes.
On 13/4/2018 at 3:49 PM, DexterZ101 said: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 ^ _^yAsyncOVERLAPPED:
* 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 ^ _^ySyncThread:
* 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.
I expect receive/send performance is the most important part for a game server, where clients are typically staying connected for several minutes/hours?
Developer journal: Multiplayer RPG dev diary
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 want to test all possible scheme
This is a very attractive idea, and I've tried it too in the past! Here's what I learned:
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. "An interchangeable networking API" generally doesn't let you check the different options, because you need to also change the way you do simulation and rendering.