Subject: Re: [vwrap] #12: Event-like resource type for LLIDL

From: Carlo Wood <[email-masked]>
Date: Tue, 6 Apr 2010 20:57:39 +0200

I'm not sure if I follow what an "event" is.

I think that the only thing we have are states or state variables
that are distributed. A single state variable has a single authority
(running program on some machine) and only that authority can change
the state of that variable. At that moment it should tell others
that need to know that the state changed, that is changed (and into
what). Confirmation of such messages is needed to be sure that there
is no desync, if and only if the messages travel over a lossy line,
ie if UDP is being used.

If some other machine then the authority wants to change a state
variable, it should send a request to the authority and assume the
variable has NOT changed, until it receives an update from the authority
that the change has been made.

The reason for this approach is because otherwise it is impossible
to keep track of non-commuting operators. As an example lets consider
the rotation of an in-world object (rotating something is non-commuting).

The authority of the rotation variables (a vector) will be the sim
where the object is 'rezzed'. If two different sources request to
rotate the object at the same time and already update their local
"cached value" when sending it, things will get desynced:

Let the vector start as x,y,x = 0,0,1 pointing up.
Let operator R1 be a 90 degree rotation around the x-axis (z = y and y = -z)
and operator R2 be a 90 degree rotation around the y-axis (z = x and x = -z)

Start condition:

host1 ------ sim ------ host2
0,0,1        0,0,1      0,0,1

host1 issues a rotation R1 and updates the local copy immediately,
host2 issues a rotation R2 and updates the local copy immediately:

host1 --R1---> sim <---R2-- host2
0,-1,0         0,0,1        -1,0,0

Suppose that R1 arrives at the sim first, the sim will then
send out the rotation to host2:

host1 -------- sim <---R2-- host2
                   ---R1-->
0,-1,0         0,-1,0       -1,0,0

Neither of the rotation have a visible effect
on the remaining states (-1,0,0 rotated around the x-axis
is still -1,0,0 and 0,-1,0 rotated around the y-axis is
still 0,-1,0). Thus when finally both R1 and R2 have reached
all hosts we end up with:

host1 -------- sim -------- host2
0,-1,0         0,-1,0       -1,0,0

A desync.

Therefore host1 and host2 may only send requests and
do NOT change the value of their internal cache:

host1 --R1---> sim <---R2-- host2
0,0,1         0,0,1         0,0,1

host1 <--R1,R2-- sim --R1,R2--> host2
0,0,1           0,-1,0          0,0,1

host1 -------- sim -------- host2
0,-1,0         0,-1,0       0,-1,0

If what you proposed here:

On Wed, Mar 31, 2010 at 09:46:31PM -0000, vwrap issue tracker wrote:
> --------------------------------+-------------------------------------------
> Reporter:  markl@…              |       Owner:  markl@…            
>     Type:  enhancement          |      Status:  new                
> Priority:  major                |   Milestone:                     
>  Version:                       |    Severity:  -                  
> Keywords:  TypeSystem           |  
> --------------------------------+-------------------------------------------
>  There didn't appear to be clear consensus on if LLIDL needed an "event-
>  like" resource type. These would be resources that had a body with the
>  request, but expected nothing other than confirmation of receipt in the
>  response.

means that upon a request the sim will not reply with a responding
state, but merely with an ACK, then the requesting host has to remember
the operator and apply it on the state at the moment he receives the
acknowledge.

For example, host1 requests R1, then it receives the update R2 and
finally receives the acknowledge for the R1 request.  Clearly it
has to apply the operators in the order: first R2 then R1.

-- 
Carlo Wood <[email-masked]>

---

From: Lawson English <[email-masked]>
Date: Tue, 06 Apr 2010 13:47:44 -0700

Carlo Wood wrote:
> [...]
You might want to look at the Teatime architecture as implemented in 
Croquet/Cobalt for one way in which this is handled. Each user of a 
Cobalt "client" initiates an event in its own copy of the 
simulator-client, which sends the event to the central authority, which 
in tun broadcasts that event to the shared simulation in the order that 
the event is received. The unique thing about Cobalt is that every 
simulator is running on the same virtual machine with 100% identical 
behavior at the ISA level and the "events" are standard Smalltalk OOP 
programming messages sent to the copy of each smalltalk object as though 
they were receiving messages directly from another object locally.

No event is recognized in any client-simulator until it is authorized by 
the central dispatcher, not even the client where the user chose to 
initiate an avatar movement can render it taking a step until the 
dispatcher broadcasts that event and it is received by each client. One 
upside is that only simple OOP messages are sent, often with less 
overhead per event than sending large amounts of state data. One 
downside is the requirement that ALL clients' simulators are running 
100% identical byte-code interpreters, along with a programming model 
that assumes that all objects are collaborative whiteboards (with some 
exception made for handling avatar actions I'm guesing) so the shared 
illusion of a SL life economy is virtually impossible, under anything 
resembling the current Croquet/Cobalt implementation.

http://opencroquet.org/index.php/Overview
http://opencroquet.org/images/e/ee/2005_Hedgehog_Architecture.pdf
http://opencroquet.org/index.php/Croquet_SDK

However, there is room for _ad hoc_ implementations of Teatime or 
Teatime-like services in a VWRAP metaverse. Consider the obvious 
use-case of a genuine in-world collaborative whiteboard that uses 
Croquet/Cobalt teatime (or something similar) as the collaborative 
networking architecture to share drawing commands between MoaP objects. 
People could subscribe as collaborators and indulge in 100% coordinated 
interactions in any level of sophistication, or they could subscribe as 
the audience and simply observer the interactions, perhaps via a 
broadcast read-only VNC session or a readonly teatime equivalent.

The interactions could range from simple drawing apps ala the flash/java 
based whiteboards you see on webpages, to more complicated setups like 
Kansas (written in Self)

 http://research.sun.com/ics/kansas.html

or Nebraska (a partial port to Squeak smalltalk) 

http://wiki.squeak.org/squeak/1356 

implemented on prims in-world or in proximity-sensative HUDs or even as 
some kind of ghostly physics simulation  where physics and other 
behavior is controlled by a different  setup than the normal central 
VRWAP server or as special physics/combat interactions governed by 
client-side simulations.

Squeak smalltalk was chosen for the implementation of Croquet for 
several reasons, including fast prototyping but also because it 
implements  100% identical VM behavior cross-platform (including 
floating point calculations) which is vital for maintaining totally 
coordinated shared simulations using distributed programming. It should 
be easily possible to use the Croquet/teatime/Cobalt island system to 
control simple objects (e.g. whiteboards and combat-physics simulators) 
using embedded squeak (suitably sandboxed to only generate safe 
messages) or in circumstances where 100% identical behavior is not 
needed, other languages and strategies could be used instead.

The demo project I'm working on would take an existing Cobalt world and 
render it on a prim using a simple modification of the Media plugin. 
This would allow for amusing things like teleconferencing between 
different virtual worlds. More practical scenarios would be to use a 
similar strategy to implement whiteboards ala Kansas/Nebraska, combat 
systems, shared line dancing, music collaboration, etc.

The pattern (assuming Squeak here, though you can do it with less 
precise coordination using other languages and systems):

SL client <=> media on a prim <=> [rendering/keyboard i/o to Cobalt 
world-client] <=> teatime/cobalt island dispatcher/event handler <=> 
[Cobalt world-client  interactions with rendering/keyboard i/o] <=> 
media on a prim <=> SL client

Put any kind of event handler/generator you like in the [ ], and you 
have, at least for those specific events, potentially 100% identical 
behavior even in a VWRAP metaverse.

Note that the SL client  would consume and generate events 
(images/keypresses/combat messages/etc) sent to the teatime system but 
that aside from these specific points of interaction, the slavish 
control of a Cobalt shared world woudn't be implemented, leaving the 
more liberal behavior of a VWRAP world intact. If a client doesn't get 
the message that a drawing was done, or that a dance step isn't to be 
initiated or that a physics simulation for ghosted prims hasn't changed 
their state, it only affects the specific view of that aspect of the 
shared simulation, not the entire simulator's.

Lawson

---

From: Joshua Bell <[email-masked]>
Date: Tue, 6 Apr 2010 15:05:10 -0700

> I'm not sure if I follow what an "event" is.

The use cases that come to mind are where the authority itself is generating
the event. In your scenario, the sim is simulating a rotating object, and is
broadcasting the current angle to clients. Other examples are text chat and
presence notifications from the sim. These don't fit into a RESTful model.

SL clients also generate "events" that don't fit into a RESTful model, e.g.
current gaze location, or (again) chat/presence.

These *can* be transported over HTTP e.g. client->server as POST with
minimal response, and server->client as a GET-based long poll
(see draft-lentczner-vwrap-foundation-00 - which uses LLIDL!). But using
HTTP in a non-RESTful way for this is an implementation details, and some
have expressed desire to describe these "events" (and LLIDL as a whole)
independent of the transport.