• Increase font size
  • Default font size
  • Decrease font size

What is CoDeS?

CoDeS is a middleware for building contributory communities, i.e., a community formed by a set of computers (resources) and its owners. It allows users to contribute a part of their computational resources to a community. These resources are used to host services for the benefit of the community. Each owner contributes one or more machines to the community, and can disconnect them from the community at any moment. Members of the community can also deploy services, specifying their execution requirements (a certain amount of CPU, RAM, disk, etc., needed for a single replica of the service), the files needed for execution (both executables and data files) and the number of replicas that should be available.

CoDeS manages the available resources autonomously to keep the services available, provided that there are enough resources to host the desired number of replicas of each deployed service.

CoDeS is developed by the Distributed, Parallel and Colaborative Systems (DPCS) group at the Universitat Oberta de Catalunya.


For applications, CoDeS can be seen as a Service Directory (SD). Users can register a service in the directory, providing the specification explained above. When they set a service's state as “active”, CoDeS makes sure that the required number of replicas are available. An application can then query the SD using a service's id to get a list of locations of the service. With these locations, the application can directly access an instance of the service.


CoDeS implements this Service Directory in a distributed and decentralized way. Services in the directory are maintained autonomously in presence of churn, and they can be deployed over a network of heterogeneous nodes.   CoDeS is programmed in java, and when instantiated in a node, it offers a simple API that can be contacted via RMI.


CoDeS' architecture is highly modular, so that different implementations of the modules can be plugged in to modify or enhance CoDeS behavior or mechanisms. This way, CoDeS can leverage the advances in areas like P2P computing, contributory storage, secure routing, etc.

The Service Deployment Module (SDM) is the main part of CoDeS, as it is the one that controls where services are executed. Some nodes host a Service Manager, an agent which is in charge of keeping a service available by selecting nodes to execute it and monitoring them. There are a number of Service Managers for each service deployed in the community, which clients can contact to ask for a service's location.

The Resource Discovery Module (RDM) finds nodes which are able to execute a given service. CoDeS' resource discovery implementation is built on top of the Service Deployment functionality, deploying a number of matchmakers as a service. However, different RDM implementations are possible.

Local resources are used to execute services, and different implementations can be used to provide and control access to those resources, such as virtualization.  

A connectivity layer offers the functionality of Key-Based Routing (KBR), to allow scalable communication between nodes. Any implementation of an overlay network with the KBR interface can be used, as CoDeS only relies on the standard KBR operations. The relation between a node and an identifier, given by the KBR, is used to decide which nodes will host a Service Manager for each service, identified by a key.  

A Spec Manager is used to interpret the specifications of nodes and the requirements of services. Different implementations can be used to adapt the system to different specification standards.  

The Remote Execution Module is in charge of controlling the use of remote resources in behalf of Service Managers. It monitors the nodes that have been assigned to perform a task, and inform the Service Manager in case of any problem.

Distributed persistent storage is used to store all the files required for deploying services (executables, data files, description files, etc.). The default implementation of CoDeS uses a DHT, built on top of the connectivity layer, although any other storage method can be used, e.g. a distributed file system.