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

[J C Lawrence]

On Wed, 5 Aug 1998 00:38:40 -0400 
Adam J Thornton<adam at phoenix.Princeton.EDU> wrote:

> My world-model is room-based.

> Thus, when someone connects to a particular server or changes rooms
> within a server, the connection-handling daemon checks to see if
> anyone is in the room; if not a new process is created, one process
> per room.

Ouch.  I presume you are aware of the scaling problems here (pessimal
case of N processes for N players).

> That process then loads all the data for things in the room from the
> database and keeps it in in-memory structures.  The player
> connection gets a thread within that process.

<nod>

> What I haven't satisfactorily solved is the case where the room
> already has players in it and I want to put a new player in the
> room.  Sending a signal to the process I want to create a new
> connection thread in is relatively straightforward (thus letting the
> signal handler deal with the initialization of the player thread),
> but passing the filehandle that represents the player's connection
> into the pre-existing process is not something I immediately clearly
> see how to do cleanly.

This is very minorly language dependant in that this may be impacted
by language virtual machines (ala Java, Limbo etc) which may run file
handles thru a VM-specific global system (unlikely).  Mostly it is OS
and TCP/IP stack dependant.  Under Unix you're out of luck.  Under
Unix file handles are private to processes and *CANNOT* be handed
between processes (without nasty kernel/TCP/IP stack hacking> (ie file
handle 0xXXXX under one process has no relevance to handle OxXXXX of
another process).  Under OS/2 (dunno about Windows) file handles are
global meaning that as long as you pass the value of a handle between
processes, a remote process can re-open and address the same file
handle (this is commonly and rightfully considered a glaring and
critical security hole in OS/2's TCP/IP stack design).

So, what to do about your design?  Abstract the problem.  The simple
soltuon is to have a connection process which handles all the TCP/IP
traffic and then communicates via Streams or other standard IPC
channels to your room processes.

            | (host)
            |
            |                         room process
            |        room process    /
            |       /               /
  user <--> | <--> connection process <--> room process
            |       \               \
            |        room process    \
      (net) |                         room process

The pipe/channel to the room process could then be handled via
standard means (signal/semaphore/whatever, tho semaphore levels are
probably the cheapest approach).

This of course also has the side effect that all your room processes
can go down and come back up without the player's connections being
dropped.

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...