[IEEE 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops) - Seattle, WA, USA (2011.03.21-2011.03.25)] 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops) - Programming language support for routing in pervasive networks

Download [IEEE 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops) - Seattle, WA, USA (2011.03.21-2011.03.25)] 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops) - Programming language support for routing in pervasive networks

Post on 09-Apr-2017

212 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

<ul><li><p>Programming Language Support for Routing in Pervasive Networks</p><p>Tomohiro Suzuki, Kevin Pinte, Tom Van Cutsem**, Wolfgang De Meuter and Akinori Yonezawa The University of Tokyo, Tokyo, Japan</p><p>Email: {tsuzuki, yonezawa}@yl.is.s.u-tokyo.ac.jp Software Languages Lab, Vrije Universiteit Brussel, Brussels, Belgium</p><p>Email: {kpinte, tvcutsem, wdmeuter}@vub.ac.be</p><p>AbstractManaging 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.</p><p>I. INTRODUCTION</p><p>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-</p><p>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</p><p>**Postdoctoral Fellow of the Research Foundation, Flanders (FWO)</p><p>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 distributed</p><p>concurrent 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 in</p><p>intermediate 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 message</p><p>passing 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-</p><p>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 variety</p><p>of routing frameworks for coordination among multiple net-</p><p>8th IEEE International Workshop on Middleware and System Support for Pervasive Computing</p><p>978-1-61284-937-9/11/$26.00 2011 IEEE 226</p></li><li><p>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.</p><p>II. AMBIENTTALK/M</p><p>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.</p><p>A. AmbientTalk</p><p>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]. AmbientTalks powerful symbiosis betweenAmbientTalk objects and Java objects [13] enables us towrite an application partly in AmbientTalk/M and partly inJava.</p><p>B. Actors</p><p>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.</p><p>C. Service Discovery and Temporary Disconnection</p><p>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</p><p>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 </p></li><li><p>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 subscribes</p><p>to 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:</p><p>on: are new functions in AmbientTalk/M with the capabilityto specify which network to use in their communication.</p><p>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;</p><p>Listing 4. Service Subscription in AmbientTalk/M1 deftype Printer;2 def port := networks.getAllPorts()[1];3 when: Printer discovered: {|p|4 p</p></li><li><p>PrinterGateway ActorClient</p><p>Network X</p><p>Network Y</p><p>reflectOnActor:{</p><p> def receive(receiver, msg) {</p><p> transfer the message to the printer</p><p>Figure 1. Coordination in Multiple Networks</p><p>A. Messaging among Multiple Networks</p><p>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 printers service information is propagated via</p><p>the gateway actor, the client sends a message to the servicethrough the gateway actor. As the gateway actors 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-</p><p>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 linked</p><p>together 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 a</p><p>single network on its underlying network stack, such asTCP/IP, and that routing frameworks in AmbientTalk/M</p><p>complement the intra-network packet routing with the inter-network message routing in the application layer.</p><p>B. Routing Frameworks for Multiple Paths</p><p>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 messages</p><p>as 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. In</p><p>this 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-</p><p>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...</p></li></ul>