Re: [ogpx] Teleports and protocol resilience

[Dan Olivares <[e-mail]>]

One option here is to have a timeout within the agent domain for a
response from the source region with a cap for the destination region
and go over the source region's head to directly request it from the
destination region.      While this isn't always optimal (in the
script and attachment state), it would provide a 'graceful failure'
scenario.     This would also necessitate the need to describe some
kind of a priority 'state backup' mechanism that gets saved to
periodically for when failures occur. It's my guess that some state is
more important then others..   such as..    financial transaction
state..  is more important then say..   who's within 20m on a sensor.
Even though we've not discussed inventory itself yet, it would seem
like we're heading in the direction of having the Agent Domain manage
inventory, therefore the inventory transactions that take place
themselves wouldn't be affected..   just the state of any item that's
'rezzed' in a simulator and not instanced (Attachments).    Would
people be okay with having old data on their attachments if they
didn't have to log-off and log back on in a failure case?

Regards

Dan Olivares


On Tue, Oct 13, 2009 at 3:40 PM, Meadhbh Hamrick
<[e-mail]> wrote:
> hmm.. there were several iterations of the teleport protocol. i'm not
> really sure this is how it was deployed. and if it is, i would argue
> it _shouldn't_ be deployed this way 'cause of the trust issue.
>
> in the typical "Second Life" use case, the client trusts the agent
> domain, and the agent domain trusts region domains 1 and 2. the two
> region domains do not necessarily trust each other. or rather, there
> may be utility to a future where all region domains do not need to
> directly trust all other region domains. in the "tourist" use case,
> the agent domain can be seen as an actor of the client, so it's really
> the client who directly trusts the two region domains. but, you retain
> the benefit when you do not depend on the two region domains trusting
> each other.
>
> man. we seriously need some diagrams.
>
> -cheers
> -meadhbh/infinity
>
> On Tue, Oct 13, 2009 at 10:31 AM, Vaughn Deluca <[e-mail]> wrote:
>> 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 <[e-mail]> wrote:
>>>
>>> On Mon, Oct 12, 2009 at 10:13 PM, Morgaine
>>> <[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
>>
>>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>