Infrastructure Group
Prospectus
Justin Crites
2005-02-14
ABSTRACT
The Infrastructure group is designing a
system that has a few primary
components. The components I can
identify are (1) the network layer (2) the
security layer (3) the controlling layer.
NETWORK LAYER
Fundamentally the network aspect of the
project is a message-passing system.
The network layer is designed simply to
express the notions of entities and allow
them to send messages to one another.
In the system, an entity is a composite
structure: it can be an endpoint or a
group of entities. An endpoint is simply
a “node” in the network that can send
and receive messages. Conceptually, the
messaging framework allows the
following message-sending operations:
(1) endpoint to endpoint (2) endpoint to
group (2) group to endpoint (3) group to
group. In each case, the sender(s) and
receiver(s) agree upon the time that the
message was received and sent,
respectively. The agreement of time
provides the synchronization necessary
to maintain the higher-level systems that
will be built on top of it.
To complete this system we will have to
design a low-level system whose
concept only consists of relaying a
message from a single endpoint to
another endpoint. Upon that system we
will build routing protocols and
synchronization for groups.
Protocol
This
messaging layer will
be
implemented using object serialization.
A message is simply an object that has a
SerializableAttribute – an object
that can be transformed into a portable
data storage format and reconstructed in
some other location.
For more
information on this, please see the
ISerializable interface on MSDN.
Although Serialization provides the
conceptual mechanism of message
transport, the serialized objects must
actually be transmitted via some lower
medium. Some possible media include
.NET Remoting (objects are passed as
function parameters and thus serialized
between
systems),
sockets,
and
Windows named pipes. The simplest
implementation early on is likely .NET
remoting or named pipes. Both have
their advantages and disadvantages.
Note that this is primarily a messagepassing system and objects in the system
communicate by sending (abstractly) a
message from one to another. This
message embodies such things as
attacks, defense, terrain changes,
weather changes, user commands to
shutdown or add servers or change
permissions, etc.
Various systems will have their own
message types that they use to
communicate. For example, the network
controller must accept commands to link
and unlink servers from the grid. Thus it
will accept some sort of command
message from users issuing those
commands. That type of message is
distinct and separate from the type of
message that the model will be sending.
Administration
An important part of this system will be
an administrative console. This console
will connect to the grid as a client would
normally, only the commands that it
sends will be primitive and text-based.
The program will exist mainly to help
administrate and debug the server grid.
This program can be a simple console
program that accepts text input as to
which server to connect to, then parses
command lines entered from the user (as
a shell would) and instructs the server
accordingly.
It would also be useful for this
administrative
program
to
have
debugging
functionality,
perhaps
accepting an event dump from the server
as to what’s currently going on.
simple framework has been developed
and exists in the source repository.
This security layer consists of a few
important entities: IIdentity, IPrincipal,
IAuthority, IPermission. We can change
the names later if people don’t like them.

An identity in most situations is
represented as a user account. For
example, my Owlnet account logon
“xiphoris” would be an identity in the
system. An identity is a group of
permissions and access information.
When a user logs onto an account, they
are said to be creating an instance of that
identity, called a principal.
That
instance inherits all the permissions of
the identity.
Other Protocols
It would be wisest to get a very simple
protocol using .NET remoting or named
pipes working first so that the other
groups may communicate, then move on
to more complex and efficient
communications protocol.
An ideal communication mechanism
would be custom sockets controls and
serialization, but as many people have
pointed out, that would take considerable
time to write. The infrastructure group
must strike a balnce between “enough”
efficiency without too much complexity.
It may be the case that a .NET remoting
solution would provide sufficient
efficiency for this project.
A principal is a particular logged on
instance of an identity. That principal by
default begins with the permissions of
the identity but permissions can be
added or removed dynamically.
If
permissions are added to the principal
they do not affect the originating
identity. If permissions are added to the
identity, they do not affect any existing
principals, although newly created ones
will have the new permissions.
SECURITY LAYER
Permissions are represented as only an
IPermissions structured.
Currently,
permissions are conceptually a Boolean
flag: either a principal/identity has them
or it does not. Permissions currently
could not contain a number, for instance.
There is no barrier to extending the
system to do that for the future,
however.
The security layer is an important layer,
one that is likely to be seen by many
components in the rest of the system. A
All messages sent within the system
have a principal attached to them.
Whether a message should be
“executed”
depends
upon
the
permissions of the sending principal. If
a user logs on as guest and sends the
“server shutdown” message, the server
controller should realize the user does
not have requisite permissions and
ignore the message.
Any part of the system may inspect
messages for custom permissions. The
principal and identity classes do not care
what sorts of permissions are attached to
them; permissions are capable of being
serialized with the identity class such
that they may persist without special
effort on the part of that class. It does
place the constraint on the permission
class that it be serializable.
Otherwise, though, systems may create
their own permissions and attach them to
identities or principals dynamically.
IAuthority is a class that handles the
authentication and logon of identities.
Any implementation of this class is
possible.
For example, an early
authentication scheme we might want to
use could be a centralized database that
all servers connect to. Then this could
be changed later to a more distributed
model.
Ultimately, it is my impression that
when a server links to another server, it
should copy that server’s permissions.
In order to link server B to existing
server A, one must log onto A with the
correct privileges. Then one issues the
command to link them, and server B
copies A’s permission and user set onto
itself. In this way, a web of trusted
authorities is created since all servers
trust the server they connect to, and the
connecting
server
only
allows
connections if they have correct account
permissions.
CONTROLLER LAYER
The controller layer handles set-up and
tear-down of the server, model, and
handling of server commands (sent
through the network). It also facilitates
communication of the model to its
various other parts (on different servers)
using the network layer. It may do this
through adapters or more complex
message translation.
Also, importantly, the controller is
responsible for reorganizing server
regions. As best I know, the game is
broken up into multiple regions, each of
which is simulated on multiple servers.
Each of these region simulation sets
must be synchronized, and the timeagreement facilities mentioned in the
earlier section should allow this. The
controller reorganized regions to loadbalanced and ensure the network runs
smoothly.