nu.kanga.list.mud-dev

19017: RE: [MUD-Dev] Re: TECH: Distributed Muds

From Chris Gray, April 26, 2001 9:31 PM:
>> From: "Derek Snider" <derek@idirect.com>
 
>> A blocking select would make it so your server would only be able
>> to do anything when it receives a command... and would not be able
>> to do any other tasks -- unless it was multi-threaded.

>> You need it to be non-blocking, with a small delay in your main
>> loop.
 
> You don't use select() to delay for a time interval. You can use
> other techniques for that (unless you have some specific reason, of
> course). You use select to wait for socket activity *or* a specific
> time interval. That's what it was designed for, and that works just
> fine for a MUD server. I've used it in both of mine with no troubles
> at all. In AmigaMUD, I don't have time "ticks", but you can schedule
> activity with 1/20 second granularity, and using select() works just
> fine. That way, the server is absolutely idle until either the next
> scheduled event is ready, or there is some socket activity that
> needs attention. Oh yes, I find I need a hundred of my fake
> "players" before I notice much load at all on this 300 Mhz PII.

Why not use select() to delay?  It's the best way under UNIX.  You
select() on a NULL set with a timeout.  If you select on the socket
with a timeout, then you have no delay if there is activity.

You are talking about a totally event based system... which is fine as
long as there aren't constant events ;)

DikuMUD's system works fine as well.  I run Realms of Despair on a
333Mhz PII, along with ftp.game.org, www.game.org, www.smaug.org, as
well as two secondary copies of the MUD... one for building.

Realms of Despair has handled well over 700 players without any load
on the machine.

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