• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
TaskMan-Middleware 2011 - Advanced implementation
 

TaskMan-Middleware 2011 - Advanced implementation

on

  • 173 views

A standard C++ distributed middleware for workflow management over a P2P INET TCP/UDP IP Push/Pull-Sending-Model oriented network.

A standard C++ distributed middleware for workflow management over a P2P INET TCP/UDP IP Push/Pull-Sending-Model oriented network.

Statistics

Views

Total Views
173
Views on SlideShare
173
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    TaskMan-Middleware 2011 - Advanced implementation TaskMan-Middleware 2011 - Advanced implementation Presentation Transcript

    • .cpp Development Project for Distributed SystemsTaskMan-Middleware 2011A Standard C++ distributed middleware for workflow management over a P2P INETTCP/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 teamsDescription of team componentsThe Project was started by both teams and advanced, together, in the initialsteps. The following core design and development stages were terminatedseparately, getting two softwares with different 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 TeamingAn overview of teams involved in the c++ project branchTwo teams were involved in the development of a C++ middleware kernelfor workflow management and execution. Both teams had some chances towork 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.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Presentation flowPresenting solutions, patterns and choicesWe are now going to describe and discuss the main characteristics of bothprojetcs focusing on design choices and implementative solutions (trying toalways 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 flows 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.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Development & codingLanguage and technical featuresBoth projects have been developed with the precise purpose of obtaining afast and low level system. According to such requirements, language andarchitecture 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::filesystem, boost::interprocess, boost::thread.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • TaskMan-Middleware OverviewGetting started with basic dynamicsTaskMan-Middleware is a distributed kernel intended to support higherlevel applications meant to manage large amounts of tasks over a networkof 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.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Setting a common groundDefinitions and assumptionsManaging a distributed kernel, we have many elements to deal with. Let’sconsider some basic aspects and some definitions that will always be withus 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.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Main actorsIntroducing UI, Manager, Discovery and WorkerEvery peer embodies four important entities, everyone of them is meant towork for a specific purpose and reach some goals. These entities interactaltogether 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.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Main servicesIntroducing functionalities and capabilitiesTaskMan-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.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Problems/Requirements to handleSolving issues: easy to say, a little harder to doThere 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 + FactoryTaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Development processDevelopment model and architectureDevelopment model and architecture were decided at the beginning of thedevelopment 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.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Data flowsDescribing data exchanged among componentsWhen running, the kernel exchanges data with all other peers. Trying tofigure 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.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • 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 DISCOVERYThis diagram shows all flows Woccurring among peers.Only two peers are shown WORKER Notifyhere (for simplicity).TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Inspecting interactionsGetting inside flowsAfter 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 YEvery flow starts from a peer’s component to another one. ALL COMMUNICATIONS happen thanks to anintermediate entity: a proxy whose purpose is hiding low level communication dynamics and avoidingcommunicating 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 aCient/Server one by just modifying proxies. This approach provides simplicty, flexibility and scalability.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • TaskDescriptor flowBefore sendingLet’s consider the first steps occurring when a workflow is created and thensubmitted 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. TIMETaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • TaskDescriptor flow (2.a)After sending - sending a command taskManager knows now the destination peer. Manager also evaluates that acommand 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. TIMETaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • TaskDescriptor flow (2.b)After sending - sending an executable taskWhat if the task were an executable one? Manager has to perform a differ-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. TIMETaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • WorkerDescriptor flowSending and receiving notificationsLet us focus on a Worker. Every Worker has an internal contol loop that de-tects status changes. Status notifications 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. TIMETaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Summarizing flowsTo 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.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Deep diving into implementationsGetting started with code, design and algorithmsLet’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 chosenstrategies and solutions in order to face all issues and avoid code flooding. ADDRESSING MULTITHREADING CONFIGURATION RUNNABLE CLASSES PROXY(ING) PERFORMANCE INDEX SYNQUEUE(ING) TDC GCOLLECT(ING) NOTIFICATION SYSTEM SYNLOGGINGTaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Peer addressingNetwork interfaces of every single peerEvery peer dialogues to all its neighbours thanks tothree specific TCP ports on a common IP address. ADDRESSINGThe 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.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Multithreaded componentsWhere a thread could be used... it wasEvery component runs as a thread in the context ofthe main application. Every component also creates MULTITHREADINGits own threads in order to perform all tasks in thebest (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 } CORETaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Configuring the kernelConfiguration file and syntaxThe kernel is initialized thanks to a configuration file.If no configuration file is provided, the kernel fails CONFIGURATIONrunning, 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:2042TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Making things runnablePatterns used to develop runnable classesTo achieve good programming style and in order tolet code be easy-to-read, all classes to be run as a RUNNABLE CLASSESthread are provided with two methods inherited byan interface (a pure C++ virtual method class, that isan 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 }TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Communications through proxiesManaging communications using proxy patternAs said before, all communications are performed bymeans of proxies, this enables the application to PROXY(ING)reach scalability and flexibility. When a component needs to communicate with another one located in the same peer or in a different 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.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Evaluating performance indexHow to decide which peer is the best to execute a task?All peers have many time variant information, forexample, the number of task in queue waiting to be PERFORMANCE INDEXexecuted. A PI is assigned to every peer basing onthese information, the best peer to send a task to isthe one having the highest PI. NETWORK FACTOR: Defines a non-linear negative- 2nd-order-derivative dependency between band- width and hop-distanceSPEED 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 resultTaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Synchronized queueA class to store tasks and workflows minding concurrencyOne idea: collapsing everything it is needed to letmany 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 workflows 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;TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Task Data Collection GCollectingGarbage collection policy for TDC in WorkerWhen data (binaries of an executable task) are sentto Worker, they are stored in a temporary place to TDC GCOLLECT(ING)stay, waiting to be extracted when the corresponsingtask 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 = 24TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Notifying status changeIntelligent P2PInside Worker a well created thread is up to manageWorker status. When a change in the Worker status NOTIFICATION SYSTEM(change of PI) is detected, the system reacts sendingthe 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 aboutupdate 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.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Logging systemAuditing and tracking eventsA well structured logging system ensures the possi-bility to trace all the most important events in the SYNLOGGINGsystem. 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 LOGTaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Differences on INet ProtocolsUDP and file transfer modeIn 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).TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Crossing platformsExecuting tasks and managing cross-platform issuesRunning 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.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Final considerationsEnhancements, applications and issuesTaskMan-Middleware is not a complete software, it is meant to be scaled infuture and also provided with more functionalities. There are also someissues 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.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Issues and little pathologiesElements to be solvedTaskMan-Middleware suffers from some issues due to time constraints anddevelopment 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.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • Applications and future projectionsWhat can it be...TaskMan-Middleware has many possibilities regarding scaling and exstensi-bility. The current implementation can be modified in order to support newfunctionalities 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.TaskMan-Middleware 2011 by M. Buzzanca, D. G. Monaco, R. Pulvirenti, G. Ravidà and A. Tino Distributed Systems Project 2011
    • DANKE GRAZIE THANK YOU ありがとう HVALA