Cycle Detection in Publish/Subscribe Overlay Networks

1. Cycle Detection inPublish/Subscribe Overlay Networks Reza SherafatAlex CheungProf. Cristiana Amza ECE1747 – Course Project University of Toronto

2. 1. Advertise Publisher 3. Publish Subscriber 2. Subscribe Overview of Publish/Subscribe Systems Network consists of • Clients: Publisher, subscriber • Routing brokers Overlay may be cyclic, non-cyclic

3. Advertisement Tree 1 Advertisement Tree 2 1 S S S S S Duplicate Messages 2 Cyclic Overlay Networks • Supporting cycles is good: • Load balancing • Hard to avoid • Failure recovery • Routing through cycles is challenging: • Duplicates waste bandwidth • Infinite loops

4. Outline • Routing in cyclic overlay • Cycle detection algorithm • Implementation • Future work

5. Routing Through Cycles Preparation: • Detect cycles • Let brokers know that they are on cycles • Keep cycle information updated Routing: • Route advertisements in a cycle-free manner • Route subscriptions in a cycle-free manner • Keep track of brokers downstream • Route publications in a cycle-free manner • Use cycle information and source routing to exploit cycles

6. Cycles • Large cycles are bad candidates for re-routing • Alternative paths may be too long • We focus on cycles smaller than a configurable size s. • Better choices for our purposes • Easier to detect Cycles detection algorithm, detects such small cycles.

7. Cycle Detection Algorithm We want to detect all cycles smaller than s+1 • Based on Asynchronous Breath-First Search • Starting from a Heart broker propagate special messages • Append broker’s id to the message and send it to neighbors • When a duplicate is received, there is a cycle • Compare broker id lists to find members • Inform all members of the cycle Delays in message delivery are problem some

8. Propagate Compare s=5L=4 Ad1: b1 Ad1:b1,b5 Ad1:b1,b2 Ad1:b1,b2,b3,b4,b5 Ad1:b1,b2,b3 Ad1:b1,b2,b3,b4 • b1,b5 • b1,b2,b3,b4,b5 Cycle Detection Algorithm

9. Cycle Detection Algorithm • By limiting the size of cycles we lower the overhead • Broker id list will be at most s-1 • Problem when the “small” cycle is far away from the Heart • Because broker id list is too short • Hearts must not be far away • Hearts roughly partition the network into local areas Heart … … A small cycle is not discovered We have to limit the depth d that messages are propagated.

10. Cycle Detection Algorithm Distance from Heart • Roughly speaking we propagate Heart’s messages to double the cycle size (2s) in order to detect whether a broker within distance s (local)is on a cycle. • Hence s brokers in each direction away have a local broker’s id • s-1 is sufficient for broker id lists • Zones: • Full discovery zone • Partial discovery zone Full Discovery zone(local) Partial discovery zone

11. Cycle Detection Algorithm • Scalability • Heart messages are propagated limited # of hops away • Broker id lists have at most s-1 ids • Each Heart locally detects cycles • We need to place hearts side by side (Future work)

12. Implementation • Based on pub/sub semantics • Message class LOOP_DETECTOR • Command attribute: control, path, loop • Loop detection module • An add-on to brokers • Process LOOP_DETECTOR publications using separate queues • Extensions to the pub/sub semantics • Source routing • Distance-aware

13. Implementation • Path information is part of publication’s payload • Brokers subscribe to LOOP_DETECTOR messages • Received messages are put into the loopdetector’s queue • Major new classes: • LoopDetector • LoopDetectorManager

14. Future Work • Heart placement We need to place hearts side by side • Implement routing algorithm With load balancing • Implement fault recovery algorithm By using alternative paths formed in cycles