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-December/000836.html | 128 ++++++++++++++++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 pipermail/nel/2001-December/000836.html (limited to 'pipermail/nel/2001-December/000836.html') diff --git a/pipermail/nel/2001-December/000836.html b/pipermail/nel/2001-December/000836.html new file mode 100644 index 00000000..b9145803 --- /dev/null +++ b/pipermail/nel/2001-December/000836.html @@ -0,0 +1,128 @@ + + + + [Nel] Re: Nel digest, Vol 1 #210 - 1 msg + + + + + + + + + +

[Nel] Re: Nel digest, Vol 1 #210 - 1 msg +

+ nicO + + nel@nevrax.org +
+ Wed, 26 Dec 2001 13:36:33 -0500 +

+
+ +
I imagine that the data resend by the server are almost the same than
+those send by the client. It isn't possible to mix this to technics ? We
+can imagine peer to peer access for close characters to interract with a
+minimuim latency. And for the farer charaters, we can use the server and
+movement prediction (which could not be so bad because if there far, the
+characters will be small on screen).
+
+The idea behind that is to relax the pressure on the needed latency of
+the server. Does it not possible to add some more intelligence inside
+the client to predict what is usefull or not to minimize exchange ? 
+
+nicO
+
+> Subject: RE: [Nel] peer to peer ?
+> 
+> There are various reasons why we haven't opted for a peer to peer model.
+> 
+> One of the most basic problems is this:
+> We are trying to achieve a high level of audio-visual immersion with scenes
+> in which tens or hundreds of individuals move about fluidly. The majority of
+> players only have 56k modems and bandwidth is a big issue. The problem with
+> peer to peer is that each player has to send and receive tens or hundreds of
+> packets per scene update at a rate of several scene updates per second. The
+> internet headers alone for these packets are liable to completely drown the
+> modem.
+> 
+> Internally we use kunning systems to decide which information on which
+> players is relavent to send to which other players taking bandwidth
+> constraints into account. This allows us to make optimum use of the
+> bandwidth available.
+> 
+> This code is tightly tied in with the game systems so I'm affraid it won't
+> be released for a while yet.
+> 
+> Daniel
+> 
+> -----Original Message-----
+> From: nel-admin@nevrax.org [mailto:nel-admin@nevrax.org]On Behalf Of
+> nicolas.boulay@ifrance.com
+> Sent: Tuesday, December 18, 2001 1:16 PM
+> To: nel@nevrax.org
+> Subject: [Nel] peer to peer ?
+> 
+> -- __--__--
+> 
+> Message: 3
+> From: "Vianney Lecroart" <lecroart@nevrax.com>
+> To: <nel@nevrax.org>
+> Subject: Re: [Nel] server architecture (front end,
+> load balancing, login service, ....)
+> Date: Mon, 17 Dec 2001 15:22:30 +0100
+> charset="iso-8859-1"
+> Reply-To: nel@nevrax.org
+> 
+> > But how clients are balanced between the N front
+> ends of a shard ?
+> 
+> For now, the welcome service does a dumb balancement
+> (try to have the same
+> player number on each front end).
+> 
+> >>>> Why don't you try to use LVS ?
+> More generaly do you plan to make direct connection
+> between client (such peer to peer network, or
+> distributed computing) ? It could be nice for
+> reduicing trafic to the server. To havoid cheating,
+> each client cheeck data as the server does. Maybe it
+> could be possible to connect people which interract a
+> lot (in the same area, ...), there is still some
+> mouvement with server to handle critical ressouces.
+> So mouvement to the center server are almost reduice
+> to the minimum.
+> 
+> Does i smoke too much ?
+> 
+> nicO
+>
+
+
+ +
+

+ -- cgit v1.2.1