Re: [ogpx] Teleports and protocol resilience

I think this gets even messier when you look at multiple deployment 
patterns. With a range of possible ways people might build out the 
services, its going to be interesting to work out what one expects at a 
region That said, one assumes that the key services which matter for 
attempting to determine if a "region" is live are those which emit the 
agent's in world component's current state. Working out what's needed, and 
why, might well, help us put some bounds on this. 

- David

Joshua Bell <josh@lindenlab.com> 
Sent by: ogpx-bounces@ietf.org
10/13/2009 11:53 AM

To
ogpx@ietf.org
cc

Subject
Re: [ogpx] Teleports and protocol resilience

On Mon, Oct 12, 2009 at 10:13 PM, Morgaine <morgaine.dinova@googlemail.com
> 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 mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx