.cpp

Development Project for Distributed Systems

TaskMan-Middleware 2011
A Standard C++ distributed middleware for workflow management over a P2P INET
TCP/UDP IP PUSH/PULL-Sending-Model oriented network

Università degli Studi di Catania - A.A. 2010/11 Distributed Systems 2010-11
Corso di Laurea Specialistica in Ing. Informatica DIIT @ Università di Catania
Riccardo Pulvirenti, Giuseppe Ravidà & Andrea Tino Prof. Eng. A. Di Stefano
Marco Buzzanca & Davide Giuseppe Monaco Eng. G. Morana

More about teams
Description of team components

The Project was started by both teams and advanced, together, in the initial
steps. The following core design and development stages were terminated
separately, getting two softwares with diﬀerent characteristics and imple-
mentative solutions (patterns).

Group components Group components
Riccardo Pulvirenti Marco Buzzanca
riccardo.pulvirenti@gmail.com marco.bzn@gmail.com

Giuseppe Ravidà Davide Monaco
pepperav@gmail.com black.ralkass@gmail.com

Andrea Tino
andry.tino@gmail.com

Project requirements Project requirements
C++ middleware kernel using a PUSH sending model C++ middleware kernel using a PULL sending model
in a P2P oriented-network using TCP/IP protocol. in a P2P oriented-network using UDP/IP protocol.

TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011

TaskMan-Middleware Teaming
An overview of teams involved in the c++ project branch

Two teams were involved in the development of a C++ middleware kernel
for workflow management and execution. Both teams had some chances to
work together. We are going to describe the team workflow.

Core Design
Design of specific (non
Requirement common) components.
Initial Design
analysis
Design of common
Requirements for components:
communications, syncronized queues, Core Design
protocols, task man- descriptors for tasks
agement, queues Design of specific (non
and workflows. common) components.
management, routing
management.
Core development
Development of specific (non
Common components common) components. Release 1
development Release 2
Development of common compo-
nents: syncronized queues, parts Core development
and structures of common classes. Development of specific (non
common) components.


Presentation flow
Presenting solutions, patterns and choices

We are now going to describe and discuss the main characteristics of both
projetcs focusing on design choices and implementative solutions (trying to
always provide accurate rationales). The members of two teams will, alter-
nately, advance the presentation on the respective parts.

Part 1: Introducing Part 2: Introducing Part 3: Introducing Part 4: Providing all Part 5: Conclusions.
main actors and all all information and describing all the development The most important
services imple- regarding technol- details regarding details. In this part, pros and cons of the
mented by the ogy, compiler, data ﬂows in the the most important applications will be
application. We’ll language and other applications in order development solu- summarized point-
focus on basic tools used to to understand how tions and patterns ing out the best
details of the soft- develop the applica- data are exchanged will be explained approaches usable
ware providing a tions. between the distrib- and described in future to solve
brief introduction to uted entities of the (rationales will be open issues.
the most important software. provided too).
elements.


Development & coding
Language and technical features

Both projects have been developed with the precise purpose of obtaining a
fast and low level system. According to such requirements, language and
architecture were choices to be taken very carefully.

Target language: Standard C++ (g++)
Rationale: Low (medium) level language, object oriented, high
performance.

Target architecture: Unix/x86
Rationale: High performance, Unix compatibility.

External resources: Boost Libraries 1.45.0
Rationale: C++ high level library for networking, interprocess,
threading, functors, binding.
Used libraries: boost::serialization, boost::asio,
boost::ﬁlesystem, boost::interprocess, boost::thread.


TaskMan-Middleware Overview
Getting started with basic dynamics

TaskMan-Middleware is a distributed kernel intended to support higher
level applications meant to manage large amounts of tasks over a network
of peers exposing available computational resources.
By taking advantage of Infrastructure-as-a-Service (IaaS) we can provide a high level application with some
APIs in order to manage tasks and their execution over a P2P network by always guaranteeing a fair share of
the computational shared resource. This approach might even lead to various forms of computing systems
able to be utilized by all people in the world.

Conceptualizing on the fly...
A collection of tasks can be submitted to a peer in order to let it being executed. A workflow
contains different numbers of tasks, they are processed by a local entity.
The local routing entity is the Manager, it decides which is the best peer where that task
must be sent to. Manager embodies complex logic.
Manager cannot decide by its own; Discovery helps him in selecting the best peer.

When a peer has been selected, it is possible to send the task to it. When a peer receives a
task, this is executed.


Setting a common ground
Definitions and assumptions

Managing a distributed kernel, we have many elements to deal with. Let’s
consider some basic aspects and some definitions that will always be with
us during the exploration of the system.

Peer: A machine of the network. It is a node of our computetional network. Every machine
is able to produce its own workflows, but must always let all other machines use its com-
putetional resources in order to execute other tasks (not belonging to the current machine).
This is needed in order to guarantee fair share.

Task: An entity to be executed. It is commonly seen as two possible types: bash command
tasks and executable tasks. The second one needs binaries to be executed.

Workflow: A collection of independent tasks to be executed.

Network: A collection of machines/peers connected, through TCP/IP protocol, one to each
other according to every possible schemes (no topology constraints applied).

Connection: A one-way link from a machine to another one. It states that the first machine
knows the second. In our system a one-way connection implicitely turns to a bidirectional
linkage because of implemented knowledge dynamics.


Main actors
Introducing UI, Manager, Discovery and Worker

Every peer embodies four important entities, everyone of them is meant to
work for a specific purpose and reach some goals. These entities interact
altogether through local connections and network connections.

UI: User Interface is meant to produce workflows to be sent to Manager in order to be
executed.
Manager: Manager works in order to execute all tasks in a workflow. It must also submit a
task to its Worker (residing in the same peer) when it comes from the network. Manager
works in symbiosis with Discovery in order to get the correct peer to send the task to.
Discovery: This component locally communicates with Manager in order to specify the
correct peer to execute a certain task. It also communicates with Worker (through the net-
work) in order to accept all their status notifications. This enables a more intelligent routing
dynamic based on a performance index evaluated basing on workers’ conditions.
Worker: This component executes a task when arriving from its Manager. It also notifies all
neighbour peers’ Discovery for its status to be changed.

Another component should be considered too: CORE. It initializes all components in the peer allowing them
to run independently as separate threads. CORE also configures the peer basing on a configuration file.


Main services
Introducing functionalities and capabilities

TaskMan-Middleware implements many services in order to reach its goals:

Task routing: In order to let the network execute a task, all workflows are managed and
each task is assigned to a specific worker on a different peer. It will be, leter, executed.
Peers’ status notification: In order to correctly route a task to the most suitable peer
(suitable here means: “the peer having the current best time-variant performance”), all
workers periodically send their status to all neighbours.
Multithreaded peers’ status management: When peers’ status notifications are received
from a peer, a thread is created in order to manage every single notification.

Multithreaded queue management: All queues are managed using threads. When a new
workflow or task must be dequeued, a new thread is created to manage it.

PUSH data sending model: When an executable task must be sent, immediately after its
sending, binaries are sent too. This automatically implies every worker to maintain a local
collection of data in order to use it when a task must be executed.

Safe sending model: When something must be sent, a control loop is considered in order
to manage unreachable destination exception.

Logging: A robust logging system is used to audit every operation occurring in the kernel.


Problems/Requirements to handle
Solving issues: easy to say, a little harder to do

There are some issues that were solved when developing our system. Previ-
ously, we introduced the most important services in TaskMan-Middleware,
now let’s try to map an issue to all those services implemented to solve it.

Fast computation Multithread

Robustness Attempts to send

PUSH sending model Collected table for data

Intelligent routing Notification system

Event tracing Synchronized logging

Configurability Configuration system

Flexibility Proxy + Factory


Development process
Development model and architecture

Development model and architecture were decided at the beginning of the
development process.
Development model: Development had to be completed very fastly. Considering time
constraints, technology and requirements for the application, a “light” and easy-to-manage
workflow was considered. For this reason the team selected a prototypal model, in particu-
lar, a spiral model in which the creation and the specialisation of a single, initial, prototype,
determined the evolution of the final software. Many branches from the original prototype
were created and others abandoned in order to get the final, working, application.

Software architecture: Due to constraints and requirements, the final application was
designed in order to reach, as first important target, Scalability. Flexibility was also consid-
ered as an important requirement, as well as Modularity. Following a responsability-chain
pattern, the team chose to develop a middleware according to a modular/multilevel plain
architecture. Thanks to this architecture, the final software defines different modules
(components) able to operate as single entities with the lowest possible interactions with
the others (loose coupling); furthermore, thanks to proxies and factories, all communica-
tions are transparent and easy-to-manage.


Data flows
Describing data exchanged among components

When running, the kernel exchanges data with all other peers. Trying to
figure a global configuration out, let’s consider first what types of communi-
cation occur among all components.
TaskDescriptor flows: All flows occurring between peers exchanging a task descriptor.
These flows are experienced during the kernel execution and typically involve peers’ Man-
ager and Discovery only.
Local flows: Exchanges happen in the same peer. Typically involve
Manager/Discovery.
Network flows: Exchanges happen between different peers. Typically
involve Manager/Manager.
WorkerDescriptor flows: All flows occurring between peers exchanging a worker descrip-
tor. These flows are experienced during the kernel execution and typically involve peers’
Manager, Discovery and Worker.
Local flows: Exchanges happen in the same peer. Typically involve
Manager/Discovery.
Network flows: Exchanges happen between different peers. Typically
involve Discovery/Worker.
Data flows: Executable tasks’ binaries exchanged between peers after routing task.


Data flows (2)
Data flows at a closer look

Proxies All three types of flow are represented:
Output port UI line styles define the type of flow. The
Input port large dashed line represents data flows
T
Task (binaries to be sent for exec tasks).
Worker MANAGER DISCOVERY

W
Stat
e : Wo
rker
Notify Des
crip
WORKER tor

State:
Work
er Descr
Se iptor
nd
Tas
k De
scr
ipt
or

Tas UI
k De
scr
ipto
r T
Sen
d
MANAGER DISCOVERY
This diagram shows all flows
W
occurring among peers.
Only two peers are shown WORKER Notify
here (for simplicity).


Inspecting interactions
Getting inside flows

After introducing flows we are ready to analyze them a bit closer and in-
spect dynamics that make possible all communications among peers.

P
Src Comp Dst Comp
R
Communication flow
O
X
Y

Every flow starts from a peer’s component to another one. ALL COMMUNICATIONS happen thanks to an
intermediate entity: a proxy whose purpose is hiding low level communication dynamics and avoiding
communicating entities to know how they are communicating (it can be over the network or locally).
By doing so (and taking advantage of factory creation pattern) it is possible to extend our model to a
Cient/Server one by just modifying proxies. This approach provides simplicty, flexibility and scalability.


TaskDescriptor flow
Before sending

Let’s consider the ﬁrst steps occurring when a workﬂow is created and then
submitted for its execution.
A new thread is
created to
manage the Each task is A worker Ready to send
Workflow is sent to workflow after considered address is the task to the
Manager through a local it has been inside the returned to obtained
M proxy by UI. dequeued. workflow. Manager. worker.
A
N

TD
WF
Addr

D
I
UI S
A new workflow is C A new request for a
generated with a casual worker descriptor arrives
number of tasks inside it. from Manager. A task Local comm.
descriptor is provided Net comm.
along with this call.

TIME


TaskDescriptor flow (2.a)
After sending - sending a command task

Manager knows now the destination peer. Manager also evaluates that a
command task must be sent, let’s see what happens.

Task is dequeued Task typology
Task to send is and a new thread is is evaluated, it
M recognized to be created to manage it. is a command Task is
a command task. task. EXECUTED.
A W
N 2
1

TD
TD

M
A
N
The task arrives to The task is
2 Manager on the enqueued in
other peer. task queue Local comm.
residing on Net comm.
Worker by a
specific thread.
TIME


TaskDescriptor flow (2.b)
After sending - sending an executable task

What if the task were an executable one? Manager has to perform a diﬀer-
ent activity and a new dynamic is considered.
Local comm.
Net comm.
Task to send is
recognized to be Binaries (data) Data is
M an executable are sent considered and
task. directly to managed by a Data is inserted
A destination specific well in a local
N peer’s Worker. created thread. collection.
1
Data
W
TD 2
TD
M
A Task is sent Task is Task is The internal
N to local dequeued and recognized to collection of task data
The task arrives to The task is Worker. a new thread is be an is searched. When
2 Manager on the enqueued in created to executable data is found (many
other peer. task queue manage it. task, need to attempts are
residing on retireve its performed) then the
Worker by a data. task is EXECUTED.
specific thread.
TIME


WorkerDescriptor flow
Sending and receiving notifications

Let us focus on a Worker. Every Worker has an internal contol loop that de-
tects status changes. Status notiﬁcations are sent to neighbour peers.

Status
A status Status notification is
Status control change has notification is sent to ALL
loop activates. been detected. formed. neighbours.
W
1
To other
neighbours.
WDs
WD

D
I
S
C The notification A new thread is The new status
2 reaches the Discovery created to of the peer who
Local comm. of one neighbour manage the sent the
Net comm. peer. notification. notification is
updated or
added.
TIME


Summarizing flows
To get the ball rolling...

Summarizing everything, we can say the following:

As the kernel runs and the network is working, a peer can communicate to its neighbours
using some flows. Each flow involves two different components on the same or in different
peers, or two same components in different peers.
All communications are performed using proxies. In particular, a proxy is created using its
factory.

Three flows ensure that a task can be successfully executed with the lowest possible effort.
This is guaranteed by taking advantage of network communications and worker status noti-
fications.
When trying to send something, every component calls a proxy. All sending procedures in
proxies are safe. The possibility that destination peer is temporary unreachable is consid-
ered and many attempts are made trying to successfully send the payload. After a max
number of attempts, only in this case, the sending process is aborted.
Discovery can take the correct decision, to choose a peer, thanks to the notification system.
To evaluate the best peer a comparison between PIs (Performance Index) is performed. PI
ensures that the current best (having the best performance) peer will be selected to execute
a given task.


Deep diving into implementations
Getting started with code, design and algorithms

Let’s have a much closer look to everything we’ve introduced up until now.
We are going to consider the most important elements focusing on chosen
strategies and solutions in order to face all issues and avoid code ﬂooding.

ADDRESSING MULTITHREADING
CONFIGURATION

RUNNABLE CLASSES PROXY(ING)
PERFORMANCE INDEX

SYNQUEUE(ING) TDC GCOLLECT(ING)

NOTIFICATION SYSTEM SYNLOGGING


Peer addressing
Network interfaces of every single peer

Every peer dialogues to all its neighbours thanks to
three specific TCP ports on a common IP address. ADDRESSING
The collection of the IP addr and the three ports,
defines the peer network interface.
The Address class is responsible for
IP addr: Specifies the unique network location of the peer
containing all the necessary informa-
where it is reachable over the INet.
tion for the peer network interface.
Man2Man port: Specifies the TCP port where the current This class is an associated member of
peer’s Manager can listen for incoming TaskDescriptor to the Worker class.
be executed by the local Worker.

Man2W port: Specifies the TCP port where the current 01 namespace middleware {
02 typedef string InetIpAddr;
peer’s Worker can listen for incoming data (bins) sent by 03 typedef _uint InetPort;
another peer’s Manager after sending an executable task. 04 class Address {
05 bool operator==(..) {..}
W2Disc port: Specifies the TCP port where the current 06 bool operator!=(..) {..}
07 InetIpAddr _ip;
peer’s Discovery can listen for incoming WorkerDescriptor 08 InetPort _port;
in order to update performances of all its neighbours. 09 InetPort _port_disc;
10 InetPort _port_w;
Network interface is set by CORE class at initialization time 11 };
12 }
basing on settings inside the configuration file.


Multithreaded components
Where a thread could be used... it was

Every component runs as a thread in the context of
the main application. Every component also creates MULTITHREADING
its own threads in order to perform all tasks in the
best (fastest) possible way (minding concurrency).
01 namespace middleware {

Worker Status Manager
02 typedef struct {
TaskManager

Manage Task
Manage WD
Manage WF

DataSender
03 string man_ip_to_man_bind;
DataSend

04 string
05 man_port_toman_bind;
06 Worker* ptrto_worker;
* * * 07 WorkerDiscovery*
08 ptrto_discovery;
09 string log_postfix;
10 } ManagerConfig;
11 class Manager
Create/Submit WF

Worker Descriptor

12 : public Runner {
arrival listener
Deque WF

Deque TD

13 void exec() {..}
14 void
UI MAN DISC W 15 exec_taskmanager() {..}
16 void enqueuer(..) {..}
17 public:
* = More instances of the
thread are created 18 void run() {..}
19 void join() {..}
20 };
= This is a thread
21 }
CORE


Configuring the kernel
Configuration file and syntax

The kernel is initialized thanks to a configuration file.
If no configuration file is provided, the kernel fails CONFIGURATION
running, and quits.
The main actor is the configuration file. It is a plain text file with a very simple line-oriented syntax. All set-
tings for the current peer are stored in the file. CORE class acquires the configuration file and sets all compo-
nents using settings in the file. Taking advantage of this cascade configuration flow, the application can get
scalability and flexibility. Typically, configuration files are named using the .config extension.

01 C:Every unrecognized sequence (before :) is treated as a comment (by def, C).
02 C:Every line is a configuration entry, recognized sequences are processed.
03 C:--------------------------------------------------------------------------------
04 C:Configuring the current peer
05 CONFIG_ADDRME_IP:127.0.0.1
06 CONFIG_ADDRME_MAN_PORT:1040
07 CONFIG_ADDRME_DISC_PORT:1041
08 CONFIG_ADDRME_W_PORT:1042
09 C:--------------------------------------------------------------------------------
10 CONFIG_OTHERPEERS_NUM:1
11 C:--------------------------------------------------------------------------------
12 C:Configuring beighbour knowledge
13 CONFIG_ADDRPEER_1_IP:127.0.0.1
14 CONFIG_ADDRPEER_1_TASKS_PORT:2040
15 CONFIG_ADDRPEER_1_WRKRS_PORT:2041
16 CONFIG_ADDRPEER_1_DATA_PORT:2042


Making things runnable
Patterns used to develop runnable classes

To achieve good programming style and in order to
let code be easy-to-read, all classes to be run as a RUNNABLE CLASSES
thread are provided with two methods inherited by
an interface (a pure C++ virtual method class, that is
an abstract class).
The interface.hpp file defines a nice trick to let C++ “recognize” the interface keyword. All interfaces can be,
so, declared using the interface keyword.
All interfaces are implemented by simply using the colon notation as for inheritance system.
The Runner interface defines the two needed methods to let a class be runnable.

The interface keyword defini- The Runner interface definition. Definition of Worker class, note
tion. how to make it runnable.
01 #ifndef _INTERFACE_HPP_ 01 namespace middleware { 01 #include “runner.hpp”
02 #define _INTERFACE_HPP_ 02 interface Runner { 02 namespace middleware {
03 03 public: 03 class Worker
04 // The trick 04 // Runs thread 04 : public Runner {
05 #define interface class 05 virtual void run() = 0 05 // Runnable class body
06 06 // Joins thread 06 };
07 #endif 07 virtual void join() = 0 07 }
08 };
09 }


Communications through proxies
Managing communications using proxy pattern

As said before, all communications are performed by
means of proxies, this enables the application to PROXY(ING)
reach scalability and ﬂexibility.
When a component needs to communicate with another one located in the same peer or in a diﬀerent one,
a proxy is used. By doing so it is possible to hide communication implementation/logic to that component
with the result that it will never know whether the communication is a local call or a remote connection.

ALL PROXIES are created via a corresponding factory. ALL FACTORIES ARE FRIENDS OF THE CORRESPONDING
PROXIES; this ensures that the proxy will be properly instantiated. As a consequence, ALL PROXIES HAVE
PRIVATE CONSTRUCTORS.

THE POINTER-SAFE FACTORY PATTERN IS 01 namespace middleware {
USED FOR FACTORIES. It means that a fac- 02 class TaskProxyFactory {
03 TaskManagerProxy* _proxy;
tory returns the pointer to the constructed 04 public:
proxy which is dynamically allocated by the 05 // Constructors
factory itself. ALL FACTORIES HOLD THE 06 TaskProxyFactory();
07 TaskProxyFactory(..);
POINTER TO THE WELL-CREATED PROXY, in 08 // Destructor
this way, WHEN A FACTORY GOES OUT OF 09 ~TaskProxyFactory() {
10 if (this->_proxy != 0)
SCOPE (destructor is called), THE PROXY 11 delete this->_proxy; }
WILL BE DESTROYED TOO. So the created 12 };}
proxy must come along with its factory.


Evaluating performance index
How to decide which peer is the best to execute a task?

All peers have many time variant information, for
example, the number of task in queue waiting to be PERFORMANCE INDEX
executed. A PI is assigned to every peer basing on
these information, the best peer to send a task to is
the one having the highest PI.
NETWORK FACTOR: Defines a non-linear negative-
2nd-order-derivative dependency between band-
width and hop-distance

SPEED FACTOR: Defines an alge- CAPACITY FACTOR: A non-
bric dependency among cpu linear factor to let cores
speed, number of processors and memory not weigh too
and current queue size much on final result


Synchronized queue
A class to store tasks and workflows minding concurrency

One idea: collapsing everything it is needed to let
many entities to be collected together (minding or- SYNQUEUE(ING)
dering) and let many threads operate on the collec-
tion avoiding data non-consistency.

SynQueue is a an object developed with SynQueue is generic and
the intention of managing tasks and accepts all possible types as
workﬂows to be enqueued in a sequence input.
collection able to keep its consistency An internal mutex and an
even when many threads operate on it. internal condition variable are
used to keep the collection
consistent.
01 using namespace middleware::queueing
02 // Max 10 task descriptor
03 SynQueue<TaskDescriptor, 10> q;
04 // Infinite capacity queue
05 SynQueue<TaskDescriptor> qq;


Task Data Collection GCollecting
Garbage collection policy for TDC in Worker

When data (binaries of an executable task) are sent
to Worker, they are stored in a temporary place to TDC GCOLLECT(ING)
stay, waiting to be extracted when the corresponsing
task descriptors arrive.
TDC is susceptible of probable data inconsistency because of binary data never extracted (caused by task
descriptor loss over the network after sending). Because of this, a control loop is necessary to periodically
check for old entries. This loop resides in a thread properly created by Worker at initialization time.
Every entry of the table is provided with a TimeToLive initialized to a value and decreased every cycle. When
TTL reaches 0, the entry is removed.

TTL = 100 TTL = 99
TTL = 11 TTL = 10
TTL = 51 TTL = 50 REMOVED
TTL = 1 TTL = 0
TTL = 120 TTL = 119
TTL = 23 TTL = 22
TTL = 110 TTL = 109
TTL = 25 TTL = 24


Notifying status change
Intelligent P2P

Inside Worker a well created thread is up to manage
Worker status. When a change in the Worker status NOTIFICATION SYSTEM
(change of PI) is detected, the system reacts sending
the new WorkerDescriptor to all neighbour peers The notification loop can be repro-
advising them to change their knowledge and grammed in order to send notifica-
tions even without caring about
update all PIs of neighbours. The notification is sent status change.
to every peer’s Discovery.
When notifications are sent by a Worker, these reach the corresponding destination peer’s Discovery.
Discovery, in each peer, has a cotrol loop listening on a configured port and waiting for incoming WorkerD-
escriptor to arrive. When a WorkerDescriptor arrives, it means that a neighbour has sent a notification and
that that peer’s status must be changed.

Notifications ensure that Discovery is able to get a Worker for a task (to Manager when questioned) choosing
the most suitable peer. This makes the general system more intelligent. If a peer has a very long queue of
tasks to execute, maybe the current task should be dispatched to a different peer. But if that peer has a very
powerful CPU and many cores, maybe that long queue of tasks will be shortly executed.

The notification system and PI provide the kernel with an intelligent way to dispatch tasks among peers.


Logging system
Auditing and tracking events

A well structured logging system ensures the possi-
bility to trace all the most important events in the SYNLOGGING
system. The system is based on files.
SynLogging is a very versatile system to create logs for one or more runs of the kernel. The system is meant
to create four log files for each component in the application. Many peers might run on the same machine,
so a postfix is used to differentiate a peer from another one and avoiding collisions.

Logging can be performed in separate or “dense” mode: it is possible to create a log for each component, or
a common log for eveyone of them. Furthermore, if no postfix is specified for the current peer, all non-
postfixed peers will operate on the same files and will log their content on a common location. This happens
because the file writing policy is “open/append or create new”.

DISC
OR
MAN
LOG
APP LOG APP
COMMON
LOG
UI W
LOG LOG

Differences on INet Protocols
UDP and file transfer mode

In our projects, one of the most important differences relies on used Inter-
net protocols in order to set communications among peers.

According to project requirements, we implemented our system communications using
UDP/IP protocol. Lack of connection allows the system to be more flexible and fault tolerant
when responding to node crashes or connection failures. On the other hand, the implemen-
tation of a well designed protocol to manage reliability had to be considered, thus, incre-
menting the development process complexity.

Another source of difference between both projects was the sending model used to transfer
files and binaries of executable tasks. Rather than using a PUSH model, a PULL model was
considered.

PULL sending model is able to reach high performance and reliability thanks to the ability to
download binaries when needed, avoiding unnecessary waste of bandwidth and problems
concerning receiver to keep an internal collection to store data (introducing all problems
regarding garbage collection and so on).


Crossing platforms
Executing tasks and managing cross-platform issues

Running processes and handling filesystem suggests cross-platform compli-
ance, this was a delicate issue to manage.

boost::process is not officially part of the Boost Project. For this reason, no cross platform
compliant operations were available in order to run processes (received tasks) and access
the filesystem.

We considered the usage of standard Posix libraries. This implies the necessity to develop
platform-dependent solutions in order to execute processes and to handle file permissions.

Implementation-wise, execve() and chmod() calls were used; available only on Posix-
compliant systems.


Final considerations
Enhancements, applications and issues

TaskMan-Middleware is not a complete software, it is meant to be scaled in
future and also provided with more functionalities. There are also some
issues to worry about, let’s see, now, the most important information.

Licensing system: GNU GPL (General Public License) v. 3.0
Rationale: Possibility to enlarge current implementations, adding new ones and solving
current issues.

Code location: Hosted on Google Code Project @ http://code.google.com/p/taskman-
middleware.

Most important scaling target: The possibility to act on the kernel in order to support
both P2P and Client/Server models by simply operating on proxies. Thanks to the
proxy pattern it is possible to re-implement all proxies in order to let them make the
entire system work as a client or a server or a peer.


Issues and little pathologies
Elements to be solved

TaskMan-Middleware suffers from some issues due to time constraints and
development resources.

Code style: There are some stylistic issues to be solved regarding, expecially, printing. No
class still supports the << operator in order to create an output of data. Logging classes use
a print() method instead of a static stream like “cout” in conjunction with a properly <<
operator overloaded on it.

Inheritance: Only some classes defines an internal environment ready for future subclass-
ing. Most classes do not use protected members and, so, do not imply a future extension for
new implementations.

Tasks: At present, tasks can be command or executables, but, for the project’s ends, no real
task final execution is performed, just simulated. It is possible to extend (not even much
effort is required for this step) the system and effectively execute a command or a binary
when it reaches the final destination.

Task generation: At present, workflows are created randomly by UI. User cannot directly
assemble a workflow and submit it using a properly user interface. It is possible, in future,
to create a front end to let users create and submit workflows.


Applications and future projections
What can it be...

TaskMan-Middleware has many possibilities regarding scaling and exstensi-
bility. The current implementation can be modiﬁed in order to support new
functionalities and new services.

GUI: There are many C++ libraries for graphic user controls and interface elements. Most of
them are not open (like Borland, DevExpress) but many are free and open too. It would be
possible to create a GUI for the kernel in order to better print events on tables or also taking
advantage of many interactive controls for a better user usage experience.

Charting: Many companies are specialised in charting and they develop solutions and APIs
to provide rendering and charting controls to developers (like DevExpress for Borland appli-
cations). It would be possible to take advantage of logging classes and implement data
structures for rendering all logs and getting statistics about network conditions, throughput,
statistical approximation and much more.

QoS: It would be possible to act on proxies in order to provide information about the qual-
ity of software, especially regarding network communication, packet loss, turnaround time,
timings, events and much more.


DANKE GRAZIE THANK YOU ありがとう HVALA

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (16)

Andere mochten auch

Andere mochten auch (10)

Mehr von Andrea Tino

Mehr von Andrea Tino (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)