لطفا منتظر باشید ...
21.4 A Multiuser Domain
A multiuser domain, or MUD,
is a program (a server) that allows multiple people (clients) to
interact with each other and with a shared virtual environment. The
environment is typically a series of rooms or places linked to each
other by various exits. Each room or place has a textual description
that serves as the backdrop and sets the tone for the interactions
between users. Many early MUDs were set in dungeons, with place
descriptions reflecting the dark, underground nature of that
imaginary environment. In fact, the MUD acronym originally stood for
"multiuser dungeon." Some MUDs
serve primarily as chat rooms for their clients, while others have
more of the flavor of old-style adventure games, where the focus is
on exploring the environment and problem solving. Others are
exercises in creativity and group dynamics, allowing users to add new
places and items to the MUD.Example 21-4
through Example 21-8 show classes and interfaces that
define a simple user-extensible MUD system. A program like this MUD
example clearly demonstrates how the RMI programming paradigm
transcends the client/server model. As we'll see,
MudServer and MudPlace are
server objects that create the MUD environment within which users
interact. But at the same time, each user within the MUD is
represented by a MudPerson remote object that acts
as a server when interacting with other users. Rather than having a
single server and a set of clients, then, this system is really a
distributed network of remote objects, all communicating with each
other. Which objects are servers and which are clients really depends
on your point of view.In order to understand the MUD system, an overview of its
architecture is useful. The MudServer class is a
simple remote object (and standalone server program) that defines the
entrance to a MUD and keeps track of the names of all the places
within a MUD. Despite its name, the MudServer
object doesn't provide the services most users think
of as "the MUD." That is the job of
the MudPlace class.Each MudPlace object represents a single place
within the MUD. Each place has a name and a description, and lists
the items in the place, the people (users) currently in the place,
the exits from the place, and the other places to which those exits
lead. An exit may lead to an adjoining MudPlace on
the same server, or it may lead to a MudPlace
object in a different MUD on a different server altogether. Thus, the
MUD environment that a user interacts with is really a network of
MudPlace objects. It is the descriptions of places
and items, and the complexity of the linkages between places, that
give the MUD the richness that makes it interesting to a user.The users, or people, in a MUD are represented by
MudPerson objects. MudPerson is
a remote object that defines two methods. One method returns a
description of the person (i.e., what other people see when they look
at this person), and the other method delivers a message to the
person (or to the user that the MudPerson
represents). These methods allow users to look at each other and to
talk to each other. When two users run into each other in a given
MudPlace and begin to talk to each other, the
MudPlace and the server on which the MUD is
running are no longer relevant; the two MudPerson
objects can communicate directly with each other through the power of
RMI.The examples that follow are long and somewhat complex, but are worth
studying carefully. Given the complexity of the MUD system being
developed, however, the classes and interfaces are actually
surprisingly simple. As you'll see, remote method
invocation techniques are very powerful in systems like this one.
