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

6
7

2. INSTALLING THE ICANCLOUD SIMULATION PLATFORM

10

3. MODELING CLOUD SYSTEMS USING ICANCLOUD

14

4. ADDING NEW HYPERVISOR POLICIES TO ICANCLOUD

20

5. ADDING NEW APPLICATION TO ICANCLOUD

25

5.1 DEFINITION OF THE APPLICATION (.NED FILE)

5.2 HEADERS (.H FILE)
5.3 IMPLEMENTATION (.CC FILE)
5.4 ICANCLOUD SYSTEM API

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.

We recommend Ubuntu 11.04. ;)

IDE.

Select

folder

~/omnetpp-4.X

as

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

is

located

in

~/omnetpp-

It consists of six parts:

1
2
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.

shows

de

declaration

of

the

application

#ifndef __BASIC_APPLICATION_H_
#define __BASIC_APPLICATION_H_
#include <omnetpp.h>
#include "AppSystemRequests.h"
class BasicApplication: public AppSystemRequests{

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.