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/000404.html | 105 +++++++++++++++++++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 pipermail/nel/2001-April/000404.html (limited to 'pipermail/nel/2001-April/000404.html') diff --git a/pipermail/nel/2001-April/000404.html b/pipermail/nel/2001-April/000404.html new file mode 100644 index 00000000..cde29a46 --- /dev/null +++ b/pipermail/nel/2001-April/000404.html @@ -0,0 +1,105 @@ + + + + [Nel] A small document for your consumption + + + + + + +

[Nel] A small document for your consumption

+ Thierry Mallard + thierry@mallard.com
+ Tue, 17 Apr 2001 08:33:31 +0200 +

+
+ +
On Fri, Apr 13, 2001 at 11:34:53AM +0200, Vincent Archer wrote:
+> Steps
+> -----
+> [...]
+> 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.
+
+The LS <--> WS connection should be studied, perhaps ?
+(if it wasn't intended in this document, then let's see that later.. ;-) )
+
+[ *err.. ok i just read the end on the original mail, just forget it* ]
+
+> 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.
+
+So the WS is (or can be?) a load-balancer to all the FES in a given world ?
+-- the balancing being done at network level, not process level --
+
+> 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.
+
+IMHO, as said in the other mail, the client should then disconnect from the
+LS ; not before. The downside I see in this case would be the extended time of
+connection (steps 11 et 13), which will lead to more network load. I don't see
+how important that would be.
+
+> 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.
+
+ok, so i should have read the whole document before arguing ;-))
+
+Hope this helps..
+
+-- 
+Thierry Mallard              | http://vawis.net
+GnuPG key on wwwkeys.pgp.net | http://erlang-fr.org (new)
+key 0xA3D021CB               | http://worldforge.org
+
+
+
+ + + + +
+

+ -- cgit v1.2.1