Re: [ogpx] Event Streams, Realtime and transport

[David W Levine <[e-mail]>]

So... Infinity made some very fair points. Lets try this.





For streaming:

I want to take a moment to walk the why... 

So, speaking a bit abstractly... 

When we inject an Avatar into a Region, we model this as a pretty straight 
forward request/response call. The region gets called, accepts the agent's 
avatar information and adds it to the
local state. The region is maintaining and continually updating the state 
of the virtual space it manages. The region needs to push down to the 
client, the current state, and then, incrementally
updates to that state. So, a side effect of entering the region is that 
the region sends its current state, and then begins to stream updates. 
This is, of course, the core business of the region. 

The Legacy Second Life Protocol streams down a series of "object updates" 
which consist of the shapes of things, along with pointers to the textures 
and (in the case of scuplties, the sculpt map) The client then can consult 
its cache, and either fetch these bulky items from the cache, or from the 
Region. 

The current charter doesn't say a lot about the nature of the Client / 
Region relationship. So.. lets try this... 

First, the attributes we want to address:

* Regions hold and manage the "state" of the virtual space they represent. 
They accept agent actions, simulate the region, and send updates to the 
clients who can see their portion of virtual space. 

Then.. in protocol characteristics:

* The specifications will include an asynchronous, region driven set of 
updates which are delivered to clients. The specifications will include a 
balanced blend of notifying clients of updates, over available transports, 
and pulling data from the region as needed. 


For realtime: 

In the attributes of worlds we want to address section:

add:

* Bounded by Latency constraints, are expected to be responsive to simple 
user inputs without queuing delays. This does not mean complex actions 
will be performed in real time, but that the overall specification set 
accepts the requirement that some low level operations happen without 
protocol imposed delays. 

(One wants forward step, turn and such, to be fast, we are NOT mandating 
"Rez 12,000 prim object in 400 mseconds" )

In the protocol characteristics:

* Managing the desired response time goals for low level user inputs may 
require routing some traffic on protocols optimized for low latency use. 
The working group will characterize these goals. The Working group will 
evaluate the suitability of proposed transports in light of these 
characterizations. 


NOTE: these are coupled. The goal is to deliver a near simultaneous 
experience, in which the collective actions of all the present avatars, 
along with scripted objects, physics simulations and other computational 
artifacts are updated in a smooth, continuous fashion. One could easily 
model the set of updates as a resource, which the client "gets" once every 
so often. At the several minute perspective,
this would likely deliver all the needed data. At the user level, it would 
not  permit the client to create a smooth, shared immersive experience. 

- David