Differences

This shows you the differences between the selected revision and the current version of the page.

uf:totam 2020/04/28 19:32 uf:totam 2020/04/28 19:41 current
Line 20: Line 20:
Figure above illustrates how a scoped tuple is propagated through the TOTAM network. It depicts two types of locations, the blue and red locations corresponding to two teams of a multi-player game scenario where users (blue team) can use their PDA’s to chase dangerous (virtual) gangsters (red team) in the outdoors. The scope of the propagated tuple has been limited to blue locations. Figure (a) illustrates that a tuple is injected from the location with a star. This location is connected to four blue locations and one red location. As the scope of the tuple is limited to blue locations the tuple is only sent to the four blue locations. From those four locations the tuple is transitively propagated obeying the scope of the tuple until all connected blue locations are reached without being transmitted to a red location. Note that one blue location is not transitively connected to the sending device and thus does not receive the tuple. Figure (b) illustrates that a blue location moved into the range of the isolated blue location and thus, transmits the tuple to it. Again the tuple is not transmitted to nearby red locations. It is important to note from this operational sketch that the first isolated location receives a tuple without being connected at any time with the start location in which the tuple was originally inserted. Figure above illustrates how a scoped tuple is propagated through the TOTAM network. It depicts two types of locations, the blue and red locations corresponding to two teams of a multi-player game scenario where users (blue team) can use their PDA’s to chase dangerous (virtual) gangsters (red team) in the outdoors. The scope of the propagated tuple has been limited to blue locations. Figure (a) illustrates that a tuple is injected from the location with a star. This location is connected to four blue locations and one red location. As the scope of the tuple is limited to blue locations the tuple is only sent to the four blue locations. From those four locations the tuple is transitively propagated obeying the scope of the tuple until all connected blue locations are reached without being transmitted to a red location. Note that one blue location is not transitively connected to the sending device and thus does not receive the tuple. Figure (b) illustrates that a blue location moved into the range of the isolated blue location and thus, transmits the tuple to it. Again the tuple is not transmitted to nearby red locations. It is important to note from this operational sketch that the first isolated location receives a tuple without being connected at any time with the start location in which the tuple was originally inserted.
 +
Line 59: Line 60:
The ''rdp(template)'' and ''rdg(template)'' operations return a tuple or all tuples matching the template in the tuple space if present (without removing), respectively. Note that if no tuple is present matching the template, ''nil'' is given back. The ''rdp(template)'' and ''rdg(template)'' operations return a tuple or all tuples matching the template in the tuple space if present (without removing), respectively. Note that if no tuple is present matching the template, ''nil'' is given back.
-In the original Linda model, read and in operations were provided to return a copy of the tuple and remove the tuple from the tuple, respectively. Those operations where blocking. TOTAM, inspired by Lime, offers non-blocking variants of these operations as follows:+In the original Linda model, read and in operations were provided to return a copy of the tuple and remove the tuple from the tuple, respectively. Those operations where blocking. TOTAM, inspired by Lime, offers non-blocking variants of these operations:
<code> <code>
Line 72: Line 73:
</code> </code>
-The ''whenever:read:'' operation takes as parameter a template and a block closure which is asynchronously applied each time a tuple matching the template is added to the tuple space. The ''whenever:in:'' operation works similarly but it also removes the tuple matching the template. Following Linda's in semantics, if several ''whenever:in:'' operations could be triggered for one tuple, //only// one of them will succeed. Variables specified in the template are bound in the body of the block closure to the concrete value of the tuple that matched the template. Both operations return a subscription object which understands a ''cancel'' message to stop the interest in tuple matching the template. Note also that both operations have a ''when:'' variant which only triggers once the block closure.+The ''whenever:read:'' operation takes as parameter a template and a block closure which is asynchronously applied each time a tuple matching the template is added to the tuple space. The ''whenever:in:'' operation works similarly but it also removes the tuple matching the template. Following Linda's in semantics, if several ''whenever:in:'' operations could be triggered for one tuple, //only// one of them will succeed. Variables specified in the template are bound in the body of the block closure to the concrete value of the tuple that matched the template. Both operations return a subscription object which understands a ''cancel'' message to stop the interest in tuples matching the template. Note also that both operations have a ''when:'' variant which only triggers once the block closure for the first tuple that matches the template.
-The ''out(tuple)'' operation to insert a private tuple in the tuple space. In order for applications to insert a public tuple, thereby making it available to other collocated TOTAM systems, the'' inject:'' operation is provided.+The ''out(tuple)'' operation actually inserts a private tuple in the tuple space. In order for applications to insert a public tuple, thereby making it available to other collocated TOTAM systems, the'' inject:'' operation is provided.
<code> <code>
Line 122: Line 123:
</code> </code>
-In order to notify the removal of a tuple, TOTAM sends an antituple for the removed tuple. For every tuple there is (conceptually) a unique antituple with the same format and content, but with a different sign. All tuples injected by an application have positive sign while their antituples have a negative sign. Whenever a tuple and its antituple are stored in the same tuple space, they immediately annihilate one another, i.e. they both get removed from the tuple space. By means of antituples, TOTAM can “unsend” tuples injected to the network.+Upon a ''retract'' operation, TOTAM injects in the network an antituple for the removed tuple. For every tuple there is (conceptually) a unique antituple with the same format and content, but with a different sign. All tuples injected by an application have positive sign while their antituples have a negative sign. Whenever a tuple and its antituple are stored in the same tuple space, they immediately annihilate one another, i.e. they both get removed from the tuple space. By means of antituples, TOTAM can “unsend” tuples injected to the network.
 +<note>
 +Note that ''retract'' is meant to be used by the creator of a tuple to stop the propagation of a tuple and remove it from the network. This is useful in cases that tuples injected carry outdate information. However, this operation should not be confused with the ''when:in:'' operation which allows applications to read and remove a tuple matching a template from the TOTAM network.
 +</note>
 
 
 
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki