Tapestry implements a distributed hash table and

Info icon This preview shows pages 10–13. Sign up to view the full content.

Tapestry implements a distributed hash table and routes messages to nodes based on GUIDs associated with resources using prefix routing in a manner similar to Pastry. But Tapestry’s API conceals the distributed has table from applications behind a DOLR interface. Nodes that hold resources use the publish (GUID) primitive to make them known to Tapestry. The holders of resources remain responsible for storing them. Replicated resources are published with the same GUID by each node that holds a replica, resulting in multiple entries in the Tapestry routing structure. 4.2.2. Plaxton Routing Mechanism The Plaxton routing mechanism has at each node local routing maps called neighbour maps that incrementally route overlay messages to the destination ID. Each node has a neighbour map with multiple levels. Any level in the neighbour map has a number of entries equal to the base of the ID, where the i-th entry in the j-th level is the ID and location of the closest node. In order to find the next node, we look at its n + 1th level map, and look up the entry matching the value of the next digit in the destination ID. Using this routing method in an N-size namespace using IDs of base b guarantees that in at most LogbN logical hops any existing unique node in the system will be found, assuming consistent neighbour maps in each node. As every single neighbour map at each node assumes that the preceding digits of each node all match the current node's suffix, it only needs to keep a small constant size (b) number of entries at each route level: NeighbourMapSize = (entries/map) * (# of maps) = b * LogbN
Image of page 10

Info icon This preview has intentionally blurred sections. Sign up to view the full version.

Page 11 of 13 This results in a constant-size neighbour map being produced. Figure: Plaxton routing example [3] 4.2.3. Plaxton Location Mechanism The Plaxton location mechanism allows a client to locate and send messages to a named object residing on a server. This is achieved by the server advertising that it has an object. It does this by routing a message to the root node, a unique node in the network that is used to hold the root of the object. Due to the root node's critical purpose and being the only one of its kind it becomes a single point of failure. Publishing is a process whereby a message is sent to the root node, and at each node along the path the <Object-ID (O), Server-ID (S)> location information is stored. On the other hand a location query allows clients to send messages to objects. As the message progresses through its path, it checks the nodes it passes through. The message is redirected to the server containing the object if the message encounters a node that has the location information for the object sought. Otherwise, the message is forwarded one step closer to the root. The location information or mapping for the object is guaranteed to be found upon the message reaching the root. The Plaxton location mechanism chooses root nodes using a globally consistent deterministic algorithm.
Image of page 11