Implementing the Peer-to-Peer Layer
6.3 DHT implementations
6.3.2 Bamboo DHT
cess or failure of each DHT operation performed. The first set of methods achieves this through the use of an instance of theChordCallbackinterface, which is notified when an operation has completed, and throws an exception if there was a failure. The second set returns an instance of theChordFutureinterface, which returns a boolean value through itsisDonemethod, to notify the thread whether the operation has been completed or not, and throws an exception if the operation ultimately fails. Both interfaces store resources in memory.
is passed to all stages that have been registered with the server. An application can receive events it registers to receive through aneventHandlermethod and can also dispatch events either for the local node or remote nodes with a dispatch_latermethod [76]. A Bamboo stage has three basic parts:
Constructor This initialises the data of the stage and registers events the stage wants to be notified of.
Event Registration This occurs in theinitfunction of the stage, which fetches configuration parameters set in the configuration file.
Event Handling This occurs through thehandleEventmethod of the stage, which is called every time an event that the stage has registered for arrives and needs to be handled.
6.3.2.4 Configuration File
When a stage is registering for events, there a number of parameters that can be fetched. The values of these parameters are set in a configuration file with a set of mandatory and optional tags that resemble XML markup. The format of the file is borrowed from another project at Berkeley called Oceanstore [77]. An example of a configuration file is given below showing some standard Bamboo stages as well as a custom stage called SimpleStage:
<sandstorm>
<global>
<initargs>
node_id localhost:3200
<initargs>
</global>
<stages>
<Network>
class bamboo.network.Network
<initargs>
</initargs>
</Network>
<Router>
class bamboo.router.Router
<initargs>
gateway_count 1
gateway_0 localhost:3200
</initargs>
</Router>
<SimpleStage>
class bamboo.apps.SimpleStage
<initargs>
debug_level 1 mode sender
</initargs>
</SimpleStage>
</stages>
</sandstorm>
In this configuration file, there are several portions to note:
Global Variables Global variables accessible by all stages are contained in the global tag.
This section defines the node identifier of the Bamboo node, which is running on the localhost at port 3200.
Initialisation of Arguments All settings of stage specific parameters are wrapped in aninita- rgstag.
Stages Network, Router and SimpleStage stages are defined here. Each stage must specify the class to be loaded upon execution. For the Network stage, that class is bamboo.network.Network. The Router stage also defines the gateway node to be contacted when joining the DHT (in this case, this node is the first node in the DHT, so it is its own gateway). The example stageSimpleStagealso defines some custom parameters it fetches in itsinitmethod.
6.3.2.5 DHT/Data Layer
In staying with the staged, event driven nature of Bamboo the classical DHT operations of in- serting, retrieving and removing data from the overlay can be supported with the inclusion of the bamboo.dht.DHTclass as a stage in the configuration. The inclusion of this stage allows an application to participate in the DHT by storing data. The DHT stage is aided by two other stages, DataManagerandStoreManager. TheDataManagerstage manages the data stored on the Bamboo node and allows a programmer to set parameters such as the data replication factor for data items stored in the DHT. The StorageManagerstage interfaces between the DHT interfaces and the actual database platform for the storage of values in the DHT, allowing a pro- grammer to set parameters such as the location to store the database file, or the maximum size of the node cache.
The database platform for Bamboo is in the form of the embeddable database called the Berkeley Database [78]. This is a lightweight storage system which stores data in key-value pairs, allowing for high performance and easy deployment. The Berkeley Database is highly configurable and needs no administrative effort to maintain, making it a good environment for developing peer- to-peer systems. In Bamboo, the database is imported as a simple .jar file and can be readily used.
6.3.2.6 Gateway layer
Another important stage in Bamboo is theGatewaystage which provides access to the DHT storage infrastructure. Nodes implementing this stage can issue commands using SUN RPC
over TCP/IP. DHT operations are supported by nodes running this stage through the classes bamboo.dht.Get,bamboo.dht.Putandbamboo.dht.Remove. By convention, a Bam- boo node listening on port 3630 which runs theGatewaystage will listen for DHT requests on a different port, such as 3632. Example uses of the interfaces are given in the code below.
java bamboo.dht.Put <server_host> <server_port> <key> <value> <TTL> [secret]
java bamboo.dht.Get <server_host> <server_port> <key> [max_vals]
java bamboo.dht.Remove <server_host> <server_port> <key> <value> <TTL> [secret]
In the code above, TTL determines the expiry time for the record. The parameters secret and max_vals that are enclosed in square brackets are optional. The secret parameter associates a password with the insertion or retrieval of data records in the DHT. The max_vals parameter determines how many values associated with the key are to be returned to the requestor.