War SERVERS and CLIENT States:
The Client-Server Paradigm for Wargaming
[Documents/03-ClientServer.txt]
Ernest Prabhakar, 28 Sep 93

A. Background

One of the most important concepts for distributed wargames - as well
as for the computer industry as a whole - is Client-Server computing.
As someone mentioned earlier, the question of "what games we support"
is largely a question of "what does our server support".  At the risk
of manifesting my ignorance, let me attempt to define what that means,
and its importance to our design.  Feel free to disagree or correct
me.

The basic idea behind Client-Server computing is that there is some
shared resource handled by a "server," and any number of independent
"clients" which access that resource.  This to be distinguished from
"monolithic" systems where everything is of one piece, and
"master-slave" systems where the slaves can only do what the master
tells.  In hardware terms, client-server is workstations with a
file-server, monolithic is a standalone PC, and master-slave is a
mainframe with terminals.

Now, it is not really necessary for the clients and servers to be on
separate machines, although that is the usual paradigm.  The main
issue is that the client and the server take care of their "own
business", and communicate with each other according to a well-defined
interface.  A properly written server can be used with a whole bunch
of different clients, without knowing very much about them.  For
example, our AIX file server has RS/6000s, a NeXT, a SUN, and a PC as
clients.  The reason it can do that is because each of those clients
supports a well-defined protocol (in this case, NFS) for two-way
communication with the server.

B. Application

By this point, some of you are asking:  "What does this have to
do with wargames?  Am I on the wrong list?"  Fear not, all shall be
made clear (I hope:).  The essence of wargaming, as someone pointed
out, is conflict.  Whether it is between several humans, or one human
and the computer, there is some finite resource which the different
players are trying to access (and control), whether it is territory,
wealth, or prestige, or whatever.  This natural breakdown of a wargame
into a common resource and autonomous players fits very naturally into
the client-server paradigm.

In practice, however, this is rarely done because of the hassles
involved in inter-process (not to say inter-machine) communication.
Games are written in master-slave mode because either authors do not
know how to use client-sever, or because they do not feel it is worth
the effort.  Thus, one of the goals of WarKit is to develop a protocol
(and perhaps one or more actual servers) for multi-player gaming.
This may be of use for much more than wargaming (e.g., poker!), but
that is what we will start with.

The first thing to realize is that client-server, with its separation
of interface from implementation, maps very naturally onto objects.
Thus, we will consider our server as a single object with a formal
Objective-C protocol for clients to use with it.  Similarly, there
will be a similar protocol for clients that the server will use.
While for communication purposes, we will deal with only one object
for each client and the server, in practice there can (and will) be
many more objects, which the "WarClient" and "WarServer" objects will
forward messages to.

C.  Questions

The most difficult question in client-server systems is to decide
which information should go where: who "owns" any particular object.
In my opinion, there are three essential things that the server needs
to do.  The first are two are primarily messages responded to, while
the last is primarily messages sent.

	- access to the players
	- information on the "geography" of the "world"
	- "clocking" of "events"

Note that these parallel the earlier definition of wargame,
as the application of force (players) across space (geography) and
time (events).

The quotes indicate that these are convenient terms for concepts
which are much broader than the word might imply to some.  In the rest
of this essay, I will attempt to define these terms and ask some of
the relevant questions.  The composition of the client will be dealt
with in a following essay (after we have answered all these questions,
of course!).


1. Players

Obviously, each player (or client - I will use the terms
interchangeably) needs to be able to get ahold of the others.  It is
may very well be possible to just have a list on the server, and
clients can add or subtract themselves from the list.  It should also
be easy for the client to get a (current) copy of the list from the
server, in order to send messages to other clients.  By having players
directly message each other, we can greatly simplify the work of the
server.


2. Geography

However, there are a number of things which are not properly the
domain of individual players.  There is a common world - in concrete
terms, a gameboard - which all the players need access to.  For
example, I have a piece which is trying to shoot another piece, and I
need to know whether there is a clean "line of sight".  To do that, I
would (possibly, depending on how we work it) message the server
asking whether the "geography" would allow it.

I have noticed two different aspects of geography, and I am not sure
of their relationship.  One is "topology" - what is connected to what?
This is primarily an issue for movement.  Does the board wrap around
the edges?  Does the world consist of disjoint rooms with finite
connections?  The other is "terrain" - what is the current location
like?  Is it steep, crowded, arid?  Does it obscure vision?  Does it
obscure hearing or smell!?!

I think these may be two separate problems (topology and terrain) -
and hence two separate protocols, but I am not sure.  What kind of
information do clients want about them?  Is it possible to parametrize
most of it?  Or will clients use "isKindOf" messages to figure out
what type of terrain they are dealing with?

Please note that when I say geography, I do not necessarily mean a
two-dimensional hexmap.  I could have a three-dimensional, continuous
space for an interstellar combat game, where terrain could be planets,
asteroid fields, or even gravitational fields.  Or I could like in an
Escherian, non-Euclidean space of rooms with bizarre connections
between them.  Is there some general interface that would work with
all these different implementations?

Closely related to topology is the issue of location.  Who knows where
a piece is located: the client, or the server?  The former has the
advantage of encapsulation, the latter has the advantage of
efficiency. For example, consider the case where you need to find all
the pieces from all the different players within a given region.  Is
it enough to poll all the players for their pieces?  Or would it be
much better for the server to have all the pieces organized by
location, and clients poll the SERVER to find 'nearby' pieces, rather
than polling all the other clients.

[Random thought:  make the location information a C++ class for
encapsulation and efficiency]

This breakdown implicitly assumes that the only "spatial" interaction
pieces have is moving, sensing, and attacking.  Is that too
simplistic?  Can other activities - for example, in role player games
- be handled in those terms, OR be handled player-to-player independent of
terrain?

Also note that clients will want to know about geography not just as it
affects the behavior of pieces, but also for the purposes of
displaying a map.  We will discuss this more when we consider the
responsibilities of the client, but it is worth mentioning now.  Is
there a representational model that works well for both 'digital' and
'visual' information?

3. Events

My boss (a high energy physicist) just put on his door:
	"Time exists to keep everything from happening at once"
	"Space exists to keep everything from happening to you!"

Virtually every wargame has some system which determines who can act
at any given time.  The simplest is where each player is given
exclusive turns in which they can act, and other players just react
psuedo-passively.  In SQPR, though, there are individual leaders on
the board who go in a precise sequence - somewhat independent of which
side those leaders are on.  Would those leaders be separate players?

Consider further that some pieces may have a time-varying state, which
needs to be updated regardless of whether the player does anything
with them.  Does the server send the player a 'clock tick' for the
smallest possible time increment?  Or, rather than a clock, does the
server maintain a general "event queue", and it sends messages out
when they are needed.  And if so, what messages can it send?

Then there is the issue of real-time play (or what I call scaled-time - is
there a better word).  We have a nice built in timing mechanism with
the Unix clock, and the DPSTimedEntry system for generating events.
How, for example, do we notify Diplomacy players how much time for
discussion they are allowed?  If we have smart pieces or computer
players, how can we notify them to "do their thing"?

D. Conclusion

These questions may be rather vague, but I hope they help stimulate
discussion.  There are also a few general points I want to make, which
(as usual) you are free to disagree with.

1. the servers will have to trust the clients; if information is
hidden from the (human) player, the client code must take care of
that.  Otherwise, the restrictions make the server too game dependent.

2. I would like to have only one server protocol, with two or three
server objects that can handle virtually any situation.  All the
complexity gets shifted onto the clients.  Is that a reasonable goal?

3.  Is the issue of multiple participants sufficiently general that we
should isolate the server part from the rest of WarKit?  Do we care if
people might want to use this for things like, I don't know,
"GreyBoard"?  I doubt it, but maybe NeXTSTEP needs a few general
server objects for a wide variety of applications.

4.  The stereotypical client-server problem is that of a database (a
file server just being a special case of a database, of course:).  Is
that a useful paradigm for thinking about the WarServer?

Well, I hope you enjoyed wading through this.  Please correct me if I
made any obvious blunders.  Also let me know whether you think I am
approaching the problem from the wrong (or right!) perspective.
Now, let the discussion begin!

- Ernie Prabhakar
WarMaster