Re: [ogpx] Teleports and protocol resilience

[Meadhbh Hamrick <[e-mail]>]

josh: two phase commit for teleport? i guess it _could_ work, but it would
make things more complicated.
david: this is why i want to limit the number of supported deployment
patterns. while it would be a great research project to work out a "design
language" for describing deployments, i think we should stick with the few
deployment patterns we have before us: Second Life, Second Life with client
mediated Services, Tourist and OpenSim standalone mode. (OpenSim UGAIM grid
mode would probably be something like "Second Life with client mediated
Services")

my primary concern is, i don't want to standardize a teleport protocol that
works ONLY with the tourist model.

On Tue, Oct 13, 2009 at 9:25 AM, David W Levine <[e-mail]> wrote:

>
> 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 <[e-mail]>*
> Sent by: [e-mail]
>
> 10/13/2009 11:53 AM
>   To
> [e-mail]  cc
>   Subject
> Re: [ogpx] Teleports and protocol resilience
>
>
>
>
> On Mon, Oct 12, 2009 at 10:13 PM, Morgaine <*
> [e-mail]* <[e-mail]>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>