The DCC structure management approach enables one to impose a hierarchy upon any underlying structured P2P-network. For this purpose, it uses only send and receive methods. Every overlay node represents one person in the disaster manage-ment, with her/his specific rank in the chain of command. The overlay node knows its rank and fills the corresponding position within the hierarchy. The rank and the position of a node in the hierarchy are represented by an unique label. The label of the peer with highest position, i.e., the root, contains one or more alphanumeric symbols. The label of each subordinate peer is composed from the label of the preceding peer, a dot and one or more alphanumeric symbols. For simplicity, we just used one decimal digit for each position. Figure 8.2 represents an exemplary scheme. The hierarchy does not necessarily need to be a completely balanced tree or to have a symmetric structure. Depending on the desired staff-line, organization leaves may be placed in different depths. The prefix values in the label of each node describe its path to the root. This path can be used for different purposes: to contact superior nodes, for targeted communication with a specific node through a common
superior node or to monitor the direct superior node and apply for its position in a case of failure.
position: 0
position: 0.2 position: 0.0
position: 0.1
position: 0.2.0 position: 0.2.2 position: 0.2.1
position: 0.1.0 position: 0.1.1
C
Figure 8.2: Example of staff-line hierarchy on top of a DHT-network
8.3.1 Joining
We use a DHT to build the staff-line organization. The position in the hierarchy is the key, and the value is the address of the corresponding peer. Assume that a new nodeAtries to join the network, as specified in the P2P network overlay. AfterA is connected to the network, it has to allocate its position within the hierarchy. To achieve that,Ahashes its rank with a hash function known to all peers, to generate a network ID. LetBbe the overlay node, responsible for the ID generated byA.
That is,Badministrates the positionPwithin the hierarchy, which corresponds to A’s rank. Asends a request to take positionPtoB. The request contains: the rank ofA, its address and the desired position. NodeAreceives a positive reply ifPis vacant, or if the node currently occupyingPis less appropriate thanA. Otherwise, Bresponds with information about the nodeXoccupyingP: its rank, its address and its position (P). ThenAsends a request toXand so on, untilAfinds its position within the hierarchy. OnceAhas found its position, it also knows its direct superior peer.
For communication within the network, it is sufficient if every peer knows its superior and its subordinate peers. However, if necessary, any peer can locate any other peer within the hierarchy. Consider Figure 8.2 again and assume that a peer C (position 0.1.1) wants to communicate with a remote peer (e.g., position 0.0).
C knows that its position is one level below the position it is searching for: the position ofChas three dots, i.e. is on level three, and the desired position only two, i.e., is on level two. Therefore,Csends a message to its superior, telling it thatC seeks a peer on a given position. Then, the superior node ofCdecides on its turn, depending on its position and the requested position, whether to redirect the request to its superior or to one of its subordinate nodes. Once the requested position has been reached, a positive message is sent back along the chain. In other words, the hierarchy of the peers is used to target messages precisely. Furthermore, each peer has to make only locally based decisions.
In order to keep the hierarchy consistent, each peer occupies the most superior
vacant position, even if this position does not directly corresponds to the peer’s rank.
Once the correct or more appropriate peer appears, the currently occupying peer goes down the hierarchy tree. In the following, we call a hierarchy without gaps a correct hierarchy.
8.3.2 Hierarchy Maintenance
P2P networks are like living systems; peers join, leave or even crash all the time.
These three processes are generalized under the term churn. The network overlay and the hierarchy have to be robust against churn. The self-reorganizing capabilities of P2P networks provide a stable basis for DCC. The exact manner depends on the concrete overlay, but they all can effectively detect and handle new, crashed and leaving peers. Once the underlying network has been repaired, the hierarchical structure also has to be adapted. A crashed or leaving node means a gap in the hierarchy. This gap has to be filled by a subordinate peer. However, this in turn produces a new gap, until the repairing peer happens to be on the bottom most level of the hierarchy tree. The same situation emerges when a peer joins the network.
It has to be placed in the most appropriate position. This, however, could mean that some peers must be demoted, until again a bottom peer has been reached.
Nevertheless, in both cases, it is only one single path within the hierarchical tree that is affected. In the worst case, the number of overall affected nodes scales as O(logd(N)), whereN is the number of peers in the network anddis the number of subordinate peers per node. More importantly, the hierarchy always remains consistent. It is simply about redistributing hierarchical positions.
In order to detect and react to churn, our mechanism periodically checks whether the peer managing a given position is still the same. If it has changed, the proposed mechanism just routes a message to the new peer. Routing messages are also periodically sent to the superior peer to determine whether it has changed or whether the position is not suddenly vacant.
8.3.3 Messages
DCC sticks to the key-based routing interface (KBR) [DZD+03] of the underlying P2P network. DCC uses a set of four different messages to communicate with the underlying network and other applications running on top of it. In this section, we describe the structure and the purpose of those messages:
• position request message
• accept position request message
• position information message
• quit position message
50 100 150 200 250 300 350
0 200 400 600 800 1000
Steps required to reestablish hierarchy
Number of peers added to the network Steps to reestablish hierarchy in Chord
Figure 8.3: Reestablished hierarchy after node join in Chord
In case a node wants to take a position within the hierarchy, for example, to join the hierarchy or to occupy a more appropriate position, a position request message is routed. The message contains: the sender’s rank, the sender’s desired position and the sender’s address. The message is sent to the peer responsible for the network ID corresponding to the desired position. If the requesting node can fill its desired position, it receives an accept position request message. The message contains the sender of the message and the position. If another node holds the desired position and is more appropriate, the requesting node receives a position information message. A position information message contains: the sender, the position, the address and the rank of the node holding the position. The requesting node must select another position in the hierarchy, generally a subordinate position.
A node may also have to quit its position, if another more appropriate node request its position. The receiver acknowledges the request and sends back a quit position message. This message contains the sender and the position. Afterwards, the requesting node starts the join procedure described above.
Of course, the message types can be extended according to the needs of the concrete application domain, for example, for information exchange among nodes with the same superior node. Furthermore, information aggregation and dissemination protocols along the tree can be applied.