aboutsummaryrefslogtreecommitdiff
path: root/pipermail/nel/2001-December/000836.html
diff options
context:
space:
mode:
authorneodarz <neodarz@neodarz.net>2018-08-11 20:21:34 +0200
committerneodarz <neodarz@neodarz.net>2018-08-11 20:21:34 +0200
commit0ea5fc66924303d1bf73ba283a383e2aadee02f2 (patch)
tree2568e71a7ccc44ec23b8bb3f0ff97fb6bf2ed709 /pipermail/nel/2001-December/000836.html
downloadnevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.tar.xz
nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.zip
Initial commit
Diffstat (limited to '')
-rw-r--r--pipermail/nel/2001-December/000836.html128
1 files changed, 128 insertions, 0 deletions
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 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
+<HTML>
+ <HEAD>
+ <TITLE> [Nel] Re: Nel digest, Vol 1 #210 - 1 msg
+ </TITLE>
+ <LINK REL="Index" HREF="index.html" >
+ <LINK REL="made" HREF="mailto:nel%40nevrax.org">
+ <META NAME="robots" CONTENT="index,nofollow">
+
+ <LINK REL="Previous" HREF="000835.html">
+
+ </HEAD>
+ <BODY BGCOLOR="#ffffff">
+ <H1>[Nel] Re: Nel digest, Vol 1 #210 - 1 msg
+ </H1>
+ <B>nicO
+ </B>
+ <A HREF="mailto:nel%40nevrax.org"
+ TITLE="[Nel] Re: Nel digest, Vol 1 #210 - 1 msg">nel@nevrax.org
+ </A><BR>
+ <I>Wed, 26 Dec 2001 13:36:33 -0500</I>
+ <P><UL>
+ <LI> Previous message: <A HREF="000835.html">[Nel] Max Bezier Patches
+</A></li>
+
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#836">[ date ]</a>
+ <a href="thread.html#836">[ thread ]</a>
+ <a href="subject.html#836">[ subject ]</a>
+ <a href="author.html#836">[ author ]</a>
+ </LI>
+ </UL>
+ <HR>
+<!--beginarticle-->
+<PRE>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
+
+&gt;<i> Subject: RE: [Nel] peer to peer ?
+</I>&gt;<i>
+</I>&gt;<i> There are various reasons why we haven't opted for a peer to peer model.
+</I>&gt;<i>
+</I>&gt;<i> One of the most basic problems is this:
+</I>&gt;<i> We are trying to achieve a high level of audio-visual immersion with scenes
+</I>&gt;<i> in which tens or hundreds of individuals move about fluidly. The majority of
+</I>&gt;<i> players only have 56k modems and bandwidth is a big issue. The problem with
+</I>&gt;<i> peer to peer is that each player has to send and receive tens or hundreds of
+</I>&gt;<i> packets per scene update at a rate of several scene updates per second. The
+</I>&gt;<i> internet headers alone for these packets are liable to completely drown the
+</I>&gt;<i> modem.
+</I>&gt;<i>
+</I>&gt;<i> Internally we use kunning systems to decide which information on which
+</I>&gt;<i> players is relavent to send to which other players taking bandwidth
+</I>&gt;<i> constraints into account. This allows us to make optimum use of the
+</I>&gt;<i> bandwidth available.
+</I>&gt;<i>
+</I>&gt;<i> This code is tightly tied in with the game systems so I'm affraid it won't
+</I>&gt;<i> be released for a while yet.
+</I>&gt;<i>
+</I>&gt;<i> Daniel
+</I>&gt;<i>
+</I>&gt;<i> -----Original Message-----
+</I>&gt;<i> From: <A HREF="mailto:nel-admin@nevrax.org">nel-admin@nevrax.org</A> [mailto:<A HREF="mailto:nel-admin@nevrax.org">nel-admin@nevrax.org</A>]On Behalf Of
+</I>&gt;<i> <A HREF="mailto:nicolas.boulay@ifrance.com">nicolas.boulay@ifrance.com</A>
+</I>&gt;<i> Sent: Tuesday, December 18, 2001 1:16 PM
+</I>&gt;<i> To: <A HREF="mailto:nel@nevrax.org">nel@nevrax.org</A>
+</I>&gt;<i> Subject: [Nel] peer to peer ?
+</I>&gt;<i>
+</I>&gt;<i> -- __--__--
+</I>&gt;<i>
+</I>&gt;<i> Message: 3
+</I>&gt;<i> From: &quot;Vianney Lecroart&quot; &lt;<A HREF="mailto:lecroart@nevrax.com">lecroart@nevrax.com</A>&gt;
+</I>&gt;<i> To: &lt;<A HREF="mailto:nel@nevrax.org">nel@nevrax.org</A>&gt;
+</I>&gt;<i> Subject: Re: [Nel] server architecture (front end,
+</I>&gt;<i> load balancing, login service, ....)
+</I>&gt;<i> Date: Mon, 17 Dec 2001 15:22:30 +0100
+</I>&gt;<i> charset=&quot;iso-8859-1&quot;
+</I>&gt;<i> Reply-To: <A HREF="mailto:nel@nevrax.org">nel@nevrax.org</A>
+</I>&gt;<i>
+</I>&gt;<i> &gt; But how clients are balanced between the N front
+</I>&gt;<i> ends of a shard ?
+</I>&gt;<i>
+</I>&gt;<i> For now, the welcome service does a dumb balancement
+</I>&gt;<i> (try to have the same
+</I>&gt;<i> player number on each front end).
+</I>&gt;<i>
+</I>&gt;<i> &gt;&gt;&gt;&gt; Why don't you try to use LVS ?
+</I>&gt;<i> More generaly do you plan to make direct connection
+</I>&gt;<i> between client (such peer to peer network, or
+</I>&gt;<i> distributed computing) ? It could be nice for
+</I>&gt;<i> reduicing trafic to the server. To havoid cheating,
+</I>&gt;<i> each client cheeck data as the server does. Maybe it
+</I>&gt;<i> could be possible to connect people which interract a
+</I>&gt;<i> lot (in the same area, ...), there is still some
+</I>&gt;<i> mouvement with server to handle critical ressouces.
+</I>&gt;<i> So mouvement to the center server are almost reduice
+</I>&gt;<i> to the minimum.
+</I>&gt;<i>
+</I>&gt;<i> Does i smoke too much ?
+</I>&gt;<i>
+</I>&gt;<i> nicO
+</I>&gt;<i>
+</I>
+</PRE>
+<!--endarticle-->
+ <HR>
+ <P><UL>
+ <!--threads-->
+ <LI> Previous message: <A HREF="000835.html">[Nel] Max Bezier Patches
+</A></li>
+
+ <LI> <B>Messages sorted by:</B>
+ <a href="date.html#836">[ date ]</a>
+ <a href="thread.html#836">[ thread ]</a>
+ <a href="subject.html#836">[ subject ]</a>
+ <a href="author.html#836">[ author ]</a>
+ </LI>
+ </UL>
+</body></html>