• The information provided is subject to change and may not reflect the current design of the project.
• This will change with the first official release.

And as I already explained in a different document:

• This library is a proof-of-concept demonstrating how Yake centric applications can be networked.
• It is not designed to replace or even compete with great networking engines like ReplicaNet, NetZ, ICE etc pp.
• It is not designed for maximum performance.
• It is designed to be easy to use. Customization and optimization may be necessary for use in a specific project.

• provide hooks that allow integration with different networking libraries at different levels
• provide sample implementation

• RMI for high-level communication
  • server browsing, authentication, generally reliable non-time-critical operations …
• ordered, unreliable transport for time-critical updates of distributed objects

So much for the basics.

• XML based communication protocol
  • Pros:
    • Easy inter-language communication
  • Cons:
    • Bandwidth overhead

• What about CORBA, ICE, ReplicaNet, NetZ … ?
  • These are great possible candidates. Use them if you want! They may be the exactly right choice!
  • Why don't we use them for the sample implementation?
    • dependency on “expensive” or “unwanted” licenses
    • different reasons for different libraries

Server registers/updates data on ServerBrowser

RMI: bool I_ServerBrowser::updateServer(const std::string& /*name*/, const uint16 /*port*/, const ByteDataChunk&);

Remarks: The address of the RMI remote connection (i.e. the server) is used as the server's address.

Server unregisters from ServerBrowser

RMI: void I_ServerBrowser::removeServer();

Remarks TO COME: information on time outs, keep-alive pings, etc.

yake::net contains the following libraries:

• authentication library (net_auth)
• server browser library (net_serverbrowser)
• server browser client library (net_serverbrowserclient)
• session server library (net_sessionserver)
• session client library (net_sessionclient)

yake::net ships with the following application for a demo simulation/game:

• server browser (cm_browser)
• standalone server (cm_dedicated)
• client (cm_client)

While it's possible to run server and client within the same process there's no demo for it (yet?).

• Security
  • Fight spamming (e.g. via the server browser client interface for servers: mass subscription of non-existing servers )
  • Handle DoS attacks
  • Banning

The RMI objects that are accessed via the RMI interfaces (see below).

DOCUMENTATION TO COME

One instance, managed by the server browser process.

One instance on the client. Lifetime should be limited so that the instance exists between the requests to the server browser and the answers.

One instance on the server. Lifetime is limited to certain requests (mainly adding, removing, updating information).

One instance per game/simluation session. Managed by the server process. The “Session” object is the main sink for requests from clients regarding the active simulation.

One instance on each client of a “Session”. This instance is the main sink for simulation events (client related events, ghosting/replication of ojects etc).

The RMI interfaces as used for the high-level communication protocol.

Basic Client Operations

Ghosting

Chat

Basic client/server operations

Ghosting - Simulation

Ghosting - Objects/Entities

boost::serialization is used to serialize/deserialize per-server information. This may not be perfect for performance (we haven't profiled this yet, though!), but definitely allows very flexible customization (including versioning) as the developer can store any information that is serializable by boost::serialization (And that which is not can be made to be :) ).

The serialized per-server data archive is stored in the server browser data storage. It hasn't been decided yet what the data storage mechanism will be. One possibility would be a SQL database (e.g. sqlite). A simple XML or binary archive as the result serialization with boost::serialization may suffice, though.

Object class ids are numeric values. yake::net uses yake::object for class and object id management.

• bandwidth reduction oriented (e.g. transmission of significant bits of class ids, special class id maps for network connector etc)
• …