[MUD-Dev] New to MUD Dev, need friendly advice!

[Mike Shaver]

On Apr 25, Jacob Cord wrote:

>>   1. Connections - What is the best method for accepting multiple
>>   connections? Ive heard individual threads are an awful idea,
>>   and
 
> I'm no pro in high availability here, but as I understand
> (primarily Linux) sockets, if you are going for a real high number
> of connections, you can either fork() child processes to handle
> incoming connections or spawn threads, but some methods will share
> socket file descriptors and others won't, so it requires some
> planning up front.  Also (in Linux, anyway, any Windows experts
> have comments about this?), you need to be careful with high-load
> servers when you are spawning new processes that you don't fill up
> the process table, since even when processes die they don't always
> get removed right away.  Perhaps I should just leave this to the
> other more professional people on this list :)

Modern Linuxes have configurable (at compile-time, if nothing else)
thread/process table sizes, I believe.  There are people running
tests with tens of thousands of threads, and likely hundreds of
thousands.

The best starting resource I know of for high-connection-count stuff
on Linux is http://www.kegel.com/c10k.html, though it's not clear
that it's been thoroughly updated for the 2.5/2.6 enhancements.  (It
does mention the NPTL stuff, though, which is a big piece.)

Using threads vs. an event-driven state machine system is largely a
matter of personal preference.  If you want to have the extra
control over scheduling and lock-necessity (which go hand-in-hand),
you can do a lot more with a state machine than with the pthreads
interface.  If you have low cross-thread contention for "hot"
resources, using threads can provide a simpler programming model,
since the compiler and kernel scheduler can do a lot of the
book-keeping for you.  The high-performance clustered filesystem I
work on uses threads for parallelizing message handling, and while
we're investigating the value of moving to an explicit event-driven
model, it's starting to look like just spinning up a few hundred
threads (!) on the metadata server will be ample to keep
thread-availability from being the limiting factor, and will greatly
simplify the programming model.

Even if you go the thread route, using threads to process
"messages", rather than spinning up a thread per connection, is
likely a win.  There isn't a lot of state that you're going to need
to keep consistent between messages that's not already somewhere
else convenient, I suspect, so the stream-of-control model that a
dedicated thread provides won't be especially useful.  (You're
possibly also going to want to process multiple messages at a time
for a client, which is "easy" when you dispatch events to a pool of
threads, and "hard" when you've got a thread-per.)

Mike

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev