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

[Ben Greear]

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
can
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,
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.


Of course, other option is to run on multiple ports and write a custom
client
that knows how to negotiate a handoff.

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

--
Ben Greear (greear at cyberhighway.net)  http://www.primenet.com/~greear 
Author of ScryMUD:  mud.primenet.com 4444        (Released under GPL)
http://www.primenet.com/~greear/ScryMUD/scry.html


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