[MUD-Dev] Re: Yet another update on threads and signals

[Adam J. Thornton]

On Fri, Aug 14, 1998 at 07:12:09PM -0600, Chris Gray wrote:
> [Adam J. Thornton:]
> I was going to reply to this thread yesterday, but was checking to see
> if anyone else had good ideas, and then forgot...
> It would add a bit of extra latency, but consider having an extra
> process to act as an fd distributor. Each room-process would have an
> open socket to that process (the distributor avoids each room having
> to have a socket to every other room). Then, to send a player from
> one room to another:

> Departing room:
>     write a message, with room indicator and fd, to the distributor
> Distributor:
>     sitting on select on the set of room sockets.
>     wakes up, reads message and gets fd.
>     writes message on socket to target room
> Target room:
>     sitting on select of player sockets and distributor socket
>     wakes up, sees activity on distributor socket
>     reads message and gets fd - player is moved.

This is basically what I'm doing, except that the distributor doesn't get
"Player Leaving Room X" messages; it just gets "Player Entering Room Y"; it
also picks up "Room X is empty and shutting down" messages.  If a player
wants to enter Room Y, and there's no one in there, the distributor creates
the Room Y process.

I don't have a good way to do "Room X is empty and shutting down" messages;
what I plan to do is open a Unix domain socket in the distributor that just
listens (blocking and having its own thread) for connections; all the
connection (from whatever process) does is tell it what process or what
room is shutting down, so the distributor can adjust its list of active
room processes.

Now, this leads to an inherent problem; there's no per-process
authentication mechanism, so *anything* could be connecting to the
distributor and telling it to mark rooms as unread.

However, this isn't really a problem, I don't think: since I'm using a Unix
domain socket, I know the request is coming from the same host.  If there
are processes running on the host I don't know about, I've already lost.
Likewise, I can get UID and GID from the socket, so I can make sure it's at
least running as the user that's supposed to be running the server room
processes.  Again, if this user is running processes I don't know about,
I've lost anyway.

As far as shared memory and file I/O go; when any player leaves a room, I
need to commit the DB transaction moving the player anyway.  So I'll just
move the player's location in the DB to wherever the door goes.  Then when
the player hits the new room, he or she gets a copy of the object trees in
the new room, which includes the player object tree.

I don't think I have to mess with shared memory at all this way, and file
I/O disappears into the database transaction layer.  At worst I have to
pass the player object tree along with the file descriptor when I move the
player from room to room.

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