[MUD-Dev] Re: TECH: Distributed Muds

[Dominic J. Eidson]

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
>> 'laggy'.

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[1], (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

[1] http://devmud.slimy.com/

--
Dominic J. Eidson
                                        "Baruk Khazad! Khazad ai-menu!" - Gimli
-------------------------------------------------------------------------------
http://www.the-infinite.org/              http://www.the-infinite.org/~dominic/







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