I think this gets even messier when
you look at multiple deployment patterns. With a range of possible ways
people might build out the services, its going to be interesting to work
out what one expects at a region That said, one assumes that the key services
which matter for attempting to determine if a "region" is live
are those which emit the agent's in world component's current state. Working
out what's needed, and why, might well, help us put some bounds on this.
- David
Joshua Bell <josh at lindenlab.com> Sent by: ogpx-bounces at ietf.org
10/13/2009 11:53 AM
To
ogpx at ietf.org
cc
Subject
Re: [ogpx] Teleports and protocol resilience
On Mon, Oct 12, 2009 at 10:13 PM, Morgaine <morgaine.dinova at googlemail.com>
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
ogpx at ietf.org https://www.ietf.org/mailman/listinfo/ogpx