assos/khaganat/nevrax-website-self-hostable - nevrax.org hostable version of khaganat project - Mirror of https://git.khaganat.net/neodarz/nevrax-website-self-hostable

diff options


context:
space:
mode:

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 'pipermail/nel/2001-December/000836.html')

-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>

+ nicO

+

+ <A HREF="mailto:nel%40nevrax.org"

+ TITLE="[Nel] Re: Nel digest, Vol 1 #210 - 1 msg">nel@nevrax.org

+ </A>

+ Wed, 26 Dec 2001 13:36:33 -0500

+ <UL>

+ <LI> Previous message: <A HREF="000835.html">[Nel] Max Bezier Patches

+</A></li>

+ <LI> Messages sorted by:

+ <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>

+

+<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

+> 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: <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

+> <A HREF="mailto:nicolas.boulay@ifrance.com">nicolas.boulay@ifrance.com</A>

+> Sent: Tuesday, December 18, 2001 1:16 PM

+> To: <A HREF="mailto:nel@nevrax.org">nel@nevrax.org</A>

+> Subject: [Nel] peer to peer ?

+>

+> -- __--__--

+>

+> Message: 3

+> From: "Vianney Lecroart" <<A HREF="mailto:lecroart@nevrax.com">lecroart@nevrax.com</A>>

+> To: <<A HREF="mailto:nel@nevrax.org">nel@nevrax.org</A>>

+> 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: <A HREF="mailto:nel@nevrax.org">nel@nevrax.org</A>

+>

+> > 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

+>

+

+</PRE>

+