[MUD-Dev] Modular Design Issues RFC

[Ryan Rhodes]

> >From Ben Chambers
>
> > When I say hot bootable I mean to allow a reboot of the Data Backend
> > without a reboot of the game, or the game without the server and vice
> > versa.
>
> If you reboot data backend, the game has to go down for a second, how
> do you load data for the game without the data backend?  How do you
> run the game without the server?

To be honest Ben, I was just trying to understand concenpts I've heard
discussed here.  My server runs on one process.  I made the assumption
of a hot bootable backend because I've read about systems here I
believe that maintain the connections on the server and in the event
of a mud crash and just hold them until its finished rebooting,
repluging them in where they were before crash.  So I'm really looking
for comments here on any systems that allow a hot boot of the mud
while the server holds the connections.  As I think about it your
correct, the game would at least have to pause for a reboot of the
backend, which means the only real advantage of separating the backend
into its own process would seem to be to keep it on a separate
machine.  If anyone does use a system like this I'd appreciate any
comments on that as well.

In addition, I've heard talk of distributing the connection servers
across multiple systems, but my question here is this.  Doesn't having
connections across multiple servers mean in the end you are echoing
the I/O to the game server anyway, causing the same overhead.  Does
anyone out there have a system where the connection server runs on a
different machine that the Game Server?

> one looping thread for each player connected?

I'm not sure your question here.  In terms of one thread per
connection to read input, java requires this.  The only way to
generate a Connection Closed exception for thread death is to be
constantly blocking for input.  Java doesn't allow you to stop
blocking once you have started, nor does it provide any sort of
asynchronous method to read input.  You can check for the ammount of
input available before you read it, reading in just enough to prevent
blocking, but then you can't capture link death.

In terms of one looping thread for each player to process their input
and generate game events, this would be a separate thread and a
separate question.  For some reason I have in my head that the
commercial graphic games work this way, but I don't understand how the
data and action could be synchronized if every player was runing
around and acting on his own clock so to speak.  So I'm asking if
anyone out there has a system that works like this.  In particual if
anyone knows if commercial games work like this.  My system, again,
does not.

Ryan


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev