Re: [ogpx] My take on Teleports and protocol resilience

[Morgaine <morgaine.dinova at googlemail.com>]

There are many different pathways and data semantics involved during a teleport event.

Almost every permutation of one client, one AD, two regions, two RDs, and a potentially unlimited number of asset services can yield a pathway that may be exercised during the overall teleport avatar operation.  There is no single rule that applies to them all and allows one to claim that it's efficient.  And it gets even more complex when you consider that some service pathways may be proxied by regions and others not, as a provider design choice.

Furthermore,  more than one type of data can flow along each pathway, so even a single pathway can involve many different semantics.  This makes generalized answers very unhelpful.

This is why I decoupled the operation of agent teleport from the other avatar-related operations that are triggered at the same time but which are very distinct from agent teleport.  This allows us to make progress on TP protocol resilience without having to consider the numerous pathways for avatar data first.


Morgaine,




================================

On Mon, Oct 26, 2009 at 11:03 PM, Carlo Wood <carlo at alinoe.com> wrote:

On Mon, Oct 26, 2009 at 08:22:26PM +0100, Vaughn Deluca wrote:
> Second, as i mentioned in my post i am not very concerned about the storage
> space, but more about the *bandwidth*. In your proposal all changes pass from
> viewer to AS to region instead of directly from viewer to region. No matter how

Nah, only the avatar state changes, which are really minimal...
The bulk, all traffic FROM the region TO the viewer can go directly
to the viewer for start (except avatar state change requests:
scripts changing the avatars animation - which is really minimal).
Also real data, like texture uploads will most likely go directly
to the simulator, but well... those are things that are not done
often:

* changing animation
* changing attachments
* changing clothes
* movement (even!)

the reason movement doesn't carry lots of data is simply because
it's generated by a few typed characters: human input.

Each of those are small messages (sone UUID's) and with a low
frequency.

In fact, I can't think of anything from viewer to simulator
that uses any significant bandwidth :/

Script state might be "significant", but 1) smaller than the
average texture, and 2) only needed when someone teleports.
Besides, scripts run on the simulator, not on the AS (although
I think HUD scripts should; but THOSE don't need their state
to be sent to the simulator).

Non-avatar state data can just go directly to the simulator
anyway, thus. For example, local chat.

--

Carlo Wood <carlo at alinoe.com>
_______________________________________________
ogpx mailing list
ogpx at ietf.org
https://www.ietf.org/mailman/listinfo/ogpx