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

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@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@alinoe.com>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>