Ho hum

[clawrenc at cup.hp.com]

In <199704132248.WAA403102 at out1.ibm.net>, on 04/13/97 
   at 11:44 PM, Ling <K.L.Lo-94 at student.lut.ac.uk> said:
>On Sat, 12 Apr 1997, Nathan Yospe wrote:
>> On Sat, 12 Apr 1997, Ling wrote:

>> Hmmm. Did any of us provide personal life stuff?

>Dunno, I thought I'd provide those snippets of information so you
>guys know my leanings and background.  *shrug*  The main bit being
>untrained which means I like to think I've got the aptitude and
>intuition for coding but I don't know all the computer jargon
>(there's a distinct trend to name and patent anything which moves).

Sounds like me, except that I've been around long enough, and read
enough to get the jargon.  

Ahh well, I guess I'm one of the few left who hasn't done the "Hi!  My
name is Bubba and I like beer, and fast women and country music!" song
and dance.  I'll start off with a cut'n'paste of a blob I posted
earlier.  I've inserted editorial comments in [[double squares]]:

--<cut>--
>Which reminds me: How did you write your mud? from scratch? based on
>some routines you had lying around and them fused together?

Oooh boy.  Long story.  Short answer: From scratch, with lots of
retries, restarts, and abandoned dead ends.  I was contracting pretty
much the whole time, so also borrowed lots of ideas from various
workplaces and folded them in (more or less successfully) as I went
along.

Back in, oh, roughly late '84 timeframe I was playing Shades and SX
MUD (MUD1/MUD2) a lot, and started talking to Pippin Caudry (cf IOWA
and Bartle's MUD survey for placement/reference) about writing a MUD
server for him to run on a BBC micro on direct dial-in lines.  About
the time that I actually started work on designing the beast (an
absolute hack I now would shudder if it had seen the light of day),
Pip instead decided to run with a local PL/1 chap who said he could do
the neatest thing since sliced bread (never happened -- Mirrorworld,
which was already in development, took its place).

However, I was hooked on the idea of a really *NEAT* MUD server.

I had hold of a PC, and a PDP-10, and was infatuated with the parallel
processing concepts of the then new Inmos Transputer and Occam.  I'd
also just bought a copy of Zorland C (nee Datalight, later Zortech,
now Symantec) and was teaching myself C.  I generously figured that by
the time I had the damn thing designed and partly written that I'd
have a Transputer based machine with at least three or four T400's to
do the rest on, and Occam would probably have succumbed to C (pray
pray).  <kof>

<<Still got all those early notes and design drafts too>>

By about 1Q87 what with the rest of real life and trashing everything
I'd done a couple times, I had a DB layer all done along with area
import/export, along with offline room, object, and mobile coding. 
<<Can you say three byte longs?  I thought you could.  I used them
*everywhere* in the DB to conserve space (lotsa arrays).  <unghh>>> 
Never did touch the actual run-time aspect then -- was still waiting
for decent MP hardware to do the event stuff on (it was event driven
from the start -- I never even thought of a polling loop).

[[Note: My design model was Shades, encluding its utter lack of
containers, etc but with a lot of the game complexity of MUD thrown in
confusedly]]

Nearly went to work for CIX with an aim to doing a MUD server on the
side for them.  Came back to the States instead.

About the same time I started get on the 'net seriously, and
discovered LP, the Tiny-* clan etc.  Trashed everything I'd done
again, dropped the three byte longs, and decided to go with a simpler
DB, and event architecture running atop MINIX.  Fell in love with Aber
(as a player) and spent an awful long time playing Northern Lights. 
Later decided to move the OS base to XINU.  

MOO (the original, pre-Lambda) happened about this time.  Thought it
was a wonderful idea, but buggier than crap.  Thought the design
concept was neater than sliced bread (everything in the DB, totally
dumb server, objects/methods etc in the DB too, objects animated
themselves).  Also thought the everything-in-memory model was stupid,
and didn't like the polling architecture.  

Started working a lot with OS/2 back when 2.0 came out.  Decided that
this multi-threading thing was a pretty damned neat replacement for
full parallel processing and Transputers, even if not quite as slick. 
Started recoding, moving everything to OS/2 and MT.  Went to a
disk-based DB model with a central MOO-style DB running everything.

Back in Oh, '94-ish decided to do C++ the thing.  Started again. 
Cleaned up the event model a LOT.  

Everything is homegrown.  Major inspirations (mostly in time order):
Shades, MUD2, Transputers, Marcus Ranum, Uber, Unter, LP, Aber, Tiny*,
Northern Lights, MOO, Stephen White, LambdaMOO, a large bunch of IBM's
OS/2 developers, Cool, Interlude (neat!), Dave Engberg, C++, Cold,
Mike Cowlishaw, Legend, ColdX, Greg Hudson, MUQ, BeOS, Inferno, Limbo.

[[Interestingly enough, looking at the above list of (typically)
social-type server references, the types of MUDs I like playing are
pretty hack'n'slash kill-the-wumpus-style monty hauls]] --<cut>--

Life history?  Hit computing back in high school in England doing a
CompSci 'O' level.  The teacher (a Mr King) and I mutually decided
that we were utterly unable to communicate to each other, and tacitly
agreed that we also had no need to and ceased to ever try.  Never did
get the 'O' level.  Did re-write space invaders in Pet BASIC with
decent run-time performance, along with several other games of minor
notoriety in the PET world (a well known growth field).  

That was my last touch with formal eductation or traning.  For various
minor reasons, like hopping countries, the fact I was working already
(started contracting when I was 14/15) and other infatuations I never
did the college thing.  So I'm essentially self-taught from day one.

I've been contracting pretty well since I was 15, starting with a
financial system for Pater written in GWBasic, and moving on from
there by word of mouth to a contact management system for a local
church etc.  I dropped off a couple times for other fun things: taught
school for a year, got back into sailing, etc yada yada, but kept
coming back to contracting.

I won't bother much with the Playboy-style bio bumph:  

  Guiness is the one true form of beer, and all else is a pale
imitation.

  Good wine is the nectar of the gods.

  I consider "political correctness" a lunacy from the ground up.

  I read.  Not so much now (used to average 20 novels a week).

  Most of my education is centred in the pure maths and literature.

  I *love* religious philosophy.

  I don't like Microsoft and refuse to work on or with any of their
products.

  Game design is a big interest.

  Private affordable spaceflight is another.

  Life is a game.  Enjoy it.  Have fun.  It is for the living.

  The last line is meant absolutely literally without reservations or
caveats.

>Earlier, someone mentioned the possibility of the processor spending
>most of it's time time-slicing between multiple threads if there was
>a lot of connections.  

There are two problems here.  

  1) Number of threads used to manage connections.
  2) Total number of threads.

#1 I think is really what you are referencing.  Having one (or
occassionally two) thread(s) per connection is a typical first
approach.  The problem is that it is not scalable.  Consider:  You
have 500 online players?  That means 500 threads PLUS whatever your
server is using.  Most current OS designs don't like such high thread
counts per process (some have hard limits).  The price of the context
shifts between the threads also begins to become significant once you
get that high.  The problem is that it makes for very thread counts
which increase linearly.

#2 Is curiously enough a smaller concern (as long as it doesn't grow
as quickly or as fast as the above).  Threads are cheaper than
processes.  Thread context shifts are cheaper than process context
shifts.  A multi-threaded process will generally run faster than an
equivalent arrangement of seperate processes.  My server idles with I
think 30 or 40 threads.  Start pumping events and users thru there and
the thread count will grow (slowly).  It would take an awful lot going
on to get my server as high as 150 threads -- certainly a lot more
than 500 users.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...