[ogpx] Teleports and protocol resilience

[Morgaine <[e-mail]>]

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.