Introduction Manual Class Reference Header Reference

Zoidcom Design

Four layers

Zoidcom is conceptually split up into four layers:

design.png

Layer 1: ZoidCom

This class is Zoidcom's root class. It manages all local ZCom_Control instances, the allocation of sockets and the routing of incoming packets to it's destined ZCom_Control. It needs to be instantiated first and deleted last. Apart from creating, initializing and deleting it, some global Zoidcom options can be set here.

Layer 2: ZCom_Control

An instance of ZCom_Control represents one host in the network. It has three main functions:

ZCom_Control is capable of initiating and receiving connections, coming from other remote or local ZCom_Control instances. It also acts as manager for ZCom_Node objects, routing incoming data updates and node events to the correct nodes, and collecting updates from local nodes so they can be sent to another ZCom_Control. One ZCom_Control can act as server and client at the same time. It is also possible to have several instances of it in the same program, one acting as a server and the other as the client. Or two ZCom_Controls acting as servers for different tasks.

Status information is provided through callback methods, which are defined as pure virtuals in ZCom_Control. Whenever something interesting happens to a connection, the according callback method is called automatically from inside ZCom_Control.

Layer 3: ZCom_Node

ZCom_Node is the bridge between gameobjects and the Zoidcom system. This class manages the synchronization of each gameobject's data and handles communication between the gameobject on client and server. Each node needs to get registered with a ZCom_Control object.

All worldobjects, i.e. each ship, car, projectile, switch, whatever interactive things there are, need to have their own instance of a ZCom_Node. When a client connects to a server, all relevant nodes will get sent to the client. On the client, a callback in ZCom_Control will be called for each object the server has sent. The client needs to create an object of the requested type in this callback, and after that data synchronization between the original server object and the cloned client object is performed automatically by the ZCom_Node.

Layer 4: ZCom_Replicator

One data field in an object is managed by one instance of ZCom_Replicator. Different data fields have different kinds of replicators, e.g. strings have a replicator specifically written for strings, while numeric data has it's own replicators. It is also possible to implement your own replicators for your own data types. Replicators are managed by ZCom_Node.
This file is part of the documentation for Zoidcom. Documentation copyright © 2004-2008 by Jörg Rüppel. Generated on Sat Aug 16 15:26:51 2008 for Zoidcom by doxygen 1.4.6-NO