[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) - Network-aware references for pervasive social applications

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) - Network-aware references for pervasive social applications

Post on 26-Mar-2017




1 download


Network-Aware References for Pervasive Social ApplicationsKevin Pinte, Dries Harnie, Elisa Gonzalez Boix, and Wolfgang De MeuterSoftware Languages LabVrije Universiteit BrusselBrussels, Belgium{kpinte,dharnie,egonzale,wdmeuter}@vub.ac.beAbstractIn recent years, mobile devices such as smart-phones have become more powerful, gaining the ability tocommunicate using multiple networking technologies. Thisevolution has given rise to pervasive social applications thatenable social networking on the move. Currently, it is hardto take advantage of the available networking technologiesbecause communication has to be managed separately for eachtechnology. This forces programmers to manually keep track ofthe connectivity state and duplicate communication code perconnection. This paper presents network-aware references, adistributed object-oriented programming abstraction that com-bines multi-networking and network awareness. They abstractover the implementation details of the different networkingtechnologies while allowing programmers to react to changesin the connectivity of different networks around them.I. INTRODUCTIONIn the recent years we have seen a boom in the market ofmobile devices such as smartphones and tablets: they havebecome powerful enough to complement existing computersas internet devices. This evolution has proliferated a new sortof mobile applications called pervasive social applications.Pervasive social applications enable spontaneous interactionsof people through mobile devices [1], [2]. These mobileapplications have changed the way people use social net-works: instead of merely serving as a tool for reporting onsocial events, people can now integrate their social networkinteractions with the real world. Various social networks likeFacebook, have created mobile applications that optimize theuser experience to accommodate mobile devices and users.Next to the performance increase, mobile devices havealso gained the ability to communicate using several differ-ent networking technologies: for example, an iPhone cancommunicate with other devices using short-range Blue-tooth, medium-range Wi-Fi and long-range 3G technologies.Pervasive social applications exploit contextual informa-tion (e.g. location, proximity, ...) to integrate social networkinteractions with the everyday life of their users. Networkawareness is an integral part of context-awareness [3],[4]. Pervasive social applications can benefit from beingnetwork-aware: mobile devices are constantly on the moveand their networking hardware allows them to sensedevices and access points in the environment. Additionally,network-aware applications can adapt their behavior accord-ing to the characteristics of the network connection that iscurrently used [5].We illustrate why network awareness is relevant for per-vasive social applications by introducing a representativepervasive social application called Pixee that allows usersto share and follow each others picture libraries. The Pixeeapplication gathers library information from nearby devicesusing Bluetooth and offers to follow other users if a librarymatches the users profile.The scenario goes as follows: on the way home fromwork, Alice and Bob, both Pixee users, happen to be inthe same metro car and thus in Bluetooth range. Since theyboth like pictures of cats, Alices picture library matchesBobs interests. When Bob arrives home, he opens the Pixeeapplication and it presents him with a selection of picturelibraries, including Alices library. Bob accepts Pixees sug-gestion and starts following Alices picture library. When-ever Alice takes a new picture it is automatically uploaded toBob. As Alice isnt home yet, Pixee uses her 3G connectionto share pictures. In order to optimize for the networkingtechnology used, Pixee resizes pictures before sharing themover 3G. When Bob rides on the metro to work the nextday the Pixee application alerts him that Alice is nearbyso they can meet in person and chat later. As long as theirphones are in Bluetooth range, their phones will exchangehigh-resolution pictures.Currently, various high-level middleware solutions existthat enable network awareness [5], [6]. Such solutions usenetwork information to enforce quality of service (QoS):they adapt the applications network usage to optimize forthe available bandwidth. However, such solutions do notsupport using multiple network links simultaneously: theychoose one primary network link and use the other networklinks only as backup links. In the networking domain thereis low-level support for multi-networking [7], [8]: they allowapplications to connect to other devices using different net-working technologies simultaneously, and switch seamlesslybetween these technologies as needed. Applications thatuse multi-networking technologies are fully communication-agnostic: all communication is performed the same way.As such, they do not allow the programmer to react tochanges in the individual network links they encapsulate,making network awareness hard. Our goal is to providepervasive social application programmers with a hybridSecond IEEE Workshop on Pervasive Collaboration and Social Networking978-1-61284-937-9/11/$26.00 2011 IEEE 537solution that allows programs to be network-aware whilesupporting multiple networking technologies simultaneously.In this paper we focus on distributed object-oriented pro-gramming abstractions to develop pervasive social applica-tions that exploit network awareness, like Pixee. Distributedobject-oriented programming languages rely on the notionof remote object references to communicate with objectsresiding on other devices. Currently, these references arespecific per networking technology and each technologyoffers a different way to discover objects. This leads to alot of duplication: multiple references to the same objectcan exist simultaneously, each using a different technology.Programmers have to do manual bookkeeping to keep trackof these different references. We propose a new program-ming abstraction, network-aware references, that extendsthe concept of a remote object reference to abstract overthe different networking technologies used. In addition, weprovide a high-level API that enables programmers to reactto changes in these networks and adapt the applicationbehavior as well as communication behavior.The main contributions of this paper are:1) We identify the challenges involved in developingnetwork-aware programs (section II);2) We introduce network-aware references that abstractover the networking technology used (section III);3) We propose programmable network behaviors asmeans for the programmer to steer remote commu-nication (section IV);To conclude, we discuss existing approaches to networkawareness and multi-networking technology in section V.II. CHALLENGES IN PROGRAMMINGNETWORK-AWARE APPLICATIONSAs mentioned in the introduction, current mobile devicessupport several networking technologies. They exhibit differ-ent characteristics such as bandwidth, energy consumption,communication range, etc. These differences occur not onlybetween technologies, but they can also be found betweennetworking technologies of the same kind. For example, thefree Wi-Fi network at an airport is restricted in bandwidthand usage volume compared to a users home Wi-Fi network.To facilitate the development of pervasive social applica-tions that are network-aware, several challenges need to beovercome:C1. Abstraction over networking technologies: In orderto build network-aware social applications, a programmershould not be concerned with the low-level details of thenetworking technologies available. For example, setting upa connection using Bluetooth is very different from a 3Gconnection. Instead a unified interface to the different net-working technologies should be provided. Communicationwith this unified interface should take advantage of allavailable network connections.C2. Reactions upon network availability: The programmershould be able to detect the appearance and disappearanceof network connections and react upon these events. Pixeesfriend list reflects the connectivity status of the users: whenBob and Alice are connected via Bluetooth, Alice is notifiedthat Bob is nearby so she can invite him for a chat. Addi-tionally, the programs must be resilient to disconnections.The Pixee application seamlessly switches from Bluetoothto 3G when Alice leaves the metro.C3. Dynamic adaptation of network behavior: Althoughthe low-level details of networking should be hidden fromthe programmer, he should retain high-level control overthe networking technology used. For example, Bobs Pixeeapplication resizes pictures when Alices device is connectedvia a 3G link to limit the data transfer. To steer communi-cation, pervasive social applications must take advantage ofthe unique properties of each networking technology.In the next section we introduce network-aware refer-ences: a programming abstraction to tackle the above chal-lenges.III. NETWORK-AWARE REFERENCES (NARS)Before we introduce network-aware references, we de-scribe terminology used in distributed object-oriented lan-guages. These languages use proxy objects to locally rep-resent objects residing on remote devices. Proxy objectsimplement the same interface as the remote objects theyrepresent, but they translate all method calls into remotemethod calls. The combination of a proxy object and itsnetwork link is called a remote object reference. Each remoteobject is identified by a GUID based on the device it ishosted on and an object identifier within that device.A program can acquire new remote references in threeways: 1) The remote object is discovered using a servicediscovery mechanism based on peer-to-peer connectionsover Bluetooth and Wi-Fi; 2) Clients can receive remotereferences from a globally reachable registry when peer-to-peer service discovery is not possible; 3) A remote referenceis created when an object is passed as an argument in aremote method call.Network-aware references (NARs) abstract over the im-plementation details of different networking technologiesand present themselves to the programmer as a singlereference. A NAR consists of multiple remote references tothe same object, each using a different network link. Whenthe application acquires a new remote reference, the systemextends the NAR for that object with the new reference ormakes a new NAR to hold the remote reference if the objecthasnt been referenced before. Figure 1 compares traditionalremote references and NARs graphically.In a mobile setting, network links are very unstable.They disconnect and reconnect as users move in and outof wireless communication range of other users [9]. Withtraditional remote references (e.g. RMI [10]) remote method538remoteobject3Gremotelocalproxy objectremoteobject3Glocalobjectnetwork-awarereferenceFigure 1. A NAR encapsulates remote references to the same object.calls block and wait for a response. Furthermore, networkdisconnections are signaled as exceptions. This model isunsuitable for a mobile setting since applications wouldbecome unresponsive when a remote party is unavailable.Therefore, we adopt the far reference model [11]. First,far references allow only asynchronous communication. Aremote method call over a far reference immediately returnsand the result is retrieved using a callback. Second, a farreference tracks the status of the network link and can bein one of two states. It is either connected, in which ittranslates method calls in remote method calls. Or it isdisconnected, where it buffers all messages that are sent ina so-called mailbox until the network link is connectedagain. A far reference that reconnects will try to transmit alloutstanding messages in the mailbox to ensure no messagesare lost. Likewise, a NAR is disconnected when all of theunderlying remote references are disconnected. As long as aNAR is disconnected, all messages sent to it are buffered ina unified mailbox. If one of the underlying remote referencesis reconnected or a new reference is added to the NAR, itswitches back to the connected state. Figure 2 illustrates this:the NAR on the left is connected, as it encapsulates oneconnected remote reference using 3G and a disconnectedremote reference using Bluetooth. The NAR on the rightis disconnected, as all encapsulated remote references aredisconnected.NAR3GNAR3GunifiedmailboxunifiedmailboxFigure 2. Connection status of a NAR.Whenever the programmer sends a message to a NAR, thesystem dispatches it to a remote reference from the set ofreferences encapsulated by the NAR. The default behavior ofa NAR nondeterministically selects a connected reference totransmit messages. Programmers can specify other behaviorsby attaching a network behavior either to the NAR, orto individual messages. A network behavior is an objectthat selects a reference from the NAR for transmission.Currently, we offer a set of network behaviors that can forexample prefer a Bluetooth reference over a 3G reference, orexclusively use 3G references. Network behaviors are furtherexplained in section IV.Communication SemanticsIn this section we detail two properties of the commu-nication semantics of NARs: they guarantee that messagessent to an object are processed in the order they are sent,and that messages are processed at most once.A NAR ensures the first property by serializing messagesends through its unified inbox. Messages are processed oneby one, and the next message is only processed if the receiveracknowledges the receipt of the previous one. Figure 3shows what happens if a message is sent to a NAR: first, itis added to the unified mailbox (1). The NAR encapsulates athread which constantly tries to deliver the first message inits mailbox. When the message eventually reaches the firstposition in the mailbox, it is removed (2) and the networkbehavior attached to the message selects a reference fromthe set of currently connected references (3). The messageis then transmitted to the receiver using that reference (4). Ifsomething goes wrong during the transmission the messageis returned to the front of the unified mailbox and thetransmission is attempted again (5). The next message inthe mailbox is only processed when the transmission isacknowledged by the receiver.unified mailboxremoteobjectNARlocalobject(1)(2)(3)(5)(4)3GmessagenetworkbehaviormessagedirectionFigure 3. The network behavior selects a remote reference.The second property that NARs offer is so-called at-most-once delivery: a message is either processed once,or not at all. By default, message duplication is avoidedbecause NARs wait for transmission acknowledgment by thereceiver. However, programmers can build network behav-iors that send duplicate messages intentionally, for exampleto ensure a critical message arrives as soon as possible.When a network behavior tries to transmit a set of duplicatemessages, each message is marked with a serial numberunique to the set and the total amount of duplicated messagesbefore it is transmitted. When a duplicate message arrives,the receiver first checks if it has already received a messagewith that serial number. If not, the message is processedas normal and a counter is initialized with the remainingamount of duplicated messages. The counter reaches zerowhen all duplicate messages have arrived, after which it isremoved. After the first message, all duplicate messages areignored.539IV. NARS: A PROGRAMMERS PERSPECTIVEWe have prototyped NARs in the distributed object-oriented programming language AmbientTalk [11]. Ambi-entTalk is designed to work in mobile settings and hasalready been used to build pervasive social applications [12].The following piece of AmbientTalk code discovers aPixee user in the environment, requests his or her name, andadds the user to the buddy list. The left-arrow operator ()represents an explicit asynchronous message send, while thedot operator is used for synchronous method invocation:when: PixeeUser discovered: { |aUser|when: aUsergetName() becomes: { |name|GUI.addUser(aUser, name) } }The asynchronous call to getName() immediately re-sults in a future: a placeholder for a future value. Thewhen:becomes: constructs installs a handler that is exe-cuted when the future is resolved with the return value.In the remainder of this section we will show howprogrammers can respond to changes in the network avail-ability around them, steer communication towards certainnetworking technologies, and implement their own networkbehaviors. We will demonstrate how the Pixee applicationuses the API offered by NARs. The examples we presenthere use AmbientTalk syntax, but NARs can be implementedin other distributed object-oriented systems, like RMI [10].A. Network AvailabilityAs mentioned earlier, information about the availablenetworks forms an important source of context for pervasivesocial applications. A NAR can encapsulate several remotereferences, so we offer a links: primitive that returns asnapshot of the state of these references to the programmer.For example, Pixee allows users to explicitly share a picturewith another user who is close by, to highlight certain photosin their library. The user interface only allows this if theother user is connected via Bluetooth:if: (links: aUser).contains(Bluetooth) then: {GUI.showShareButton() }However, as shown by the scenario, changes in the net-work connectivity of references also play a big role, as usersmove about and connectivity fluctuates. For example, Pixeesfriend list reflects the connectivity of a users friends andupdates it in real time. It uses the links: primitive aboveto draw the friend list initially and then updates the statusof indiviual friends whenever their connectivity changes:when: aFriend linkStatusChanged: { |change|if: (change.link == Bluetooth) then: {if: (change.isConnected()) then: {GUI.notifyFriendNearby(aFriend);} else: {GUI.notifyFriendLeaving(aFriend); } } }The when:linkStatusChanged: function installs acallback on a NAR that is called whenever one of thereferences it encapsulates disconnects or reconnects.We also provide two generalized handler functions thatare triggered when a NAR switches to a disconnected ora connected state, respectively. Programmers can react ondisconnections using a when:disconnected: handler.Likewise, programmers can use when:reconnected: toreact on reconnections, which happen whenever a discon-nected NAR either adds a new reference or one of theexisting references it encapsulates reconnects.Together with the links: primitive, these event handlersprovide programmers with information about the connectiv-ity of the different references in their applications and allowthem to react on changes in network connectivity.B. Network Behavior AdaptationIn order to allow programmers to steer communicationtowards certain networking technologies, we introduce net-work behaviors. Our implementation provides a number ofbuilt-in network behaviors. Additionally, programmers canimplement their own behaviors and override the defaultbehavior attached to NARs using annotations.The first network behavior is called Only: it restrictsmessage transmission to a set of network technologies. Theexample below ensures an explicitly shared picture is onlysent using Bluetooth:aUsersendPicture(aPicture)@Only(Bluetooth)This message will only be sent using a Bluetooth connection:if there is no connected Bluetooth reference to aUser themessage is returned to the mailbox and message processingfor the aFriend NAR will stop until a Bluetooth referenceis connected.The Prefer behavior allows programmers to order anarbitrary number of technologies in decreasing order ofpreference:aFriendsendPicture(aPicture)@Prefer(Bluetooth, WiFi)The Prefer behavior here first tries to transmit the sendPic-ture message using a Bluetooth link; if this is not availableit tries to use a Wi-Fi link. If a Wi-Fi link is also unavailable,the Prefer behavior defers to the default behavior: this willeither transmit the message using other technologies, orbuffer the message if the NAR is disconnected.Programmers can also attach network behaviors to NARsusing the setDefaultBehavior:for: function as fol-lows:setDefaultBehavior: aBehavior for: aReferenceThis operation makes every message sent using the NAR usethe aBehavior behavior, unless programmers explicitlyoverride this behavior by annotating a message.Existing network-aware approaches have shown thatworking with properties instead of explicit technologies ismore versatile. For example, if a programmer wants to senda big file using a fast network connection, he should be540able to use a keyword like Fast instead of listing everyfast network connection explicitly. In order to do this, weprovide programmers with a set of categorization functionsthat select networking technologies based on their properties.We provide three built-in categorization functions: weoffer a categorization function Speed(x) which only se-lects network links that theoretically offer at least x Mbitsof bandwidth. Another categorization function we offer iscalled Range(x), which selects links with a communicationrange that allow communication in a range of at mostx meters. Finally, cost can also be a factor in decidingwhich network link to use: we provide a Free categorizationfunction that only selects network links that are free to use.Currently these properties are statically defined as attributesof the network links (Bluetooth, WiFi, etc.).Programmers can create their own categorization func-tions based on the built-in ones described above. For exam-ple, they can define Fast as Speed(10). Additionally, pro-grammers can manually define new categorization functionsbased on the properties of the network links.Using categorization functions instead of explicit tech-nologies has another advantage: when a new networkingtechnology becomes available, one only has to declare towhich categories that new technology belongs or create newcategorization functions if necessary. For example, a bodyarea network (a very close-range wireless technology fornon-intrusive health monitoring [13]) could be deemed Fastand Secure, but could also belong to a new category suchas PhysicalContact.C. Writing custom network behaviorsThe network behaviors we have presented so far onlyinfluence the technology selection process. If we want toallow full network awareness, programmers also need tobe able to adapt the content of messages to the tech-nology used to transmit them. In our system, behaviorsare represented by objects that expose a single methodtransmit(connections, message). This method isinvoked during step two of the message sending process(when network technologies are chosen). This method trans-mits the message(s) to the receiver and informs the NARthat the message can be removed from the mailbox. Theconnections and message parameters of the methodare the current set of available network links in the NARand the message being sent, respectively.In the scenario, Pixee resizes pictures before transmissionif a Bluetooth link was not available; programmers canimplement this as follows:def PictureResizer := extend: defaultBehavior with: {def transmit(connections, message) {def bt := connections.find: {|x| x.link == Bluetooth };if: bt != nil then: { supertransmit(bt, message)} else: {message.data := resize(message.data); supertransmit(connections.first, message) } } };This behavior first looks for a Bluetooth link in the net-work links managed by the aFriend NAR. If a Bluetoothlink is found, the message is sent as is (). Otherwise, thebehavior sends a resized version ().This behavior inherits from defaultBehavior and alltransmit calls are delegated to it: the default behaviorenforces the two properties we outlined in section III:message ordering and at-most-once delivery.V. RELATED WORKIn this section we discuss how network-aware referencesfit into the state of the art. Traditionally, network-aware ap-plications are defined as applications that adapt to networkconditions in an application specific way [6]. This has ledto frameworks for maintaining quality of service (QoS) inmedia streams [5], where image or sound quality is reducedif the available bandwidth decreases. These are usuallyimplemented in a framework or middleware and require theprogrammer to set up policies, giving up explicit control.Current network-aware applications assume network linksare stable and treat network failures as an exceptional case.This makes them unsuitable for a mobile situation wherepervasive social applications are deployed.A number of network protocols have been proposed thatenable multi-networking at a low level, like SCTP, mSCTP,SIGMA, TraSH and Mobile IP(v6) [7], [8]. However, theseapproaches focus on the problem of ensuring devices arealways reachable at a certain address and maintaining exist-ing network connections when a mobile device migrates toa different access point (horizontal handover). Some tech-nologies support transitions between different networkingtechnologies (vertical handover), but they assume these tran-sitions are short-lived, so they limit themselves to ensuringno data is lost during a transition. In contrast, NARs acceptthat there may be multiple connections at once, which canbreak at any time. NARs still ensure that all communicationarrives, but cannot offer time guarantees: a message withthe Bluetooth behavior attached will only be sent when aBluetooth connection is available. This may depend on usermobility.In [14] a policy-based architecture is proposed that man-ages several different routes to another device. They usepolicies to select appropriate network interfaces and set pri-orities between interfaces if several policies apply. However,their approach is not suitable for a mobile setting as theirsystem immediately returns an error if there are no matchinginterfaces at the moment a packet is sent. In contrast, NARsbuffer communication until a connection is re-established.Furthermore, their policies currently operate at the systemlevel instead of the application level, so all applications onthe system have to agree on the same set of policies.Haggle [15] is an architecture that enables seamlessnetwork connectivity for devices in dynamic mobile environ-ments. It abstracts over different network transport bindings541and protocols so that applications become communicationagnostic. Haggle is a central component in the mobiledevice that selects and switches network links as needed.In contrast to using NARs, programmers have no controlover communication within a single application and cannotadapt its behavior to changes in the network context.VI. CONCLUSION AND FUTURE WORKIn this paper we have introduced network-aware refer-ences: a programming abstraction that encapsulates sev-eral references to remote objects over different networkingtechnologies and keeps track of the state of the networklinks involved. Network-aware references tackle the threechallenges for programming network-aware applications welisted earlier: abstraction over networking technologies, re-acting to changes in the network availability, and dynami-cally adapting network behavior. We have demonstrated hownetwork-aware references can be used to build pervasivesocial applications using a representative picture-sharingapplication called Pixee.We are currently exploring different types of network be-haviors and how they interact with NARs as they are definedhere. For example, a behavior that limits retransmission ofmessages, or a behavior that spreads parts of a messageacross different links. Currently, the information offered byour system, like speed, communication range, pricing, etc.are statically defined. We would like to enable applicationsto dynamically retrieve these parameters to further enhancenetwork awareness. Additionally, we intend to allow theseparameters to vary per reference rather than per network link(e.g. the signal strength for a reference over Bluetooth).ACKNOWLEDGMENTSElisa Gonzalez Boix and Dries Harnie are funded bythe Prospective Research For Brussels program of IWOIB-IRSIB. We would like to thank the anonymous referees fortheir comments and advice.REFERENCES[1] S. Ben Mokhtar and L. Capra, From pervasive to socialcomputing: Algorithms and deployments, in ACM Inter.Conf. on Pervasive Services (ICPS), 2009.[2] A. Meshhadi, S. Ben Mokhtar, and L. Capra, Habit: Lever-aging human mobility and social network for efficient contentdissemination in manets, in IEEE Inter. Symp. on a Worldof Wireless, Mobile and Multimedia Networks, 2009.[3] B. Schilit, N. Adams, and R. Want, Context-aware comput-ing applications, in First Workshop on Mobile ComputingSystems and Applications, 1994, pp. 8590.[4] G. D. Abowd, A. K. Dey, P. J. Brown, N. Davies, M. Smith,and P. Steggles, Towards a better understanding of contextand context-awareness, in 1st Intl. Symp. on Handheld andUbiquitous Computing (HUC). London, UK: Springer-Verlag, 1999, pp. 304307.[5] J. Bolliger and T. Gross, A framework-based approachto the development of network-aware applications, IEEEtransactions on Software Engineering, vol. 24, no. 5, 1998.[6] N. Miller and P. Steenkiste, Collecting network status infor-mation for network-aware applications, in IEEE INFOCOM,vol. 2. Citeseer, 2000, pp. 641650.[7] S. Fu, M. Atiquzzaman, L. Ma, and Y. Lee, Signaling costand performance of SIGMA: A seamless handover schemefor data networks, Wireless Communications and MobileComputing, vol. 5, no. 7, pp. 825845, 2005.[8] W. Xing, H. Karl, A. Wolisz, and H. Muller, M-SCTP:Design and prototypical implementation of an end-to-endmobility concept, in Proc. 5th Intl. Workshop The InternetChallenge: Technology and Applications, Berlin, Germany.Citeseer, 2002.[9] J. Dedecker, T. Van Cutsem, S. Mostinckx, T. DHondt,and W. De Meuter, Ambient-Oriented Programming, inOOPSLA 05: Companion of the 20th annual ACM SIG-PLAN conference on Object-oriented programming, systems,languages, and applications. ACM Press, 2005.[10] T. Downing, Java RMI: Remote Method Invocation. IDGBooks Worldwide, Inc. Foster City, CA, USA, 1998.[11] T. Van Cutsem, S. Mostinckx, E. Gonzalez Boix, J. Dedecker,and W. De Meuter, Ambienttalk: object-oriented event-driven programming in mobile ad hoc networks, in Inter.Conf. of the Chilean Computer Science Society (SCCC).IEEE Computer Society, 2007, pp. 312.[12] E. Gonzalez Boix, A. Lombide Carreton, C. Scholliers, T. VanCutsem, W. De Meuter, and T. DHondt, Flocks: Enablingdynamic group interactions in mobile social networking appli-cations, in 26th Symposium On Applied Computing (SAC) Mobile Computing and Applications track (to appear), 2011.[13] E. Jovanov, A. Milenkovic, C. Otto, and P. De Groen, Awireless body area network of intelligent motion sensorsfor computer assisted physical rehabilitation, Journal ofNeuroEngineering and Rehabilitation, vol. 2, no. 1, p. 6,2005.[14] J. Ylitalo, T. Jokikyyny, T. Kauppinen, A. Tuominen, andJ. Laine, Dynamic network interface selection in multihomedmobile hosts, in Proc. of the 36th Annual Hawaii Int. Conf.on System Sciences. IEEE Computer Society, 2003.[15] J. Su, J. Scott, P. Hui, J. Crowcroft, E. De Lara, C. Diot,A. Goel, M. H. Lim, and E. Upton, Haggle: seamlessnetworking for mobile applications, in Proc. of the 9thint. conf. on Ubiquitous computing (UbiComp). Berlin,Heidelberg: Springer-Verlag, 2007, pp. 391408.542


View more >