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

[Carlo Wood <[e-mail]>]

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 <[e-mail]>