# Home    # nevrax.com   
Nevrax
Nevrax.org
#News
#Mailing-list
#Documentation
#CVS
#Bugs
#License
Docs
 
Documentation  
Main Page   Namespace List   Class Hierarchy   Alphabetical List   Compound List   File List   Namespace Members   Compound Members   File Members   Related Pages   Search  

How the login system works ?
Id:
login_system.dxt,v 1.2 2002/09/30 14:02:40 lecroart Exp

Author:
Vianney Lecroart
Date:
09/30/2002

Introduction

This document briefly describes the connection process of a client to a shard running a NeL-based system.

Here it is a picture that displays different system with interaction between them:

login_system.png

Abbreviations

  • LS: Login Service (a single unique LS services the entire shard set) that accept connection from web server on port 49990 and accept Welcome Service on port 49998.
  • WS: Welcome Service (one for each shard).
  • FS: FrontEnd Service (N per shard), port numbers are dynamically attributed by the Naming Service.
  • NL: nel_launcher, it's the program on the client side that the player launch. This program is used to identify, select a shard and patch the game. It also launchs the game with good parameters to identiy the game to the shard.

Login system steps

  • Step1: The client launchs the NL and automatically connects to the login server (cnx1).
  • Step2: The Web Server, using NeL Login Webpages and the NeL Database decides if the user has a valid login password (cnx2). It also sends the list of available shard to the NL
  • Step3: The user selects the shard he wants to connect to. If the NL has to patch the client it connects to the Patch Directory and process the patch. After that, the NL sends the selected shard to the Web Server.
  • Step4: The Web Server connects (cnx4) to the LS using a fake NeL TCP connection (with a php script) and send the client requests, the LS sends the requests to the selected Welcome Service (cnx5) and creates a uniq cookie for this client.
  • Step5: The WS looks which FS is the best to receive the client and returns the FS IP to the LS and send the information to the selected FS to says that it'll receive a client with this cookie (cnx6). The LS forwards to the php and then forward to the NL.
  • Step6: The NL has now the FS IP and cookie. It connects to the FS and sends the cookie (cnx7). The FS checks if the client IP and cookie is valid and send to the WS that the client is effectively connected. The WS forwards that to the LS and the LS updates the NeL Database (cnx3) to says that the user is online.

Logout system steps

The FS detects the deconnection of a client, sends a message to the WS that is forward to the LS. Then, the LS updates the NeL database setting the user offline.

nel_launcher configuration

The configuration parameters are in the nel_launcher.cfg.

  • StartupHost is the server where the web server is. It's only an ip, not an URL
  • StartupPage is where the first web page is. It must starts with a /
The startup url is composed using this rule: http://<StartupHost><StartupPage>

For example if StartupHost is "itsalive.nevrax.org" and StartupPage is "/login/welcome.php", the resulting url will be "http://itsalive.nevrax.org/login/welcome.php",

  • Application is the application that the NS will launch when it's necessary. The first value is the application name that will be compared with the server database to select good shards. The second value is the executable filename with a path if necessary. the third value is the path where the launcher will go before executing the application.

Login Service configuration

The configuration parameters are in the login_service.cfg.

  • WSPort is the port that will be used by the Welcome Service (default is 49998) to connect to the LS.
  • AcceptExternalShards is 1 if the LS accept shard that are not already in the NeL database. If you set the value to 0, the shard will be disconnected if it s not in the database.
  • Beep is 1 if you want the LS beeps when users comes (debug purpose and only on Windows).
  • DatabaseHost is a string that contains the address of where the database server is. For example "localhost".
  • DatabaseName is the name of the database where we can find needed info (default is "nel").
  • DatabaseLogin is the login to access the database (default is "").
  • DatabasePassword is the passwrd to access the database (default is "").
  • ForceDatabaseReconnection can be anything. Change this value to force a configfile reload and reconnection to the database to take in count the new value of Database*. The content of this variable doesn't matter, it s just a fake to reload database var.

Welcome Service configuration

The configuration parameters are in the welcome_service.cfg.

  • LSHost is an address of where the Login Service is (for example "localhost").
  • FrontendServiceName is the little name of the frontend service that will be use to know when a FS is up or down using the naming service (default is "FS").
  • ShardId is the value that identify the shard in the NeL Database. It must be uniq for each different shard.

NeL Database

The Database name is "nel" by default. It contains 2 tables; "shard" and "user".

shard table

  • ShardId is an int that identify a shard. It must be uniq and is used when a shard connects to the LS.
  • WsAddr is a string that is the ip address in numerical format (127.0.0.1). This address is used to check if the shard can connect. The WsAddr must be the same as the connection and also the ShardId to accept a shard.
  • NbPlayers unsigned int. Contains the number of player really connected to this shard.
  • Name is the string that is display when displaying the list of available shards.
  • Online is 1 if the shard is online an ready to accept players.
  • ClientApplication is a string that must match the Application variables in the nel_launcher.cfg. It's used to display only shards that are compatible with the nel_launcher.
  • Version is a string that represent the version of the shard. If the version is not the same on the client in the VERSION file and in the shard, the nel_launcher will have to patch to connect to this shard.
user table

  • UId is a uniq number for a player.
  • Login is the user login.
  • Password is the user password.
  • ShardId is the ShardId where the client is connected to if the user is online, otherwise the ShardId is -1
  • State describes the user state, if he's online or not.

NeL Webpages

  • index.php contains all "customizable" php code. It manages the login/password verification using database access, display available shard and use cookie to remember users.
  • service_connection.inc contains codes that enables the connection to the Login Service and send/receive messages.
  • make_patch.php is a page that create all stuffs needed to realize a patch. It compress all files and create a dir.gz that contains all files with date and size used by the nel_launcher to patch a client.

Side notes

Whenever a shard starts, the WS establishes a permanent link with the LS. A validation on the LS will done to check that the shard is authorized to work on this login system using the WS IP and the ShardId.

outofdate If the LS detects that a person is trying to connect to an account that is already on use by another person, then the 2 people will be disconnected. The goal is to discourage people from sharing their accounts and also to avoid account deadlock in the case of bug. If for an obscur reason the user state in the LS is bad, then the next time the user tries to connect, they will be disconnected and their account will be reseted to the offline state and the user will be able to retry with a normal state.

A cookie is a class (CLoginCookie in login_cookie.cpp) that contains the web server's IP (uint32) as seen by the LS (to avoid address translation problems) for validation, a unique key (uint32) and the user id (uint32).