[MUD-Dev] Re: TECH: Distributed Muds
Dominic J. Eidson
sauron at the-infinite.org
Thu Apr 26 19:47:56 New Zealand Standard Time 2001
On Thu, 26 Apr 2001, Derek Snider wrote:
>>From Christopher Kohnert, April 26, 2001 3:53 PM
>> You know, I've been curious. I've tried to get that sort of idle
>> time in some prototype servers I've implemented. Granted, I have a
>> sort of nasty requirement in that my 'tick' needs to be in 1/100th
I think your main "problem" is that you still use "ticks" (Then again,
maybe I'm biased... Read further :)
>> of a second. I've done a blocking select on the sockets but found
>> the latency for commands entered on any of the sockets to be too
>> unbearable. My question is how you achieve a 90% idle rate with any
>> sort of responsive sockets. Perhaps a simple usleep() with no
>> actual blocking select? I'm just curious because I've found that
>> anything other than a tight non-blocking polling loop is just
Well, it seems to me that DIKU (and it's derivatives) are the only mud
bases out there that handle I/O and/or sleeping - the "wrong"
way... Cold, DevMUD, (it's sister, BozoMUD) and others, seem to do
it IMHO, correctly.
The basic premise is to sleep in select() either until the next event
is due to ripen, or until I/O happens. If there are no events
scheduled, you sleep indefinitely (or until I/O happens).
Of course, a requirement of a system like this, is the proper
implementation of an event queue/heap, and the need to re-design all
the things that are done via DIKU's "heartbeat" - having an event
re-schedule itself when it's done doing it's duty.
A neat side effect of this is that when there's nothing "going on" and
no I/O happening - the mud truely sleeps (uses no cpu time).
Performance of doing it in this fashion seems very good - I've had 150
connections open, all of them submitting data to the mud, coupled with
a few thousand objects wandering around (recurring "move in a random
available direction" event), and not experienced any performance
degradation (Was using about 5% CPU on the old K6-2/500 - now, on the
Athlon/800 - I think the issue will be I/O bound-ness)
Dominic J. Eidson
"Baruk Khazad! Khazad ai-menu!" - Gimli
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev