All information between the client and the server is sent over an abstract network
called INetwork. The INetwork
implementation uses an abstract INetworkEndPoint object to indicate a location on
the network. Each INetworkEndPoint
possesses the ability to connect to other network end points and send and receive
raw data. INetworkEndPoint objects
only know how to transmit and receive byte arrays - they are agnostic to higher-level
constructs such as behaviors and
events. Currently, we have a DummyNetworkEndPoint implementation of
INetworkEndPoint. This implementation communicates
with other DummyNetworkEndPoint objects by invoking methods on the other object
in a remote thread. No data is actually
sent over a real network. We plan to write a socket-based INetworkEndPoint in the
near future that supports two parties
communicating over different computers.
The INetwork implementation is still agnostic to SkyNet constructs such as behaviors,
entities, events, etc., but
features some higher level constructs than INetworkEndPoint to facilitate
communication. In particular, it allows
the transmission of arbitrary objects and encapsulates the process of serializing them
into a byte array and
restoring them back. INetwork supports the following operations:
- connect to a server
- listen for incoming connections
- send objects
- receive objects
- send request for which a reply is expected
- reply to a pending request
The INetwork implementation handles the bookkeeping of deciding when a reply
comes in, which request
it is associated with and when a request comes in, which listener should service it.
The INetwork implementation
also encapsulates threading logic to handle both synchronous and asynchronous
versions of all network operations.
A synchronous operation blocks until it is complete. An asynchronous operation
returns immediately and calls
a registered completion routine when the operation is complete.
To facilitate dispatching of requests and replies, each request contains two
parameters - a service id and a request id.
A service id is a well known constant shared between the client and server identifying
what type of request is being
performed. The INetwork implementation allows the server to register a seperate
receive listener for each service id,
prevent the server from having to write one giant listener to handle everything. The
request id is a Guid that uniquely
identifies the request. When the server replies, the server sends back the guid.
When the client gets a raw bit-stream
that indicates a reply, it looks up the guid in a table to retrieve the associated
request. This allows the INetwork
implementation for the client to wake up the appropriate thread or call the
appropriate completion routine. If a request
