[MUD-Dev] How to support 1000+ simultaneous connections, and some philosophy.
greear at cyberhighway.net
Wed Mar 10 19:43:44 New Zealand Daylight Time 1999
Matthew D. Fuller wrote:
> On Tue, Mar 09, 1999 at 10:03:22PM -0700, a little birdie told me
> that Ben Greear remarked
> > 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.
> > 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?
> I believe (but don't kill me if I'm wrong) that Apache does this by
> having the master httpd accept() all the connections, and then pass them
> onto one of the child processes to do the page serving, though a pipe or
> shared mem or some other IPC. That seems to be The Way To Do Things
> among a lot of higher-volume servers like that.
Yeah, but how can you hand a socket to another process? Let me
that: How can you hand a telnet connection to another process?
> Personally, I find it easier on the small scale (and 1000 is small scale,
> large scale is 40,000 or so) to just pump up the number of descriptors
> per-process in the OS kernel. This, of course, carries its own set of
> complications, and I suspect it'll really start choking beyond maybe 10
> thousand, but if my own personal ultimate MUD ever gets a) finished (not
> likely, it'll never be finished) and b) that popular, I'll be more
> surprised than the next person. I'm relying on brute force, sure, but
> enough of it will always work ;>
I'm thinking of making a very lightweight multi user environment. I
would be cool to add to an E-commerce site. Then you as staff it with a
paid sales associates. Thus, instant communication with your customer.
asuming that if you are already surfing the web, you have no ability
line) or no desire to pick up the phone. I would strip my current
to the bones and then build back up to what I desired. Along the way,
like to implement something that can scale up to obscenely large
your CPU can handle it.
> > Btw, as an observer of human behavior, I don't understand, but
> > think it is significant, that as soon as the dev-mud project came
> > online, there was a rash of implementation detail posts, and then
> > almost silence on both groups. Books have been written about
> > the outcome of clashes between a fantasy realm, and a 'real' realm.
> > I think that is what we saw played out before our eyes. The high
> > fantasy of imaginary realms, features, and lofty goals collided
> > mightily with databases, language choice, and the ugly details of
> > reality. After a huge amount of sparks, both lie almost in a coma.
> > Am I being too melodramatic? Did I just get dropped from the lists? :)
> It's some sort of psychological exponential backoff in action I think :)
> You get the flurry of debate and suggestions, and eventually those most
> concerned, able, and interested go off and start implementing (and thus
> tend to shut up and code), and the rest realize they've said all they
> have to say, people have made their decisions, and get bored with it.
> > Anyway, good cheer to all,
> > Ben
> | Matthew Fuller http://www.over-yonder.net/~fullermd |
> * fullermd at futuresouth.com fullermd at over-yonder.net *
> | UNIX Systems Administrator Specializing in FreeBSD |
> * FutureSouth Communications ISPHelp ISP Consulting *
> | "The only reason I'm burning my candle at both ends, |
> * is because I haven't figured out how to light the *
> | middle yet" |
> 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