150 

   151 \subsection{Network}

   152 

   153 The network code is implemented as separate NetworkServer and NetworkClient modules, which use a common high-level

   154 network interface, NetworkSession and NetworkObject.

   155 

   156 The low-level details are implemented using ClanLib's CL\_IPAddress (referred to as NetworkAddress) and CL\_Socket.

   157 NetworkUDP provides an interface to send and receive NetworkPackets to/from specific NetworkAddress's across a 

   158 NetworkSocket. NetworkTCP provides a NetworkTCPTransport interface, which can send/receive NetworkPackets on a

   159 NetworkSocket (using NetworkBuffer to buffer socket I/O). NetworkTCPServer is a listen() socket which accepts client

   160 connections as NetworkTCPTransports, and NetworkTCPClient is a NetworkTCPTransport that's connect()'d to some address.

   161 

   162 NetworkSession encapsulates some simple application server/client behaviour, it can function as both a server, and

   163 represents remote NetworkSessions (either clients or servers) as NetworkNode objects. These then provide an interface

   164 to send and receive NetworkPackets on specific NetworkChannelDs, using either TCP or UDP as a reliable/unreliable

   165 transport.

   166 

   167 NetworkObject then implements a kind of object-oriented network protocol. A NetworkObjectController (with specific

   168 subclasses for server/client behaviour) uses a NetworkSession to send messages on a specific NetworkChannelID. This

   169 controller then creates and looks up NetworkObjects (again, with specific subclasses for server/client behaviour).

   170 Clients and servers can then communicate by having the server construct new NetworkObjects (which are allocated an

   171 unique id), and then sending NetworkPackets with a specific NetworkMessageID type on a specific object. The message is

   172 then delivered directly to the NetworkObject instance on the remote end of the connection, or a new NetworkObject is

   173 constructed using the data in the NetworkPacket. This enables an easy way to send events for specific objects, and

   174 referr to other objects in these messages.

   175 

   176 NetworkServer then implements a core NetworkServer class which has a NetworkSession and a

   177 NetworkObject\_ServerController. Players that connect are represented as NetworkServerPlayers, which inherit from

   178 LocalPlayer and NetworkObject\_Server. This class then overrides methods in Player to deliver messages on the Player

   179 object to the clients, or to create new NetworkServerProjectiles. NetworkServerProjectile inherits from Projectile and

   180 NetworkObject\_Server, and sends messages when constructed, upon hitting a player, and upon being destroyed.

   181 

   182 NetworkClient is a bit more complicated as it must handle both the LocalPlayer, and a number of RemotePlayers. Again,

   183 NetworkClient has a NetworkSession and a specialized NetworkClientController, which then creates objects of various

   184 other NetworkClientClasses upon receiving messages from the server.

   185 

   186 Two of these classes are NetworkClientLocalPlayer and NetworkClientRemotePlayer. Both inherit from

   187 NetworkClientPlayerBase, which inherits Player (virtually) and NetworkObject\_Client. NetworkClientLocalPlayer and

   188 NetworkClientRemotePlayer then also inherit LocalPlayer and Remote player virtually, respectively.

   189 NetworkClientPlayerBase contains the common methods that update the Player's state in response to messages received

   190 from the server. NetworkClientLocalPlayer overrides handleInput to send the input mask to the server, and

   191 NetworkClientRemotePlayer can handle remote clients disconnecting from the server.

   192 

   193 In addition, there is a NetworkClientProjectile class, which inherits from Projectile and NetworkObject\_Client.

   194 this is created when a Player fires a Weapon on the server, and handles events received from the server like the

   195 projectile hitting a player (inflicting damage), or being destroyed (by hitting the terrain or something similar).

   196 

   197 When the player first connects to the server, the server sends a large packet containing the terrain array to the

   198 client, which updates its own GameState world's terrain array with the received data.

   199 

   200 Currently, the client only sends handleInput using unreliable UDP messages, and the server only sends position updates

   201 (as sent in response to handleInput events) unreliably. All other events are sent using reliable TCP.

   380 Currently, the program lacks an AI which was in the original plan and most of the optional features were also omitted. Liero clone proved to be, however, a very interesting software project and we are hoping to release Kishna Glista 2.0 one day.

   381