DisGB: Using Geo-Context Information for Efficient Routing in Geo-Distributed Pub/Sub Systems

Proceedings of the 7th IEEE/ACM International Conference on Utility and Cloud Computing 2020 (UCC 2020). IEEE 2020.

Jonathan Hasenburg and David Bermbach

Explanations and help text are at the bottom of the page. Choose a projection and then try dragging the visualization!

Choose strategy visualization:

Load local file:

Choose projection of data:

Choose width of visualization (commit with Enter):

Legend:

Lambda (Yaw):		Value:
Phi (Pitch):		Value:
Gamma (Roll):		Value:

Topic Table

Help

This page can be used to visualize broker setups from the rendezvous point (RP) selection strategy simulation using d3.js. The simulation is part of the DisGB: Using geo-context information for efficient routing in geo-distributed pub/sub systems paper that is currently under review for the Middleware 2020 conference. The visualizer can read the simulation's setup files (filenames end with _broker) and project their content onto a globe for easier spatial visualization. The globe can be rotated by dragging it with the mouse or through the sliders below the globe. The projection can also be changed to, e.g., the Mercator projection and others via a dropdown menu.

Depending on the chosen RP selection strategy, the simulation shows different kinds of data. The legend below the simulation is updated accordingly; more details on the RP selection strategies can be found below and in the paper.

The simulation setups that can be selected via the drow down menu are the ones used in the paper (100,000 clients, 25 broker). It is also possible to visualize your own simulation setups by selecting a local file. This file can then be visualized by choosing local data in the dropdown menu.

RP Selection Strategies

Please see the paper for full information.

Flooding events (Flood_E)

Every broker is an RP for every event. When an LB of a publisher receives an event, it distributes it to all other brokers. After matching this event, brokers can deliver the event to their local subscribers directly.

For this strategy, the visualization shows for each broker its location and the area in which its clients might be located.

DisGB: Selecting RPs close to the subscribers (DisGB_E)

The RPs for an event are all brokers that are the respectively closest broker to each of the subscribers that have created a matching subscription. Thus, the RPs are the LBs of these subscribers. Hence, subscriptions are not distributed to other brokers as subscribers create subscriptions at their LB. The event, on the other hand, is distributed to all brokers which could possibly manage a matching subscription (hence, DisGB_E). The event geofence can be used to select these RPs because only broker areas intersecting with the event geofence might contain clients that pass the event GeoCheck (subscriber location inside event geofence).

For this strategy, the visualization shows for each broker its location and broker area.

Flooding subscriptions (Flood_S)

The LB of a publisher is the only RP for a given event. When an LB of a subscriber receives a subscription update, it distributes it to all other brokers. After matching an incoming event, the broker might have to notify remote brokers about successful matches so that they can deliver the event to their local subscribers. This is necessary, as each client is only communicating with its LB.

For this strategy, the visualization shows for each broker its location and the area in which its clients might be located.

DisGB: Selecting RPs close to the subscribers (DisGB_S)

With this strategy, the RP for an event is the broker closest to the publisher of that event. Thus, the RP is the LB of the publisher. While this means matching only occurs at a single broker, it also implies that all subscriptions must be distributed to all brokers to which a matching event might be published (hence, DisGB_S); subscription updates must also be propagated in a similar fashion. The subscription geofence can be used to select these RPs because only broker areas intersecting with the subscription geofence might contain clients that pass the subscription GeoCheck (publisher location inside subscription geofence).

For this strategy, the visualization shows for each broker its location and broker area.

Consistent hashing (DHT)

This strategy is used by pub/sub systems that rely on distributed hash tables (DHT) such as Scribe or Hermes. The RP is determined by mapping the event and subscription topics to a particular broker with consistent hashing. Once an RP has matched the event, it notifies the LBs of matching subscribers about successful matches to that they can deliver the event to their local subscribers.

For this strategy, the visualization includes a table showing all the brokers and the topics that map to them. The visualized brokers are also colored according to how many topics they handle. The colormap includes six colors that are assigned to equally sized buckets of topics in the interval [0,highest individual topics]. Brokers on the visualization can be clicked, which highlights the corresponding row of the table.

Grid Quorum (GQPS)

To determine RPs, an application-level overlay network is created that makes each broker addressable by a position in a grid, i.e., by its row and column. RPs are all brokers in the same row or column as the LB, so this is where events and subscriptions must be distributed. After matching an event, the RP notifies the LBs of matching subscribers that have not been in the same row/column as the LB of the publisher about successful matches.

For this strategy, each broker in the visualization can be clicked. This highlights every broker that is part of the quorum.

Broadcast groups (BG)

Physically close brokers organize themselves in broadcast groups in which events are flooded to other group members for matching, i.e., all group members of a publisher’s LB (local broker) are an RP. Furthermore, one broker of each broadcast group (the leader) aggregates and forwards events and subscriptions originating in its group to a centralized cloud broker. The cloud broker matches events with subscriptions created by other leaders, therefore, it is also an RP. If an event is matched successfully at the cloud broker, every member of the corresponding broadcast group also becomes an RP for this event to match and deliver it.

For this strategy, the visualization includes information on which brokers are leaders and which are members. All brokers located in an area of the same color are part of the same broadcast groups.