[MUD-Dev] Re: Socket-Script: Socket-capabable script language and matching library

[Adam J. Thornton]

Thanks much, folks.  I'm going to implement both J.C.'s and Chris's
suggestions: that is, I'm going to sit down with the design and a cup of
coffee and see if I can easily abstract it into a cleaner parent-child
process model so that the handoffs aren't quite as ugly, but I'm also going
to count on using sendmsg, since it seems to be relatively portable; my
child processes can create AF_UNIX sockets and use those to pass around
connection data as needed.

I'm doing this right now on a Linux box; I doubt that that will change in
the near future, and if it does, I suspect I'd be going to either Solaris
or HP-UX.  I have no plans, thankfully, to write any of the back end code
under Win32.  I'm doing it in C right now, but mostly because I don't know
enough Java and there isn't a Java->native compiler for Linux yet.  (I
don't want the portability, I want the good thread and network support);
does Java provide something equivalent to sendmsg/recvmsg?

I'm not actually too worried about the N-processes-for-N-players problem,
mainly because empty rooms are kind of boring, and I suspect that players
will quickly congregate in rooms with other players.  If I have per-room
scoping then I have a reasonably natural solution to the data
representation problem by making each room a process and making its object
data available to all threads (player objects) running in it.  Object data
is ultimately represented in the database backend, but for each process it
is locally represented in in-memory data structures, which, as they change,
get written to a low-priority database queue thread, which runs when the
cycles are free or gets flushed on some schedule (e.g. every thirty seconds
if it hasn't had a chance to run yet).

One thing I haven't worked out yet in my model is just what to lock when
players move globally visible objects.  I could lock everything in the
room--that is, put a mutex around the room data for as long as it took to
copy the transaction to the DB queue thread--but that locks a lot of stuff
that doesn't need to be locked.  If I'm willing to do the computation, I
can lock the object tree with the manipulated object's parent at its head
(that is, if an orange is in the cupboard, lock the cupboard and everything
in it...but if an orange is in a shoebox in a cupboard, do I lock the
cupboard or the shoebox?), or I can cheat a little and lock the region of
space that contains the object in question (each room has a Cartesian grid
underlying it--if the orange in the shoebox in the cupboard is at (5,5),
lock all objects which are at (5,5)).  This works up until I want objects
that occupy multiple spaces; for instance, ropes.  However, ropes are such
hideously intractable objects (rec.arts.int-fiction yells about this at
least once a month) that I'm tempted to go with a purely localized object
model and do spatial locking, at least for now.

Adam
--
adam at princeton.edu 
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman