General Overview of NLNET

Introduction

This documents presents NeLNet (NLNET) the NeL Network Library.

NeL is a toolkit for the development of massively online universes. It provides the base technologies and a set of development methodologies for the development of both client and server code.

The NeL Net comprises code libraries for inter-server communication and client-server communication. It also provides implementations of the service executables required by the higher level layers of the code libraries.

Mission Statement

The first objective of NeLNet is to provide a complete data transfer system that abstracts system specific code and provides mechanisms for complete control of bandwidth usage by the application code.

NeL Net has a further objective of providing a complete toolkit, comprising further layers of library code and core service implementations, for the development of performance critical distributed program systems for massively multi user universe servers.

The current feature requirement list for NeL Net corresponds to the application architecture for Nevrax' first product. This notably includes the requirement for a centralized login validation system at a separate geographical location from the universe servers.

Target Platforms

The Nevrax team expect to run GNU/Linux servers for their first product. As such, GNU/Linux is the primary target operating system.

NeLNet is currently tested on GNU/Linux and Microsoft Windows NT platforms.

Features

General Features

• 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

Shard Back-End Service Framework and API

• 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 synchronization
• Management of log messages with consolidation and filtering tools
• Centralized shard administration and management
• Current implementation is based on TCP/IP

Shard Front-End Application API

• 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

Login / Logout Management

• 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.

Statement of Requirements

The Network library addresses the following problems:

Client to Server Communication

• 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.

Server to Client Communication

• 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 prioritizing 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.

Inter-Process Communication Across Servers

• 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).

General Requirements

• 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.

Login / Logout Management

• The product that Nevrax is developing handles multiple instances of the game world running on different server sets (known as 'Shards') with a single centralized 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.

Account Management

• 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.

Technical Design Details

Design Outline

There is a program skeleton for the programs within a shard who are capable of communicating with each other via layer 5 messages. Programs of this form are referred to as 'Services'.

The login manager and account manager are standalone programs at an isolated site.

System Services

The following system services are provided as part of NeL. For each of these services there exists an API class that may be instantiated in any app-specific service in order to encapsulate the system service's functionality.

The Naming Service

A standalone program used by all services to reference each other.

• All services connect to the naming service when they are initialized. They inform the naming service of their name and whereabouts.
• The naming service is capable of informing any service of the whereabouts of any other service.
• When more than one instance of the same service connect to the naming service we anticipate the possibility of the naming service managing simple load balancing by distributing connection requests to the given service across the available instances.

API class: CNamingClient

• Generates dynamic port numbers
• Registers the application service's name with the naming service.
• Retrieves the IP address and port number for a named service.
• See technical documentation for details

The Service Skeleton

The network library presents a generic service skeleton, which includes the base functions of a distributed service. At initialization time it performs the following:

• Reads and interprets configuration file and command line parameters
• Redirects the system signals to NeL handler routines
• Creates and registers callbacks for network layer 4
• Sets up the service's 'listen' socket
• Registers itself with the Naming Service
• Connects itself with the Admin Executor Service

The skeleton also handles exceptions and housekeeping when the program exits (whether cleanly or not)
Login system

Account Manager (Stand-Alone)

Stand alone program that handles the list of users permitted to connect to shards managed by a given Login Manager.

NeL provides a skeleton program that includes the communication protocols for the Login manager.

Administration

NeL provides the base mechanisms for administering a NeL shard. Two basic services are provided:

The Admin Service (1 Per Shard)

• Provides an entry point for cluster administration.
• Provides access to logging information and mechanisms for starting or restarting services

The Admin Executor (1 Per Server)

• This is the relay for the Admin Service.
• Fetches statistics on the local machine and relays them to the Admin Service.
• Launches and controls the services running on the local machine.