RELOAD

Abstract

The aim of this project is to implement RELOAD Protocol. RELOAD is an acronym for Resource Location And Discovery Base Protocol. The current code provides implementation of encoder/decoder module for RELOAD messages (Store and Fetch request/response, RELOAD error messages), implementation of RELOAD storage module, implementation of basic skeleton for future work e.g. Transport layer, routing of request/response according to Chord algorithm using static routing table and Logging mechanism. This document describes the overall architecture and modules of the system in detail.

Introduction

RELOAD is a peer-to-peer signaling protocol. It provides its clients with an abstract storage and messaging service between a set of co-operating peers that form an overlay network. It provides a generic, self-organizing overlay network service, allowing nodes to efficiently route messages to other nodes and to efficiently store and retrieve data in the overlay.

The RELOAD project implementation is done in C++ language. Below is the list of items supported in the current RELOAD implementation:

• The current implementation of RELOAD project focuses on message encoder/decoder module and RELOAD storage module.
• RELOAD messages are routed amongst peers according to statically constructed Chord finger table. The Chord finger table is constructed according to config.txt file. Currently, RELOAD messages are sent using TCP protocol.
• The implementation supports following RELOAD messages: store_req, store_ans, fetch_req, fetch_ans and error.
• It supports all the RELOAD defined data models i.e. single_value, array_entry and dictionary_entry.
• Users can invoke easy to use RELOAD API calls e.g. putSingleValue(), getSingleValue(), deleteSingleValue(), putArrayEntry() etc. to store, retrieve, update and delete data stored into the RELOAD storage.
• As an additional feature, the implementation also provides a facility to take JSON string representation of RELOAD requests as an input and convert it into RELOAD message object (i.e. C++ object). This can be done using APIs such as createStoreFromJSON(), createFetchFromJSON(). This feature can be handy for testing of RELOAD implementation.

• RELOAD Architecture
• Modeling RELOAD Messages
• Storage Model
• System Limitations
• Code Organization
• Project Artifacts
• Third Party Libraries
• References

RELOAD Architecture

The architecture diagram is as shown below. It displays main modules of RELOAD and interaction between them:

This module is responsible for handling end-to-end delivery of RELOAD messages. RELOAD client or usage layer interacts with RELOAD protocol using RELOAD Common Message Transport API (ReloadCMT class). The Message Transport module interacts with Storage module to construct RELOAD store_req or fetch_req and sends it to the destination of the request. While sending the request on network, Message Transport module interacts with Topology plugin to determine next hop for the request. Message Transport module is also responsible to receive incoming messages. After receiving the RELOAD message, Transport module instructs Encoder/Decoder module to decode the ForwardingHeader component of the message. Then it examines the ForwardingHeader to check if the message is intended to be processed by this node. If yes, it instructs Encoder/Decoder module to decode the complete RELOAD message and sends it to the appropriate RELOAD module for further processing. Otherwise the packet is forwarded to the node resulted from performing routing table lookup for the packet.

Note that, in current implementation, there is no distinction between Message Transport module and Forwarding and Link Management module. The Message Transport module is itself responsible for doing routing table lookups and sending the message to next hop. The need for Forwarding and Link Management module will become more apparent when implementing overlay algorithm which allows dynamically adding and removing nodes from the overlay network.

This module is responsible for processing of messages related to storage and retrieval of data. Storage module talks to Message Transport module to send and receive messages such as store_req, store_ans etc. The entry point to Storage module is the StorageManager class which contains methods such as processRequest(), processResponse(), displayResources(). Message Transport module forwards requests for storage and retrieval of data to Storage module through above function calls. These methods delegate their work to other helper methods such as processStoreRequest(), processStoreResponse(), processFetchRequest(), processFetchResponse() based on the type of the message. The data from Store request is stored in in-memory storage classes. The heart of the Storage module is the class named DataStorage. RELOAD storage model is discussed in a separate section in this report.

The Topology module is responsible for implementing the specific overlay algorithm. Topology plugin is responsible for maintaining the overlay algorithm routing table which is consulted by Message Transport module before sending/forwarding RELOAD messages. Note that, once Message Transport module and Forwarding and Link Management module gets separated, it will be Forwarding module which consults with Topology module for sending messages. The current implementation of this module contains route lookup algorithm according to Chord DHT. It does not allow dynamic addition or removal of nodes from overlay network. Instead, routing table is statically constructed from the input configuration file.

Encoder Decoder is responsible for packaging RELOAD messages into byte stream at the sender side and converting them back into request/response object at the receiver side. The module takes into account intricacies of Host and Network byte order conversion.

The above four modules form core of the RELOAD protocol implementation. To test this implementation, the project includes a Test client. This client is built on top of ReloadCMT class and it instantiates RELOAD by calling initializeReloadCMT() method of ReloadCMT. Then it accepts the operations to be performed from user e.g. storing array entry, retrieving array entry, deleting array entry etc. After that, it invokes appropriate method of ReloadCMT e.g. putArrayEntry(), getArrayEntry(), deleteArrayEntry().

Modeling RELOAD Messages

RELOAD messages comprise of three parts: forwarding header, message contents and security block. While modeling RELOAD messages, these three parts are packed inside a class named Envelope.

Envelope encapsulates ForwardingHeader, Message and SecurityBlock. Note that, currently, SecurityBlock is just an empty class. This class shall be used when working on security aspects of RELOAD in future.

Each RELOAD message e.g. store_req, store_ans etc. is represented by a separate class e.g. StoreReq, StoreAns. These classes (i.e. StoreReq, FetchReq etc.) are subclass of the Message class. At the time of sending reload message over network, the Message is packed inside an Envelope and the Envelope is stamped with the ForwardingHeader which contains information of destination and possibly path to get to that destination. Then, the Envelope is serialized into raw byte stream and the raw byte stream is sent out of the system over the network.

Storage Model

The Storage Model of RELOAD is as shown in the figure below:

• single value: Represented by class SingleValue
• array: Represented by class Array
• dictionary: Represented by class Dictionary

Each of the above classes (i.e. SingleValue, Array, Dictionary) store their respective data entries using one or more instances of class StoredData. StoredData contains information such as storage_time, lifetime of the data along with the data itself. The relationship between KindData, SingleValue, Array, Dictionary, StoredData etc. is exaplained in more details in the figure below:

System Limitations

• Current work provides implementation of only RELOAD Store and Fetch request/response and error messages.
• It provides implementation of encoder/decoder module for the abovementioned RELOAD messages.
• If you decide to implement another RELOAD message, you have to model the classes for that message and call functions of encoder/decoder for sending it over network or receiving it from network and converting to C++ object. You can reference the current implementation to check how RELOAD messages are encoded or decoded (see encode() and decode() methods of StoreReq/StoreAns classes). With current encoder/decoder implementation, it is fairly simple to encode/decode new RELOAD messages.
• Current work provides implementation of data storage for RELOAD. You can store single value, array entry or dictionary entry in RELOAD storage. However, the current implementation limits the value type contained in each of these entries to string i.e. you can only store string type data in RELOAD storage.
• The data stored in RELOAD storage is not replicated.
• The draft mentions that each stored data element should be individually signed. However, this part is not implemented in current project.
• The access control policies for stored data are not implemented in current project.
• Each RELOAD message has three parts, ForwardingHeader, Message Contents, Security Block. Implementation of security block component of RELOAD messages is not provided in the current implementation.
• The Topology plugin module constructs the routing table statically from the input config file and routes messages according to that routing table. It does not allow dynamic addition or removal of nodes from overlay network.

Code Organization

• The code for RELOAD is organized into various modules e.g. Storage, Message Transport, Topology etc.
• Each module is placed in its own folder.
• For simplicity of code maintenance, all the classes used for modeling RELOAD messages are placed under the folder named Messages. All utility classes are placed under the folder Util e.g. classes such as FileReader, StringTokenizer, Util, Constants etc.
• The project also includes third party JSON parser implementation to parse JSON string representing RELOAD messages. This parser code is present under the folder named JSON. This code is modified to add functionality of translating this JSON string into RELOAD C++ object.
• Each class in the project is placed into a separate class file (with exception of third party libraries) as this simplifies code maintenance greatly. Member variables for each class are accessed through getter/setter methods.
• All the constants used across project are listed in a class named Constants.

Project Artifacts

The project artifacts include RELOAD source code, RELOAD API documentation, readme file.
RELOAD source code is hosted on google code repository. Follow this link to access RELOAD project repository. The repository contains README.txt file which has instructions on how to install and run RELOAD source code. It also contains RELOAD API reference document.

Third Party Libraries

The project uses following third party libraries:

• JSON parser: http://sourceforge.net/projects/jsoncpp/
• bigint: http://sourceforge.net/projects/cpp-bigint/

References

1. C. Jennings, B. Lowekamp, Ed., E. Rescorla, S. Baset, H. Schulzrinne , "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base-07
2. I. Stoica, R. Morris, D. Karger, Kaashoek, H. Balakrishnan , "Chord: A Scalable Peer-to-peer Lookup Service for Internet", http://pdos.csail.mit.edu/papers/chord:sigcomm01/chord_sigcomm.pdf