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

Oliver Jowett icecube at ihug.co.nz
Wed Mar 10 19:48:56 CET 1999

On Tue, 9 Mar 1999, Ben Greear wrote:

> It looks like you'd want one program sitting on your well known
> port, accepting connections.  It could be attached to the 'real'
> server via a single socket or pipe.  A trivial packet encapsulation
> with a unique ID as far as the main server is concerned should
> work just fine.
> However, I wonder what to do when the accepting server on the
> well known port is full?  One thing would be for it to quit
> listening and spawn a new process on that well known port?
> That works for a while, but then how do you re-use this detached
> server when it's load goes down again?
> Anyone know how Apache does it?

Apache appears to use a mutex to make sure that only one child is
attempting to select on the accepting socket at once (it's set up once, in
the parent).  This isn't really the same as the problem here since we
don't want to completely block the child servers.. 

Perhaps something like:

- Parent sets up accepting socket on well-known port

- Parent does the select() on the accepting socket. When a connection is
  ready to be accepted, it picks a free child and sends it a control
  message to that child saying "accept a connection now".

- When a child gets this message, it calls accept() on the accepting
  socket and starts handling that connection.

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

- When a child gets full, it sends a message to the parent saying "no more
  connections for me please". When it gets space again, it sends the
  opposite message. The parent keeps track of which children are free
  to accept new connections based on these messages.

- If a child gets a "accept a connection" message and it's full, it sends
  an appropriate message to the server to farm it out again (this is
  possible if the "I'm full" message didn't arrive in time)

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) 


MUD-Dev maillist  -  MUD-Dev at kanga.nu

More information about the mud-dev-archive mailing list