> Caliban Tiresias Darklock wrote:
> my final question; is that really a bad thing? I mean, I could handle 16
> 14.4 modems under DOS on a 286 running ZModem downloads on arbitrary files,
> so theoretically I could do about the same with 40 56K lines on a P166, but
> hopefully the Pentium is even faster than that and could handle a lot more.
Of course your maximum number of users is going to depend on the
bandwidth requirements of a given MUD, and the amount of CPU overhead
involved in running your world. But as a single point of reference I
can tell you what we're handling with Furcadia right now. I would guess
that its bandwidth usage is comparable to a typical text mud, and its CPU
usage lighter than most. On a Pentium-90 with 48 megs of RAM,
communicating through an ethernet card to (I think) a T-1, and running
Linux, we're able to handle over 300 players with no noticable server
lag. I think we could do 400 or more. I don't really know what the
limit is before we'd have lag, and I would certainly rather get on a
faster box before we find out. :X)
Currently the server runs 47 independent processes, which talk to each
other through sockets. It's probably going to be boosted to 57 shortly
to meet growing demand. (45 of the 47 are map servers, that'll go to
55.) I personally think threads are an effete affectation. But then, I
think C++ is mostly an affectation too. Furcadia uses one CPU to let
multiple users do some computing at the same time pretty much the same
way the old CDC-6600 mainframe I programmed in 1980 did it. It executes
a bunch of CPU instructions related to what one user wants to do, then
switches to executing a bunch related to what somebody else wants to do,
and since it can do many many many things per second, everbody gets the
illusion of interactivity and of a computer executing their program and
giving them their results. Furcadia does this, multi-threaded programs
do this. One CPU, multiple users, and splitting time between doing stuff
for different users by "some means or other".
If I shifted from my current means to multi-threading, I think there
would be three changes. 1) My ratio of time spent coding to time spent
learning new crap I don't know already will shift further towards learning.
I've already learned how to deal with the operating environment on a wide
variety of videogame consoles and 8 bit 6502 systems in the 1980s, now
obsolete, I've learned multiple computer languages, libraries, protocols,
etc. etc. I maximize my effectiveness and value if I learn just enough
to get the job done, and don't learn much stuff that I don't need and
that doesn't contribute to facilitating or improving my code. There's
enough techno-stuff that's been invented and documented by now that I
could spend the rest of my life reading manuals and learning things,
without ever producing another line of code. This would have little
practical value. On the other hand, I could spend the rest of my life
right now programming neat cool useful new stuff without learning one
single new fact about computers, and that wouldn't be so bad. So the
time spent learning how to do threaded code is basically a negative, that
has to be counterbalanced by enough positive benefits to make it worthwhile.
2) My IPC (Inter Process Communication) would be a tiny bit more
efficient, due to shared access to variables and arrays and stuff. Ok,
this is true, but it's not worth much. My IPC is light, by design, and
always will be. I feel any design where that isn't so is a flawed
design, except for a few problem domains where the task you're trying to
accomplish might inherently require heavy IPC. My tasks don't. Also,
with computing horsepower having grown at a phenomenal pace since I wrote
my first Life program in BASIC in 1978 (I never got it debugged, alas!),
the value of CPU time vs. programmer time has been steadily shrinking -
and thus the portion of your code that it's worth optimizing, and the
level of perfection you strive for in your optimizing chores are both
getting tinier and tinier. I have many optimizations for Furcadia worked
out in my head that have been sitting there since before it opened to the
public, which I will probably never implement because they're just not
needed. I spent an hour and a half optimizing one key part of the
scripting language interpreter two weeks ago, that's about all the
optimizing I've done in the last year.
3) If I were multi-threaded rather than talking through sockets, I would
lose the ability to easily distribute the server over multiple Unix boxes
just by moving the processes to different machines, and making sure to
change the addresses they tried to connect their IPC sockets to to make
sure everybody was talking to the right place. If I really wanted to, I
suppose I could even be spreading the server around between Unix,
Windows, BeOS, Mac, and other types of boxes - though I don't think I
particularly want to. :X) Anyway, I really really don't want to limit
my maximum server size to whatever the largest computer currently made
could handle. And moving up to such a box would probably give me a
poorer price/performance ratio than a bunch of smaller boxes networked
together.
I think the reason this list often brings up solutions that I personally
wouldn't go for, like threading, are primarily a matter of focus. As an
individual I am, of course, more narrowly focused than the group as a
whole. But I also have a tighter focus than a lot of the other
individuals here. This is largely a research community, and I think for
a lot of people their mission as a developer is figuring out what they
want to do with a mud, or what would be interesting to do, or in some
cases they aren't really trying to accomplish any goal so much as having
fun tinkering and learning how different things can work by making stuff
and fiddling around with it. I, on the othe hand, have known for a long
time exactly what I want to do, why I want to do it, and how to do it.
That leads to a very different approach to development.
I look at all the talk about locking stuff and keeping different
independent doohickies from giving you "Dragon's Dilemna" type problems.
I glance at stuff like that and I think two things. One of them is "Gee,
I would have to learn a bunch more technology stuff to understand 100% of
what JC says". But the other one is "Gee, why would I ever want to build
my server architecture in such a way that those kind of problems could
ever even be possible and I'd have to work to prevent them?" And the
answer is that I don't. None of my goals as a game designer, programmer,
architect of server structures that could (hopefully) scale to millions
of users, or business manager lead me to any desire for any software
architecture that would have any sequence or locking issues. Actions
that are sequence critical are handled by the same single-threaded
process in my system, and those processes succeed in making two or more
people at a time feel like stuff is happening for them, 'cause
microcomputers have gone from executing hundreds of thousands of
instructions per second like my first one, to hundreds of millions like
my current one.
In a research environment, though, just about every approach is fair game
to get tried out. And maybe some of the experiments in intense
complexity will lead to valuable new results that will be adapted in the
next generation of commercial products. Personally though, I'm happy
that I'm commercializing older, simpler, stabler and easier technology.
I just want to innovate in user interface design, community building and
enhancing tools, extreme scalability, the delivery and targetting of
advertising, and ways to help people with common interests and tastes
find each other and group together. The idea of having different parts
of my software system fighting over who gets to access the door or room
or dragon object first gives me a headache. :X)
*-------------------------------------------**-----------------------------*
Dr. Cat / Dragon's Eye Productions || Free alpha test:
*-------------------------------------------**
http://www.bga.com/furcadia
Furcadia - a new graphic mud for PCs! || Let your imagination soar!
*-------------------------------------------**-----------------------------*
P.S. The latest addition to my text file of saved quotes is "...and I also
discovered that an employee became even MORE indispensable if he simply
bought donuts for the office twice a week." Thanks!