Re: [ogpx] Beyond the monolithic client protocol endpoint (was Re: Synchronization of gestures)

[Han Sontse <[e-mail]>]

On Dec 6, 2009, at 7:46 PM, David W Levine wrote:

>
> The current specs certainly are intended to be totally neutral on  
> this. The only place I can see where one would have to pay attention  
> would be in managing and establishing TLS pipes (HTTPS) and this is  
> routinely done within web environments. As you observe, the semantic  
> of capabilities is designed to support this. It would actually take  
> some effort to break that semantic.
>
> That said, there are structures which work better, and worse, when  
> they are widely distributed.Asset, Messaging, and Such distribute  
> without much pain. The core state sharing application (What a region  
> does for a living) is harder to spread out, and likewise, there are  
> interesting synchronization challenges as you break apart client  
> components. The less shared tasks (such as manipulating your  
> inventory) are less sensitive. The data flows which manage the  
> shared visual experience more so.
>
> From the protocol perspective, I suggest the question is "Are there  
> specific synchronization management issues we need to surface." I'm  
> not expecting a lot, but if we know of some, we should get them on  
> the table.I will also gently remind people of the notewell, when it  
> comes to
> any IPR encumbered issues in this space.
>
> - David / Zha
>

Loosely speaking we need to be able to deal with a cloud-to-cloud  
relationship.   This fuzzy notion seems to extend to client-clouds and  
server-clouds, as well as P2P clouds.   To the extent that a given  
simulation space might contain other simulations, one could even  
consider each client as a server and each server as a client.

maybe a way to begin to break down the complexity in these  
relationships it to look at the different classes of service that may  
be declared:

Protocol constraints
One-shot  (UDP)
simple Ack (UDP-UDP)
Transactional short term (TCP)
Complex (Multi-port/multi-host???)

QoS
Isochronous -- definite real time interval; predefined sequence order
Synchronous --  predefined sequence ordering, indefinite time interval
Asynchronous -- indefinite sequencing, indefinite timing

Payload class declaration
	content streams
	parametric events
	bulk transfers
	OoB Signalling

Payload structure declaration
	intrinsics (uint32, bool, etc)
		direct
		indirect
	structured
	complex

Topology (Client and server are sub-classed peers)
	Ringed/chained P2P (a peer only knows 1 or 2 neighbors in the context)
	Open P2P( a peer knows all other peers in the context)
	Hierarchical P2P (peer knows a small set of super-peers and an  
arbitrary number of local peers)
	???

and so on....
~HS~