[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



OK, you convinced me regarding the bandwith. We are talking very low frequency user generated changes, and a small amount of data is passed by reference. Should be no problem.

I am still worried about the detour, but  i have no argument, just a gut feeling  :)

I do not see the need to send the movement instructions via the AS. It will ony generate unneeded delays, and that info is not part of the avatar state anyhow.
Why "even" movment?


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>


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.