What is this Wizardry? about netcoreserver HOT 4 CLOSED

This uses async sockets. Any events triggered will be executed asynchronously, so you'll need to handle this in your application.

from netcoreserver.

@volundmush With async tasks, code either gets executed on a free ThreadPool thread, or on the thread captured by the context (in case you are doing UI stuff and need to dispatch the results back on the one-and-only UI thread). I/O work also runs on dedicated OS threads, which is supported throughout the OS with IOCP . The main idea is to keep the number of threads low (e.g. tied to the number of cores) and dispatch tasks around them without additional allocations and without too much chattiness between cores.

This article sums it up for .NET tasks, although it goes all the way to the CPU interrupts to explain how the whole process works.

from netcoreserver.

Thanks. Did some research after getting this info. Things make far more sense now. It never occurred to me that C# worked like this.

from netcoreserver.

@volundmush

A little late but I assume since muds/mushes are a hobby you might still be interested. A mud/mush server is what I'm using this for (thought I would share what's worked for me in case it helps anyone later). A mud/mush needs to process things in an ordered fashion (usually). What I did to make that happen was once a command came in asynchronously I added it to a ConcurrentQueue that held the command and the session it came from. All sends go into a buffer instead of to the socket and THEN the game loop will write the buffer out with netcoreserver. Process in the game loop is:

1.) Dequeue and execute the commands (the queue making it FIFO or the order in which they came in).
2.) Determine what game processing occurs (a Tick, battle messages, game motion stuff, mob updates, etc.)
3.) Send the buffered output to the sessions (basically everything that happened in 1 and 2).
4.) Rinse, repeat.

Generally with a MUD/MUSH/MOO you're not going to run into issues with backpressure.

The async nature of netcoreserver fixes one of the core issues with most C based muds and that is that the commands get queued up as they come. With most C code bases the sockets are looped over from a linked list (in the order they are in the list) and as a result a command that should have been run earlier might get run later (so players who stay on the server longer end up in a better position in the list which is important if you're processing combat commands and want to be at the top of a combat pulse). Few C code bases I've seen randomize their linked lists (because it's a pain and most people run the servers as a hobby on spare time).

from netcoreserver.