Antiquity
Secure Log For Wide-Area Distributed Storage

• Note:
• This is a summary of how Bamboo and Bamboo applications operate. Detailed explanation is located in the Programmer's Guide
  
• Recall:

• Bamboo is a robust Distributed Hash Table (DHT)
  

• Bamboo's Architecture (Bamboo Tutorial):
• Note:
• The Bamboo Tutorial explains the basics to constructing a standard stage and ultimately, a Bamboo application
  

• Bamboo is written in a single threaded programmatic style known as SEDA
  
• " SEDA is an acronym for staged event-driven architecture, and decomposes a complex, event-driven application into a set of stages connected by queues. This design avoids the high overhead associated with thread-based concurrency models, and decouples event and thread scheduling from application logic. By performing admission control on each event queue, the service can be well-conditioned to load, preventing resources from being overcommitted when demand exceeds service capacity." (http://www.eecs.harvard.edu/~mdw/proj/seda/).
• Events
• Since the stages used in these applications use Bamboo, to be able to be a part of the event handling Bamboo is built on, they must:
• Implement the interface, seda.sandStorm.api.EventHandlerIF
  
• Or also, extend the class bamboo.util.StandardStage (also known as ostore.util.StandardStage)
• Note:
  
• The StandardStage is most commonly used
• Events are essentially actions/methods performed in order to achieve or produce some result
  
• i.e. The pinging of a server from a client to test if the server is alive by echoing a message the client sends, is an example of an event
  
• The configuration file (ends in .cfg)
  
• Note:
• Bamboo inherits and uses the SandStorm operating system from OceanStore
• The programming style of the configuration file used is mostly related to that of XML and HTML, so it is easily readable
  
• This is a file that contains any pre-defined settings, necessary for loading the Bamboo application and the stages used in the application
• Each stage is defined with a tag, the name of the java class used for this stage, followed by a listing of options required for the use of the stage
• These options include, but are not limited to, possible connection attributes (i.e. server addresses, ports, timeouts, fragment sizes etc.), debugging settings and much more
• Layers of a stage
  
• A stage can be thought of having 3 layers:
• The constructor
• Just like a java constructor, this is where all the data for the stage should be initialized (i.e. variables, all events, etc)
  
• init(ConfigDataIF config) - Initialize
  
• Since everything in Bamboo operates by the use of events, here the StandardStage registers all the events that the application wants and is responsible for
  
• Here is also where all the settings provided in the configuration file are called and incorporated into the application
  
• handleEvent(QueueElementIF elem)
  
• When a registered event arrives in the application, handleEvent locates the assigned method for the event and carries out the event
  
• Communication amongst Stages:
  

• Now aware that the Bamboo system is divided into stages we address how the registered events of a stage operate with each other
  
• To be able to access different stages with events we use:
• Remote Procedure Calls (RPC) - RFC File
  
• Each event has its own RPC that needs to be registered and mapped to its required arguments and results in order to function
  
• Explicitly, we use RPC's to send an event request to a stage, the destination stage handles the event, and we expect a response/reply for our request from the opposing stage
  
• i.e. in the ping example used above:
• Request: The client uses a ping event to request the measurement of its bandwidth from the server
• Response/Reply: The server measures the bandwidth based on its statistics of the ping event and replies to the client with the result