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

[Nel] A small document for your consumption

+ Vincent Archer + archer@nevrax.com
+ Tue, 17 Apr 2001 12:27:13 +0200 +

+
+ +
I'll answer both posts at the same time...
+
+According to Thierry Mallard:
+> Possibly this can be partially avoided by providing your own DN Server's IP ?
+> (dunno precisly how the client would connect to it, but still...)
+
+There are two ways you can find out a server:
+
+1) Hardcode the IP address (then, you cannot move the server)
+2) Use DNS for dynamic IP (then, the hardcoded address is the root of the
+	DNS tree - which, hopefully, changes even less often than we will)
+
+You can't specify your "own DNS". Using that is basically the same as
+using method 1: you still have to put a server at a static IP that gives
+you off the dynamic IP.
+
+> > 2: The client submits its login, password, and system capabilities.
+> 
+> In plaintext ?
+
+If we assume the link has a crypt method in it, why not.
+
+Three possible methods for password submission
+
+1) Plaintext, assuming the connection has a form of crypt in place
+2) MD5/crypt password. Spoofable, since:
+	a) You can capture the MD5/crypt string
+	b) You have the client source, so can hack it to send the static
+		crypted password instead of crypting the - unknown - plaintext
+3) MD5 for a dynamic challenge. A good example: the server sends you the
+	current date when you connect, and you use that date as the first
+	bytes of the MD5 digest.
+
+> > 4: The client selects the world it wants to log on, and submits the IP address
+> >    of its world service to the LS.
+> 
+> Would it be good if the client could select several worlds ?
+> (then the negociation following could use this to get a good WS)
+
+Not good. Typically, the client will connect to the world the player has
+a character he wants to play today :)
+
+However, the client may use the IP addresses of the WS to ping them and
+figure out which connection is better (when selecting its first world).
+
+> 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 --
+
+The WS *is* the load balancing mechanism. Since he's aware of all FES
+up and running, and knows their load right now, he's best suited to
+determine which FES can afford to manage a new character.
+
+> I wonder if it couldn't be more interesting if the client disconnects from LS
+> _after_ having initiated the connection to the FES. Then, if something goes
+> wrong, the client could goto 4 directly.
+
+Hmmm, that might be good, yes.
+
+-- 
+Vincent Archer                                         Email: archer@nevrax.com
+
+Nevrax France.                              Off on the yellow brick road we go!
+
+
+ + +
+

+ -- cgit v1.2.1