[MUD-Dev] Re: Sockets and fibers

[Dr. Cat]

> 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!