Re: [ogpx] My take on Teleports and protocol resilience

Carlo Wood <carlo@alinoe.com> Mon, 26 October 2009 22:03 UTC

Return-Path: <carlo@alinoe.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8654F28C18B for <ogpx@core3.amsl.com>; Mon, 26 Oct 2009 15:03:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.985
X-Spam-Level:
X-Spam-Status: No, score=0.985 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGxJI34pE1az for <ogpx@core3.amsl.com>; Mon, 26 Oct 2009 15:03:44 -0700 (PDT)
Received: from viefep19-int.chello.at (viefep19-int.chello.at [62.179.121.39]) by core3.amsl.com (Postfix) with ESMTP id 51C2A28C181 for <ogpx@ietf.org>; Mon, 26 Oct 2009 15:03:44 -0700 (PDT)
Received: from edge01.upc.biz ([192.168.13.236]) by viefep19-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20091026220356.JEIG27358.viefep19-int.chello.at@edge01.upc.biz>; Mon, 26 Oct 2009 23:03:56 +0100
Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upc.biz with edge id xa3t1c02r0FlQed01a3uxN; Mon, 26 Oct 2009 23:03:56 +0100
X-SourceIP: 77.250.43.12
Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from <carlo@alinoe.com>) id 1N2XfE-0006N8-9e; Mon, 26 Oct 2009 23:03:44 +0100
Date: Mon, 26 Oct 2009 23:03:44 +0100
From: Carlo Wood <carlo@alinoe.com>
To: Vaughn Deluca <vaughn.deluca@gmail.com>
Message-ID: <20091026220344.GA24111@alinoe.com>
References: <20091025121547.GB7775@alinoe.com> <9b8a8de40910251530u273830a5k47bdd8927b7efc76@mail.gmail.com> <20091026150239.GA6496@alinoe.com> <9b8a8de40910261222q30780f0fp1c8f4fa38383ab5d@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9b8a8de40910261222q30780f0fp1c8f4fa38383ab5d@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: ogpx@ietf.org
Subject: Re: [ogpx] My take on Teleports and protocol resilience
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Worlds and the Open Grid Protocol <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2009 22:03:45 -0000

On Mon, Oct 26, 2009 at 08:22:26PM +0100, Vaughn Deluca wrote:
> Second, as i mentioned in my post i am not very concerned about the storage
> space, but more about the *bandwidth*. In your proposal all changes pass from
> viewer to AS to region instead of directly from viewer to region. No matter how

Nah, only the avatar state changes, which are really minimal...
The bulk, all traffic FROM the region TO the viewer can go directly
to the viewer for start (except avatar state change requests:
scripts changing the avatars animation - which is really minimal).
Also real data, like texture uploads will most likely go directly
to the simulator, but well... those are things that are not done
often:

* changing animation
* changing attachments
* changing clothes
* movement (even!)

the reason movement doesn't carry lots of data is simply because
it's generated by a few typed characters: human input.

Each of those are small messages (sone UUID's) and with a low
frequency.

In fact, I can't think of anything from viewer to simulator
that uses any significant bandwidth :/

Script state might be "significant", but 1) smaller than the
average texture, and 2) only needed when someone teleports.
Besides, scripts run on the simulator, not on the AS (although
I think HUD scripts should; but THOSE don't need their state
to be sent to the simulator).

Non-avatar state data can just go directly to the simulator
anyway, thus. For example, local chat.

-- 
Carlo Wood <carlo@alinoe.com>