[MUD-Dev] How to support 1000+ simultaneous connections, and some philosophy.

[Oliver Jowett]

On Wed, 10 Mar 1999, Ben Greear wrote:

> > - When a child gets this message, it calls accept() on the accepting
> >   socket and starts handling that connection.
> 
> Sounds great, but I know of no way to implement this.  Don't think you
> can
> pass descriptors around from process to process.

Well, you can pass fds between unrelated processes (via unix domain
sockets and sendmsg and general uglyness), but this scheme doesn't need it
because..

> > - If the parent finds there are no free children, it starts a new one
> >   (inheriting the common accepting socket)

.. the children just inherit the socket when they are started.

Maybe I wasn't clear, the approach I was suggesting has the central
game server as the parent of many fork()ed children that actually talk to
the clients. The socket is set up once, in the parent process, and
inherited by all the children.

> > Might work. This would also let you balance the connection load between
> > several children (assuming the children do a bit more than just
> > en/decapsulate and pass on data)
> 
> I want one main program doing all the work, and potentially many small,
> stupid
> servers accepting and MUX/DEMUXing data to the main server.  Thus the
> main
> server has few descriptors (just pipes/sockets) to the stupid acceptor
> servers.

That's what I was describing. Once you have that scheme in place, you can
potentially move code to do things like batching up client input into
lines, output compression, etc. into the children - these are pretty much
independant of the game itself, and seem like a relatively easy way to
take advantage of whatever hardware parallelism you have available. 

-O



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev