Re: [ogpx] Teleports and protocol resilience

[Meadhbh Hamrick <[e-mail]>]

ack. this was supposed to go out to the list.

On Tue, Oct 13, 2009 at 1:36 PM, Meadhbh Hamrick
<[e-mail]> wrote:
> but before we go too far down the rabbit hole with solutions, can we
> make sure we understand the problem domain?
>
> if i understand it, there's a preference that a user's avatar be
> rezzable in the destination region before it is derez'd in the source
> region. so in other words, we don't want to derez the user's av from
> where it is until we know it can be rezzed where it's going.
>
> is this a fair discussion of the problem? i mean irrespective of the
> proposed solutions, this is a feature of teleport that we want, right?
>
> assuming there is consensus on this point, we may want to gingerly
> inject the requirement that the agent domain or the destination region
> domain MAY want to deny the user's teleport. (remember the fuss over
> adult content and underaged users?)
>
> it seems that this is a reasonable place to consider this topic.
> however, it doesn't seem like there's radical consensus over the
> question of whether it's the AD's responsibility to block underage rez
> attempts in adult sims or the destination RD's responsibility or both.
> so when discussing teleport, maybe we could add some verbiage like
> "the AD has the option to block the teleport request here" or "the RD
> has the option to block the teleport here" in flow diagrams.
>
> -cheers
> -meadhbh
>
> On Tue, Oct 13, 2009 at 12: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
>>>
>>>
>>
>