[MUD-Dev] Re: TECH: Distributed Muds

Derek Snider derek at idirect.com
Fri Apr 27 12:57:43 New Zealand Standard Time 2001


>From Caliban Tiresias Darklock, April 27, 2001 12:18 AM
> On Thu, 26 Apr 2001 20:31:37 -0700, J C Lawrence <claw at 2wire.com> wrote:

>> I've never liked the base concept of a select() looping process
>> that tried to do real work between select() calls.  It can work to
>> be sure, but it has always smelled of playing with fire.
 
> I've always seen it as sort of an "every other MUD does this, it
> must be a good idea" solution. I think most people who start writing
> a MUD server concern themselves first and foremost with making a
> good *MUD* instead of with making a good DB core, a good object
> model, and a good communications link. Those who do try to get into
> those areas seem to go with the object model and the DB more than
> the communications.
 
> Don't mention this communications model on any kind of network
> programming forum, though. You'll never hear the end of how stupid
> you are. ;)
 
>> I prefer having a thread dedicated to socket IO, pulling in and
>> buffering the IO as received, and then handling compleated blocks
>> off to one or more queues (depends on whether you do pre-sorts) for
>> the other game systems to pick up and process appropriately.  There
>> are several advantages, not the least of which is that you decouple
>> your command/entry model from your processing model.
 
> That's pretty much what I consider the "ideal" model, myself. I
> don't do it, because I'm still not entirely comfortable with
> threads, but I'm working on getting there. Currently, I still use
> select() for I/O, just because... well, every other MUD uses it. :P

Select() looping is one of the best ways to have a single-process MUD.
Threaded/multi-process MUDs are a completely different story.  It's
like comparing apples and oranges.

It works well for what it does.  I've played with the model to make a
working single-process BBS system (which was a kinda clone of
MajorBBS, if anyone remembers that), which ran as a single process,
and had modules to support HTTPD, SMTPD, the BBS itself with a
teleconference module, mail module, and a telnet module.  It ran quite
well.  I made the pulses 1/16 seconds rather than 1/4 seconds, and
made the routine that flushed the output buffer push out a maximum of
2K/pulse (which means you'd get a maximum HTTP download rate of
32K/second -- this was meant to be a BBS, not a webserver.)

Also, as I stated, I've tested this model up to 768 players, and
others have likely tested it higher.  It works well for single process
MUDs up to 1,000 players.

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



More information about the MUD-Dev mailing list