publishers increases. The new advertisements require a moderate amount of additional messaging. The number of publishers did not have a significant effect on the rendezvous point-based protocols. This was expected, because the RP constrains the topology and flooding does not occur.
0 2000 4000 6000 8000 10000 12000 10 20 30 40 50 60 70 80 90 100 Messages Publishers Signalling cost
In.Acyclic border only In.Acyclic+RP border only Co.Acyclic border only Co.Acyclic+RP border only
In.Acyclic any In.Acyclic+RP any Co.Acyclic any Co.Acyclic+RP any
Figure 5.14: Simulation results for a variable number of publishers.
5.9
Engineering Implications
The presented discrete formal model for both subscriber and publisher mo- bility allows us to gain valuable insight into the engineering of efficient and mobility-safe publish/subscribe protocols. Typically the mobility-safety of pub/sub protocols has not been established, and indeed we have observed that some implementations do not guarantee this. Yet, receiving every message is important for many signalling applications. We have presented a formal foundation for pub/sub mobility, which may also be used with the subscriber and publisher mobility strategies, such as the prefetching and proxy protocols proposed in [17, 97].
From the analysis presented in this chapter we can draw the following design principles, which are important for engineering efficient mobility-safe pub/sub systems:
• The generic protocol is mobility-safe and applicable to various under- lying pub/subs systems, but it is very inefficient and does not allow pub/sub system or topology-specific optimizations. We note that the mobility-safety of this mechanism requires that the ping/pong inter- action is sufficient to establish the completeness of the path or paths.
• The general acyclic graph-routing topology is more efficient than the generic protocol, but suffers from the problem that the source broker needs to be located using event routing. Since covering and merg- ing do not preserve information pertaining to the original broker that issued a subscription or advertisement, the use of content-based flooding may be required. This routing topology also suffers from the incompleteness of subscriptions, and thus the covering optimiza- tion that uses out-of-band communication cannot be performed if mobility-safety is required. Incompleteness may also cause a broker to flood subscriptions to several exit interfaces. Incompleteness of the subpath from the source broker to the destination broker may be corrected, but it has a high cost due to potential content-based flooding.
• Rendezvous point models with cyclic overlay routing support better coordination of mobility. With rendezvous points, advertisements are no longer flooded throughout the network, which improves update la- tency and performance. Moreover, rendezvous points may be used for fast completeness checks. The covering optimization may be used with completeness checking. Furthermore, the overlay address may be used to prevent content-based flooding by consulting the overlay routing tables and finding the proper next hop. On the other hand, the upper bound cost for cyclic topologies may be higher than for gen- eral acyclic graphs if the moving subscriber has subscribed to multiple rendezvous points that have to be updated.
• Rendezvous point models with acyclic overlay routing have the sim- plifying features mentioned above and the upper bound cost cannot be greater than for the general acyclic graphs.
Therefore we propose the following three techniques for improving mo- bility support in pub/sub systems: overlay-based routing, rendezvous points, and completeness checking. Overlay addresses prevent the content-based flooding problem. This abstracts the communication used by the pub/sub system from the underlying network-level routing and allows the system to cope with network-level routing errors and node failures. Rendezvous
5.9 Engineering Implications 103
Table 5.5: Optimizations for pub/sub handovers. Optimization Description
None Flooding of update messages. Overlay addresses No flooding of update messages. Rendezvous points Completeness checking to RP.
Covering optimization If update received (make-before-break) or complete (break-before-make).
points simplify mobility by allowing better coordination of topology up- dates. There is only one direction where to propagate updates for a single rendezvous point. Completeness checking ensures that subscriptions and advertisements are fully established (complete) in the topology. This is needed to perform the covering optimization. Table 5.5 presents a summary of the optimizations and how they may be applied for the two handover types: network-initiated make-before-break and break-before-make.
We give an outline of the subscriber handover algorithms both at the source (Algorithm 7) and destination (Algorithm 8). We assume that an overlay addressing system is used that allows each broker to deduce in which direction (outgoing interface) a given server is located. This prevents the flooding of control messages. The algorithms support both make-before- break and break-before-make. The algorithms take three parameters: C is a structure that stores information pertaining to the client, src is the identifier of the source broker, and dst is the identifier of the destination broker.
Algorithm 7 support different modes of operation. First, it supports the RP-based operation and checks the completeness to the RP using the check- RP-CO procedure. Second, if make-before-break is used, the algorithm uses the procedure send-path-update to send a path update towards the destination. Third, if the basic break-before-make protocol is used, the algorithm simply disconnects the client. Fast handovers are detected using the waiting-for-update procedure, which returns true if the given broker is waiting for the update message.
Algorithm 8 presents move-in functionality for these three modes of operation. The skip variable indicates whether or not the path between source and destination needs to be updated. If make-before-break is used, the algorithm checks if the update message has been received using the procedure rcv-update. If the update has been received and the state has been already transferred, the protocol may terminate. Otherwise, the al-
gorithm skips the topology update and uses the send-transfer-request to send a state transfer message to the source. If the update has not yet been received, the protocol has to wait until the message is received. The procedure wait-for-update adds the current client into a list of unfinished updates.
If RPs are used in Algorithm 8, the update message is sent only to the RP in question using the procedure send-update-RP. When receiving the update, the RP notifies the source that the path is complete. If RPs are not used, the update is sent to the source using the procedure send-update. For break-before-make, the procedure sub-complete is used to check if the relocated subscription is already complete at the destination.
Algorithm 7 The move-out-sub algorithm.
move-out-sub(C, src, dst)
1 if waiting-for-update(src,dst,C) 2 then
3 Fast handover detected, prevent transfer of session 4 return
5 if dst = ∅ and RPs are used 6 then
7 Wait until check-RP-CO(src,dst,C) is true 8 elseif dst 6= ∅
9 then send-path-update(src,dst,C)
10 Wait for response for client-initiated make-before-break 11 C.dst ← dst
12 C.src ← src 13 Disconnect client.
The publisher mobility algorithms are similar to the subscriber mobil- ity algorithms. The move-out-pub algorithm follows Algorithm 7 with the exception that no state is transferred. If RPs are used, completeness to the RP is checked before relocation. If make-before-break is used, the update message is sent by the source broker. In this case, the path is updated by the message and only the direction from source to the destination needs to be tested.
The move-in-pub follows Algorithm 8. If it is known that the path is complete, the protocol terminates. If make-before-break is used, the reception of the update message indicates that the path is complete and
5.9 Engineering Implications 105
Algorithm 8 The move-in-sub algorithm.
move-in-sub(C, src, dst) 1 let skip = false
2 if C.dst = ∅ break-before-make 3 then
4 if sub-complete(C) 5 then skip ← true 6 else
7 if rcv-update(src,dst,C) 8 then skip ← true
9 if state has already been transferred
10 then return
11 else
12 wait-for-update(src,dst,C) and return 13 if (¬skip)
14 then
15 Send update or out-of-band transfer request 16 Update will result in a state transfer
17 if RPs are used
18 then send-update-RP(src,dst,C) 19 else send-update(src,dst,C) 20 else send-transfer-request(src,C)
the protocol terminates. If RPs are used, the protocol waits until the RP has confirmed that the path is complete. When the message from the RP arrives, the destination broker knows that any active subscriptions have been connected. If RPs and make-before-break are not used, the protocol sends an update message to the source broker. The protocol terminates when a reply is received from the source broker.