Re: [ogpx] Teleports and protocol resilience

[Vaughn Deluca <vaughn.deluca at gmail.com>]

Regarding the serialisation and passing-off of avatar data, the present TP draft keeps the source region in the communication path, even *after* a successful Derez and serialisation. The result from the new Rez is passed via the source region back to the agent domain. 

There might be good reasons for that path (efficiency?), but for sure it complicates things if the source region is dying.

@Joshua

RD is not the same as Region, in the TP drafs its the Region(service) that has the interface.

@Infinity, the tourist use case is not very well defined as yet (working on that) but in my interpretation if will for sure specify the same constraint of "no duplication of avatars".

-Vaughn

On Tue, Oct 13, 2009 at 5:53 PM, Joshua Bell <josh at lindenlab.com> wrote:

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