research:ambientrefs
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
research:ambientrefs [2006/07/11 21:20] – tvcutsem | research:ambientrefs [2009/05/07 13:56] – tvcutsem | ||
---|---|---|---|
Line 1: | Line 1: | ||
===== Ambient References ===== | ===== Ambient References ===== | ||
+ | [[http:// | ||
{{ ambientrefs.jpg }} | {{ ambientrefs.jpg }} | ||
- | Ambient references are a novel remote object | + | Ambient references are a novel type of remote object |
+ | Remote object references are " | ||
=== Motivation === | === Motivation === | ||
Line 9: | Line 11: | ||
One may wonder why new referencing abstractions are required for mobile networks. In order to motivate the need for new referencing abstractions at the language level, we list a number of desirable properties of remote references for mobile networks which current remote referencing abstractions do not offer: | One may wonder why new referencing abstractions are required for mobile networks. In order to motivate the need for new referencing abstractions at the language level, we list a number of desirable properties of remote references for mobile networks which current remote referencing abstractions do not offer: | ||
- | - **Provisional References**: remote references should be able to point to remote objects which are "not yet available" | + | - **Intensional Naming**: in mobile networks, one does not always know the identity or the exact number of the services one requires. Hence, rather than having to // |
- | - **Resilience to Partial Failure**: remote references for mobile networks should be able to tolerate network disconnections because of the volatile connnections hardware phenomenon of mobile | + | - **Resilience to Partial Failure**: remote references for mobile networks should be able to tolerate network disconnections because |
- | - **Transitory Addressing**: remote references in mobile networks should bind to (point to) objects based on what services that object provides, rather than based on a low-level UID, object-id, IP address or MAC address. Such low-level IDs preclude the reference from reconfiguring itself by rebinding to a different object providing the same or equally matching services. | + | - **Roaming**: remote references in mobile networks should bind to (point to) objects based on what services that object provides, rather than based on a low-level UID, object-id, IP address or MAC address. Such low-level IDs preclude the reference from reconfiguring itself by rebinding to a different object providing the same or equally matching services. In other words, we want object references for MANETs to integrally support roaming by being able to opportunistically bind to whatever proximate matching service is available, regardless of its identity. |
- | - **Group Communication**: in mobile networks, one often wants to communicate with an entire group of objects. To this end, remote references should be introduced that automatically | + | - **Broadcasting**: in mobile networks, one often wants to communicate with an entire group of proximate |
=== Design === | === Design === | ||
- | Ambient references | + | Ambient references |
- | When the service object to which an ambient reference is bound moves out of communication range, the ambient reference can become unbound again. It becomes a dangling pointer anew and immediately becomes | + | Ambient references unify two concepts: they are both a peer-to-peer discovery channel |
- | == Describing services == | + | An ambient reference is initialized with a type tag: a network-wide name that describes a service |
- | + | ||
- | An ambient reference is always | + | |
<code javascript> | <code javascript> | ||
- | printer | + | def printers := ambient: Printer; |
</ | </ | ||
- | The code excerpt above creates an ambient reference to an object providing the '' | + | The variable |
- | The primary advantage of using such service types rather than e.g. name servers, IP addresses or URLs is, evidently, abstraction over the machine address | + | It is possible to restrict |
+ | <code javascript> | ||
+ | def printers := ambient: Printer where: { |p| p.dpi > 400 }; | ||
+ | </ | ||
- | == Communicating with services | + | == Message Passing Styles |
- | Asynchronous messages may be sent to an ambient reference | + | An ambient reference |
+ | === Point-to-point === | ||
+ | Here is how to send a point-to-point message to any matching printer: | ||
<code javascript> | <code javascript> | ||
- | printer< | + | printers< |
</ | </ | ||
- | In this example code ''< | + | The ''< |
- | One may wonder how return values can be acquired from such asynchronous | + | AmbientTalk/ |
<code javascript> | <code javascript> | ||
- | answer = printer< | + | def answer |
- | when(answer) lambda(ok) -> { | + | when: answer |
- | | + | |
- | print(" | + | |
} | } | ||
</ | </ | ||
- | == Synchronising with the ambient | + | Ambient references seamlessly support roaming via point-to-point messaging: multiple messages sent to the same ambient |
- | Sometimes it is useful to know when a matching | + | We will discuss later what happens if there are // |
+ | |||
+ | === One-to-many === | ||
+ | |||
+ | The following piece of code illustrates | ||
<code javascript> | <code javascript> | ||
- | printer | + | def peers := ambient: ChatPeer; |
- | printers = []; | + | ... |
- | when-found(printer) lambda(foundService) { | + | peers<-receiveTextMessage("hello world")@All; |
- | | + | </ |
- | } | + | |
- | when-lost(printer) lambda(lostService) { | + | Note the use of the '' |
- | | + | |
+ | Ambient references extend AmbientTalk/ | ||
+ | |||
+ | <code javascript> | ||
+ | def multifuture := peers<-receiveTextMessage("hello world")@All; | ||
+ | whenEach: multifuture becomes: | ||
+ | | ||
} | } | ||
</ | </ | ||
- | The '' | + | The above block closure |
- | == Design Dimensions | + | == Disconnected Operation and Timeouts |
- | One may notice from the above description of ambient references | + | Ambient references have been designed for Mobile ad hoc networks in which transient network partitions are commonplace. Hence, |
+ | |||
+ | Any message sent to an ambient reference may be annotated with '' | ||
+ | |||
+ | When an ambient reference discovers a receiver for its buffered messages in the ad hoc network, the messages | ||
- | * **Scope of binding**: it is possible to restrict the set of remote service objects to which an ambient reference may bind even further, by using so-called filter queries. For example, suppose one only wants to send documents to a printer that supports a resolution greater than 400 dpi. This can be expressed as: | ||
<code javascript> | <code javascript> | ||
- | printer | + | def reply := printers< |
- | </ | + | when: reply becomes: { |ack| |
- | | + | |
- | <code javascript> | + | catch: TimeoutException using: { |e| |
- | printer = ambient(1min) Printer; | + | |
- | </ | + | } |
- | | + | |
- | <code javascript> | + | |
- | cars = ambient* Car; | + | |
- | cars< | + | |
</ | </ | ||
- | For more details regarding all of these design dimensions, have a look at the further reading section below. | + | If there are no matching '' |
- | In conclusion, what is important to recall is that an ambient reference is a remote object reference that may be in two states: it can be unbound, searching for a matching object or it can be bound, becoming an asynchronous communication channel to a remote object. The programmer can tweak **what** objects can be bound to, **how long** it should bind with an object and **how many** objects an ambient reference can bind to simultaneously. | + | == Conclusion == |
- | === Implementation === | + | What is important to recall is that an ambient |
- | + | ||
- | A detailed explanation of ambient | + | |
=== Further Reading === | === Further Reading === | ||
- | Ambient References: Addressing Objects in Mobile Networks. Tom Van Cutsem, Jessie Dedecker, Stijn Mostinckx, Elisa Gonzalez Boix, Theo D' | + | * Ambient References: Object Designation in Mobile Ad Hoc Networks. Tom Van Cutsem. PhD Thesis, Vrije Universiteit Brussel, May 2008. [ [[http:// |
+ | |||
+ | * Object-oriented Coordination in Mobile Ad Hoc Networks. Tom Van Cutsem, Jessie Dedecker, Wolfgang De Meuter. In // | ||
+ | |||
+ | * Ambient References: Addressing Objects in Mobile Networks. Tom Van Cutsem, Jessie Dedecker, Stijn Mostinckx, Elisa Gonzalez Boix, Theo D' | ||
+ | |||
+ | * Ambient References: Addressing Objects in Mobile Networks. Tom Van Cutsem, Jessie Dedecker, Stijn Mostinckx, Elisa Gonzalez Boix, Theo D' | ||
Also see the [[research: | Also see the [[research: |
research/ambientrefs.txt · Last modified: 2010/09/13 15:13 by tvcutsem