Re: [ogpx] Teleports and protocol resilience

["Infinity Linden (Meadhbh Hamrick)" <[e-mail]>]

the reason the teleport process removes a user from one region before
placing it in another is to ensure that the user's avatar exists in at
most one place. i understand that this is a non-issue with hypergrid
or tourist models, as there's no assumption of coherence between
regions. but, many of us want to provide a virtual world experience
that includes this concept.

thx
m/∞
--
   infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
         http://wiki.secondlife.com/wiki/User:Infinity_Linden



On Mon, Oct 12, 2009 at 22:25, Kari Lippert <[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.
>
> +1
>
> Kari
>
>
> On Tue, Oct 13, 2009 at 1:13 AM, Morgaine <[e-mail]>
> 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
>>
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>