IETF Logo Mail Archive

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

Vaughn Deluca <vaughn.deluca@gmail.com> Tue, 27 October 2009 21:32 UTC

Return-Path: <vaughn.deluca@gmail.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 2CE6A3A69BB for <ogpx@core3.amsl.com>; Tue, 27 Oct 2009 14:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.388
X-Spam-Level:
X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 kHocsKD7WclE for <ogpx@core3.amsl.com>; Tue, 27 Oct 2009 14:32:28 -0700 (PDT)
Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id A0EB53A6950 for <ogpx@ietf.org>; Tue, 27 Oct 2009 14:32:27 -0700 (PDT)
Received: by bwz23 with SMTP id 23so205374bwz.29 for <ogpx@ietf.org>; Tue, 27 Oct 2009 14:32:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=TkD5pYkMgE8+r+1XEy0s22GGNGNNfij6sSwkLXgXIrc=; b=BjXa/EwPRDE9VMJjaQ3DQbHbdmnHs/tJTMj1l3YTqLEGGyZjO+1NHCev6JU+3rchkj IRWhvdMg05LQ31G9BM7cSQi6sKuD7Fqk6ZGHXjwLBf5YdwelwYDlzt/q31gL/kZy+Bsp 30XrLuIp+0WuefRxwTp3hvG6aUFDNlEzqOEWU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=f6C8H41n0BzuyMlH62fIRSsW82CFrog7GOug5/XvJXJjga51LlDkEgq+3w21RtHFuI o5q2OXQkuL5vyob5Nwlfb2ZUU+rEl/WnIXl9mazzuSpDOQhvHvLSjrfjiP6nVJP+T9zP CQweM+q0+UjVcA5+NrXWjV7tVWuX8KeTInyik=
MIME-Version: 1.0
Received: by 10.204.154.131 with SMTP id o3mr9394797bkw.66.1256679159757; Tue, 27 Oct 2009 14:32:39 -0700 (PDT)
In-Reply-To: <20091026220344.GA24111@alinoe.com>
References: <20091025121547.GB7775@alinoe.com> <9b8a8de40910251530u273830a5k47bdd8927b7efc76@mail.gmail.com> <20091026150239.GA6496@alinoe.com> <9b8a8de40910261222q30780f0fp1c8f4fa38383ab5d@mail.gmail.com> <20091026220344.GA24111@alinoe.com>
Date: Tue, 27 Oct 2009 22:32:39 +0100
Message-ID: <9b8a8de40910271432n7ce70496vffd4076614335303@mail.gmail.com>
From: Vaughn Deluca <vaughn.deluca@gmail.com>
To: Carlo Wood <carlo@alinoe.com>
Content-Type: multipart/alternative; boundary=0015175cae66e9ff150476f16ae4
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: Tue, 27 Oct 2009 21:32:29 -0000

OK, you convinced me regarding the bandwith. We are talking very low
frequency user generated changes, and a small amount of data is passed by
reference. Should be no problem.

I am still worried about the detour, but  i have no argument, just a gut
feeling  :)

I do not see the need to send the movement instructions via the AS. It will
ony generate unneeded delays, and that info is not part of the avatar state
anyhow.
Why "even" movment?


On Mon, Oct 26, 2009 at 11:03 PM, Carlo Wood <carlo@alinoe.com> wrote:

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

v2.8.7 | Report a Bug | By Email