---

The Network library addresses the following problems:

• The product code (also referred to as app code) on the Client needs to be able to pass blocks of information to the network layer for communication to the server. The network code is responsible for ensuring that the blocks of data arrive complete server-side. In the majority of cases the blocks of data from the client will be significantly smaller than the maximum packet size, which means that the network code should not need to split data blocks across network packets.
• In order for the app code to control the flow of data to the server, the network code should buffer sends until either an app-definable time has elapsed or an app-definable packet size has been reached.
• Note: The information sent from the client to the server will generally be small in size, typically representing player actions such as movement.

• The app code on the Server needs to be able to pass blocks of information to the network layer for communication to the client. This problem is exactly the same as the Client -> Server problem, described above.
• The app code is responsible for limiting the amount of data sent to each player each second by prioritising the information to be dispatched. In order to achieve this, the network code should buffer sends until the app code explicitly requests a buffer flush. The network API should provide the app code with the means of tracking the growth of the output buffer.
• Note: The information sent from the server to the client will often be large in size, as the server must inform the player of changes of state and position of all other characters and objects in the player's vicinity.

• The different processes that make up the game need to be able to send messages to each other to request or exchange information.
• There needs to be a transparent routing mechanism that locates the services to which messages are addressed and dispatches them.
• There needs to be a standard framework that handles the queue of incoming messages and manages the dispatch of messages to different modules within a process. (e.g. A process that manages a set of AI controlled characters may have one module that handles incoming environment information, another that treats other processes' information requests, and so on).

• There needs to be a reliable centralised system for backing up and retrieving world data.
• The system must be capable of treating large volumes of data as 'transactions'. This means that if a server goes down - when it comes back up transactions will never be 'half complete'. Any transactions that had been begun but not finished must be automatically undone.
• The backup system must be capable of managing a 'backup schedule' under which it sends backup requests to scheduled processes and treats the return data.
• The backup system must be capable of handling spontaneous backups from different processes (particularly the player management processes who are capable of backing up players at any time).
• The backup system will be called upon to retrieve player data whenever a player logs in. This operation must be reasonably fast.
• The backup system will be called upon to supply data to each system at system initialisation time. The backup system should supply such systems with their complete data sets.

• The app code is responsible for network traffic and must be capable of much lower level access to the Network library than the above requirements suggest.

• The product that Nevrax is developing handles multiple instances of the game world running on different server sets (known as 'Shards') with a single centralised login manager.
• The login manager must:
  • Receive login requests from client machines
  • Validate login requests with the account management system
  • Provide the client with the active shard list
  • Negotiate a connection with the shard of the client's choice
  • Dispatch the shard's IP address and a unique login key to the client
• The login manager must refuse attempts to login multiple times under the same user account. This implies that the login manager must be warned when players log out.
• The login system should include client and shard modules that provide a high level interface to the login manager, encapsulating communication.

• No choice has been made as to what solution to take to account management at NeL.
• It is sufficient to know that we need a standard API for the account management system capable of validating logins.

• A layer based architecture with API access to every layer
• Client application API
• Encapsulation of process of connection to Shard Front End
• Encapsulation of buffering and data transmission to Shard Front End
• Encapsulation of reception and decoding of messages within data packets received from shard
• Current implementation is based on TCP/IP

• Framework for developing new services
• Abstraction of inter-service connections with disconnection and reconnection management
• Management of transmission of messages to other services (with buffering)
• Management of reception and treatment of messages from other services (with buffering)
• Management of time synchronisation
• Management of log messages with consolidation and filtering tools
• Centralised shard administration and management
• Current implementation is based on TCP/IP

• All features pertaining to back end services
• Multi-threaded client-communication management for large numbers of client connections
• Separation of incoming messages from the shard back end and incoming messages from clients
• Login authentication
• Mechanisms for monitoring growth of output data packets to the application program
• Current implementation is based on TCP/IP

• Automated system fo registration of shards with Login Manager
• API for connection of client application to Login Manager, for login and password authentication and for valid shard list retrieval by the client.
• API for selection of a shard (for an authenticated user), selection of least loaded front end server on the shard for client connection and secure system for establishing the client connection.

• Management of a backup schedules and shard backup synchronisation
• Standalone service dedicated to reception and secure storage of backup data (with concept of transactions and data coherency)
• Service API for backing up data

• Multi-threaded application support
• Add a UDP channel from Client to Shard front end
• Investigate ways of adding a UDP channel from shard to client (looks tricky)
• Add support for data compression
• Optimisation of communication between services running on the same server (via pipes and/ or shared memory)

The purely network library is typically self-contained, and not much subject to modification, unless one wants to change the entire paradigm around which the platform runs. Addition of a specific and non-standard network or network API would be the only reason one would change layer 1.