From 0ea5fc66924303d1bf73ba283a383e2aadee02f2 Mon Sep 17 00:00:00 2001 From: neodarz Date: Sat, 11 Aug 2018 20:21:34 +0200 Subject: Initial commit --- pipermail/nel/2001-April/000402.html | 123 +++++++++++++++++++++++++++++++++++ 1 file changed, 123 insertions(+) create mode 100644 pipermail/nel/2001-April/000402.html (limited to 'pipermail/nel/2001-April/000402.html') diff --git a/pipermail/nel/2001-April/000402.html b/pipermail/nel/2001-April/000402.html new file mode 100644 index 00000000..feee946b --- /dev/null +++ b/pipermail/nel/2001-April/000402.html @@ -0,0 +1,123 @@ + + + + [Nel] A small document for your consumption + + + + + + +

[Nel] A small document for your consumption

+ Vincent Archer + archer@nevrax.com
+ Fri, 13 Apr 2001 11:34:53 +0200 +

+
+ +
While waiting for the whole load, here's a quick and short document. Look
+at it, and critique your hearts out...
+
+Client server connect
+
+This document describes quickly the connection process of a client to a world
+running a NeL-based system.
+
+Abbreviations
+-------------
+
+LS: The login service (one overall)
+WS: The welcome service (one for each world)
+FES: The front-end service (N per world)
+
+Steps
+-----
+
+1: The client initiates a connection to the login service, using the supplied
+   IP and port from the configuration file, with the help of the DNS for IP
+   resolution.
+
+   Note: DNS spoofing or configuration file modification can lead to LS
+   spoofing and hacking of the login/password information of the client.
+   However, DNS is needed for flexibility of the login service location.
+
+2: The client submits its login, password, and system capabilities.
+
+3: The LS checks the login/password validity, and builds the list of all
+   available worlds according to account information and current system
+   settings. This list contains world names and the IP for the WS of that
+   world.
+
+   Note: DNS is not used in that step.
+
+4: The client selects the world it wants to log on, and submits the IP address
+   of its world service to the LS.
+
+5: The LS sends a notification to the selected WS of the client's connection
+   desires. It generates and submits a single-use cookie to validate the
+   incoming connection.
+
+   Note: The cookie includes the client's IP, as seen by the LS (to avoid
+   address translation problems) for validation.
+
+6: The WS selects a FES to accept the client connexion, and submits the cookie
+   to the FES.
+
+7: The FES acknowledges its capacity to accept the client to the WS.
+
+8: The WS acknowledges its capacity to accept the client to the LS, and
+   indicates the IP/port of the selected FES.
+
+9: The LS acknowledges the login request to the client, and indicates the
+   IP/port of the selected FES.
+
+10: The client disconnects from the LS.
+
+11: The client initiates a connection to the indicated FES.
+
+12: The client sends the submitted cookie to the FES.
+
+13: The FES validates and acknowledges the cookie.
+
+Side notes
+----------
+
+Whenever a world starts, the WS establishes a permanent link with the LS,
+using an encrypted link (it is assumed that the LS and WS are located on two
+physically and probably geographically distinct networks). A 'SHARD' message
+serves as authentification, and the WS then updates the LS with its state,
+name and IP address. The WS may have a list of valid IP/port address for WS
+to avoid the occasional pirate server registration.
+
+-- 
+Vincent Archer                                         Email: archer@nevrax.com
+
+Nevrax France.                              Off on the yellow brick road we go!
+
+
+ + + +
+

+ -- cgit v1.2.1