Re: [ogpx] Teleports and protocol resilience

[Vaughn Deluca <[e-mail]>]

On Tue, Oct 13, 2009 at 10: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?
>

Yes, i definitely think so.


> 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.
>

I think there was reasonable consensus that both can block the TP, simply
because its local policy that rules.


> 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.
>

Absolutely, and I did so in this example:
 http://www.ietf.org/mail-archive/web/ogpx/current/msg00570.html

:)
-Vaughn


> -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
> >>
> >>
> >
>