What is this Wizardry?

[volundmush]

This isn't actually an issue with the code, and more with my difficulty in figuring out what's happening under the hood.

I'm designing an application that needs to run a telnet server - gonna be running a MUD game, hopefully! And I'd like to use this for the networking. So far so good, the server is up and echoing some text back as it's sent...

But I don't understand how this library works. What mechanisms are being used under the hood to achieve responsiveness? Is this running in its own thread for instance? Thread-per-connection? I've seen some usage of Events but I also saw a Thread.Yield() and lots of using System.Threading but I'm not seeing Threads actually CREATED anywhere either...

Since I need to design my main loop and everything related, I kinda need to know how this thing fits into the equation.

I'm a little new to C#, so...

[jhmckimm]

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

[vgrudenic]

@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.

[volundmush]

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

[blakepell]

@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).