wiki:WikiStart

Version 17 (modified by xleon, 13 years ago) (diff)

--

Welcome to the Currency Management System (CMS) project

TOC?

News

30/10/08 - CMS development version is available through the subversion repository. Take a look at here.

Introduction

The current and future Internet, as a shared open network and service infrastructure, is used every day by more people and more diverse applications. This growth in usage, capacity and diversity makes even more difficult to provide sustainable high quality services to its heterogeneous population. In these kind of shared and cooperative infrastructures, resource providers may find there is not sufficient compensation and may be tempted to simply stop contributing more resources or block certain applications to reduce their load. Besides, users have no incentive to make an efficient use of resources of the, otherwise usually congested, overall infrastructure.

The Currency Management System (CMS) is a software package developed within the Grid4All European project in line with the work and effort at the Distributed Systems Group in developing decentralized mechanisms to support economics-inspired resource allocation in large-scale shared infrastructures like the grid. Other works complementary to this are the Market Information System (MIS) and the Grid Market Middleware (GMM).

CMS principal aim is two-fold:

  • provide the means to self-regulate and account for resource exchanges to ensure the stability and fairness of the infrastructure. Thus, it is modelled as a decentralized banking service which enable participants to exchange currency among to incentive sharing while limiting purchase power as well as provide the necessary infrastructure to support regulation policies based on different wealth re-distributions.
  • provide en enhanced peer-to-peer storage middleware to support ACID transactions. Our framework generalizes the transactional problem of the banking service allowing application designers to focus on semantics and not worry about conflicting transactions. Hence, other applications might benefit from our framework relying on lower latency transactions at a cost of probabilistic guarantees.

Overview

The currency abstraction enables participants to pay for resource exchanges over time and enables system designers to apply regulation policies to leverage users to behave accordingly. The currency in CMS is represented as a bank account balance that specifies the amount of currency each user owns as well as a history of past transactions over time. Although currency may be seen as a rather simple mechanism to regulate complex and widespread infrastructure, it is able to solve some of the main issues in large-scale computational infrastructures:

  • The need for regulation: It acts as a regulation mechanisms to solve the overloading problem as each user has a limited amount of currency being a ceiling on its purchase power.
  • Lack of incentives: For resource consumers it is an incentive to manage carefully their finite endowment or budget over a period of time using only the right amount of required resources. For resource providers it is also an incentive to maintain the nodes they contribute in good condition of capacity and availability in order to be competitive in the resource market and earn currency which in turn might be used to acquire future resources.
  • Non-reciprocal exchanges: It is a generic exchange mechanism able to cope with the heterogeneity between resource consumption and contribution.

Following the banking infrastructure requirements (scalability, fault-tolerance and self-managing), we have developed our system on top of DKS, a peer-to-peer middleware providing a structured overlay. Besides, we have enhanced this middleware to support ACID (atomic, consistent, isolated and durable) transactions through a decentralized timestamping and mutual exclusion mechanisms allowing different nodes of the enhanced DHT to handle and manage different user's accounts.

cmsLayers.png

Thus, our system provides the necessary accounting mechanisms to enable market-based allocations on top of a transactional storage through the following layers allowing their de-coupling and reusability:

  • Banking Layer: This layer is the responsible to create user’s accounts and provides management functionalities of client’s accounts. It also provides operations to perform currency payments between user’s accounts. This layer implements the CMS API as presented in the documentation. The API is felxible enough to support different charging policies such as pay-before-use, pay-during-use or pay-after-use.
  • Transactional Layer: This layer is responsible for providing mechanisms to execute transactions in an atomic and isolated way to the banking layer considering that accounts are spread across several nodes. As the main transaction of the banking layer is the transfer of funds between two accounts, both of them must be modified or none at all (atomicity). Moreover, concurrent updates against the same account must be handled correctly avoiding inconsistent account balances and the lost of updates (isolation).
  • Consistency Layer: This layer is responsible for providing to the upper layers with a fault-tolerant distributed storage (durability). Most existing DHTs provide good support for immutable data but with no consistency guarantees. In other words, current DHTs do not deliver any consistency guarantee so that stale values might be recovered from replicas after a failure. This way, its aim is to retrieve always the most recent item stored in the DHT despite the joining, leaving or failure of nodes (consistency).

Project status

This page is under construction so be patient :-)

Publications

Download

Installation

Distributed Systems Group homepage

Grid Market Middleware homepage

Grid4All European Project homepage