17 Mar, 2009, Grimble wrote in the 1st comment:
Votes: 0
I don't know how many of you are writing/maintaining a server in C++, but I suspect at least a few…

I've been looking on-and-off at the asio networking library and finally began the effort to port over to it. Originally I planned to use it just for io, but have found it can be leveraged for scheduled events (e.g., scripts) and background tasks (e.g., hostname lookup) as well. I expect it will simplify my existing server quite a bit.

The documentation is a bit sparse, but if you work through the examples and search the user group postings, you should be able to work through any problems. Anyway, I thought I'd point it out for those who are interested in this kind of thing.
17 Mar, 2009, elanthis wrote in the 2nd comment:
Votes: 0
Are you _sure_ you want asynchronous IO? That is a huge hairy mess that grants almost no advantages to things like MUD architectures.

Nothing with asynchronous IO or background tasks simplifies a server. Especially in C++, where you have to manually deal with concurrency, locking, etc.

I would highly recommend going with an event-based IO, e.g. libevent. For background tasks you shoudl rely on a scripting language that has coroutine (user threads) support. For DNS I'm fairly sure there are DNS lookup implementations that integrate with event-based IO.

Just my $0.02.
17 Mar, 2009, David Haley wrote in the 3rd comment:
Votes: 0
I'd tend to agree with elanthis, you can get the benefits of async IO by using non-blocking sockets, without all the hassle that async stuff gives you. A MUD server doesn't typically need to handle truly async IO where things can come in and any moment and need to be serviced right then. You can emulate that behavior anyhow using a timeout based 'select' call, such that it will return as soon as a socket is ready to be serviced. I am very wary of anything that involves true concurrency in a MUD server.
17 Mar, 2009, Grimble wrote in the 4th comment:
Votes: 0
elanthis said:
Are you _sure_ you want asynchronous IO? That is a huge hairy mess that grants almost no advantages to things like MUD architectures.

Actually, you're not required to run asio multi-threaded. You register asynchronous handlers (think of them as queued work items), that process accepts and reads and writes as needed, but these are invoked serially when running single-threaded. You can then add timeout handlers for scheduled events, which also run serially. Basically, the library implements the main loop for you, resulting in a purely event driven (i.e., tickless) server. This is the main selling point IMHO.

If asio is also used to run background tasks, then you would run it multi-threaded and need to serialize access to any protected data.

In my case (YMMV) there are instanced zones that load on-demand in the background, so I'm already dealing with a thread pool and protected data, and may use asio to take over the thread pool management. I do agree a typical server sees no real benefit from multi-threaded io, but in this case I'm considering it (for not much extra effort beyond what I've already put in) in order to simplify other parts of the server.

Edit: I took a quick look at eventlib mentioned earlier, and the two libraries appear to be comparable. Also, I believe the author of asio has a proposal in to C++ TR2, but I don't know where it stands.
18 Mar, 2009, elanthis wrote in the 5th comment:
Votes: 0
Nice. I'll have to read up on the asio interface more instead of making assumptions I guess. :)

Using threads for zones is a decent idea if you've got that data separation already set. I've been debating doing something similar, albeit using full processes (so a crash only brings down one zone).