[MUD-Dev] How to support 1000+ simultaneous connections, and some philosophy.
greear at cyberhighway.net
Wed Mar 10 19:48:30 New Zealand Daylight Time 1999
Oliver Jowett wrote:
> 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.
Sounds great, but I know of no way to implement this. Don't think you
pass descriptors around from process to process.
> - 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)
I want one main program doing all the work, and potentially many small,
servers accepting and MUX/DEMUXing data to the main server. Thus the
server has few descriptors (just pipes/sockets) to the stupid acceptor
Of course, other option is to run on multiple ports and write a custom
that knows how to negotiate a handoff.
> MUD-Dev maillist - MUD-Dev at kanga.nu
Ben Greear (greear at cyberhighway.net) http://www.primenet.com/~greear
Author of ScryMUD: mud.primenet.com 4444 (Released under GPL)
MUD-Dev maillist - MUD-Dev at kanga.nu
More information about the MUD-Dev