Programming Language Support for Routing in Pervasive Networks

Tomohiro Suzuki∗, Kevin Pinte†, Tom Van Cutsem†**, Wolfgang De Meuter† and Akinori Yonezawa∗∗ The University of Tokyo, Tokyo, Japan

Email: {tsuzuki, yonezawa}@yl.is.s.u-tokyo.ac.jp† Software Languages Lab, Vrije Universiteit Brussel, Brussels, Belgium

Email: {kpinte, tvcutsem, wdmeuter}@vub.ac.be

Abstract—Managing communication in pervasive environ-ments is a difficult challenge because of characteristics suchas: no central server and frequent disconnections. Further-more, services to be composed for coordination are sometimesdistributed in multiple networks. In that case, intermediatenodes linking these networks have to route communication datatoward appropriate destinations. However, incorporating suchrouting protocols into applications significantly increases com-plexity of the code. In this paper we propose AmbientTalk/M, aconcurrent distributed programming language for coordinationof services among multiple networks. The language providespowerful support for creating routing frameworks to hook uptwo or more networks. With the language support, we canexpress how service information is propagated or how mes-sages are routed using high-level abstraction over underlyingnetwork technology. We show the language is flexible enoughto express a variety of routing frameworks with respect torobustness, traffic efficiency, and security. Because the frame-works are installed reflectively, they are completely separatedfrom application code. To the best of our knowledge, this isthe first attempt to integrate routing semantics among multiplenetworks into a programming language using reflection.

I. INTRODUCTION

Today, pervasive environments are common; many appli-cations in mobile devices, including cellular phones, PDAsand laptop computers, are capable to communicate with eachother. Sometimes they are directly connected through theirown ad hoc networks, e.g. 802.11 or Bluetooth networks,without requiring any central managing server. When thereis no fixed access point, this kind of spontaneous communi-cation is necessary to connect devices in one place. We callsuch networks mobile ad hoc networks or MANETs.

Coordination in MANETs is difficult, especially when ser-vices that are required to compose coordination are scatteredin different ad hoc networks. In the first place, the mobilityof the portable devices poses significant requirements formiddleware or runtimes [1]. Moreover, it often occurs thatthere are many separated networks in the same location; weoften have a number of 802.11 wireless networks, Bluetoothnetworks and cabled Ethernet networks in a universityclassroom. A service, e.g. printing service, held in a certainnetwork may not be available in another one. To coordinate

**Postdoctoral Fellow of the Research Foundation, Flanders (FWO)

entities in such environment, we have to exchange serviceinformation and route data through intermediate nodes, ifany, among them. Incorporating these routing semanticsinto applications causes a significant increase in complexity.Although a number of research activities for middleware[2], [3], [4], [5] , as well as new communication protocols[6], [7], have been developed to achieve better coordination,these models assume that all entities are on a single network.

In this paper, we present AmbientTalk/M, a distributedconcurrent programming language for coordination in mul-tiple networks. From its ancestor AmbientTalk [8], it inheritsservice discovery based on publish/subscribe communicationand messaging communication via asynchronous messagesbetween actors [9]. These characteristics make the languagesuitable for programming in MANETs. In addition to that,AmbientTalk/M is able to utilize multiple networks and tocoordinate entities among them.

The language employs new kinds of actors located inintermediate devices between a device publishing a serviceand another one subscribing to it. The roles of the actorsare to propagate service information and transfer messagesamong them. The actors help to create routing frameworks,which manage how messages are routed in networks, andhow applications without routing semantics work on thoseframeworks. The frameworks have the following properties:

Highly abstract in that the routing is written as messagepassing and receiving behavior of AmbientTalk/M actors.Programmers think which services are available in theirnetworks and what messages are to be sent to them, ratherthan thinking about IP addresses of services. The routingframeworks are written in high-level operations in Ambi-entTalk/M, compared to manipulating binary data of somenetworking protocols like [10], [11].

Transparent in that they do not conflict with the ex-isting service discovery mechanism for a single networkas explained in Section II. In other words, the routingframeworks are backward compatible with applications fora single network. Because they are installed reflectively intoactors, they work independently from the application codeand thus avoid unnecessary code complexity.

Expressive in that AmbientTalk/M can describe a varietyof routing frameworks for coordination among multiple net-

8th IEEE International Workshop on Middleware and System Support for Pervasive Computing

978-1-61284-937-9/11/$26.00 ©2011 IEEE 226

works. To show the expressiveness this paper presents sev-eral applications of frameworks for specific tasks in SectionIII, including a printing service accessed from different kindsof networks, a chatting service using multihop messagingand message encryption for secure communication.

II. AMBIENTTALK/M

AmbientTalk/M is a programming language for coordina-tion of services in two or more networks. Before elaboratingon the language, we start with AmbientTalk [8], the ancestorof AmbientTalk/M.

A. AmbientTalk

AmbientTalk has been developed as an event-driven pro-gramming language for a single mobile ad hoc network.The language is dynamically-typed and object-oriented. Asits virtual machine is written in Java, it is portable tomany platforms where the JVM runs, such as GoogleAndroid [12]. AmbientTalk’s powerful symbiosis betweenAmbientTalk objects and Java objects [13] enables us towrite an application partly in AmbientTalk/M and partly inJava.

B. Actors

One of the distinctive features of AmbientTalk is actor-based communication. Actors are concurrent computationalagents [9], each of which has own message queue andindependently and sequentially processes its messages. InAmbientTalk, distributed communication among devices isexpressed as passing messages among actors. When an actoris to perform an action of an object residing in another actor,it sends a message to the actor. Then the message is added tothe message queue of the actor, which sequentially processesmessages from its queue, usually resulting in a methodinvocation of the object corresponding to the message. Theseattributes of actors bring benefits to concurrency in thatactors do not cause race conditions or deadlocks againstshared objects. We refer to actors [9] and concurrent objects[14], [15] for this style of concurrency.

C. Service Discovery and Temporary Disconnection

Since mobile ad hoc networks cannot rely on any cen-tral server to provide the locations of services [2], [16],AmbientTalk employs the following procedure to discoverservices available in a network before exchanging messages.Suppose we have two devices: a device hosting a printingservice and another device that is going to use the service.Listing 1 and 2 depict typical communication in Ambi-entTalk. First an actor creates an object that implementsnecessary methods for the service (line 2-6 in Listing 1)and publishes it as a service to other AmbientTalk virtualmachines in the network (line 7). A publication alwayscarries a type tag, e.g. Printer, which is used for serviceinformation in AmbientTalk. When another actor starts to

subscribe to the service specifying the type tag (line 2in Listing 2), the underlying virtual machine searches forservices corresponding to the type tag. After the search, thesubscribing actor discovers the service, meaning that it getsa far reference to the service. A far reference is a stub for theservice and any message sent to the far reference is sent tothe actor holding the real service entity. Finally, through thefar reference, the actor can send messages with parametersto the service (line 3 in Listing 2). The <- operator is alanguage construct for sending a message via a far reference.The message is sent to the recipient actor, which invokes theimplemented method print of the object for the service.This procedure is abstracted and thus is simpler than that offocusing on low-level socket manipulations and other systemcalls.

Far references are remote objects designation technique.When the virtual machines are disconnected, messages arebuffered by the interpreter and are flushed when the peers arereconnected. This makes AmbientTalk suitable for MANETswhere temporary failures are the norm rather than exception.

Listing 1. Service Publication in AmbientTalk1 deftype Printer;2 def obj := object: {3 def print(s) {4 ...5 };6 };7 export: obj as: Printer;

Listing 2. Service Subscription in AmbientTalk1 deftype Printer;2 when: Printer discovered: {|p|3 p<-print(somedoc);4 }

D. Problem with Multiple Networks

Although AmbientTalk is suitable for a single mobile adhoc network, it does not support programming in a multi-networked environment; an AmbientTalk virtual machinejoins at most one TCP/IP network. However, it is oftenthe case that there are a number of distributed entitiesto compose without all of the entities belonging to thesame network. In that case the intermediate nodes, if any,have to act as routers that transfer data from a network toanother. These intermediate nodes require a means to specifywhich network is used for publishing service information orsubscribing it. Since the routing strategy may vary dependingon the applications and the status of the network environ-ment, a system with flexibility of adopting various routingalgorithms is ideal. AmbientTalk/M has been developed forthat purpose.

E. AmbientTalk/M

AmbientTalk/M is capable of utilizing multiple networksand making coordination among services distributed in thosenetworks. The capability comes from port objects and spe-cial methods defined on them.

227

Listing 3 and 4 write the previous coordination in Am-bientTalk/M. First, in addition to the type tags, each actorretrieves a port object, the first element of the array returnedby the getAllPorts method (line 2 in the both listings).After defining an object for the printing service, it ispublished using the export: as: on: function (line 9).What is interesting about the code is its third argument;because AmbientTalk/M uses multiple networks, it is ableto specify which network the service is to be published onby using a port object that represents a network interface,e.g. eth0.

On the remote side, the other actor of Listing 4 subscribesto the service. When the service is discovered by the actor,it calls the closure of the second parameter of when:

discovered: on: function (line 3-5). In the closure, theactor gets a far reference as the variable p. After getting thefar reference, it sends a message print with its parameter(line 4). The third parameter is a port object used to specifywhich network the service is to be discovered from.

Both export: as: on: and when: discovered:

on: are new functions in AmbientTalk/M with the capabilityto specify which network to use in their communication.

Listing 3. Service Publication in AmbientTalk/M1 deftype Printer;2 def port := networks.getAllPorts()[1];3 def obj := object: {4 def print(s) {5 ...6 };7 };8 export: obj as: Printer on: port;

Listing 4. Service Subscription in AmbientTalk/M1 deftype Printer;2 def port := networks.getAllPorts()[1];3 when: Printer discovered: {|p|4 p<-print(somedoc);5 } on: port;

F. Port Objects

The third argument of the new functions is a port object(port in Listing 3 and 4). This is a new kind of object inAmbientTalk/M representing a physical network interface ofthe device. From an actor’s point of view, it represents anetwork, which is used to specify the scope of the publica-tion and subscription. The networks object has the controlof the port objects. If the device, for example, has threeactive network interfaces, its getAllPorts method returnsan array of three port objects that represent these interfacesrespectively. They are used in publication and subscriptionof services to specify which network to export the serviceto and which network to discover the service from. They aredistinguished by its name such as eth0 and the networks

object provides a method to retrieve a corresponding portobject from a far reference. Note that normal applicationcode does not use port objects as in Listing 1; port objectsare for programming special actors for routing.

G. Actors for Routing

Actors play an important role in coordination in Am-bientTalk/M. Developing applications for mobile devicesthat use a service in another network increases the codecomplexity because they cannot reach the service directlyand thus some routing algorithms are to be implementedin the applications. To solve this, AmbientTalk/M providesa means of dealing with implementing routing algorithms.This is done by creating a special actor, gateway actor, in anintermediate node which belongs to two or more differentnetworks. A gateway actor works as a router connectedto other networks, through which service information ispropagated and messages are transferred from a networkto another. Propagating service information means that itpublishes a stub for the service to the other network whena gateway actor discovers a service form one network. Thegateway actor uses port objects to specify the direction ofthe propagation. Since gateway actors are implemented byreflection, the routing algorithms are dynamically customiz-able to a variety of routing frameworks as explained inSection III.

By reflection, we mean the ability to intercept a languagebehavior from within the language [17], [18], [19]. Normallywhen a message is created and sent from an actor and subse-quently received by another actor, this results in invoking thecorresponding method of an object residing in the receivingactor. Programmers can intercept such behaviors from ameta-level point of view using reflectOnActor function.It offers two methods to override the default behaviors ofactors: how the message is sent (by overriding the sendTo

method) and how an actor receives the message (by over-riding the receive method). By using them, when gatewayactors receive a message from a sender in a network, theyforward the copy of the message toward the actual receiverin another network, instead of calling a method of an object.

There may be another way to implement messagingframeworks directly in the virtual machine of Ambi-entTalk/M in Java. However, it requires converting Javaobjects to AmbientTalk/M objects and vice versa. Comparedto implementing it in virtual machines, it is thus far moreconcise to manipulate AmbientTalk/M object from withinthe language, especially when implementing routing algo-rithms based on AmbientTalk/M objects.

III. COORDINATION IN AMBIENTTALK/M

AmbientTalk/M exhibits expressiveness and flexibilityfor creating a variety of coordination frameworks amongdifferent networks. This section shows how the actors inAmbientTalk/M are customized for specific tasks and howtheir reflective capability plays an important role in thecoordination.

228

PrinterGateway ActorClient

Network X

Network Y

reflectOnActor:{

def receive(receiver, msg) {

transfer the message to the printer

｝｝

Figure 1. Coordination in Multiple Networks

A. Messaging among Multiple Networks

Let us start with a simple coordination problem across twonetworks. Suppose we are going to print a document using aprinter but it belongs to a different network than the networkour mobile phone is using. The printer logically belongs to,say, Network Y and the client belongs to Network X as shownin Fig. 1. The client runs the subscription code in Listing 2and the printer runs the publication code in Listing 1. Anintermediate device has two network interfaces to belong toboth networks, having a gateway actor to bridge them.

After the printer’s service information is propagated viathe gateway actor, the client sends a message to the servicethrough the gateway actor. As the gateway actor’s receptionbehavior is modified to transfer the message to the printer,the printer in Network Y receives the message from NetworkX. This simple communication can be extended to deal withmany cases, where devices communicate beyond networkboundaries.

One possible situation is a heterogeneous network envi-ronment; Network X and Y in Fig. 1 can be IEEE 802.11and Ethernet. Bluetooth is also a possible network. Sincethere are already many portable devices that can belong tostationary networks and wireless networks, applications writ-ten in AmbientTalk/M would bridge the logically separatednetworks, where logically separated means these networksform different subnets or they work on different protocols.

Another target can be a number of networks linkedtogether by gateway actors. Suppose a train of eight carsand in each car at least one person is seated playing thesame chatting application written in AmbientTalk/M. Evenif the train is too long to bring persons in the first car and thelast car into the same ad hoc network, they can be logicallylinked together by intermediate devices and all devices canexchange messages each other. In that case, gateway actorsnot only propagate service information one another and relaymessages, but also receive the messages in themselves asnormal behaviors for the users running the application inthe intermediate linking devices.

Note that AmbientTalk/M depends packet routing in asingle network on its underlying network stack, such asTCP/IP, and that routing frameworks in AmbientTalk/M

complement the intra-network packet routing with the inter-network message routing in the application layer.

B. Routing Frameworks for Multiple Paths

Sometimes networks create two or more paths from thesource of a message to its destination as shown in Fig.2. A service Chat is published in Actor D. The actor isconnected Actor B and C, but is separated from Actor S,which discovers the chat service through two paths: D-B-A-S and D-C-S. After the service is discovered by ActorS through the two paths, the actor sends a login messageto the service, selecting the path(s) according to its routingframework. Routing frameworks, reflectively installed intoactors, control how the messages are transferred to thedestination. Here, we introduce following two frameworks:

Flooding framework uses all paths to deliver the messagesas in Fig. 2. The message sent in Actor S is intercepted at themeta-level as shown in (s2) and the message is duplicatedwith the same identity number and these copies are sentto all of the available paths. When the service of ActorD receives the duplicated messages, its reception behavioris also intercepted at the meta-level to filter duplicatedmessages based on the their identities, as shown in (d2), re-sulting in one method invocation in Actor D for one originalmessage in Actor S. This framework has robustness againstfailures in intermediate nodes. Note that to add identities toservices or messages we extend multiway references used inAmbientTalk RFID project [20]; a service that uses multiwayreferences is published with its identity and actors recognizethe references to the service from two or more paths as onereference based on the identity.

Minimum Hop framework selects a shortest path. Inthis framework gateway actors propagate service informationwith its hop counts from its origin in addition to the serviceidentity. This means, when an actor gets a far reference toa service, it also knows how far away the service is. Byusing the hop count information, a message sender selects areference which has the minimum hop count. Compared tothe flooding framework, this framework has traffic efficiencyby avoiding unnecessary duplicated messages flooded innetworks.

Note that routing frameworks act transparently; the appli-cation code, (s1) and (d1) in Fig. 2, are written orthogonallyfrom their routing frameworks, (s2) and (d2). This is thereason why applications written in AmbientTalk for one net-work can be extended to multiple-networked environments,by installing these frameworks into actors reflectively. Thisseparation of concerns avoids unnecessary code complexity.

C. Opportunistic Networks

Opportunistic networking [21] consists of mobile devices,some of which are frequently out of range from a networkbut are in the range of other networked devices. The networkopportunistically uses the intermediate nodes’ mobility to

229

reflectOnActor:{

def receive(receiver, msg) {

remove duplications

｝｝

reflectOnActor:{

def sendTo(receiver, msg) {

send copies of the messages

｝｝

when:Chat discovered:{|s|

s<-login(” Hello” );

...

def obj := object: {

def login(m) {...}

};

export: obj as: Chat;

S

A B

D

C

(s1)

(s2) (d2)

(d1)

Figure 2. Flooding Framework for Two Available Paths

deliver data from one network to another as they moveacross networks. Suppose that, in Fig. 1, Network X and Yare physically apart and thus the intermediate node hostingthe gateway actor cannot belong to both networks at thesame time. If the intermediate node moves between the twonetworks and delivers necessary information among them,this situation is one example of opportunistic networks.

AmbientTalk/M can be easily used in such networksbecause the language regards moves of portable devices fromone network to another one as temporary disconnectionsin MANETs. The messages which are sent during thedisconnected period are implicitly buffered by the virtualmachine of the device and then automatically delivered tothe destination when it is reconnected to the network ofthe destination as the device moves. This abstraction meansthat applications written in AmbientTalk/M work normallyin opportunistic networks without otherwise serious caresfor the mobility and the disconnections.

Note that, of course, AmbientTalk/M provides meansof being notified when a communication partner is dis-connected and of retrieving the buffered messages fromthe virtual machines. They are necessary to select pathsthat are currently alive when we implement such routingframeworks.

D. Encryption in Routing

AmbientTalk/M is applicable to secure messaging. Some-times we cannot trust intermediate nodes and do not wantthem to look inside our messages. In that case we canadopt the following encryption framework as in Listing 5and 6 in the communicating endpoints and insert additionalannotations in the application code to modify messagingbehavior.

When a service is discovered in the client of the serviceat the beginning of Listing 5, the client sends the login

message with a secret password, which the client does notwant to be seen in intermediate nodes. In this encryptionframework, the client uses the annotation Encryption (line1) when sending a secret message, which triggers an addi-tional encryption procedure (line 6-7) just before the mes-sage is sent. This encryption algorithm can be simple XOR

encryption based on their pre-shared key. If so, only nodeswhich have the pre-shared key can decrypt the contents ofthe message. On the other hand, the receiving actor decryptsthe message with their pre-shared key (line 4-5 in Listing6) if the message is tagged as Encrypted; otherwise, theoverriding function uses its default behavior (line 7). Asall encryption and decryption procedures are performed inreflective parts of the code, the software engineering costin the application code to act on this encryption frameworkonly consists of the annotation.

Listing 5 and 6 assume that specific functions, e.g.decrypt and encrypt, are already defined and, thoughwe mention XOR encryption the example above, moresophisticated encryption algorithms such as asymmetric keycryptosystem can be installed into the actors using reflection.

Listing 5. Message Sending in Encryption Framework1 service<-login(password)@Encryption2 ...3 reflectOnActor: {4 sendTo(receiver, msg) {5 if: (is:msg Tagged:Encryption) then: {6 def key := getPreSharedKey();7 superˆsendTo(receiver, encrypt(msg, key));8 }9 superˆsendTo(receiver, msg);

10 ...

Listing 6. Message Reception in Encryption Framework1 reflectOnActor: {2 receive(receiver, msg) {3 if: (is:msg Tagged:Encrypted) then: {4 def key := getPreSharedKey();5 superˆreceive(receiver, decrypt(msg, key));6 }7 superˆreceive(receiver, msg);8 ...

IV. RELATED WORK

To achieve coordination among devices, a number ofapproaches have been presented. They can be classifiedas communication protocols, middleware, and languages.Communication protocols, such as JINI [6], or UPnP [7]are standards to connect devices in an easy and systemizedway. They have stepped forward from conventional stablenetworks toward more dynamic ones, where clients dynam-ically discover services in a “plug-and-play” manner. AsUPnP is supposed to work in a stable network with plentyof computation resources, it requires each service to have anHTTP server to send its XML description. This characteristicmakes the standard not suitable for being used in smallportable devices that are common in MANETs. In contrast,JINI’s proxy can play a substitute role for a service when thedevice of the service does not have enough machine powerto hold a service.

There are packet routing protocols, such as AODV [10]and TORA [11], to transfer packets in dynamically changingad hoc networks. There is generally a trade-off betweenthem and high-level abstractions; these low-layer protocolsare relatively fast and can be used to support other systems

230

than a specific programming language, while high-levelabstraction presented in this paper allows programmers toadjust routing frameworks to their requirements in a high-level programming language. Evaluation of our approachefficiency remains future work. Sensor networks [22] arealso active fields, where applications using them are beingdeveloped for surveillance and health monitoring. Comparedto mobile ad hoc networks, they deploy a much highernumber of embedded sensor nodes and their focuses are alsoon relatively low layer, such as energy efficiency in digitalcircuit design, rather than programming support.

LIME [3] and TOTA [4] are middleware of tuple spacesfor mobile environments. LIME’s tuple spaces are processedby merging two tuple spaces when two nodes are closeto each other. In TOTA, a tuple itself moves across tuplespaces according to its own propagation rule. By doing so,a host can send tuples to another host that was not ini-tially connected to it. EMMA [5], middleware for epidemicmessaging in ad hoc networks, also considers sending amessage to a non-connected host as normal. Its epidemicprotocol enables hosts to transfer a message to other ad hocnetworks which do not have the message yet. A messagingprotocol AMQP [23] supports reliable connections betweentwo processes on middleware over a network. Compared toAmbientTalk/M, however, it does not help service discoveryor communication over multiple networks.

There are also object-oriented middleware whose mes-sage transmission is performed in method invocation ofobjects. JINI [6], mentioned in communication protocols,and CORBA [24] fall into this category. JINI’s proxy andJava’s code mobility enable services to evolve implicitlywithout notifying its change to its clients. CORBA is awidely accepted middleware for its interface-based commu-nication that hides details of service implementation and itsimplicit data conversion that occurs when a service receivesa message.

As an approach of high-level programming language,Pantaxou [25] provides programming support especially inaudio and its consistency verification will help programmingin distributed environments. SpatialViews [2] provides asimple way to iterate over devices located in a room. Each ofthe iteration is executed in each device to collect informationin the space. YABS [26] is a programming language basedon the behavior of social insects. Although the languageneeds no global knowledge, individual reactions againstcontext changes are enough powerful to produce robustnessfor changing environment. In session-based programming[27], the ability of passing a session through another ses-sion supported by underlying middleware is a noteworthyabstraction.

As to reflection, DIL [28] employs techniques of reflectionupon actors. The language provides simple yet expressivecontrols of actors’ sending and receiving behaviors, enablingthem to build up backup systems and distributed snapshots.

Java RMI [29] uses reflection to translate method calls onspecial references into remote calls to a server, keepingJava’s security policy, compatibility with legacy code andobject-oriented style. While these approaches also haveachieved the separation between application and other se-mantics, they assume a stable networks to deploy the systemrather than multiple MANETs; they have no abstraction overtemporary disconnections and thus routing among severalnetworks is out of their scopes.

Note that all of high-level approaches for mobile ad hocnetworks assume that the services or hosts to be composedare placed in a single network or they are not expressiveenough to describe routing semantics in the system itself.

V. CONCLUSION

It is difficult to achieve coordination in pervasive envi-ronments where communicating entities are scattered overvarious networks. This paper presents AmbientTalk/M, a dis-tributed concurrent programming language for coordinationamong devices residing in multiple networks. In additionto its inherited abstraction over difficult characteristics ofMANETs, the language has the capability of composingentities distributed in several networks. Applications inAmbientTalk/M utilize intermediate devices by installingrouting frameworks into the gateway actors hosted by thosedevices. The special actors are responsible to propagateservice information and to route messages to the services.Among many other researches for MANETs, we say Am-bientTalk/M distinguishes itself because it has powerfulabstractions to cope with multiple mobile ad hoc networksand has the expressive functions to create a variety of routingframeworks with respect to robustness, traffic efficiency andsecurity. As the language offers a means of overriding theactor’s behaviors from within the language, it avoids unnec-essary code complexity at the application level. Althoughan evaluation on the efficiency remains future work, we areconfident that our programming model for network routingwill bring benefits to the field of programming in pervasiveenvironments.

REFERENCES

[1] J. Collins and R. Bagrodia, “Programming in mobile ad hocnetworks,” in Proceedings of the 4th Annual InternationalConference on Wireless Internet, ser. WICON ’08. ICST,2008, pp. 73:1–73:9.

[2] Y. Ni, “Programming ad-hoc networks,” Ph.D. dissertation,New Brunswick, NJ, USA, 2006.

[3] G. P. Picco, A. L. Murphy, and G.-C. Roman, “Lime: Lindameets mobility,” in ICSE ’99. ACM, 1999, pp. 368–377.

[4] M. Mamei, F. Zambonelli, and L. Leonardi, “Tuples on theair: a middleware for context-aware computing in dynamicnetworks,” in Distributed Computing Systems Workshops,2003, pp. 342 – 347.

231

[5] M. Musolesi, C. Mascolo, and S. Hailes, “EMMA: EpidemicMessaging Middleware for Ad hoc networks,” Personal andUbiquitous Computing, vol. 10, no. 1, pp. 28–36, Aug. 2005.

[6] J. Waldo, “The Jini architecture for network-centric comput-ing,” Communications of the ACM, vol. 42, no. 7, p. 76, 1999.

[7] “Universal plug and play (upnp),” http://upnp.org.

[8] T. V. Cutsem, S. Mostinckx, E. G. Boix, J. Dedecker, andW. D. Meuter, “AmbientTalk:Object-oriented Event-drivenProgramming in Mobile Ad hoc Networks,” SCCC, pp. 3–12, 2007.

[9] G. Agha, Actors: A Model of Concurrent Computation. MITPress, 1986.

[10] C. Perkins and E. Royer, “Ad-hoc on-demand distance vectorrouting,” in WMCSA. IEEE, 1999, pp. 90–100.

[11] V. Park and M. Corson, “A highly adaptive distributed routingalgorithm for mobile wireless networks,” in INFOCOM’97,vol. 3. IEEE, 1997, pp. 1405–1413.

[12] “Google android,” http://www.android.com.

[13] T. V. Cutsem, S. Mostinckx, and W. D. Meuter, “Linguisticsymbiosis between event loop actors and threads,” ComputerLanguages, Systems and Structures, vol. 35, no. 1, pp. 80–98,2009.

[14] A. Yonezawa, J.-P. Briot, and E. Shibayama, “Object-orientedconcurrent programming abcl/1,” OOPLSA, pp. 258–268,1986.

[15] T. Watanabe and A. Yonezawa, “Reflection in an object-oriented concurrent language,” SIGPLAN Not., vol. 23, pp.306–315, January 1988.

[16] R. E. McGrath, “Discovery and its discontents: Discoveryprotocols for ubiquitous computing,” Champaign, IL, USA,Tech. Rep., 2000.

[17] B. C. Smith, “Reflection and semantics in LISP,” AnnualSymposium on Principles of Programming Languages, 1984.

[18] P. Maes, “Concepts and experiments in computational reflec-tion,” in Conference proceedings on Object-oriented program-ming systems, languages and applications. ACM, 1987, pp.147–155.

[19] S. Mostinckx, T. Van Cutsem, S. Timbermont, E. Gon-zalez Boix, E. Tanter, and W. De Meuter, “Mirror-basedreflection in ambienttalk,” Softw. Pract. Exper., vol. 39, pp.661–699, May 2009.

[20] A. Lombide Carreton, K. Pinte, and W. De Meuter, “Dis-tributed Object-Oriented Programming with RFID Technol-ogy,” in Distributed Applications and Interoperable Systems.Springer, 2010, pp. 56–69.

[21] M. Conti, J. Crowcroft, S. Giordano, P. Hui, H. Nguyen, andA. Passarella, “Routing Issues in Opportunistic Networks,”Middleware for Network Eccentric and Mobile Applications,pp. 121–147, 2009.

[22] K. Sohrabi, J. Gao, V. Ailawadhi, and G. Pottie, “Protocolsfor self-organization of a wireless sensor network,” IEEEPersonal Communications, vol. 7, no. 5, pp. 16–27, 2000.

[23] “Advanced Message Queuing Protocol,”http://www.amqp.org/.

[24] S. Vinoski, “CORBA: integrating diverse applications withindistributed heterogeneous environments,” IEEE Communica-tions Magazine, vol. 35, no. 2, pp. 46–55, 1997.

[25] J. Mercadal, N. Palix, C. Consel, and J. L. Lawall, “Pantaxou:a domain-specific language for developing safe coordinationservices,” Generative Programming And Component Engi-neering, pp. 149–160, 2008.

[26] P. Barron and V. Cahill, “YABS:: a domain-specific languagefor pervasive computing based on stigmergy,” GenerativeProgramming And Component Engineering, p. 285, 2006.

[27] J. Vitek, R. Hu, N. Yoshida, and K. Honda, “Session-BasedDistributed Programming in Java,” ECOOP 2008, vol. 5142,2008.

[28] D. Sturman and G. Agha, “A protocol description languagefor customizing failure semantics,” in Reliable DistributedSystems, 1994. Proceedings., 13th Symposium on, Oct. 1994,pp. 148 –157.

[29] “Java remote method invocation specification,”http://download.oracle.com/javase/7/docs/technotes/guides/rmi/.

232