[MUD-Dev] Modular Design Issues RFC

[J C Lawrence]

On Mon, 12 Feb 2001 20:43:23 -0800 
Ryan Rhodes <ryanshaerhodes at hotmail.com> wrote:

>   Question: Is it not true, that while we may divide our system
> into threads and processes to deal with other issues, we do not
> divide our system into threads and processes to increase the
> logical modularity?

This can be true, it often is true with inexperienced designers, but
it need not be true.  It also happens to be a thing which is usually
revealed on the second re-write.

> 2. To allow components to be hot bootable

A btter term is perhaps, "fault tolerance".

>   Question: Are these the only two reasons to divide a system into
> separate processes?

Scalability is usually the driving force with performance a close
cousin.  Reliability (through distribution, redundancy and fail
over) occassionally follow.

> I've seen three primary candidates in the posts for a separate
> process.

>   1. Game Servers 2. Connection Servers 3. Data Servers

Loosely, there are two distribution models: horizontal and vertical.
You have described a vertical model in building a stack of services
which build each atop the others to present a service.  A vertical
model, for instance, would have multiple processes, each
representing the game world to their connected players and handling
the compleat process/function stack from the connection socket all
the way down to the backing store, and working cooperately with the
other simultaneous processes in regard to significant data which is
currently resident in another process via IPC.  (If you want to
think about this in architecture terms, think about CC:NUMA for a
bit as a possible model).

> The game would be distributed only if you wanted to allow for
> worlds, or a world, distributed over multiple systems.
> Distributed servers to allow for multiple login sights and
> connection handling over multiple systems.  It would seem as if
> the database should, at least logically, appear as if it's on a
> single machine but could easily be distributed.  All three
> components might even run on a single system and receive the hot
> booting benefits of a distributed architecture.

I think you need to think about this a bit more.

>   Question: Are these the only three logical subsystems that
> benefit from distribution?

No.

> Having the logical modularity and distribution issues already
> covered, there seems to be left only 4 reasons for threads in a
> system.

To allow for continued system processing and reasonable
responsiveness during high latency operations (something that
threads and multi-processing both address).  The advantage of using
threads is that they share the same data segment and thus remove the
IPC overhead implicit in a multi-process model.  An advantage of a
multi-process model is that many of the abstractions needed to move
to a physically distributed model are already done in moving to the
multi-process model (there are massive exceptions here, I know
(signals, shared memory, etc)).  Note: An advantage of moving away
from a single process/stack model is that long running processes
(internal to the execution) need not hold up other processes, and
need not suffer the internal locking/deadlock complexity of doing
their own context shifts (cf MOO).

> 1. To block for Data Base I/O 2. To block for Socket Input 3. To
> block for incoming connections 4. To simulate time and action in
> the world

Don't think blocking, think latency.

> The posts have confirmed my own experience with java in that you
> can't interrupt a thread from blocking for I/O (please post
> anything to the contrary).  

And we used to think that BASIC bred bad programming habits?

> Question: When you divide these various things into threads are
> you generating the ticks for players in the area from this thread
> also?  

I don't have a tick system at all.  I do have some rate limiting
systems, but those simply control how rapidly or frequently
something may happen, not the frequency at which something will
happen.

> Are you parsing input and generating game action for players in
> the area from this thread?  Are you handling the timing of weather
> events from the weather thread or combat events from the combat
> thread, for those of you that do this?

I believe my basic process model is fairly well decribed in previous
posts.

> Assuming that our architecture modularizes the system logically.
> We've used distribution for the reasons stated above and threads
> to eliminate I/O blocking from halting the CPU.  Beyond that,
> using additional threads to simulate time and process game events
> just slows down the system.

Large process tables are generally a Bad Idea, no matter how many
are blocked.

>   Question: Is it not true then that to divide any non-blocking
> sequential piece of code into multiple threads only degrades
> performance.  Threading is used purely to prevent the CPU from
> waiting on I/O?

I'm told by Intel that even on a single processor system, in certain
cases due to command pipelining a threaded or multi-process
architecture may run faster than a single process architecture due
to being able to better take advantage of parallel execution paths
within the CPU.  (This came up during the Linux/IA64 port, but I
didn't follow up on it at that time and no longer work in that
field)

>   Question: Am I correct in assuming that most game systems out
> there use a single threads "Game Loop" to simulate time and,
> indirectly, trigger the parsing and processing of all game events?

Yup.  It has the advantage of simplicity and obviousness.

>   Question: What are the design and synchronization issues
> involved in a system where every player is parsing input, moving,
> acting, delaying, and generating events from his own thread?  What
> are the benefits?

This is a data model and consistancy question.  Without knowing your
assumptions its impossible to asnwer.

--
J C Lawrence                                       claw at kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev