Re: [ogpx] Teleports and protocol resilience
Joshua Bell <josh@lindenlab.com> Tue, 13 October 2009 15:53 UTC
Return-Path: <josh@lindenlab.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 2D2633A6774 for <ogpx@core3.amsl.com>;
Tue, 13 Oct 2009 08:53:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.624
X-Spam-Level:
X-Spam-Status: No,
score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001,
FM_FORGED_GMAIL=0.622, 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 JNZMSPGqSJX0 for
<ogpx@core3.amsl.com>; Tue, 13 Oct 2009 08:53:20 -0700 (PDT)
Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com
[209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id C5ED33A6822 for
<ogpx@ietf.org>; Tue, 13 Oct 2009 08:53:16 -0700 (PDT)
Received: by pzk42 with SMTP id 42so3176856pzk.31 for <ogpx@ietf.org>;
Tue, 13 Oct 2009 08:53:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.177.3 with SMTP id z3mr821151rve.127.1255449195172;
Tue, 13 Oct 2009 08:53:15 -0700 (PDT)
In-Reply-To: <e0b04bba0910122213n66886b92x57446ad84def466f@mail.gmail.com>
References: <e0b04bba0910122213n66886b92x57446ad84def466f@mail.gmail.com>
Date: Tue, 13 Oct 2009 08:53:15 -0700
Message-ID: <f72742de0910130853y2e14a37bkef366f7ddcbf1f63@mail.gmail.com>
From: Joshua Bell <josh@lindenlab.com>
To: ogpx@ietf.org
Content-Type: multipart/alternative; boundary=000e0cd1a6204fd2a50475d30bb7
Subject: Re: [ogpx] 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, 13 Oct 2009 15:53:21 -0000
On Mon, Oct 12, 2009 at 10:13 PM, Morgaine <morgaine.dinova@googlemail.com>wrote;wrote: > I suggest that the protocol define Derez and Rez as *concurrent* and * > non-dependent* operations to avoid this situation. The AD can mark R1 as > disabled for all further agent state changes --- this will provide all the > protection needed to prevent brief double-presence anomalies from being > significant. If a jammed R1 refuses to give up its hold on the avatar, then > at least the user will not suffer from it. Reaping dead simulator sessions > then becomes a problem for the region operator alone, and not for the AD, > the user, and the region as happens now. > Unresponsive origin regions are an excellent use case to consider. One of the reasons that this fails today is that the origin RD maintains some amount of agent state (e.g. script state for attachments). For a sim-to-sim handoff, the origin RD must successfully transmit information either to the AD or the destination RD (or both), otherwise the user experience is poor (information is lost). Note that this needs to happen during a simple logoff/login as well. It seems to me that agent state in the AD should have ACID-ish characteristics, including the agent's current location. Given that we must be able to describe behavior of closing a client-AD connection when the RD is unresponsive (e.g. the host has dropped off the network, etc), I'd be inclined to tackle unresponsive origins in similar fashion for logout/login, region crossing, and teleport. (Which in the current drafts are indeed tackled together.) So: I would agree that the current behavior of SL is less than ideal - if the source region is unresponsive (for some TBD definition), a teleport should probably not fail. But to preserve user data (and preserve the user experience), the initial transport attempt must involve a transaction between the AD, source RD and destination RD.
- [ogpx] Teleports and protocol resilience Morgaine
- Re: [ogpx] Teleports and protocol resilience Kari Lippert
- Re: [ogpx] Teleports and protocol resilience Infinity Linden (Meadhbh Hamrick)
- Re: [ogpx] Teleports and protocol resilience Joshua Bell
- Re: [ogpx] Teleports and protocol resilience David W Levine
- Re: [ogpx] Teleports and protocol resilience Meadhbh Hamrick
- Re: [ogpx] Teleports and protocol resilience Mike Dickson
- Re: [ogpx] Teleports and protocol resilience Charles Krinke
- Re: [ogpx] Teleports and protocol resilience Joshua Bell
- Re: [ogpx] Teleports and protocol resilience Vaughn Deluca
- Re: [ogpx] Teleports and protocol resilience Joshua Bell
- Re: [ogpx] Teleports and protocol resilience Vaughn Deluca
- Re: [ogpx] Teleports and protocol resilience Meadhbh Hamrick
- Re: [ogpx] Teleports and protocol resilience Dan Olivares
- Re: [ogpx] Teleports and protocol resilience Meadhbh Hamrick
- Re: [ogpx] Teleports and protocol resilience Vaughn Deluca
- Re: [ogpx] Teleports and protocol resilience Morgaine
- Re: [ogpx] Teleports and protocol resilience David W Levine
- Re: [ogpx] Teleports and protocol resilience Morgaine
- Re: [ogpx] Teleports and protocol resilience Lawson English
- Re: [ogpx] Teleports and protocol resilience Morgaine
- Re: [ogpx] Teleports and protocol resilience Vaughn Deluca
- Re: [ogpx] Teleports and protocol resilience Morgaine
- Re: [ogpx] Teleports and protocol resilience Carlo Wood