Re: [ogpx] Teleports and protocol resilience

[Kari Lippert <[e-mail]>]

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.



+1


Kari



On Tue, Oct 13, 2009 at 1:13 AM, Morgaine <[e-mail]>wrote;wrote:

> One of the advantages we have in developing the VWRAP protocols is that we
> are able to look back at legacy SL and Opensim protocols and recognize
> design mistakes or limitations in them.  This allows us to avoid repeating
> such mistakes or limitations in the next generation of systems.
>
> One of the most common sources of frustration and dissatisfaction is
> simulator non-responsiveness.  While this has many possible causes, in VWRAP
> we are not interested in the internal implementation of simulators, but we
> *ARE* interested in the ability of a protocol endpoint to perform its duty
> within the protocol.  A jammed simulator host is in many cases quite unable
> to perform its protocol duties, or in some cases only exceedingly slowly,
> often timing out in a TP for example.  We have a huge amount of experience
> of this happening in both SL and Opensim, so it is a practical reality.  On
> occasion, simulators will be unable to fulfil their part in a protocol, and
> this needs to be taken into account because it is *not uncommon*.
>
> One key area in which the above is relevant is in teleports *OUT* of a
> simulator that is under distress.  Quite often users wish nothing more than
> to *leave* the region being run by a dying simulator, but when
> teleport-out requires cooperation from the host that one is trying to leave
> then this is often not possible at all.  In this situation, the only remedy
> in existing systems is to forcibly terminate the client and relog in another
> region.  We should avoid such out-of-protocol remedies being necessary
> through good protocol design.
>
> In VWRAP, we have both Rez Avatar and Derez Avatar capabilities, which lead
> to corresponding protocol operations during teleport.  If R1 is a region
> being run by a non-responsive simulator from which we want to escape, and R2
> is another region to which we wish to go, if the protocol requires a Derez
> in R1 to be completed before a Rez in R2 can commence then the user will
> have difficulties.  Clearly we don't want this.
>
> In http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 , it is made
> clear that "*The agent domain MUST also remove the avatar from it's
> current location before placing the avatar in the destination location*."
> This suggests that the protocol will be sensitive to R1 non-responsiveness.
> While we do not yet have an actual VWRAP Teleport draft, it seems likely
> that its initial incarnation will have that same problem built in.
>
> 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.
>
>
> Morgaine.
>
>
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>