Vinod Muthusamy and Hans-Arno JacobsenDepartment of Electrical and Computer Engineering, University of Toronto,Toronto, Canada
4.1 Introduction 624.2 Mobile Applications 634.3 Publish/Subscribe 664.4 Client Mobility 734.5 Example Application 824.6 Summary 84References 84
4.1 INTRODUCTION
Emerging mobile applications such as location-based services, mobile commerce,games, and entertainment services exhibit communication patterns for which exist-ing transport layer communication primitives are ill-suited. These applications pro-duce massive volumes of data and require sophisticated interaction patterns, such asmany-to-many communication, which necessitate powerful and efficient filtering androuting capabilities. Furthermore, mobile devices are typically resource constrainedand highly dynamic, which presents a challenge in developing a communication in-frastructure that scales with network traffic and size.
The distributed content-based publish/subscribe communication paradigm ad-dresses the requirements of emerging mobile applications. The loose coupling among
participants supports mobility seamlessly at the messaging layer. Also, an expressive,declarative language allows for fine-grained message filtering, complex interactions,and scalable, efficient routing of messages to mobile nodes.
In this chapter, Section 4.2 first provides some context for the discussion bydescribing a sample of mobile applications of interest and extracts the key character-istics of these applications. These characteristics are used to motivate the requirementsof a communication infrastructure for these applications. Section 4.3 describes thepublish/subscribe model, which addresses the above requirements, and Section 4.4presents algorithms to efficiently support mobility in a distributed publish/subscribesystem. Then, in Section 4.5, an example scenario is presented to illustrate the filteringand complex interaction patterns possible using a publish/subscribe communicationabstraction. Finally, Section 4.6 concludes with a brief summary of the chapter.
4.2 MOBILE APPLICATIONS
Before designing a system architecture for mobile applications, it is important tounderstand the characteristics of these applications. In this section, we present variousmobile applications and outline the properties of these applications and the devicesthey run on. From this analysis, we argue for certain infrastructure requirements tofacilitate mobile applications.
4.2.1 Example Applications
Mobile applications are constantly evolving and it is difficult to outline a definitiveset of application requirements. However, there are certain trends and properties wesee in emerging applications.
Early applications on mobile devices were often stand-alone programs that didnot interact with other applications or with a network. Examples include rudimentarypersonal information management (PIM) utilities such as calendars and to-do lists;single-player games, such as solitaire card games; and camera applications that letusers capture and view photos. In the context of this discussion, the notable propertyof these applications is that they had no network access and all the data are man-ually entered. While such applications may provide the ability to synchronize datawith a desktop computer, physical access to the computer is required, decreasing theadvantage of a mobile device.
Here, we are more concerned with mobile applications that have access to anetwork while mobile. Most mobile devices today provide some means to access anetwork, such as the Internet, while the user is mobile. For example, mobile phonesallow applications to utilize the SMS capabilities of the phone, or to access the Web.Many PDAs, likewise, support a variety of means to access data outside the device,such as infrared, Bluetooth, GPS, or WiFi interfaces.
Initial network-enabled applications on mobile devices were often traditionalnetwork-aware desktop applications that were ported to mobile devices. This in-cludes PIM applications such as e-mail (a popular example of which are the
64 Mobility in Publish/Subscribe Systems
BlackBerry devices), instant messaging capabilities (such as the short message ser-vice), and simple file sharing (using the multimedia messaging service). These appli-cations were typically limited versions of their desktop equivalents but could be usedwhile mobile.
As the mobile device capabilities improved (most notably in terms of their wire-less network cost and performance), and as developers gained experience on the vari-ous mobile platforms, new classes of mobile applications emerged that had no desktopequivalents. One such class of applications are location-based services. Examples ofsuch services include location-aware alerts (such as information about local trafficadvisories or advertisements about nearby merchants), or an enterprise fleet trackingsystem that can be used to provide real-time locations of the vehicles belonging to anorganization. These location-aware applications, naturally, require knowledge aboutthe location of the device. This information can be gathered automatically using GPSreceivers or various location-tracking technologies provided by telecom providers, orbe input by the user. They may also be deduced in various ways, such as detectingthe presence of a signal from a known landmark.
More recently, commerce and financial applications have emerged on mobiledevices. Examples of such applications include mobile payment services that allowusers to securely purchase goods from their mobile device, or store financial datasuch as credit card information on their mobile devices. Such applications may belocation-aware, network-capable, and above all must be robust to malicious attacks.
All the above examples consist of applications and devices ultimately used byhuman, which we note does not preclude the applications from performing intelligentprocessing or automatic actions the user is unaware of. However, another class of ap-plications consist entirely of autonomous agents with little or no human interactions.Perhaps the most representative of such applications are those based on sensor net-works, in which a large number of resource-constrained nodes collaborate to performsome common task. Examples of sensor network applications include distributedenvironment sensing or assembly line automation.
4.2.2 Device and Application Characteristics
On the basis of the sampling of applications above, we summarize some key propertiesof the mobile devices and applications of interest.
The mobile devices are typically resource constrained. While the computation,memory, bandwidth, and battery life available in such devices are always improving,these devices are still constrained relative to other compute devices such as desktopcomputers. Also, the user interface of these devices is either nonexistent in the caseof sensor network nodes or very limiting in the case of PDAs and mobile phones.We also notice that most mobile devices today support some means to communicatewith the outside world while the user is mobile. The technology used to achieve this,however, varies widely and includes WiFi, Bluetooth, and GPRS.
In terms of the applications, the key characteristic we note is that virtually allemerging applications require some sort of wireless network connectivity in order
4.2 Mobile Applications 65
to collaborate with other mobile devices or communicate with other services on theInternet. Also, the applications are, unsurprisingly, becoming more resource intensiveas they exploit improvements in the mobile devices. Of particular interest in thisdiscussion is the increasing amount of data the applications must process, much ofwhich are transferred over the limited, unreliable network. For example, a location-aware traffic report service may need to filter and process a large and continuousstream of data in order to find the information relevant to the user.
4.2.3 Infrastructure Requirements
The mobile applications presented above require some sort of infrastructure to operate.We will focus in particular on the communication infrastructure needed by theseapplications to communicate with other devices or services accessible through thenetwork and outline some of the requirements of such an infrastructure.
� Large scale: The incredible growth in the use of mobile phones and the increas-ing number of mobile applications available on these devices requires that theinfrastructure be able to support a very large number of devices.
� Network constraints: Mobile devices today typically have wireless connectionsthat have limited bandwidth, long latencies, and are unreliable. The infrastruc-ture must be able to tolerate such networks. Most notable here is that unreli-able network connections require the disconnected operation of applications,in which applications must continue to operate (in some limited way) while thenetwork is unavailable and “recover” when the network becomes available.
� Dynamic system: A system of mobile nodes is highly dynamic. Not only arethe nodes constantly moving, but they also experience ongoing fluctuations intheir network connection performance and availability. Applications require acommunication abstraction that can simplify dealing with such an environment.
� Data volume: The infrastructure as a whole must be able to support the immensevolume of data being transferred among the large number of mobile devices. Inaddition, the applications on the individual devices need a simple and powerfulmechanism to filter and process these data.
� Sophisticated interaction: While much of the communication in traditional In-ternet applications involves a conversation between two parties (such as Webbrowsing and e-mail applications), applications are increasingly establishingmore complex communication among mobile devices and services. For ex-ample, sensor networks collaborate in unpredictable ways, and location-awaremobile applications may communicate with any number of mobile deviceswithin proximity. The interaction patterns here may be arbitrarily complexand include any combination of one-to-one, one-to-many, and many-to-manycommunication.
� Location support: Location is an important contextual property of mobile de-vices that applications can exploit. Therefore, the communication abstractions
66 Mobility in Publish/Subscribe Systems
need to expose (or hide) this information as required by the applications. Oneapplication may require addressing the services in a location-independent man-ner, while another may require location-dependent names.
� Flexible naming and addressing: The issue of device naming cuts across severalof the points above. Devices or services need to be named in such a way thatthey can be addressed in a location-dependent or -independent way, or beaddressed individually or as a meaningful subset of some group. For example,an application may wish to communicate with John’s PDA regardless of itslocation (or even its network connectivity), with all sensors within some radiusaround the device or with all mobile phones anywhere that support the SMSservice. The communication abstractions must allow such flexible addressingcapabilities.
� Responsiveness: Some mobile applications require real-time notificationsabout external events. For example, a traffic reporting application may need tonotify the user as soon as a traffic alert is issued.
While the properties above need to be supported by the physical communicationinfrastructure, they must also be addressed by the software abstractions made avail-able to the applications and system software architecture. We refer to this softwareand architecture as the middleware and will spend the remainder of this discussionpresenting a middleware paradigm that addresses these concerns.
4.3 PUBLISH/SUBSCRIBE
The requirements of a communications infrastructure presented in the previous sectionare addressed by the publish/subscribe model. The publish/subscribe model providesa simple yet powerful abstraction for application interactions. Below, we presentthe publish/subscribe model, briefly outline its benefits, and describe a distributedimplementation of this model.
4.3.1 Publish/Subscribe Model
Publish/subscribe is a data-dissemination model that has many useful properties.There are three main entities in the publish/subscribe model: the publisher, subscriber,and broker. The publisher is the data producer, the subscriber the data consumer, andthe broker mediates between the publisher and subscriber. These entities are onlylogical and do not have to correspond to physical components. For example, it ispossible for a computer to be a publisher, subscriber, and broker.
A popular example of the publish/subscribe model is a stock quote informationdissemination application. In this example, the publisher would be the stock exchange,such as the New York Stock Exchange, and the consumer could be a stock broker whois interested in tracking the latest prices of certain stocks. A subscriber S expresses hisinterest in these stocks by sending a subscription message s to the broker. The brokerstores these subscriptions in an index T as a set of (subscription, subscriber) tuples.
4.3 Publish/Subscribe 67
Publisher Publisher
Subscriber Subscriber
(2) Publications
(1) Subscriptions
Broker
(3) Notification(3) Notification
Figure 4.1 Publish/subscribe message sequence.
The publisher P communicates the latest stock updates by sending a publicationmessage e to the broker. Upon receipt of a publication e, the broker searches index T
for the set of subscribers whose subscriptions match e and notifies these subscribersof a matching publication (usually by simply forwarding e to the subscribers). Thissequence of events is illustrated in Figure 4.1.
Notice that messages from publishers (publications) do not contain any address;instead, they are routed through the system based on their content (for a content-basedsystem). This ability to send messages to a set of subscribers without specifyingtheir explicit address decouples the interaction between the publishers and sub-scribers and is key to achieving many of the infrastructure requirements outlined inSection 4.2.3
The publish/subscribe model is in some ways the dual of the traditional databasemodel. In a database, data are persisted in a database and queries retrieve these data,whereas in the publish/subscribe model, the queries (subscriptions) are stored at thebroker, and the data (publications) are pushed to the subscribers. A subscription can bethought of as a long running query, so it may be helpful to think of publish/subscribemodel as being similar to database triggers [18]. It is important to note that in mostpublish/subscribe systems, subscriptions only match future publications. Publicationsenter the system, are sent to interested subscribers, and are then lost1. This is animportant difference from the database model. Another point to note is that data onlytravel from publisher to subscriber. Of course, in a given application, bidirectionalcommunication between two components is possible by having the components actas both publisher and subscriber.
Publish/subscribe systems can be classified based on the expressiveness of theirsubscription language, such as those based on topics (or subjects), types, or content.
1There are extensions to the publish/subscribe semantics to support matching historic data [15].
68 Mobility in Publish/Subscribe Systems
In topic-based publish/subscribe, clients can subscribe to several topics and receivenotifications about all publications within these topics. These systems usually offerflat or hierarchical addressing. In flat addressing, all topics are disjoint, while in hi-erarchical addressing, topics are organized in hierarchies; subscriptions can addressany node in the hierarchy, implicitly addressing all subtopics of the node. Type-basedpublish/subscribe systems are similar to topic-based, but use publication types in-stead of topics for matching. Content-based publish/subscribe systems increase theexpressiveness of subscriptions by allowing more complex queries on the publicationcontent [11] including XML data [16]. There are even systems that support locationconstraints, such as conditions on the number of mobile users near a fixed landmark,or within the vicinity of themselves [28–30].
Early publish/subscribe systems were centralized system [2, 11]; there was onlyone broker in the system that received all publications and subscriptions in the sys-tem. This is the scenario shown in Figure 4.1. Research in these systems were fo-cused on developing algorithms that can quickly and efficiently match a publica-tion against millions of subscriptions. However, in systems with potentially millionsof subscriptions and with subscribers dispersed geographically, a centralized bro-ker can still become a processing, memory, and network bottleneck. Newer systemswere developed that employed a distributed set of brokers [7, 10, 12]. The researchhere was focused on distributed matching and multicasting. Distributed matchingrefers to storing subscriptions in a subset of the nodes in the system such thatmatching can be distributed among the nodes. Multicast refers to a technique ofdisseminating publications to interested subscribers such that total network traffic isminimized.
4.3.2 Publish/Subscribe Benefits
The publish/subscribe model offers many benefits . First, the model has a very simpleinterface . As shown in Figure 4.1, the only messages involved are publications, andsubscriptions, and the only operations are publish, subscribe, and notify.
Another important benefit is the decoupling of publisher and subscribers. Thisdecoupling exists along several dimensions as described below.
� Address decoupling: Publishers and subscribers do not know the addressesof one other. Instead, publications are routed to subscribers based on thecontent of the publications and the interests of the subscribers. For this reason,publish/subscribe is also often referred to as content-based routing. Anotheradvantage of address decoupling is the anonymity it offers to the publishersand subscribers. Only the brokers know the identity and interest of a subscriber,and the data published by a given publisher.
� Platform decoupling: All entities in the publish/subscribe communicate usingnetwork messages, and as such can run on heterogeneous platforms. Therefore,a powerful multiprocessor server with a dedicated network connection canseamlessly communicate to a resource-constrained PDA with a wireless link.
4.3 Publish/Subscribe 69
� Space decoupling: As mentioned above, publishers and subscribers can existin geographically distant areas of the globe.
� Time decoupling: Some publish/subscribe algorithms allow publishers andsubscribers to not be connected to the network simultaneously, allowing sub-scribers that experience network disconnection to retrieve missed publicationsupon reconnection [4, 20].
� Representation (semantic) decoupling: Some publish/subscribe systems canmediate between publications and subscriptions whose predicates have differ-ent meaning [23]. For example, in a dating service application, it is possibleto match publications that specify a user’s age in years and subscriptions thatrequest users born before a certain date.
Publish/subscribe also provides benefits regarding network bandwidth use. No-tably, data are pushed to subscribers as it becomes available. This is more efficientthan having subscribers periodically poll for new data. A system with millions ofsubscribers polling a broker can easily overwhelm a broker. Data push also deliversdata quicker to subscribers than polling. Furthermore, distributed publish/subscribesystems use efficient multicast techniques to minimize the messages used by sub-scribers. An example of the benefits of multicast is shown in Figure 4.2 in which thepublication only travels a total of three hops to reach both subscribers. Unicasting thepublication, that is, sending the publication individually from the publisher to eachsubscriber, would require four hops. In a large system with millions of subscribers,multicast is much more bandwidth efficient than unicast.
In addition to the above inherent benefits of publish/subscribe, there has beenmuch work to augment the basic publish/subscribe model with enterprise-grade fea-tures such as security [22, 26, 27], reliability [9, 14], load-balance [8], transactionalclient movement guarantees [13], and unified access to publications in the futureand past [15]. These efforts make publish/subscribe more attractive and useful inmission-critical enterprise applications.
4.3.3 Publish/Subscribe Router
As mentioned in Section 4.3.1, a publish/subscribe broker can be replaced by a brokernetwork for scalability reasons. In a broker network, each broker only has local
Multicast Unicast
Network node
Subscriber
Figure 4.2 Comparison of multicast and unicast propagation.
70 Mobility in Publish/Subscribe Systems
knowledge and routes messages to its neighbors. In this section, we describe themain routing operations performed by a broker in a distributed publish/subscribenetwork.
A publish/subscribe router performs the following three operations: (1) for-warding of advertisements, (2) forwarding of subscriptions, and (3) forwarding ofpublications.
The details of the three operations are highly dependent on the expressiveness ofthe subscription and publication representation languages.
To better understand the operation of a publish/subscribe router, we give a moreformal definition of a subscription and a publication representation language mostcommonly used in the research literature. The formal representation of a publicationis given by the following expression: {(a1, val1), (a2, val2), . . ., (an, valn)}. Subscrip-tions are expressed as conjunctions of Boolean predicates. In a formal description,a simple predicate is represented as (attribute name relational operator value). Apredicate (a rel op val) is matched by an attribute–value pair (a, val) if and only ifthe attribute names are identical (a = a) and the (a rel op val) Boolean relation istrue. A subscription s is matched by a publication p if and only if all its predicates arematched by some pair in p.
We are now ready to look at the details of the publish/subscribe router operations.
4.3.3.1 Forwarding of Advertisements
Advertisements are used by publishers to announce the set of publications they aregoing to publish. Consequently, advertisements create routing paths for subscriptionsfrom subscribers to publishers, whereas subscriptions build routing paths for publica-tions from publishers to subscribers. Usually, both subscriptions and advertisementshave the same formal representation. However, there is an important distinction be-tween the predicates in an advertisement and those in a subscription: the predicatein a subscription is considered to be in a conjunctive construction, while that in anadvertisement behaves as in a disjunctive one.
An advertisement a matches a publication e if and only if all attribute–valuepairs match some predicates in the advertisement. Formally, an advertisement a ={p1, p2, . . . , pn} determines a publication e, if and only if ∀(attr, val) ∈ e, ∃pk ∈ a
such that (attr,val) matches pk.An advertisement a intersects a subscription s if and only if the intersection
of the set of the publications determined by the advertisement a and the set of thepublications that match s is a nonempty set. Formally, at the predicate level, anadvertisement a = {a1, a2, . . . , an} intersects a subscription s = {s1, s2, . . . , sn}if and only if ∀sk ∈ s, ∃aj ∈ a and there exists some attribute–value pair (attr,val) such that (attr, val) matches both sk and aj . Table 4.1 presents some ex-amples of subscriptions and advertisements and the corresponding intersectionrelations.
The following are the steps performed by the publish/subscribe router uponreceiving an advertisement:
4.3 Publish/Subscribe 71
Table 4.1 Examples of Subscriptions, Advertisements, and Intersection Relations
Subscription s Advertisement a Intersection relation
1. For the advertisement received, check if there are covering advertisementsin the advertisement table. If there are, then do not forward the advertise-ment.
2. If there is no covering advertisement, insert incoming advertisement in theadvertisement table and forward the advertisement to all neighbors.
3. Check if there are intersecting subscriptions in the subscription table. If thereare, forward the intersecting subscriptions to the neighbor from which theadvertisement was received.
4.3.3.2 Forwarding Subscriptions
Subscription processing is similar to advertisement processing. Given two subscrip-tions s1 and s2, s1 covers s2 if and only if all the publications that match s2 also matchs1. In other words, if we denote with E1 and E2 the set of publications that matchsubscription s1 and s2, respectively, then E2 ⊆ E1.
At the predicate level, the covering relation can be expressed as follows: Giventwo subscriptions s1 = {p1
1, p21, . . ., pn
1} and s2 = {p12, p2
2, . . ., pm2}, s1 covers s2 if
and only if ∀pk1 ∈ s1, ∃pj
2 ∈ s2 such that pk1 and pj
2 refer to the same attribute, andif pj
2 is matched by some attribute–value pair (a, val), then pk1 is also matched by the
same (a, val) attribute–value pair. In other words, s2 has potentially more predicatesand they are more restrictive than those in s1. Table 4.2 presents some examples ofsubscriptions and covering relations.
Informally, when a broker B receives a subscription s, it will send it to its neigh-bors if and only if it has not previously sent them another subscription s′, that coverss. Broker B will receive all publications that match s, since it receives all publicationsthat match s′ and the publications that match s are a subset of the publications thatmatch s′.
Table 4.2 presents some examples of subscriptions and the corresponding cover-ing relations. The goal of subscription covering is to quench subscription propagation,thereby reducing network traffic and trimming the size of subscription (i.e., routing)tables.
72 Mobility in Publish/Subscribe Systems
Table 4.2 Examples of Subscriptions and Covering Relations
The processing of the subscriptions at the publish/subscribe router then proceedsas follows:
1. For each incoming subscription, check if there are covering subscriptions inthe subscription table. If there are, then do not forward the subscription.
2. If there is no matching subscription, insert incoming subscription in the sub-scription table.
3. Check if there are intersecting advertisements in the advertisement table. Ifthere are, forward the subscription to those neighbors from which the matchingadvertisements were received.
4.3.3.3 Forwarding Publications
Finally, publications are processed as follows.
� For each incoming publication, check if there are matching subscriptions inthe subscription table. If there are, forward the publication to all the neighborsfrom which each of the matching subscriptions was received.
4.3.4 Publish/Subscribe Broker Network
To summarize, a number of publish/subscribe brokers can be organized into a content-based routing network. In such a network, one of the most important problems isthe routing of a publication to interested subscribers based on the content of thepublication. There are several routing protocols proposed in the literature, all of whichfollow the described publish/subscribe broker architecture to some extent [7, 10, 12].Some of them do not use advertisements and some of them do not perform subscriptioncovering.
Generally, the proposed solutions always involve a network of brokers thatcollaborate in order to route the information in the network based on its content.As shown in Figure 4.3, advertisements from publishers are flooded throughout thenetwork and stored at each broker’s routing table in order to build a distributedadvertisement tree. When a subscriber receives an advertisement, it sends intersectingsubscriptions along the reverse path of the advertisement tree. These subscriptions
4.4 Client Mobility 73
Figure 4.3 Distributed publish/subscribe.
are stored in the routing table of each broker along the subscription path and result ina distributed multicast tree. Finally, publications from a publisher follow the reversepath of all matching subscriptions (i.e., the multicast tree rooted at the publisher) andare delivered to interested subscribers.
In some distributed publish/subscribe systems, the message flow follows Fig-ure 4.3 conceptually but the details may differ. For example, protocols where brokersare implemented in mobile ad hoc networks [3, 24], wireless sensors networks [25],peer-to-peer networks [1, 19], or cyclic overlays [17] tweak their routing protocolsto exploit features or overcome limitations in their respective environments. In thischapter, however, we restrict ourselves to a traditional distributed publish/subscribesystem in which brokers are assumed to be relatively stable and form an acyclicoverlay as shown in Figure 4.3.
4.4 CLIENT MOBILITY
Cugola et al. were among the first to support mobility in distributed publish/subscribe systems [10]. They introduce the “movein” and “moveout” operations thatoffer clients the ability to disconnect from and reconnect to the system. However,these standard distributed publish/subscribe algorithms may not perform well whenthe clients in the system experience frequent mobility [5, 20]. Various algorithms toaddress client mobility are presented below. We distinguish between subscriber andpublisher mobility as the solutions to deal with each are different.
74 Mobility in Publish/Subscribe Systems
4.4.1 Subscriber Mobility
We first describe the subscriber mobility algorithm proposed by Cugola et al.,which we refer to as the standard algorithm [10]. Then we present a set of optimiza-tions to this algorithm.
4.4.1.1 Standard Algorithm
Figure 4.4 illustrates a timeline of a subscriber going into a period of disconnection andreconnecting to a different broker. During period t1, the client is connected to Broker 1and can receive events. At the end of period t1, the client disconnects from Broker 1 andreconnects after period t3 to Broker 2. Period t2 is used by an optimization describedin Section 4.4.1.2. Period t4 is required to complete the reconnection phase, whichinvolves retrieving and playing back events that the client missed while disconnected.Finally, during period t5, the client receives newly published events as in period t1.
The objective of the algorithm is to reconfigure the event multicast tree to accountfor client mobility. We assume the client always reconnects to its physically closestbroker. When a client disconnects from Broker 1, the broker begins to locally storethe events that the client would have received if it had been connected. If the clientreconnects to Broker 1, then the stored events are simply replayed to the client duringperiod t4. The more interesting case is when the client reconnects to some other broker,say Broker 2. The following steps take place during period t4:
1. Upon reconnection, the client notifies Broker 2 that it was previously connectedto Broker 1.
2. Broker 2 retrieves the subscriptions associated with the client from Broker 1.
3. Broker 2 subscribes to these subscriptions and then sends a REQUNSUB
message to Broker 1 requesting it to unsubscribe.
4. Broker 2 stores in a local queue new events it receives for the client.
t1 t3
t2
t4 t5
At broker 1 Disconnected
Disconnect(moveout)
Connect(movein)
At broker 2
Receivenew events
Figure 4.4 Mobile subscriber timeline.
4.4 Client Mobility 75
5. Broker 1 forwards stored events to Broker 2.
6. All the state has now been transferred from Broker 1 to Broker 2. Broker 2now replays both the events received from Broker 1 and the new events storedin its local queue, to the client.
In step 6, duplicates in the set of events transfered from Broker 1 and those in Bro-ker 2’s local queue are removed. This assumes duplicate events can be distinguished,with, for example, a publisher-specific event sequence numbers.
In step 3, to guarantee that no events are lost, we require that the common ancestorof Brokers 1 and 2 in the broker hierarchy sees the subscriptions from Broker 2 beforethe unsubscriptions from Broker 1. To simplify this step, we assume that the overlaybroker hierarchy is consistent with the underlying network hierarchy such that theshortest path between any two brokers in the overlay topology is the shortest path inthe underlying topology. We also assume that messages between brokers are receivedin the order they were sent, which is reasonable, as we expect TCP connectionsbetween brokers. Since Broker 2 sends the subscriptions followed by REQUNSUB,the common ancestor sees them in this order, and since the common ancestor is inthe shortest path between Brokers 1 and 2 in the overlay topology, Broker 1 seesREQUNSUB after the common ancestor, by our assumption. Thus, our requirementis met, and no events are lost. More elaborate schemes are possible in cases whereour assumption is not valid [6]. However, more complex algorithms likely increasethe state transfer costs and thus only worsen the overhead costs [20].
All the messages exchanged between the two brokers represent unicast messages.As we will see in the experimental section, the unicast messages contribute signifi-cantly to system overhead. Also, it is possible that cost of reconfiguring the multicasttree may be greater than the gains from having events take the shortest path.
We now describe several optimizations to the standard subscriber mobilityalgorithm.
4.4.1.2 Prefetching Algorithm
The prefetching algorithm exploits knowledge of future mobility patterns. It issimilar to the standard algorithm except that steps 2–5 (the transfer of subscriptionsand stored events) occur during period t2. In period t4, only step 6 (the replay ofstored events) takes place. Prefetching gains in two ways. First, the latency of thestate transfer from Broker 1 to Broker 2 is hidden from the user, since is occurs whilethe user is disconnected. This results in a shorter t4 period. Secondly, since statetransfer occurs early, there are very few stored events that Broker 1 needs to forward.Therefore, there are fewer messages transferred overall.
The effectiveness of prefetching depends on the successful prediction of theclient’s destination. To improve the likelihood of success, Broker 1 can predict the setof brokers that are likely to be the next destination of the mobile client. Broker 1 canmake this prediction based, for example, on statistics of the mobility patterns of itsclients. If the client reconnects to one of the predicted brokers, that particular brokerreplays all stored events and informs the other brokers to discard the stored events and
76 Mobility in Publish/Subscribe Systems
subscriptions for that client. If the client reconnects to a completely different broker,the new broker can contact the closest broker from the set of prefetched brokers,and the state transfer happens as in the standard algorithm. We do not evaluateprefetching to multiple brokers here.
4.4.1.3 Logging Algorithm
The logging algorithm exploits subscription locality (a measure of the similarityof subscriptions) in the system. Here, all brokers maintain a log of recently receivedevents. When the mobile client reconnects, Broker 2 scans its log for events of interestto the mobile client. Any relevant events found in the log do not need to be transferredfrom Broker 1.
The state transfer is similar to the standard algorithm. After Step 2, however,Broker 1 sends a message with the IDs of its stored events to Broker 2. Broker 2checks for these events in its log and sends any matched IDs to Broker 1 instructingit to not send these events during Step 5. By only transferring, in Step 5, those eventsnot already at Broker 2, the period t4 can be shorter than in the standard algorithm.However, if no such events exist, the wasted overhead of sending event IDs can makeperiod t4 longer. Thus, in terms of both message and latency costs, logging canperform better or worse than standard depending on the movement scenario andsubscription locality.
Logging requires that events have system-wide unique IDs. This can be easilyachieved if we consider that each publisher in the system has a unique ID and thatevents are ordered within the publisher. Thus, the ID for the event is composed fromthe ID of the publisher that sent it and a locally incrementing sequence number.
4.4.1.4 Home-Broker Algorithm
In this algorithm each client is assigned a home broker. Upon a movein operation,a client reconnects to its physically closest broker. The client, however, reconnectslogically to its home broker. Subscriptions remain on the home broker, which keepsreceiving events through the regular multicast mechanism. The home broker then for-wards these events to the client using unicast messages. The home-broker algorithmis designed to emulate handling mobility in a way similar to MobileIP [21].
Home-broker gains by not migrating subscriptions and rebuilding the multicasttree, at the expense of not sending events through the shortest path. Note that there isunicast traffic even when the client is connected.
4.4.1.5 Subscriptions-On-Device
Subscription migration is an important component of state transfer. If the mobiledevice has sufficient resources, it can locally store the subscriptions, and directlysend the subscriptions to the new broker upon reconnection. This way, the old brokerdoes not need to transfer the subscriptions to the new broker. The applicability of thismethod depends on the number of subscriptions that a client has, the resources of themobile device, and whether the user wishes to use more than one device.
4.4 Client Mobility 77
4.4.1.6 Discussion
It should be noted that these optimizations make minimal assumptions about theunderlying system. They can be used with any type of distributed publish/subscribesystem. Moreover, the optimizations can be combined. For example, subscriptions-on-the-device can be combined with prefetching or logging.
In an experiment with in which 800 subscribers commuting home at the endof the work day were simulated, we saw that the standard algorithm incurred analmost 80% overhead in terms of the overhead of the mobility algorithm [5]. Thismeans that introducing mobility to a network built with enough capacity to servicea non-mobile publish/subscribe system will require almost doubling the networkcapacity. Prefetching, by transferring state early, has almost no overhead in thisscenario, because the periods of disconnection are large and the traffic required tomigrate subscriptions is much smaller than the event traffic during the disconnectionperiod. Logging improves on standard by partially replacing unicast state transferwith multicast by leveraging logging and subscription locality. The home-brokeralgorithm fared the worst with an average overhead of up nearly 600%. Since thehome-broker algorithm works similar to MobileIP, the latter result indicates thataddressing mobility at the network layer is not feasible in such a scenario.
Figure 4.5 plots the total message costs (as opposed to relative overhead) ofthe above experiment. In the figure, the total messages incurred by each mobilityalgorithm are plotted in the four curves, and the impulses indicate the number ofdisconnected subscribers in the corresponding time period. First, we notice that theprefetching algorithm achieves almost optimal performance, with little increase inmessage load when subscribers are mobile compared to when they are stationary at
0
100000
200000
300000
400000
500000
600000
700000
800000
15:00 pm 16:00 pm 17:00 pm 18:00 pm 19:00 pm0
10
20
30
40
50
60
70
80
90
100
Tot
al n
umbe
r of
mes
sage
s
Num
ber
of s
tate
tran
sfer
s
Time
Standard Logging
Prefetching Home-broker
Figure 4.5 Subscriber mobility message cost.
78 Mobility in Publish/Subscribe Systems
the beginning and end of the experiment. We also note that the message costs ofthe other algorithms closely track the number of concurrent clients executing statetransfers, indicating that these state transfers are the primary cause of the increasedmessage load. This figure helps explain the dismal home-broker performance. Afterall clients have reconnected, the other three approaches have identical costs, sincethey rebuild the multicast tree and events are multicast to clients. With home broker,however, events are still unicast from the home broker to the client. This large andsustained unicast that persists even after reconnection is why home broker performspoorly.
The reader is referred to Ref. [5] for more details on the above as well as otherexperiments. The results indicate that the prefetching algorithm virtually eliminatesthe mobility overhead, while the logging algorithm can approach the performanceof the optimal prefetching algorithm in situations where the subscriptions exhibit ahigh degree of locality. This makes sense because when subscriptions express interestin similar publications, the publications cached in the logging algorithm for onesubscriber are more likely to be needed by other subscribers. The experiments alsoindicate that the home broker algorithm is almost always a poor choice.
4.4.2 Publisher Mobility
As described in Section 4.4.1, to support the disconnected operation of subscribers,brokers must store publications for the subscriber and replay them to the subscriberwhen it reconnects to the network. Unlike disconnected operation with subscribers,there is no information that the publisher has missed while disconnected, and hence itmay seem that publisher mobility is not a problem. However, this is not the case. It hasbeen shown that publisher mobility can generate significant overhead as advertisementtrees (which are broadcast throughout the network) need to be torn down and rebuiltevery time a publisher moves [20].
Below we describe the standard publisher mobility algorithm as well as someoptimizations that we propose.
4.4.2.1 Standard Algorithm
The timeline of a publisher going into a period of disconnection and reconnecting toa different broker is identical to Figure 4.4 except that after period t4 the publisherpublishes new events as opposed to receiving them. During period t1, the publisheris connected to Broker 1, the publisher rooted advertisement and multicast treeshave been built, and publications are correctly multicast to all interested subscribers.At the end of period t1, the publisher disconnects from Broker 1 and reconnectsafter period t3 to Broker 2. Period t2 is used by the prefetching and prefetch-delayed optimizations below. Period t4 is required to complete the reconnectionphase, which involves rebuilding advertisement and multicast trees. Finally, duringperiod t5 publications from the publisher are again correctly multicast to all interestedsubscribers.
4.4 Client Mobility 79
The objective of the publisher mobility algorithm is to reconfigure the advertise-ment and multicast trees to account for publisher mobility. We assume the publisheralways reconnects to its physically closest broker. When a publisher disconnects fromBroker 1, Broker 1 sends an unadvertisement message for any advertisements it hasreceived from the publisher. Note that these unadvertisements may induce unsubscrip-tions to be propagated in the reverse direction of the unadvertisement propagation (totear down the multicast tree) just as advertisements induce subscriptions to be sent.This tree teardown occurs during period t2 after which there is no state associatedwith the publisher in the system. At the end of period t3, the publisher connects toBroker 2, and upon reconnection sends its advertisements again. During period t4,the advertisement and multicast trees are rebuilt, and finally publications sent dur-ing period t5 are delivered to all interested subscribers. It is this mobility-inducedtree teardown and reconstruction that makes the traditional assumption that there areadvertisements invalid in this context.
Publications sent during period t4 may not be delivered to interested subscribers,since the multicast tree has not been rebuilt yet. However, in this algorithm, there isno way to know when period t4 is complete; Broker 2 does not know for certain whenthe multicast tree has been rebuilt. This is a fundamental problem arising from the de-coupling of publishers and subscribers in the publish/subscribe model; publishers donot know the set of subscribers that are interested in their content. In fact, no one nodeknows the set of participants in a given multicast tree. This problem is exacerbatedby the fact that it is difficult to distinguish between new subscriptions that enter thesystem shortly after the publisher moves in, and old subscriptions that simply arriveslowly at the publisher. The publish/subscribe semantics require the latter subscribersto receive publications from the publisher, while the former is allowed to miss somepublications until their subscriptions propagate through the system. Since the lengthof period t4 is unknown, we would like to minimize this period so as to minimizethe probability that a publication sent soon after reconnection is not delivered to aninterested subscriber.
4.4.2.2 Prefetching Algorithm
The prefetching algorithm exploits knowledge of future mobility patterns. It issimilar to the standard algorithm except that the advertisement and multicast treesare rebuilt during period t2 instead of period t4. Therefore, the length of period t4is now zero, and any publications sent immediately after reconnection are deliveredto interested subscribers. Note that t2 is the time it takes to rebuild trees, and isindependent of the disconnection time.
This algorithm has the advantage of hiding tree rebuilding time from the publisher,since it occurs while the publisher is disconnected. Also, since the old tree (rooted atBroker 1) is being torn down concurrently with the building of the new tree (rooted atBroker 2), it may occur that the new tree grafts onto the old tree before it is torn down,obviating the need to tear down the old tree completely. The delayed algorithm belowtries to force this case, which only occurs by chance in the prefetching algorithm.
80 Mobility in Publish/Subscribe Systems
4.4.2.3 Proxy Algorithm
The proxy algorithm is an extension of the prefetching algorithm. The assumptionhere is that publishers tend to move within a restricted area. For example, a taxidriver may service only certain regions of a city. (The taxi may be publishing locationupdates to a dispatcher or potential customers.) The proxy algorithm assigns a setof brokers to act as proxies for the publisher. These proxies always maintain a treefor the publisher. This way, there is no teardown or rebuilding of the tree when thepublisher disconnects from or connects to one of its proxies. However, tree rebuildingdoes need to occur if the publisher connects to a non-proxy broker.
4.4.2.4 Delayed Algorithm
The delayed algorithm exploits the fact that the old tree (rooted at Broker 1) and thenew tree (rooted at Broker 2) have significant overlap. This is especially true if Broker1 and 2 are nearby, as in the case of an always connected mobile publisher. In thedelayed algorithm, the teardown of the old tree at Broker 1 is delayed for some timeafter moveout. This time is to allow the publisher to reconnect to another broker,and graft the new publication tree to the old one. After the delay, the old broker tearsdown only the extraneous portions of the combined tree.
4.4.2.5 Prefetch-Delayed Algorithm
The prefetch-delayed algorithm is a combination of the prefetching anddelayed algorithms. As in the prefetching algorithm, prefetch-delayed initiatestree rebuilding at Broker 2 when the publisher disconnects from Broker 1, therebyhiding the tree reconstruction time from the publisher. However, since the tree rootedat Broker 1 is torn down concurrently with the construction of the tree rooted at Bro-ker 2, it may occur that the old tree is completely torn down before the new tree isbuilt. In the prefetch-delayed algorithm, the teardown of the old tree is delayed toallow the new tree to graft onto the old one. In this way, prefetch-delayed offersthe advantages of both the prefetching and delayed algorithms.
4.4.2.6 Discussion
These optimizations make minimal assumptions about the underlying system andcan be used with any type of distributed publish/subscribe system. Moreover, theoptimizations can be combined. For example, proxy can be combined with delayedto potentially achieve even better performance.
It is instructive to notice that the standard algorithm does not distinguish be-tween a moving publisher and a publisher that leaves and enters the system. Therefore,it discards all state (advertisement and multicast trees) associated with a publisher onmoveout, and must completely rebuild it on movein. Our optimizations addressthis issue.
4.4 Client Mobility 81
50 100 150 200 250
Publishers
Mes
sage
s (×
1000
)
600
500
400
300
200
100
0
StandardProxy
DelayedPrefdel
Figure 4.6 Publisher mobility message cost.
Since publisher mobility causes expensive reconstruction of advertisement andmulticast trees, it may be tempting to eliminate advertisement flooding and floodsubscriptions instead. However, subscribers typically outnumber publishers, so thesavings in publisher mobility-induced tree rebuilding cost do not justify subscriptionflooding. Furthermore, subscriber mobility will now cause multicast tree reconstruc-tion; this reconstruction is much more expensive than when advertisements are used,since the multicast trees now span the whole network rather than being a minimal treefrom the subscriber to interesting publishers.
Figure 4.6 shows the tree building message cost for the four mobility algorithmswith an increasing number of publishers. The details of this experiment can be foundin Ref. [20]. We see that while the cost of tree rebuilding grows approximatelylinearly for all the algorithms, there is a substantial difference in their costs. Thestandard algorithm has more than 10 times the message cost of the proxy,delayed, and prefetch-delayed algorithms. Standard performs poorly becauseevery moveout (movein) causes the entire advertisement and multicast trees forthe moving publisher to be torn down (rebuilt). While not shown here, the same is truefor prefetching but with an additional cost of having the old broker inform the newbroker to start rebuilding the tree. Therefore, prefetching is not building the newtree fast enough to graft onto the old tree that is being torn down. Since prefetchingdoes not offer any benefits that are not present in prefetch-delayed, we do notpresent results for the prefetching algorithm here in order to simplify the exposition.
Unlike the standard algorithm, the proxy, delayed, and prefetch-delayedalgorithms all graft onto existing trees. The reason delayed performs better thanproxy is because in delayed the old tree is rooted at a nearby broker (recall that thepublishers move along adjacent brokers), so the distance an advertisement must travelto graft onto an existing tree is short. In proxy, the distance to the old tree depends onthe position of the publisher relative to its fixed proxies. Prefetch-delayed has the
82 Mobility in Publish/Subscribe Systems
same message cost as delayed. The only difference between the two is that prefetch-delayed performs tree reconstruction earlier—during the publisher’s disconnectionperiod.
More experiments that analyze the various publisher mobility algorithms can befound in Ref. [20]. The results generally indicate that the prefetch-delayed andproxy algorithms perform the best, with the caveat that they require precise (in thecase of prefetch-delayed) or approximate (for the proxy) knowledge of futuremobility patterns. The delayed algorithm is worse than the above two algorithms,but does not require any mobility knowledge. The standard algorithm, however,performs quite poorly and should not be used to handle publisher mobility.
4.5 EXAMPLE APPLICATION
In this section, we describe how the publish/subscribe model can be used to implementan example scenario. While the previous section illustrated the performance of thepublish/subscribe system, here we point out the benefits of the model by showinghow the publish/subscribe messaging abstractions provide a simple and powerfulmechanism to achieve complex interactions among the various services.
We consider a scenario in which a municipality develops an integrated systemwhere information about its transportation infrastructure, including road conditions,highway traffic patterns, and transit operations. Such systems have been implementedby jurisdictions such as Georgia’s Department of Transportation and the Common-wealth of Pennsylvania. The goal of such a system would be to provide an integratedplatform where a rich, diverse, and large volumes of data can be filtered and deliveredto the interested parties in a flexible and efficient manner.
In our scenario, the information producing entities, or publishers, include sensorsthat monitor traffic volumes and speeds, citizens who can report on road congestionduring their commute, police officers who file electronic reports from the scene of anaccident or request for backup at a crime scene, or meteorological organizations thatsend important weather alerts. Correspondingly, subscribers include emergency re-sponse personnel that need to be notified of accidents on roads, taxi drivers that wouldlike to know about congested roads in their vicinity, or transportation departmentsthat wish to monitor traffic patterns in order to manage traffic flow.
Figure 4.7, presents a sample of possible publications and subscriptions thatvarious entities in this system might issue. The entities along the top are the publishersand the subscribers are at the bottom of the figure. In Figure 4.7, a police officerpublishes traffic reports, such as publication P1, that includes information about thenature and details of the accident. Motorists use their cell phone to notify the systemabout congestion they experience while driving as shown in publication P2, andthe local meteorologist sends weather alerts as in publication P3. The informationpublished into the system is used by various users such as paramedics who subscribeto S1 in order to be notified of any reports within their jurisdiction in which a seriousinjury has occurred, and to S2 in order to be notified of congested routes they shouldavoid while traveling to an emergency. Automobile dealerships may be interested in
4.5 Example Application 83
Figure 4.7 Publish/subscribe messages in a traffic reporting scenario.
accidents involving their vehicles, as shown in subscription S3. With subscriptionS4, tow truck operators will be notified of potential incidents where a tow truck maybe needed and of any weather alerts. Ordinary citizens wishing to be notified of anyemergency involving their friends or family would issue subscription S5, and sendS6 to receive severe congestion alerts.
The above example illustrates the complex interactions that are possible with thesimple content-based publish/subscribe model. First, we notice that the publicationsand subscriptions are relatively easy to construct and understand. Also, the decouplingof publishers and subscribers means that the publisher simply publishes informationwithout any regard for who should ultimately receive it, and subscribers indicate theirinterest without explicitly specifying the publishers from whom they should receivethe data. Notice that these simple, descriptive messages give rise to complex messag-ing patterns. For example, publication P1 matches subscriptions issued by all foursubscribers and is delivered to all of them, which is essentially a broadcast opera-tion in the scenario depicted in Figure 4.7. Meanwhile, publication P2 only matchessubscriptions S2 and S6, and is sent to two subscribers, which is a multicast opera-tion. Finally, publication P3 only matches subscription S4 and behaves like a unicasttransmission. From the subscriber’s point of view, we also see that some subscribersreceive data from multiple publishers, while other only interact with one publisher.The simple yet powerful publish/subscribe messaging abstraction achieves all theseinteractions patterns through the interplay among the subscriptions and publications.
84 Mobility in Publish/Subscribe Systems
We also note that subscribers are able to filter the data they receive, which isimportant in a system with large volumes of publications. Also notice that subscribersmay “address” their publishers in various ways, including based on location. Forexample, subscription S4 is only interested in accidents within a particular city. Muchmore complex location-based semantics are supported by extended content-basedpublish/subscribe languages [28].
All the publishers and subscribers in Figure 4.7 may be mobile, and the mobilityalgorithms in Section 4.4 can be employed by the broker network to transparentlymanage disconnected or intermittently connected users. For example, the subscriberon the bottom right may have turned off her PDA, but the publish/subscribe brokernetwork will store any accident reports of interest to her and deliver them to her whenshe eventually turns on the PDA. Such features provided by the publish/subscribeinfrastructure simplify application development.
4.6 SUMMARY
Mobile applications increasingly make use of network connectivity to provideenhanced services such as multiplayer games, mobile payment applications, andlocation-based services. The constraints of mobile devices, especially in terms oflimited or unreliable network connections, the large volumes of data that need tobe processed, and the complex interactions exhibited by some mobile applicationsrequire a communication infrastructure that addresses the requirements of these ap-plications and platforms.
The publish/subscribe messaging paradigm provides a simple yet powerfulabstraction that decouples the communication between providers and consumers ofdata. This decoupling is especially of benefit in mobile applications by hiding inter-mitted disconnections by mobile devices from the applications. Also, the powerfulfiltering capabilities provided by the model allow applications to receive only thosemessages of interest to them over the often expensive and limited wireless channelavailable to mobile devices. Furthermore, content-based publish/subscribe routingallows applications to devise sophisticated interactions in which applications can ad-dress devices using, among other ways, location-independent or location-dependentaddresses in a unified manner. In addition to the benefits of the publish/subscribemodel, distributed publish/subscribe systems have been shown to be scalable andalgorithms exist to handle the stresses of a highly dynamic mobile environment.
REFERENCES
1. I. Aekaterinidis and P. Triantafillou. Pastrystrings: a comprehensive content-based publish/subscribeDHT network. In ICDCS ’06: Proceedings of the 26th IEEE International Conference on DistributedComputing Systems, Washington, DC, USA. IEEE Computer Society, 2006, p. 23.
2. M. K. Aguilera, R. E. Strom, D. C. Sturman, M. Astley, and T. D. Chandra. Matching events ina content-based subscription system. In Symposium on Principles of Distributed Computing, 1999pp. 53–61.
References 85
3. S. Baehni and R. Guerraoui, and C. S. Chhabra. Frugal event dissemination in a mobile environment.In Gustavo Alfonso, editor, 6th International Middleware Conference (MIDDLEWARE 2005), LectureNotes in Computer Science Grenoble, France, vol. 3790, 2005, pp. 205–224, Springer.
4. S. Bhola, Y Zhao, and J S. Auerbach. Scalably supporting durable subscriptions in a publish/subscribesystem. In Proceedings of the International Conference on Dependable Systems and Networks (DSN2003). IEEE Computer Society, 2003, pp. 57–66.
5. I. Burcea, H.-A. Jacobsen, E. de Lara, V. Muthusamy, and M. Petrovic. Disconnected operation inpublish/subscribe middleware. In International Conference on Mobile Data Management (MDM),2004.
6. M. Caporuscio, A. Carzaniga, and A. L. Wolf. Design and evaluation of a support service for mobile,wireless publish/subscribe applications. IEEE Trans. Software Eng., 29(12):1059–1071, 2003.
7. A. Carzaniga, D. S. Rosenblum, and A. L Wolf. Design and evaluation of a wide-area event notificationservice. ACM Trans. Comput. Syst., 19(3):332–383, 2001.
8. A. K. Y. Cheung and H.-A. Jacobsen. Dynamic load balancing in distributed content-based pub-lish/subscribe. In ACM/IFIP/USENIX 7th International Middleware Conference, Melbourne, Australia,2006. ACM/IFIP/USENIX, ACM.
9. P. Costa, M. Migliavacca, G. P. Picco, and G. Cugola. Epidemic algorithms for reliable content-basedpublish-subscribe: an evaluation. In ICDCS ’04: Proceedings of the 24th International Conference onDistributed Computing Systems (ICDCS’04), , Washington, DC, USA. IEEE Computer Society, 2004,pp. 552–561.
10. G. Cugola, E. Di Nitto, and A. Fuggetta. The JEDI event-based infrastructure and its application to thedevelopment of the OPSS WFMS. IEEE Trans. Software Eng., 27(9):827–850, 2001.
11. F. Fabret, H.-A. Jacobsen, F. Llirbat, J. Pereira, K. Ross, and D. Shasha. Filtering algorithms andimplementation for very fast publish/subscribe systems. In Proceedings of ACM SIGMOD, 2001.
12. E. Fidler, H.-A. Jacobsen, G. Li, and S. Mankovski. The PADRES distributed publish/subscribe system.In International Conference on Feature Interactions in Telecommunications and Software Systems(ICFI), Leisester, UK, 2005.
13. S. Hu, V. Muthusamy, G. Li, and H.-A. Jacobsen. Transactional mobility in distributed content-basedpublish/subscribe systems. In 29th IEEE International Conference on Distributed Computing Systems(ICDCS), Montreal, Canada, 2009.
14. R. S. Kazemzadeh and H.-A. Jacobsen. Reliable and highly available distributed publish/subscribeservice. In Symposium on Reliable Distributed Systems, Niagara Falls, New York, 2009.
15. G. Li, A. Cheung, S. Hou, S. Hu, V. Muthusamy, R. Sherafat, A. Wun, H.-A. Jacobsen, and S. Manovski.Historic data access in publish/subscribe. In Proceedings of the Inaugural Conference on DistributedEvent-Based Systems, , New York, NY, USA, ACM Press, 2007, pp 80–84.
16. G. Li, S. Hou, and H.-A. Jacobsen. Routing of XML and XPath queries in data dissemination networks.In Proceedings of the 28th International Conference on Distributed Computing Systems (ICDCS’08).IEEE Computer Society Press, 2008.
17. G. Li, V. Muthusamy, and H.-A. Jacobsen. Adaptive content-based routing in general overlay topologies.In ACM Middleware, Leuven, Belgium, 2008.
18. D. McCarthy and U. Dayal. The architecture of an active database management system. In Proceedingsof the 1989 ACM SIGMOD International Conference on Management of Data. ACM Press, 1989, pp.215–224.
19. V. Muthusamy. Infrastructureless Data Dissemination: A Distributed Hash Table Based Pub-lish/Subscribe System. PhD Thesis, University of Toronto, 2005. (Also available as a Technical Report.)
20. V. Muthusamy, M. Petrovic, and H.-A. Jacobsen. Effects of routing computations in content-basedrouting networks with mobile data sources. In International Conference on Mobile Computing andNetworking (MobiCom), Cologne, Germany, 2005.
21. C. E. Perkins and D. B. Johnson. Mobility support in IPV6. In MobiCom ’96: Proceedings of the 2ndannual international conference on Mobile computing and networking, New York, NY, USA, ACM,1996, pp. 27–37.
22. L. I. W. Pesonen and D. M. Eyers. Encryption-enforced access control in dynamic multi-domainpublish/subscribe networks. In Proceedings of the Inaugural Conference on Distributed Event-BasedSystems, New York, NY, USA. ACM Press, 2007, pp. 104–115.
86 Mobility in Publish/Subscribe Systems
23. M. Petrovic, I. Burcea, and H.-A. Jacobsen. S-ToPSS: a semantic publish/subscribe system. In Inter-national Conference on Very Large Databases (VLDB), Berlin, Germany 2003.
24. M. Petrovic, V. Muthusamy, and H.-A. Jacobsen. Content-based routing in mobile ad hoc networks.In MOBIQUITOUS ’05: Proceedings of the the Second Annual International Conference on Mobileand Ubiquitous Systems: Networking and Services, Washington, DC, USA. IEEE Computer Society,2005, pp. 45–55.
25. M. Petrovic, V. Muthusamy, and H.-A. Jacobsen. Managing automation data flows in sensor/actuatornetworks. Technical report, Middleware Systems Research Group, University of Toronto, Toronto,Canada, 2007.
26. A. Wun, A. Cheung, and H.-A. Jacobsen. A taxonomy for denial of service attacks in content-basedpublish/subscribe systems. In Proceedings of the Inaugural Conference on Distributed Event-BasedSystems, New York, NY, USA. ACM Press, 2006, pp. 116–127.
27. A. Wun and H.-A. Jacobsen. A policy framework for content-based publish/subscribe middleware. InGustavo Alonso, Eyal de Lara, Indranil Gupta, and Ramses Morales, editors. ACM/IFIP/USENIX 8thInternational Middleware Conference, Lecture Notes in Computer Science (LNCS). Springer-Verlag,Vol. 4834, 2007.
28. Z. Xu and H.-A. Jacobsen. Expressive location-based continuous query evaluation with binary decisiondiagrams. In IEEE International Conference on Data Engineering (ICDE), 2009.
29. Z. Xu and H.-A. Jacobsen. Adaptive location constraint processing. In Proceedings of the InternationalConference on Management of Data (SIGMOD 2007). ACM, 2007 pp. 581–592.
30. Z. Xu and H.-A. Jacobsen. Evaluating proximity relations under uncertainty. In Proceedings of 23rdInternational Conference on Data Engineering (ICDE). IEEE Computer Society, 2007.
