mobil-ity patterns into account by transferring the state while the user is mo-bile. With logging, the brokers maintain a log of recent events and only those events not found in the log need to be transferred from the old lo-cation. The home-broker approach involves a designated home broker that buffers events on behalf of the client. This approach has extra messaging costs when retrieving buffered events. Subscriptions-on-device stores the subscription status on the client so it is not necessary to contact the old broker. In this study the cost of reconfiguration was dominated by the cost of forwarding stored events (through the event routing network).
The cost of publisher mobility has also been recently addressed [96, 97].
They start with a basic model for publisher mobility that simply tears down the old advertisement and establishes it at the new location after mobility.
Thus a specific handover protocol is not needed. They confirm the high cost of publisher mobility and present three optimization techniques, namely prefetching,proxy, anddelayed. The first exploits information about future mobility patterns. The second uses special proxy nodes that advertise on behalf of the publisher and maintain the multicast trees. The third delays the unadvertisement at the source to exploit the overlap of advertisements, but does not synchronize the source and target brokers. The publisher mobility support mechanisms used in the study are not necessarily mobility-safe.
5.4 Generic Mobility Support
The Siena event system was extended with generic mobility support, which uses existing pub/sub primitives: publish and subscribe [22, 24].
The mobility-safety of the protocol was formally verified. The benefits of a generic protocol are that it may work on top of various pub/sub systems and requires no changes to the system API. On the other hand, the performance of the mobility support decreases, because mobility-specific optimizations are difficult to realize when the underlying topology is hidden by the API.
Indeed, in this section we show that a general API-based pub/sub mobility support may have a very high cost in terms of message exchanges.
The Siena generic mobility support service, the ping/pong protocol, is implemented by proxy objects that reside on access routers. Figure 5.1 presents an overview of the process: 1. the client arrives to access pointB from A and sends the move-in request to the new local proxy. 2. a ping request is sent and a response will be eventually received (3) from the old
proxy. The response can also be called apong. The pong message ensures that subscriptions are fully propagated from B to A. 4. the client sends a download request for buffered events and 5. the buffered events are sent to the proxy. Finally, in 6. the client receives the messages and duplicates are removed.
move-out proxy
move-in proxy
A B
Client 1. move-in
request 2. ping request
3. ping reply 4. download
5. buffered events
6. messages, merge queues
Figure 5.1: Move-in function in mobility support service.
The mobility protocol proceeds in four distinct phases: first, the target subscribes to the relocated events, then the target and source synchronize by sendingping and pong events in order to ensure that the subscriptions have taken effect, the source unsubscribes, and finally any buffered events are relocated. In addition, there may be further costs triggered by changes in the subscription tables of the intermediate routers. The cost structure of the procedure is given by Table 5.1 as the number of brokers that will be updated during each phase. N denotes the total number of brokers and n the number of brokers on the path from source to destination. For advertisement semantics we assume that the publication of a ping message also includes the advertisement. The unsubscription cost also depends on other active subscriptions on the servers and is a worst-case estimate.
For subscription semantics the basic problem with the ping/pong
syn-5.4 Generic Mobility Support 79
Table 5.1: Cost structure for generic mobility.
Phase Sub semantics Adv semantics
Source: Subscribe Ping(id) N
-Target: Subscribe Filters [0, N] [0, N]
Target: Subscribe Pong(id) N
-Target: Publish Ping(id) n + periodic N
Source: Publish Pong(id) n N
Source: Unsubscribe Ping(id) N n Target: Unsubscribe Pong(id) N n Target: Unadvertise Ping(id) - N Source: Unadvertise Pong(id) - N
chronization protocol is that the signalling messages are guaranteed not to be subscribed by other brokers on the network and hence the subscription messages will be introduced at every broker on the network. With adver-tisements, the protocol works in a similar fashion, but the ping and pong messages need to be advertised, which also requires flooding the network.
If the client relocates faster than the ping message is propagated, it has to wait until the target receives the ping subscription. This requires that the pub/sub API allows to query the subscription status of the broker.
The Siena support service does not require specific API support, because the ping messages are continuously resent [24], but this kind of behaviour further burdens the network. The ping is published by the target along with the pong subscription and they will reach the source, which replies with the pong event. It is clear that when the pong reaches the target the subscription is established between the source and target.
Publisher mobility for subscription semantics does not require addi-tional handover funcaddi-tionality, since it is supported directly by the pub/sub system. Publisher mobility for advertisement semantics follows the above model and has a similar cost structure. If changes are allowed to the rout-ing behaviour the prout-ing/pong phase may be optimized by propagatrout-ing an update message from source to target on the reverse path of the target’s advertisement.