[MUD-Dev] Re: TECH: Distributed Muds

[Jon Leonard]

On Mon, Apr 30, 2001 at 09:02:17AM -0700, Caliban Tiresias Darklock wrote:
> On Fri, 27 Apr 2001 15:38:45 -0400, "Jon Lambert"
> <tychomud at ix.netcom.com> wrote:

>> Any new ideas on efficient network designs that handle large
>> numbers of sockets?
 
> Virtually nobody is releasing source code for high-performance TCP
> network servers where the socket STAYS OPEN for extended periods of
> time. There are web servers which support HTTP 1.1 keepalive, but
> that's not quite the same thing. I've found many clients which do
> this, but no servers to speak of. I don't think I'm smart enough to
> design one, so I'm just sort of faking it. ;)

To tell the truth, I'm not sure that it's all that important...

The problem with select (and poll as well, in a MUD-like context where
most descriptors are active/interesting) is that it filters the
network activity behind an interface with quadratic cost.  That is,
each connection needs to be checked every time (if only in kernel
space), and the activity also scales with the number of sockets.

For a real fix, we need a new interface to the kernel, and maybe a new
system call.  Something like the AmigaDOS interface where IO messages
all arrive at the same port, and then are inspected as to source
scales much better.  The best unix equivalent I can think of would be
a special device, that when read gives the 'next' active file
descriptor.  So instead of calling select, you'd just read the next fd
(and possibly blocking), and process that.  A read with timeout call
would be even better.

But there are simpler (and portable) workarounds if your MUD load is
really that high.  You can run connections through port concentrators,
which substantially reduces the quadratic part of the load.  It does
other things too: Some of the load can be moved to a different
machine, the per-process FD limit is avoided, and server crashes no
longer need to lose connections.

And that's only needed if the select() (or poll) portion of your
process is really a significant portion of the load.  If the server is
otherwise loaded, the select() call can catch several active sockets
at a time...

In short, write the network interface portion so that it can be easily
replaced, and then worry about other parts of the server.  They
probably need work more anyway.

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