2011/11/30

iCanCloud: Quick guide

Version 0.9 (Beta)

Alberto Nez Covarrubias Gabriel Gonzlez Casta

www.iCanCloudSim.org

Table of contents
INTRODUCTION 1. WHAT IS ICANCLOUD? 1.1. ICANCLOUD FEATURES 1.2. ICANCLOUD DESIGN 2. INSTALLING THE ICANCLOUD SIMULATION PLATFORM 3. MODELING CLOUD SYSTEMS USING ICANCLOUD 4. ADDING NEW HYPERVISOR POLICIES TO ICANCLOUD 5. ADDING NEW APPLICATION TO ICANCLOUD 5.1 DEFINITION OF THE APPLICATION (.NED FILE) 5.2 HEADERS (.H FILE) 5.3 IMPLEMENTATION (.CC FILE) 5.4 ICANCLOUD SYSTEM API 4 5 6 7 10 14 20 25 25 26 26 26

Introduction
Hi iCanCloud user! This is the first version of the first manual of iCanCloud. The goal of this quickguide is to show you how to compile and use iCanCloud, and also give you a brief overview of this simulation tool focused on cloud computing systems. Of course, we are (continuously) planning to improve this guide both by adding new sections and by completing the existing ones. If you have any suggestion, please send us e-mail1. Due to the fact that iCanCloud is developed on the top of OMNeT++, we strongly recommend you to read the Manual provided by the OMNeT++ framework, which can be found in ~/omnetpp-4.X/doc/Manual.pdf. Also, the HTML version of that manual can be visited here. Currently we are working very hard to release a new version by adding new features of iCanCloud with a fantastic IDE.

Enjoy! The iCanCloud team.

Contact e-mail can be found at http://www.iCanCloudSim.org

1. What is iCanCloud?
Simulation techniques have become a powerful tool for deciding the best starting conditions on pay-as-you-go scenarios. This is the case of public cloud infrastructures, where a given number and type of virtual machines are instantiated during a specified time, being this reflected in the final budget. In order to develop new proposals aimed at different topics related to cloud computing (for example, datacenter management, or provision of resources), a lot of work and money is required to set up an adequately sized testbed including different datacenters from different organizations and public cloud providers. Even if automated tools exist to do this work, it would still be very difficult to produce performance evaluation in a repeatable and controlled manner, due to the inherent variability of the cloud. Therefore, it is easier to use simulation as a tool for studying complex scenarios. The ever-increasing complexity of computing systems has made simulators a very important choice for designing and analyzing large and complex architectures. In the field of cloud computing, simulators become especially useful for calculating the trade-offs between cost and performance in pay-as-you-go environments. Hence, this work describes a flexible and scalable simulation platform for modeling and simulating large environments that represent, both actual and non-existent cloud computing architectures. iCanCloud is a simulation platform aimed to model and simulate cloud computing systems, which is targeted to those users who deal closely with those kinds of systems. The main objective of iCanCloud is to predict the trade-offs between cost and performance of a given set of applications executed in a specific hardware, and then provide to users useful information about such costs. However, iCanCloud can be used by a wide range of users, from basic active users to developers of large distributed applications. This simulation framework has been developed on the top of OMNeT++ and INET frameworks. Thus, both frameworks are needed to execute and develop new modules for iCanCloud. For more information, please visit the OMNeT home page. Although each user is intersected on different features provided by the cloud, all of them have the same objective: optimizing the trade-off between cost and performance, which is the real hard task iCanCloud tries to alleviate. Thus, this simulation platform provides a scalable, flexible, fast and easy-to-use tool, which let users, obtain results quickly in order to help to take a decision for paying a corresponding budget of machines. The proposed features are desirable for any simulation platform, but their meaning can be blurry depending on the context in which they are used. Scalability means whether the corresponding simulator is able to simulate large-scale systems without loosing performance. Likewise, performance determines the speed which a simulator executes a corresponding simulation. In general, the larger the size of the architecture to be simulated, the greater the time needed to execute the simulation. Moreover, a flexible simulator must let users build environments easily, using

several component models with different levels of detail. In fact, the proposed hypervisor model let users to integrate any cloud brokering policy to manage a set of fully customizable VMs. Thus, different brokering policies can be fully customized by using this simulation platform. The simulated cloud computing scenarios are modeled using a set of existent components provided by iCanCloud; they represent the behavior of real components that belong to real architectures like disks, networks, memories, file systems, etc. Those components are hierarchically organized within the repository of iCanCloud, which compose the core simulation engine. Besides designing simulated environments using components provided by iCanCloud, new components can be added to its repository. Moreover, iCanCloud allows an easy substitution of components for a particular component. Those interchangeable components can differ in level of detail (to make performance versus accuracy trade-offs), in the functional behavior of the component, or both.

1.1. iCanCloud features

The most remarkable features of the iCanCloud simulation platform include the following: Both existing and non-existing cloud computing architectures can be modeled and simulated. A flexible cloud hypervisor module provides an easy method for integrating and testing both new and existent cloud brokering policies. Customizable VMs can be used to quickly simulate uni-core/multi-core systems. iCanCloud provides a wide range of configurations for storage systems, which include models for local storage systems, remote storage systems, like NFS, and parallel storage systems, like parallel file systems and RAID systems. iCanCloud provides a user-friendly GUI to ease the generation and customization of large distributed models. This GUI is especially useful for: managing a repository of pre-configured VMs, managing a repository of preconfigured Cloud systems, managing a repository of pre-configured experiments, launching experiments from the GUI, and generating graphical reports. iCanCloud provides a POSIX-based API and an adapted MPI library for modelling and simulating applications. Also, several methods for modelling applications can be used in iCanCloud: using traces of real applications; using a state graph; and programming new applications directly in the simulation platform. New components can be added to the repository of iCanCloud to increase the functionality of the simulation platform.

1.2. iCanCloud design

The basic idea of a cloud computing system is to provide users a pseudocustomizable hardware environment where they can execute specific software. Therefore, in order to model entire cloud computing systems, the architecture of iCanCloud has been designed based on this principle. Thus, Figure 1 shows the layered architecture of iCanCloud.

Figure 1 Basic layered schema of iCanCloud architecture

The bottom of the architecture consists of the hardware models layer. This layer basically contains the models that are in charge of modeling the hardware parts of a system, like disk drives, memory modules and CPU processors. Using those models, entire distributed systems can be modeled and simulated. In turn, this section consists of four groups, where each corresponds to a specific basic system: processing system (CPU), memory system, storage system, and network system. The basic system's API module is directly connected with the hardware models layer. Basically this module contains a set of system calls which are offered as an API (Application Programming Interface) for all applications executed in a VM modeled using iCanCloud. Thus, those system calls provide the interface between applications and the services provided by the hardware models. Moreover, researchers can write applications to be simulated in iCanCloud using this API. In order to maintain a certain degree of compatibility, this API pretends to be a subset of POSIX. Upper layer consists of a VMs repository. This repository contains a collection of VMs previously defined by the user. Initially, the iCanCloud simulator provides few models of existing VMs in well known clouds like Amazon (EC2). Moreover, users can add, edit or remove VMs from this repository. Each VM is modeled by configuring the corresponding underlying hardware models for each basic system.

In a cloud system, the VM is the most relevant component. Similarly in iCanCloud, a VM is a building block for creating cloud systems. The key of this simulation platform is modularity, which let nested complex modules using other modules previously defined. Thence, the basic idea of iCanCloud consists on using VMs modules for building entire cloud computing systems. In those systems, VMs are in charge of hiding the hardware details, providing to users a logic view that corresponds with the user requirements. Thus, the VMs models defined in this layer use the previously defined hardware components defined in the bottom layer. Otherwise, the application repository contains a collection of pre-defined applications customized by users. Similarly to the repository of VMs, initially this repository provides a set of pre-defined application models. Those models will be used in order to configure the corresponding jobs that will be executed in a specific instance of a VM in the system. Moreover, new application models can be easily added to the system, because iCanCloud provides an API in order to ease the development of new application models. Upper layer, called cloud hypervisor, consists of a module in charge of managing all incoming jobs and the instances of VMs where those jobs are executed. Once a job finishes its execution, this module sets as idle the VMs where that job has been executed, and then re-assign the available resources in the system to execute the remaining jobs. This module also contains cost policies in order to assign incoming jobs to a specific instance calculated by the corresponding heuristic. Finally, at the top of the architecture is the cloud system module. This module contains a definition of the entire cloud system, which basically consists on the definition of the hypervisor, and the definition of each VM that composes the system. However, the key innovation of this simulation framework lies in a modular and flexible design. Figure 2 shows the UML 2.3 class diagram of the iCanCloud simulation platform. This model is split in two different parts. On the one hand, dark grey squares represent the hardware part of the cloud environment. On the other hand, the light grey squares represent those modules in charge of managing the cloud system. The VM class acts as a link among the physical resources of the cloud environment, such as nodes and networks, and the resources used by users, giving them an illusion of using directly the physical resources to execute the corresponding jobs. Thus, depending of the configuration of each VM, those are mapped to the physical nodes existent in the cloud system model. The main module of this section is the hypervisor, which is the center piece of the system.

Figure 2 UML class diagram of iCanCloud simulation platform

2. Installing the iCanCloud simulation platform

This section provides the steps required to install iCanCloud on Linux Distributions2. First of all, iCanCloud needs both OMNeT++ and INET simulation frameworks, which are provided in the same package that iCanCloud. If you prefer to install a newer version of those frameworks, or just to obtain more information about them, please visit http://www.omnetpp.org/ Install process: 1. Download iCanCloud from www.iCanCloudSim.org. 2. Extract iCanCloud. Now, a folder called omnetpp-4.X is generated. This folder contains the OMNeT++ framework, the INET framework and iCanCloud.
tar -zxvf iCanCloud-YYYY_MM_DD.tgz

3. Install OMNeT++. There is a very detailed installation guide in ~/omnetpp-4.X/doc/installGuide.pdf. Installing OMNeT requires (Flex, bison, tcltk ..) . 4. Install INET. i. Launch omnetpp workspace. IDE. Select folder ~/omnetpp-4.X as

We recommend Ubuntu 11.04. ;)

ii. Import INET to the workspace (File -> Import).

iii. Compile INET

5. Install iCanCloud i. Launch omnetpp (if not running) ii. Import iCanCloud to the workspace. a. File -> Import -> Existing projects into Workspace b. Select iCanCloud folder c. Click Finish

iv. Compile iCanCloud

3. Modeling cloud systems using iCanCloud (IDE)

The iCanCloud simulation framework provides an IDE to manage and configure simulation environments. Using this IDE, different elements such as the cloud architecture, jobs to be launched in the cloud and different user profiles can be configured and edited. Those configurations can be also stored on disk. Thus, a repository of different elements can be managed to create different configurations and environments. This IDE is written in Java, and 4.X/iCanCloud/iCanCloud_ide It consists of six parts: it is located in ~/omnetpp-

1 2 3 5

6
1. Task bar. This bar let user access to some functionalities of the iCanCloud IDE. 2. Simulation bar. This bar consists of three buttons. From left to right, create configuration, launch simulation and create configuration + launch simulation. 3. Main repository. This area shows the repository of the iCanCloud system which is divided in four groups (clouds, users, virtual machines and applications). 4. Simulation area.

This area shows the finalized simulations. Once a simulation has successfully finished, users can use the results file to extract it in .csv format. The name of the results is the same that the launched cloud simulation. 5. Configuration area. Once user select a specific group, a new panel shows the corresponding set of parameters to be configured. 6. Information area. It shows the main messages of iCanCloud IDE such as errors and events. The following screenshots shows the main functionality of the IDE: Add a new virtual machine. o o o o Right click on Virtual Machine in the main repository. Click in add VM. Fill all the textbox with values. Click on save button.

Add a new application. o o o o Right click on Applications in the main repository. Click in add Application. Select a name for the new application. Select an application type. The iCanCloud IDE only shows the applications found in the folder:
iCanCloud/src/Applications/Apps/

o Fill the table with the corresponding values.

o Click on save button.

Add a new user. o Right click on Users in the main repository. o Select a name for the new user. o Add the applications that the corresponding user is going to launch in the cloud system. o Configure the number of executions (iterations) of that application. o Select the number of virtual machines required by the user o Select the type of the virtual machines. o Click on save button.

Add a new cloud. Right click on Clouds in the main repository. Select a name for the Cloud. Select the number , type and cost of the providers virtual machines. Click on add button. Select the users that are going to launch applications to the cloud system. o Click on add button. o Select an hypervisor and a scheduler. o Finally click on save button. This will update all the modifications in the IDE system. o o o o o

Launch a specific simulation. o Click on a created cloud in the main repository. o Click on create configuration and then on launch simulation or create configuration + lanch simulation in the simulation bar. o You can stop the simulation, but the results might contain errors.

Generate CSV o Once a simulation is launched, a results file is created into the simulation area. When the execution finished, click on generate CVS. o Generate .csv.

Advices: If you remove an element which is used in a specific simulation, it might contain errors. The simulation file is created at the moment of launching the execution. Generating the CSV before the execution has finished can show only partial results or produce errors in the process of write results file.

4. Adding new hypervisor policies to iCanCloud

The hypervisor module is the master key of the iCanCloud simulation core. Basically, this module is in charge of managing the VMs and executing the jobs defined by users. In order to accomplish this task, the hypervisor can be fully configured by integrating customized brokering policies. The main goal of the proposed hypervisor is two-fold: First, to provide a set of brokering policies to be customized easily depending of the system's requirements. Second, to allow the integration of custom brokering policies, such as cost-based policies, execution time-based policies and resource allocation-based policies. In order to accomplish those goals, the proposed hypervisor has been designed to provide a high level of flexibility and usability. This module is implemented as an abstract class called CloudHypervisor. Also, this class provides a very intuitive interface to deal with the main tasks for managing a cloud system. The underlying idea of this subclass is to select the next job to be executed in the cloud, and the VM instances where that job will be executed. Thus, new scheduling policies can be easily integrated into the proposed hypervisor just by implementing the corresponding abstract methods. Hence, this subclass may also use methods provided by the hypervisor and the relevant information of each job submitted to the system. This information is basically the number of instructions to be executed, the size of the data to be read, and the output data to be written, which can be retrieved from each job object.

Figure 3 Basic Schema of iCanCloud architecture

Figure 3 shows the basic schema of the proposed hypervisor module. Basically, the main parts of the hypervisor model are: Waiting queue: This queue handles jobs that have been submitted to the system, and are currently waiting to be executed. User-defined queues: Those queues contain those jobs that are currently being executed on any VM. Those queues must be declared on the subclass. Thus, depending of the brokering policy, the number of those queues may vary. Finished queue: This queue handles those jobs that have finished their execution. VMs map: This data structure contains relevant information of all those VMs that have been started up in the cloud system, such as the state of each VM, time-frame that each VM has been in an idle state, current job that is being executed in each VM, etc. List of users: List of users that have submitted jobs to the cloud system. Job scheduling and brokering policy: Policies required to manage jobs and VMs. Those policies must be implemented in the corresponding subclass of CloudHypervisor. Cost policy: Policy that establishes a price and budget to each VM instance type.

4.1 iCanCloud hypervisor API

This file is an abstract class that can be used to create custom Hypervisors by implementing all the abstract methods. The hypervisor API is included in the file HypervisorBase.h. defines hypervisors which implements several methods. The current version of iCanCloud provides the implementation of one hypervisor, the BasicHypervisor.

The API of the hypervisor base:

1 // Functions provided by operate to the new hypervisors 2 3 vector <vector <int> > create_VmMap_Indexes (); 4 int getIndexOfJob (string jobID, vector <CloudJob*> *qSrc); 5 6 int getQueueSize (vector <CloudJob*> *qSrc); 7 vector<cModule*>* start_up (vector <vector <int> > *setMachinesToExecute, CloudJob* job, vector <CloudJob*> *qSrc, vector <CloudJob*> *qRunning,int position_qRunning); 8 9 void execute_new_iteration (CloudJob* job); 10 void send_feedback (CloudJob* job); 11 12 void insert_waiting_q (string jobID); 13 cModule* create_job (CloudJob *job); 14 15 //Functions to be implemented by the hypervisor 16 17 virtual void init_hypervisor () = 0; 18 virtual CloudJob* select_job (string jobID) = 0; 19 20 virtual vector <vector <int> > select_vm (VmInstancesList* requestVMs) = 0; 21 virtual void job_has_been_inserted () = 0; 22 23 virtual void job_has_finished (CloudJob* job) = 0; 24 virtual void run_job (vector <vector <int> > *setMachinesToExecute, CloudJob* job, vector <CloudJob*> *qSrc, vector <CloudJob*> *qRunning, int position_qRunning) = 0; 26 27 virtual void restart_execution (CloudJob *job) = 0; 28 29 // Functions provided by operate with schedulers 30 31 // Functions provided by operate with users and jobs 32 33 vector <CloudJob*> get_job_list (); 34 CloudUser* get_user_by_index (int userIndex); 35 36 CloudUser* get_user_by_name (string name); 37 CloudJob* get_job_by_ID (string jobID); 38 39 CloudJob* get_job_by_index (int index); 40 41 // Functions provided by create a virtual machine map 43 44 VmInstancesList* create_VmMap_list(); 45 46 // Functions provided by operate on waiting queue 47 48 void move_WQjob_from_to (int initPos, int dstPos); 49 int get_index_of_WQjob (string jobID); 50 51 int get_WQ_Size (); 52 void move_Rq_to_Fq (CloudJob *job, vector<CloudJob*> *qSrc);

The hypervisor module is in charge of managing the main structures of an iCanCloud simulation. Jobs, users and virtual machines are parsed from an xml file previously generated by the GUI. The jobs are allocated in the jobList vector, the VMsMap contains virtual machines, and the users in the usersList.

The API provides the following functions: Method create_VmMap_Indexes (line 3), creates an empty matrix to manage the different requests of virtual machines. Method getIndexOfJob (line 4), returns the index of the job in the given vector. Method getQueueSize (line 6), returns the size of the given queue. Method start_up (line 7), receives as parameters an execution matrix, the job that is going to execute on them, the structure where the job is allocated before the execution, the structure where the job is going to be allocated and finally, the position on it. This function returns a vector of pointer to cModule that contains the virtual machines requested with the job allocated on them. The execution matrix is a virtual machine map which consists of where hypervisor let the job executes. Method execute_new_iteration (line 9), executes a new iteration of a given job. It decreases the parameter iterationsRemaining of the current job and, finally calls to the application method to set the state into running. Method send_feedback (line 10), sends the results to the user. It serializes a job results to append them into a XML file. Method insert_waiting_queue (line 12), is in charge of moving the given job from the jobList to the waitingQueue. Method create_job (line 13), gets the job and returns the new application in a cModule created dynamically.

The following methods are abstract methods to be implemented by new hypervisors. Method init_hypervisor (line 17), initializes the new hypervisor. Method select_job (line 18), selects a job from the waiting queue to be executed. Method select_vm (line 20), receives a set of requested virtual machines and it returns an execution matrix. Method job_has_been_inserted (line 21), calls the method job_has_been_inserted of the scheduler. Method job_has_finished (line 23), is invoked by the application when it finishes an iteration. Method run_job (line 24), is called by the hypervisor to execute a job in a set of virtual machines. It has to call to the protected method start_up internal to the hypervisor. Method restart_execution (line 27), is invoked by the scheduler when it wants to launch a new iteration of a job.

The following methods provide functionalities to the scheduler. They are grouped in three groups: To operate with users and jobs, to create virtual machine map and to operate with on the waitingQueue. Methods provided to operate with users and jobs: Method get_job_list (line 33), returns the structure jobList to let the scheduler decide which job will be launched.

Method get_user_by_index (line 34), returns the user allocated in the position userIndex of usersList structure in the hypervisor. Method get_user_by_name (line 36), returns the user with the name name into the usersList structure. Method get_job_by_ID (line37 ), returns the job from the waitingQueue with an equal ID that the given one (jobID). Method get_job_by_index (line 39), returns the job from the waitingQueue in the given position by index.

Methods provided by create a virtual machine map: Method create_VmMap_list (line 44), creates a new and empty VmMap (execution matrix) as the cloud provider map.

Methods provided by operate on waitingQueue. Method move_WQjob_from_to (line 48), receives two integer. The initial position and final one to move a job into the waitingQueue. Method get_index_of_WQjob (line 49), returns from a jobID the position of the job into the waitingQueue structure. Method get_WQ_Size (line 51), returns the size of the waitingQueue structure. Method move_Rq_t_Fq (line 52), moves a job from a scheduler vector which contains jobs, to the finishQueue structure of the hypervisor.

5. Adding new applications to iCanCloud

Currently, iCanCloud provides different applications to be launched by users. Each application consists of a set of parameters that define the behavior of such application. Moreover, new applications can be added to the application repository of iCanCloud. The folder that contains the collection of applications is ~/omnetpp4.X/iCanCloud/src/Applications/Apps Each application is located in a separated folder. Thus, three different files must be written to create an application.

5.1 Definition of the application (.ned file)

This file contains the name of the application, and a set of parameters that define its behavior. Next portion of code shows the definition of the application BasicApplication.
1 package iCanCloud.Applications.Apps.BasicApplication; 2 import iCanCloud.Applications.Apps.IApp; 3 4 simple BasicApplication like IApp{ 5 6 parameters: 7 string application_netType; // Network type (INET or BASIC) 8 double startDelay; // Starting delay time! 9 int inputSize; // Input size of data 10 int outputSize; // Output size of data 11 int MIs; // Number of MIs to execute 12 int iterations; // Number of iterations 13 @display("i=msg/job"); 14 15 gates: 16 input fromOS; // Input gate from OS (Operating System) 17 output toOS; // Output gate to OS (Operating System) }

The name of the application is indicated in line 4. Also, each application must implements interface IApp. Line 7-12 shows the list of parameters of this application. Each line must contain the type of the parameter, and its name. For more details of .ned language, please read chapter 3: The NED language of the manual provided by OMNeT++ framework ~/omnetpp4.X/doc/Manual.pdf

5.2 Headers (.h file)

This file contains the function headers of the application. The declaration of the application must inherit from the AppSystemRequest class. This class contains the functions provided by the simulation API, which will be described in section 5.4. Next portion of code BasicApplication.
#ifndef __BASIC_APPLICATION_H_ #define __BASIC_APPLICATION_H_ #include <omnetpp.h> #include "AppSystemRequests.h" class BasicApplication: public AppSystemRequests{

shows

de

declaration

of

the

application

5.3 Implementation (.cc file)

Finally, this file contains the implementation of each function contained in the headers file.

5.4 iCanCloud system API

The basic system's API module is directly connected with the hardware models layer. Basically this module contains a set of system calls, which are offered as an API (Application Programming Interface) for all applications executed in a VM modeled using iCanCloud. Thus, those system calls provide the interface between applications and the services provided by the hardware models. Moreover, researchers can write applications to be simulated in iCanCloud using this API. In order to maintain a certain degree of compatibility, this API pretends to be a subset of POSIX. Following, the set of functions provided by this API is described for each basic system. Line 2 shows a function for using the CPU service. Basically applications which request CPU processing must invoke the iCanCloud_cpu function to specify the corresponding amount of instructions to be executed, measured in MIs (Million Instructions). The CPU can contain one or more CPU cores.

// Functions provided by the computing system void iCanCloud_cpu (long int numInstructions); // Functions provided by the memory system void iCanCloud_allocMemory (int memorySize); void iCanCloud_freeMemory (int memorySize); // Functions provided by the storage system void iCanCloud_open (char* fileName); void iCanCloud_close (char* fileName); void iCanCloud_create (char* fileName); void iCanCloud_delete (char* fileName); void* iCanCloud_read (char* fileName, unsigned int offset, unsigned int size); void* iCanCloud_write (char* fileName, unsigned int offset, unsigned int size); // Functions provided by the network system void iCanCloud_createListenConnection (int localPort, string type); void iCanCloud_createConnection (string destAddress, int destPort, int id, string type); void iCanCloud_sendDataToNetwork (iCanCloud_Message *sm, int id); void iCanCloud_receiveDataFromNetwork (iCanCloud_Message *sm, int id);

The main task of the memory system is to assign the corresponding amount of memory to each application that requires it. Thus, this system receives requests for memory allocation and calculates where and how this memory has to be assigned. This feature is very useful for analyzing the amount of memory used for each application, especially in large distributed environments. In order to interact with the memory system, applications must use the functions specified in lines 5-6. Basically this interface consists of two functions. First function, called iCanCloud_allocMemory, is in charge of allocating memory. Second function, called iCanCloud_freeMemory, is in charge of freeing the previously allocated memory. Parameter memorySize indicates the amount of memory required (measured in bytes) to perform the corresponding operation. The storage system is in charge of managing all accesses to data. The set of functions shown in lines 9-14 offers an interface to interact with the storage system, which basically consists of a set of functions for managing files. Functions iCanCloud_open and iCanCloud_close are in charge of opening and closing respectively a file given its name. Functions iCanCloud_create and iCanCloud_delete are in charge of creating and removing respectively a file given its name. Finally, function iCanCloud_read is in charge of reading data in the file specified in the parameter called fileName. Similarly, function iCanCloud_write writes data in a given file. The amount of data to be read or written is specified in the parameter size. Finally, the parameter offset specifies the starting point in the file where requested data is processed. The network system is in charge of managing connections with other applications located in remote nodes, and also processing both the received and sent packets. The network system's API is shown in lines 17-20. Using this interface, applications can manage connections with remote nodes, and send and receive data through the network.

Function iCanCloud_createListenConnection creates an incoming connection from a remote location. Otherwise, function iCanCloud_createConnection establishes a connection with a remote application. Function iCanCloud_sendDataToNetwork sends data through the network system to a remote location. Similarly, iCanCloud_receiveDataFromNetwork receives data from a remote location. First function is in charge of sending data from the application that invokes this function to a remote application specified in the message sm. Second function is in charge of receiving data from a remote application specified in the message sm Besides functions provided by this API, iCanCloud also provides a high level layer for developing distributed applications. This layer is placed in the application component and provides standard interfaces for executing distributed applications. Currently iCanCloud has implemented an interface for executing MPI applications.