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

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

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 



Morgaine <[e-mail]> 
Sent by: [e-mail]
12/06/2009 12:11 PM

To
[e-mail]
cc

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






>From a protocol perspective, the key observation in this area is that 
different data paths from VWRAP services to the client no longer all 
terminate in the same client-side process --- that is only one extreme end 
of the possible spectrum of implementations.

In today's concurrent execution environment, the "application" may 
comprise multiple processes on the same client-side host, or be 
distributed across several client-side hosts (either virtualized or real), 
and quite possibly involve multiple remote hosts on the Internet as well.  
The concept of "application" has broadened since its early years, in part 
because of the arrival of multicore, and in part because of ever-growing 
user expectations fueled by the Internet and social networking.

It's not up to us to prejudge nor prescribe how VW applications will be 
structured.  The fact that advanced ones will involve multiple disjoint 
processes is a given, and our protocol endpoint design must take that into 
account, or it will be obsolete before it is even ready.

Fortunately, the capability model embraces this concept perfectly.  Having 
acquired a capability from an AD or from an RD, this capability represents 
all that is needed for anyone to perform whatever action is controlled by 
that capability --- it does not prescribe who may do so.  That capability 
can (in principle) be passed around or copied to any other party whom the 
original acquirer permits to carry out that action for them.

Unfortunately, practice does not always follow principle, and a bad 
implementation of capabilities could prevent a capability being expressed 
by any party except the party to whom it was granted.  That would be a 
corruption of the concept of "capability" as a rights token, confusing its 
clean semantics with those of the endpoint-permission model that 
capabilities were designed to improve.

It's not easy to identify what our early specs offer on this score, since 
they seem to assume a single client-side endpoint but don't actually 
address the issue --- it appears that they were drafted against a 
background of the original monolithic client application representing the 
"norm".  This will have to be examined in more detail to prevent newer 
non-monolithic clients from being constrained by that original 
implementation.

Does anyone know of any current restrictions on acquiring a capability 
from one host IP address but using it from another address, or acquiring 
it from one source port but using it from another source port on the same 
host address?  (The latter is the single-host, multi-process scenario.)


Morgaine.







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

On Sun, Dec 6, 2009 at 9:24 AM, Lawson English <[e-mail]> wrote:
Thanks Morgaine. The concept of a plugin-driven client is simply your 
modular client idea built off of the existing LL client.

The final extension of your client is a collection of interacting plugins 
with a central mediator and possibly  connections between plugins and/or 
services that bypass the mediator. So the network looks like a star 
network of plugins with a central mediator and a conduit of connections 
between plugins and services. The final design would make the mediator an 
optional central point to establish new connections, and process 
scripting/macro/GUI commands, while the actual functions are carried out 
by the outlying modules, which may not even be on the same computer. 
Similarly, the "server" side might be equally as distributed and the 
distinction between client and server disappears completely with clients 
handling some 3D element generation and physics and assets, etc, while the 
server broadcasts 2D mashups of the client's perspective to cell phones.

Etc.

So at one end, we have pure client-server designs like Second Life, at the 
other extreme, purely p2p worlds like Croquet, and every possible 
combination/permutation in-between.

Lawson



Morgaine wrote:
I agree with Lawson, but the topic goes far beyond gestures, so this is a 
new thread.

Putting it another way, the days of the monolithic client are over, in the 
same way as the days of the walled garden and single service provider are 
over.

In VWRAP, we are formalizing the unbundling of service provision so that 
server-side is becoming distributed, but we don't seem to have grasped the 
corresponding concept of non-monolithic clients yet.  Perhaps the client 
needs more flexibility than we are currently considering.

Although we are not dealing with client application architecture here, we 
/are/ dealing with protocol endpoint architecture, and the design of 
clients has a direct impact on that.  The protocol should not require nor 
give preference to any one particular client architecture, in the same way 
as we seek not to hardwire any single choice of server-side deployment 
pattern.  It seems reasonable to apply this same philosophy to the client 
endpoint, so that the protocol can allow for many different kinds of 
client-side deployment.

Midway through the two years of operation of the Architecture Working 
Group in SL, we explored a variety of client-side scenarios, including 
this design for a multi-process client <
https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft> . 
 This split out all functional parts of a client into separate processes, 
all interconnected through a "Mediator" hub process via sockets, while 
also accepting point-to-point and shared-memory communication paths as 
accelerators between subprocesses where required for speed.

Such a client architecture is a perfect match for this new age of 
multicore, among a huge list of other benefits enumerated on that page. 
 It can be considered the fully distributed end of the large spectrum of 
possible clients.  Lawson's SL client- Squeak bridge represents another 
split, libomv's gridproxy <http://lib.openmetaverse.org/wiki/SLProxy> and 
its Jabber plugin <
http://forge.opensimulator.org/gf/project/jabberimproxy/> shows another, 
while LL's own system for media plugins is yet another.  All these moves 
take us away from the notion of a VW client being a monolithic entity, and 
correspondingly, we should no longer assume that the client-side protocol 
endpoint is monolithic either.


To that end, it might be an effective approach to model VWRAP as a 
/protocol over sets of sources and sinks for data/.  One set is 
server-side, which we are already modelling as a multiplicity of service 
endpoints, and another set is client-side, representing the many 
subsystems that deal with different aspects of interacting with VW worlds 
and talking to their services.  Those subsystems are clear candidates for 
distinct protocol endpoints of their own.

Such a model would more accurately reflect how client applications are 
actually built (in other words, in a modular fashion), instead of 
funneling everything through a single client-side endpoint.  The current 
single-client-endpoint approach is hardwiring an unnecessary bottleneck 
into the client model, as well as encouraging a poor design for clients 
through making all data appear at a single doorway.

Perhaps we need to reflect on this a little before rushing ahead with 
yesterday's design philosophy for protocol endpoints.


Morgaine.





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

On Sat, Dec 5, 2009 at 2:00 PM, Lawson English <[e-mail] <mailto:
[e-mail]>> wrote:

   All this goes back to what I just posted on the SLDEV list about
   taking initiative and coding something up. Having the ability for
   clients to talk to each other rather than some 3rd party service
   might blur the line concerning what VWRAP is supposed to be
   talking about, but, IMHO, the line is getting blurred anyway.

   What's the difference between a plugin sitting on someone's
   desktop in order to augment the client in some way, and a plugin
   that actually allows clients to talk to each other directly in
   order to collectively augment them in some way? As far as I'm
   concerned, these discussions about clients talking to each other
   are just extensions totalks about what responsibilities client
   plugins might have.

   My current project is based on this idea:

   
http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Proposed_Extension_to_Media_Plugin


   I'm writing a SL client- squeak bridge (starting off easy with a
   port of my  do-nothing Python client for practice) that will allow
   me to test new client plugin ideas. The Holy Grail for the project
   will be to integrate Cobalt/Croquet with SL in some way(s) and
   that is just the tip of an iceberg that is being held under water
   by a large outcropping of land. There's more potential in
   P2P-VWRAP hybrids than there is in  P2P (Croquet/Cobalt) OR VWRAP
   (clear-cut client-server worlds) taken separately. While
   VWRAP/OGP/whatever's charter may not consider the P2P approach as
   relevant, the fact is, P2P is potentially in ANY extension of
   services involving clients which aren't talking exclusively to an
   old school SL simulator.


   Lawson




   Carlo Wood wrote:

       On Fri, Dec 04, 2009 at 06:11:10PM -0800, Han Sontse wrote:
        
           With all due respect,  Carlo, I am finding that I disagree
           with your analysis.
              

       There is no analysis.. it is something has been said before
       on the list: if YOU don't want something, then that doesn't
       mean there will be no need for it in the future by others.

       You shouldn't take YOUR experience and desires and then say:
       "we will never need this, NOBODY will EVER need this",
       while it's relatively easy and simple to add the *support*
       for it to the protocol!

       By adding the *possibility* for viewers to wait for others,
       you do not force anyone to do it different from what you
       describe. But you also don't take away the possibility to
       do it how other people WANT it (like me, I personally think
       this is important - so thus far we have a 50% - 50% vote for
       the NEED of this wait feature).

       So, to be really undiplomatic blunt: who are you to deny
       me this experience? While adding just a little to the protocol
       we BOTH can be happy? You can do it your way, and I can do it
       my way? But you say: "You don't need it" and want to remove
       the possibility from the protocol so that you can do it your
       way and I CANNOT do it the way I want ?!

       THAT is the reasoning behind NOT leaving out rather trivial
       options to the protocol. And really, this has been said on
       the list before a few times imho (and no, I'm not going to
       find that back).

        
           I have a lot of practical experience in SL getting animations
           as well as sound and textures to synchronize under a lot
           of different conditions by taking into account the
           client's existing
           cacheing behavior.   I'm drawing on that experience for my
           assertions.
              

       I am too, and I say I need this.

        
           I can't think of a single reasonable use case that would
           *require* clients
           to hold for the slowest link.  The examples you have suggested
              

       I can.

        
           don't require it to achieve the outcome you desire.    

       ??? Then you didn't read very well what I said.
       If you want to do what I said then you *NEED* the possibility
       to wait
       for other (some) clients (some limited time), and why not,
       have the
       possibility to abort, or continue anyway (as you want).

       Having those options you can synchronize the experience well
       within
       lag-time, well within typing-delay time (ie, under 1 second).
       If you
       don't wait, the playing time could run up till 30 seconds or more!

       Having those options you can synchronize the experience well
       within
       1 second AND you can do what you want: just state don't wait
       for anyone
       and play stuff the second you get it.

       [...]
        
           So here I'll walk through an example... the hug:

           To synchronize a hug all that is needed is for the    

       "all that is needed" to accomplish YOUR needs and views.
       For me, I realllllly need to know when other clients are
       ready too.

       [...snip...]
        
           be longer for some clients than others.  The exact wall
           clock delay does not
           matter since the end user has no idea when the event was
           actually sent.
              

       Yes we totally disagree here, and you are wrong: there are
       many other
       shared experiences (typed text, and remaining movement of the
       avatar
       before and after; not to mention voice chat) that need to be
       more or
       less in sync with gestures; the user WILL have an idea when
       the event
       was sent.

       The wall clock DOES matter - certainly when the delay can run
       up to a whole minute.

       You are "right" for delays less than a second, and I argue
       that we should try hard to get the shared experience synchronized
       within one second IF THE USER(S) SO DESIRE.

       I already gave you examples where it is notable when the delay
       is larger, but I guess every example is personal. If YOU don't
       care that your friends see you bolt for the door and once outside
       you jump and shout "Whooohooo!", while you really intended to
       first jump and shout and THEN run for the door, then well--
       that is entirely your choice. Now let me, and others, have mine.

       Another example, your hug: You initiate a hug request (your client
       already has the needed assets or starts to download them
       immediately).
       By the time that your partner clicks 'Ok', your viewer is ready
       and immediately starts to play the hug. While hugging you say:
       "Mmmmmmmmmmm, so nice". And YOU don't care if your partner sees
       that text while they don't see you hugging yet; others do however.
       Because others DO, we NEED support in the protocol to know when
       other clients are ready (at least, have all the needed data
       cached; any other delay is too short to be bothered with-- I'm
       with you on that then).

        

   _______________________________________________
   ogpx mailing list
   [e-mail] <mailto:[e-mail]>

   https://www.ietf.org/mailman/listinfo/ogpx


------------------------------------------------------------------------


_______________________________________________
ogpx mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ogpx
 

_______________________________________________
ogpx mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ogpx