From 450c9e0da0fa03f2356dd4f1ba75bb5308f2ad48 Mon Sep 17 00:00:00 2001 From: neodarz Date: Sat, 11 Aug 2018 21:06:36 +0200 Subject: Move old php3 extension to simple php extension --- docs/nelnet.php | 530 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 530 insertions(+) create mode 100644 docs/nelnet.php (limited to 'docs/nelnet.php') diff --git a/docs/nelnet.php b/docs/nelnet.php new file mode 100644 index 00000000..3780c401 --- /dev/null +++ b/docs/nelnet.php @@ -0,0 +1,530 @@ + + + + Nevrax.org : docs + + + + + + + + + + + + + + +
# Home   # nevrax.com   
+ + + + +
Nevrax
+ + + + + + + + + + +
+ + +
+ Nevrax.org
+ + + + + + + + + + +
#News
#Mailing-list
#Documentation
#CVS
#Free software
#Download
#FS Suggest
#FAQ
+
+ + + +
+ + +
+docs + +
+ + + + + +
Nel Network Library
+

Introduction

+

This documents +presents 'NeL Net', 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 +server-client 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 NeL Net 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 centralised login validation system at a separate +geographical location from the universe servers.

+

Nevrax is currently +developing a TCP/IP implementation of the low level network layers. A +UDP implementation may be developed at a later date.

+

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.

+

NeL Net is +currently tested on GNU/Linux and Microsoft Windows NT platforms.

+


+

+

Statement of requirements

+

The Network library +addresses the following problems:

+

Client -> 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 -> 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 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. +

    +
+

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

    +
+

On the fly backup management

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

    +
+

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

    +
+

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

+

The NeL network +library provides a single solution which caters for all of the Server +-> Client, Client -> Server and Inter-Process communication +requirements.

+

This solution is +structured as a number of layers that are stacked on top of each +other. The API gives the app programmers direct access to all of the +layers.

+

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 backup system +is a standalone service (a service being a process which exposes a +standard message interface) which will encapsulate a 3rd party +database.

+

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

+

In a nutshell the +network support layers include:

+ + + + + + + + + + + + + + + + + + + + + + + +
+

Layer 4

+

(Top Layer)

+
+

Inter-Service + message addressing layer

+

Handles routing of messages to + services, encapsulating connection to naming service and handling + of lost connections.

+
+

Layer 3

+
+

Message management layer
(Handling + of asynchronous message passing, and callbacks)

+
+

Layer 2

+
+

Serialised data + management layer

+

Supports the standard serial() + mechanism provided by NeL for handling data streams.

+
+

Layer 1

+
+

Data block + management layer
(buffering and structuring of data with + generic serialization system)

+

Also provides multi-threading + listening system for services

+
+

Layer 0

+

(Bottom Layer)

+
+

Data transfer layer
Abstraction + of the network API and links (PC may be across a network, or local + messaging)

+
+


+

+


+

+

Layer 0

+

Layer 0 includes +the following classes:

+
    +
  • CSock : + Base interface and behavior definition for hierarchical descendents

    +
  • CTcpSock : + Implementation of a socket class for the TCP/IP protocol

    +
  • CUdpSock : + Implementation of a socket class for the UDP protocol

    +
+

**** +Document under construction

+

Layer 1

+

Layer 1 includes +the following classes:

+
    +
  • CBufNetBase : + Buffer functionality common to client and server

    +
  • CBufClient : + Implements client-specific buffer functionality +

    +
  • CBufServer : + Implements server-specific buffer functionality

    +
+

**** +Document under construction

+

Layer 2

+

Layer 2 includes +the following classes:

+
    +
  • CStreamNetBase : + Stream functionality common to client and server

    +
  • CStreamClient : + Client-specific stream functionality

    +
  • CStreamServer : + Server-specific stream functionality

    +
+

**** +Document under construction

+

Layer 3

+

Layer 3 includes +the following classes:

+
    +
  • CCallbackNetBase : + Functionality common to client and server

    +
  • CCallbackClient : + Client-specific functionality

    +
  • CCallbackServer : + Server-specific functionality

    +
+

**** +Document under construction

+

Layer 4

+

**** +Document under construction

+

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 initialised. 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 Time Service

+

Provides standard +universal time (in milliseconds) for the services within a shard and +also for remote clients across the internet.

+

API class: +CUniTime - See technical documentation for details

+
    +
  • Synchronises + the local machine time with the universal time

    +
  • Provides + access to the universal time

    +
+
    +
  • See + technical documentation for details

    +
+

The Log Service

+

Provides a +centralised information logging system.

+

API class: +CNetDisplayer

+
    +
  • Allows any log + message to be directed to the log service (instead of or as well as + the screen, a disk log file, etc)

    +
  • This is a + displayer in the logging system (see misc library for details)

    +
  • See + technical documentation for more details

    +
+

The Service Skeleton

+

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

+
    +
  • Reads and + interprets configuration file and command line parameters

    +
  • Redirects the + system signals to NeL handler routines

    +
  • Connects to + the Log Service

    +
  • Connects to + the Time Service and synchronises clock with universal time

    +
  • Creates and + registers callbacks for network layer 3

    +
  • Sets up the + service's 'listen' socket

    +
  • Registers + itself with the Naming Service

    +
+

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

+

Login system

+

**** +Document under construction

+

Login manager(stand alone)

+

**** +Document under construction

+

Login client API

+

**** +Document under construction

+

Login shard API

+

**** +Document under construction

+

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.

+

Backup Service

+

**** +Document under construction

+

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.

    +
+

Future plans

+

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

+

**** +Document under construction

+ + +
                                                                                                                                                                    +
+ + + \ No newline at end of file -- cgit v1.2.1