diff options
| author | neodarz <neodarz@neodarz.net> | 2018-08-11 20:21:34 +0200 |
|---|---|---|
| committer | neodarz <neodarz@neodarz.net> | 2018-08-11 20:21:34 +0200 |
| commit | 0ea5fc66924303d1bf73ba283a383e2aadee02f2 (patch) | |
| tree | 2568e71a7ccc44ec23b8bb3f0ff97fb6bf2ed709 /pipermail/nel/2001-December/000836.html | |
| download | nevrax-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.html | 128 |
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 + +><i> Subject: RE: [Nel] peer to peer ? +</I>><i> +</I>><i> There are various reasons why we haven't opted for a peer to peer model. +</I>><i> +</I>><i> One of the most basic problems is this: +</I>><i> We are trying to achieve a high level of audio-visual immersion with scenes +</I>><i> in which tens or hundreds of individuals move about fluidly. The majority of +</I>><i> players only have 56k modems and bandwidth is a big issue. The problem with +</I>><i> peer to peer is that each player has to send and receive tens or hundreds of +</I>><i> packets per scene update at a rate of several scene updates per second. The +</I>><i> internet headers alone for these packets are liable to completely drown the +</I>><i> modem. +</I>><i> +</I>><i> Internally we use kunning systems to decide which information on which +</I>><i> players is relavent to send to which other players taking bandwidth +</I>><i> constraints into account. This allows us to make optimum use of the +</I>><i> bandwidth available. +</I>><i> +</I>><i> This code is tightly tied in with the game systems so I'm affraid it won't +</I>><i> be released for a while yet. +</I>><i> +</I>><i> Daniel +</I>><i> +</I>><i> -----Original Message----- +</I>><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>><i> <A HREF="mailto:nicolas.boulay@ifrance.com">nicolas.boulay@ifrance.com</A> +</I>><i> Sent: Tuesday, December 18, 2001 1:16 PM +</I>><i> To: <A HREF="mailto:nel@nevrax.org">nel@nevrax.org</A> +</I>><i> Subject: [Nel] peer to peer ? +</I>><i> +</I>><i> -- __--__-- +</I>><i> +</I>><i> Message: 3 +</I>><i> From: "Vianney Lecroart" <<A HREF="mailto:lecroart@nevrax.com">lecroart@nevrax.com</A>> +</I>><i> To: <<A HREF="mailto:nel@nevrax.org">nel@nevrax.org</A>> +</I>><i> Subject: Re: [Nel] server architecture (front end, +</I>><i> load balancing, login service, ....) +</I>><i> Date: Mon, 17 Dec 2001 15:22:30 +0100 +</I>><i> charset="iso-8859-1" +</I>><i> Reply-To: <A HREF="mailto:nel@nevrax.org">nel@nevrax.org</A> +</I>><i> +</I>><i> > But how clients are balanced between the N front +</I>><i> ends of a shard ? +</I>><i> +</I>><i> For now, the welcome service does a dumb balancement +</I>><i> (try to have the same +</I>><i> player number on each front end). +</I>><i> +</I>><i> >>>> Why don't you try to use LVS ? +</I>><i> More generaly do you plan to make direct connection +</I>><i> between client (such peer to peer network, or +</I>><i> distributed computing) ? It could be nice for +</I>><i> reduicing trafic to the server. To havoid cheating, +</I>><i> each client cheeck data as the server does. Maybe it +</I>><i> could be possible to connect people which interract a +</I>><i> lot (in the same area, ...), there is still some +</I>><i> mouvement with server to handle critical ressouces. +</I>><i> So mouvement to the center server are almost reduice +</I>><i> to the minimum. +</I>><i> +</I>><i> Does i smoke too much ? +</I>><i> +</I>><i> nicO +</I>><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> |