CONFIIT : a middleware for peer-to-peer computing - Semantic Scholar

Noname manuscript No. (will be inserted by the editor)

CONFIIT : a middleware for peer-to-peer computing Oliver Flauzac · Michael Krajecki · Luiz-Angelo Steffenel

Received: date / Accepted: date

Abstract CONFIIT (Computation Over Network with Finite number of Independent and Irregular Tasks) is a purely decentralized peer-to-peer middleware for grid computing. This paper presents CONFIIT main features and how it deals with topology changes and communication faults. To illustrate CONFIIT operation, we demonstrate how the car-sequencing problem can be solved in a distributed environment. Keywords P2P · distributed computing · grid computing · car-sequencing problem

1 Introduction During many years, computation and storage were done in a local way. A few years ago, a new approach emerged: the distribution of computation and storage over a network. This new approach tends to the use of all available computational resources from a local network, and to a larger scale, from the Internet. This new paradigm is called GRID computing. In [15], authors discussed arising issues related to this new paradigm, and explained how to design efficient GRID based solutions. CONFIIT, introduced in [13], is a purely decentralized peer-to-peer middleware. It was designed to cope with joining the computation means to be used on a local area network or on the Internet, all while providing fault tolerance and autonomy to the peers. This paper we focus on the description of CONFIIT architecture and how it can be used to easily deploy a given application over a distributed computing environment. Hence, we illustrate its operation through the study of the parallel deployment of a car-sequencing problem solver. Additionally, we introduce GRAPP&S, the next step towards CReSTIC-SysCOM, Universit´ e de Reims Champagne-Ardenne, BP 1039, F-51687 Reims Cedex 2, France E-mail: [email protected]

2

CONFIIT evolution. The GRAPP&S framework aims to improve CONFIIT scalability and interoperability aspects. The rest of this paper is organized as follows: firstly, we present actual issues in GRID computing. Section 3 describes the CONFIIT framework. We detail how the topology management is used to improve robustness, and how tasks are locally and globally scheduled on processors. Section 4 illustrates how the car-sequencing problem can be implemented in this computing model. Section 5 briefly presents GRAPP&S and the features we are working on to extend CONFIIT. Finally, Section 6 presents our conclusions. 2 Related works The GRID computing concept appeared in the 90’s, as an extension on the Internet of the cycle stealing principle. Former applications aimed to crack by exhaustive search encryption keys based on RC5 or DES algorithms. They showed the opportunity of aggregating hundreds of PCs to solve a problem. Web-based Computing projects arose at the end of the 90’s, as Charlotte [7], Bayanihan [24] or SETI@home [2, 3]. Indeed, the SETI@home project [2, 3] popularized the Global Computing concept. It was designed for Searching ExtraTerrestrial Intelligence, distributing tasks on thousands of computers on Internet. The current version of the project is based on the BOINC platform [4], and gathers more than 30 TeraFlops simultaneously. It has already produced more than the equivalent of 500,000 years of computation on a PC. After SETI@home, dozens of academic or industrial projects were developed. In the former world, projects are often dedicated to a single application (as Distributed.net) or propose complete environments: XtremWeb1 or OurGrid2 . GRID applications are actually designed for two main purposes: data sharing and distributed computation. Whereas data sharing applications aim to share and recover data through a network, distributed computation applications aim to share a computation over a network and build a global solution. In the remaining of this paper, we will focus almost exclusively on distributed computation GRID applications. Hence, the GRID related issues can be classified in three main categories. (i) applications specially designed to compute a particular problem. The most known application of that category is the SETI project, designed to Search for Extra Terrestrial Intelligence. (ii) protocols and libraries, put together to help in writing a dedicated GRID application. JXTA project is an example of this category [23]. It proposes a peer-to-peer communication protocol, platform and language independent. (iii) middlewares offering different services (grid construction and management, task sharing management and results gathering). In this last group we can find Globus [14, 1], XtremWeb [12], DIET [10] or ProActive [6]. 1 2

www.xtremweb.net www.ourgrid.org

3

Whatever the application is, and whatever the means are, a GRID based application has to verify some properties to be efficient [16, 17]: (1) sharing hardware and software capacities and capabilities, (2) scheduling the use of these means and the capability of peer-to-peer computation over Internet. F. Capello presented the topical issues of peer-to-peer globalized computation system in [9]. Notice that authors propose partially centralized, or hybrid decentralized architecture, in most cases [5]. For example, DIET is a hierarchically centralized system: global information is maintained in replicated servers, called Master Agents, and a given computer organization is managed by Local Agents. Also, the BOINC [4] framework consists of two layers that operate under the client-server architecture.

3 CONFIIT middleware 3.1 FIIT applications The notion of FIIT applications was defined in [20], and they are composed by a Finite number of Independent and Irregular Tasks (FIIT). We assume that each task satisfies the following features: – A task cannot make any hypothesis on the execution of any other one. Hence, there is no communication between tasks. – Execution time of each task is unpredictable. In other words, we cannot have a good estimation of the execution time before a task ends. – A same algorithm is applied to compute all tasks. Hence, two tasks are distinguished by the set of data they have to process. The well-known Mandelbrot’s set [11] can be seen as a FIIT application: each pixel (or set of pixels) can be computed independently from the others, and its computation time is unpredictable since it depends on the corresponding region. In such a framework, the programmer needs to answer two questions: (i) How to divide the problem into a finite number of independent tasks? (ii) How to compute each individual task? The choices carried out are significant: decomposition granularity (number of tasks) influences load-balancing quality and impacts the use of the interconnection network [27]. If the problem is divided into too small tasks, scheduling will induce too many communications. Conversely, if the number of tasks is too small in comparison with the number of nodes, resolution will not able to exploit available parallelism. Thus, decomposition has to be adapted to the underlying computing environment (nodes architecture and interconnection network).

4

3.2 CONFIIT outline CONFIIT (Computation Over Network for FIIT), introduced in [13], is a middleware for peer-to-peer computing. It aims to: – distribute over the network all the tasks obtained by decomposition of a FIIT problem, – solve each distributed task, – spread computed results of each task over the network. Each computer collaborating in a CONFIIT computation is called a node. A node is set up with three main basic thread components: a topology and communication manager, a tasks manager and one or several task solvers, dedicated to one problem. The nodes are connected according to a logical oriented ring, set up and maintained by the topological layer of the system. Basically, each node knows its predecessor and successor. Communications between nodes are achieved using a token, carrying the state of computation around the ring. Actually, the main goal of the ring is to achieve load balancing between nodes. Task status are exchanged to broadcast local knowledge on all nodes, and thus, to compute an accurate global view of the calculus. At the end of the computation, the ring spreads termination on nodes. A task manager can cope with several tasks solvers. Typically, one tasks solver should be launched for each processor on the node. Over and above the three main thread elements, each node owns a set of data representing the entire problem, and the local known state of the global computation.

3.3 Programming models Since constraints of a given application could be different and sometimes in contradiction (fault tolerance, efficiency, . . . ), CONFIIT offers two main programming models: distributed and centralized mode. The distributed mode allows an accurate fault tolerance in the computation since task results are locally stored on each node in the community. Thus, a broken computation can be re-launched using already computed tasks. Figure 1 shows information exchanges in the community for a distributed application. At first, the launcher sends the computing request to a node. The request is propagated along the community by the token (dotted arrows). During computation, results of individual tasks are propagated across the community (thick dashed arrows) such that each node could locally store all individual results (data blocks). Concurrently to the computations, information on the global computation is exchanged according to the thin arrows. Another interesting point from this mode is that the launcher only needs to be connected during the initiation phase. At the end of the computation, the global result can be retrieved from any node in the community.

5

While this mode allows greater flexibility and fault tolerance, it may induce the need of a large storage space on each node. Similarly, as results must be spread to each node, it may overload slow network connections.

launcher

receiver

Fig. 1 Distributed mode

The centralized mode reduces the global load of storage space and network communications, with the drawback of reducing fault tolerance. Figure 2 shows information exchanges in the community for a centralized application. At first, the launcher sends the computing request to a node. The request is propagated along the community by a specific token (dotted arrows) as in the distributed mode, but the launcher must remain connected. During computation, results of individual tasks are sent to the initial launcher (thick dashed arrows), which has the storage in charge (data blocks). As in the distributed mode, information on the global computation evolution is updated through the token (thin arrows). A crash on a computing node is not a problem for the computation since the main community ring is fault tolerant, but a crash on the launcher will stop the computation because the gathering of information cannot be achieved.

launcher

Fig. 2 Centralized mode

6

3.4 Java based implementation To illustrate the operation of CONFIIT, we implemented it in Java, structured around six main classes [21]. The class Confiit contains the main program. The instances of the problem (MyApplication class) are linked to the middleware by implementing the abstract class Application.

1

ThreadRing

1

1

1

1

1

1 1

ThreadToken

1

1

Confiit

Param

1

1 0..*

0..*

Resolve

1

1



MyApplication

Application

Fig. 3 Diagram of CONFIIT classes.

Figure 3 summarizes the architecture of CONFIIT prototype achieved in Java. Communications are not shown here. They are performed with XMLRPC [26] calls. All messages are sent by synchronous calls so a node has an immediate acknowledge. When a node needs to send information, it uses an XmlRpcClient object to ”call” distant node. Effective message is transmitted by RPC parameters.

3.5 Initialization When a node initiates a computation, it first gathers data necessary to the application. When a node joins an existing logical ring, it gets execution parameters from a distant node already inserted in the logical ring. After initialization, the main program instantiates a Param object, which gathers the set of information shared by all threads in the node. Mainly, it memorizes a local view of the global computation. Service Threads are then instantiated: – ThreadRing for ring management. It memorizes topological information and offers several callable methods: – InsertNode to allow a new node to enter in CONFIIT ring. It can be seen as a public call (implemented as a XML-RPC call) since every computer can call it to become a CONFIIT node. – AddNode to allow broadcasting of information on a new node insertion.

7

– DeleteNode to allow broadcasting of information on a new node deletion. AddNode and DeleteNode calls can be seen as private calls since they are used by CONFIIT for information transmission between registered nodes. – SendToken to allow ThreadToken to send a token according to the logical ring topology. It’s an internal call, not implemented via XMLRPC calls. – ThreadToken for token management. It updates local view of the computation (in Param) according to a received token, and globally spreads tasks information on the ring. It implements only one XML-RPC service: TokenReceive to propose an exchange point of information. – Resolve for tasks resolution. No callable methods are provided here, but the thread computes the different tasks by calling the application object that implements the Application abstract class.

3.6 Topology management All topological managements are performed in class ThreadRing. To achieve robustness according to computer crash-downs and dynamic evolution, it maintains a central structure representing the ring topology. Each node participating to the computation knows each other. Information is stored in a Java Hashtable called ring. We extend the fault tolerant mechanism summarized in [18] on rings to the concept of k-tolerance to recover a functional ring when k successive nodes simultaneously fall down in an n-sized ring (k < n). As ring is a local data, a data exchange must be performed to maintain a global view of the ring in each node. If we assume the token for computational state follows the logical ring clockwise, each change in ring topology involves a special token that circulates counterclockwise. Thus, when a node enters or exits the ring, nodes that are the most interested by the information (before it clockwise) are informed first. From the point of view of a given node, communications are initiated by itself or by another node. When the node initiates communications, it has a client behavior since it contacts another node. When communications are initiated by another node, it has a server behavior since it offers a service to other nodes. The operation is considered as pushing something. The main impact of this duality is that nodes have to accept communication initiated from and toward each other nodes. So firewalls must be configured friendly for CONFIIT communications. Accordingly, a two-way handshake between the nodes is used to check if they can exchange information in both directions. 3.6.1 Entering the ring Entering facility is provided by the main public call in the class ThreadRing: InsertNode. In a normal mode, the thread is blocked, waiting for a call. A

8

Algorithm 1 DefineTasks XML-RPC call. 1 2 3 4 5

proc DefineTasks ( next, parameter) add add in ring process parameter start resolution

Algorithm 2 InsertNode XML-RPC call. 1 2 3 4 5

proc InsertNode ( requester) call DefineTasks ( next, parameter) from requester add in ring call AddNode ( me, requester, me) from predecessor sendTopology ( requester)

Algorithm 3 AddNode XML-RPC call. 1 2 3 4

proc AddNode ( node, new, initiator) if initiator 6= me then add in ring call AddNode ( node, new, initiator) from predecessor

node wanting to enter in the ring calls the XML-RPC InsertNode procedure, with its identification as a parameter. See Algorithm 1 for a scheme of the caller-side protocol. We assume method add keeps an accurate track of a node and its successor in the ring topology. The caller attempts to receive a DefineTasks auxiliary call to define its position in the ring and computation parameters. Then, tasks resolution starts. Its local definition of the global view of the ring can be updated by successive AddNode calls (see below). The server-side of InsertNode procedure implies to change the local structure of ring and to spread it to every nodes in the ring. The requester is inserted after the local node in the ring. Algorithm 2 shows a pseudo-code for InsertNode procedure. We assume that the method sendTopology sends the whole ring topology to the designated node. This is achieved by successive calls to the AddNode method with each node and its successor as parameters, as presented in algorithm 3. Thus, a new node will receive and update its local ring structure directly from its new predecessor. Conversely, other nodes are informed of the modification by a special token from their own successor. If the initiator of the broadcast is the local node, spreading is stopped (this prevents infinite spreading), the new node is added in the local ring structure, and insertion is sent to the previous node. Additionally, as the initiator can crash before stopping its own spreading, each node should verify if the initiator is already in its ring structure before broadcasting the insertion.

9

Algorithm 4 DeleteNode XML-RPC call. 1 2 3 4

proc DeleteNode ( node, initiator) if initiator 6= me then delete in ring call DeleteNode ( node, initiator) from predecessor

3.6.2 Exiting the ring A node can exit a CONFIIT computation ring for three reasons: (i) the user decides to stop computing collaboration, (ii) a network problem occurred and the node becomes unreachable, or (iii) the system crashes. In the first case (a voluntary exit), the procedure is started by the exiting node. In the two other cases, the predecessor detects the failure and reacts accordingly. We present the procedure for crash-down exits since a voluntary exit follows the same broadcast procedure. In case of computer crash-down, the failure is detected when the predecessor attempts to pass the token. The predecessor then removes the crashed node from its own view of the logical ring and spreads the suppression to its predecessor. It then tries to pass the token to its following successors until an active node is found. Propagation of crashed nodes is achieved through the DeleteNode call, presented in algorithm 4. We assume in the pseudo-code that method delete removes the node and reconnect its previous and next nodes together in the local view of the ring. When a node decides a voluntary exit, it calls DeleteNode (me, me) from its predecessor, and exits. A simple condition is checked to prevent exiting before sending the token. However, such a problem is considered in next section. Network problems must be especially handled since the disconnected node continues to run its threads. An isolated node tries to change the ring topology until it stays alone in its own ring. Similarly, if a network link is broken, physically separated nodes will rebuild a functional independent ring on each side of the cut. This situation is not taken into account in CONFIIT since it requires human actions to reconnect the node after repairs. However, a problem remains in these algorithms: when a node attempts to back-spread a ring modification, its predecessor could have been crashed, since no tests are performed between two broadcasts. Calling XML-RPC methods for back-spreading (AddNode and DeleteNode) should be achieved in a while loop, iteratively following predecessor links when a call can’t be achieved. Crashed nodes are not spread in this procedure to prevent cascade deletions. 3.7 Tasks scheduling To be efficient, computation of a problem has to be fairly distributed among all nodes, i.e. each task has to be computed on one node. Load balancing can be

10

Algorithm 5 Receiving a token. 1 2 3 4 5 6 7 8 9

proc receiveToken ( token) for each t ∈ token update t in taskStatus if t ∈ toReceive then toReceive ←− toReceive \ { t } else if t ∈ / toSend toForward ←− toForward ∪ { t } toReceive ←− toReceive ∪ toSend toSend ←− ∅

discussed on different ways: 1) between processors in a single node, 2) between nodes in the ring, 3) when computation ends, and 4) when information is lost. On a CONFIIT node, tasks scheduling is managed by an array of tasks status (called taskStatus). Each task can be marked as uncomputed, locally running, remotely running, or finished. At the beginning of the computation, all tasks are marked as uncomputed. When a task is completed (locally), its result is stored and will be spread to the whole ring with the token. In a single node, array of tasks status is a global data for all processors. To prevent tasks to be scheduled several times in the node, a processor marks tasks as locally running when it starts computation, and marks them as finished when computation ends. Because several processors can change task status simultaneously, all changes are synchronized: When a processor has to choose a new task to be computed, it scans taskStatus for a no-finished and nolocally running task. If found, the processor marks the task as locally running. Scanning and status changing is done into an atomic operation, so each task can be locally computed by only one processor. Achieving load balancing between nodes is more complex since no global information can be used. Each node owns a local view of the taskStatus array, and uses the token to periodically update it. CONFIIT manages the token to prevent overloading communications with obsolete data. It constantly updates three lists of tasks: – toSend: a list of tasks to be sent with the next token. it is fed by thread Resolve each time it starts or ends a task. – toReceive: a list of tasks sent with the previous token, and to be received for control with the next one. – toForward: a list of tasks to be forwarded with the next token. When it receives a token, a node uses Algorithm 5 to update these lists and to create a new token with the latest update information (Algorithm 6). To prevent additional delays, the task manager schedules a new task without waiting for the token. But the task could have already been scheduled by another node, and will be replicated in the ring. So, the local list of tasks owned by a node is randomly rearranged. Thus, when the task manager picks up the nth task, it probably will be different from the nth task on another node [13, 20].

11

Algorithm 6 Building a new token. 1 2 3 4 5 6 7

proc buildToken token ←− ∅ if ¬ringDeletion then token ←− token ∪ toForward toForward ←− ∅ token ←− token ∪ toReceive ringDeletion ←− false

3.7.1 Termination When a processor has to find a new task to be solved, it scans taskStatus for an uncomputed task. But when all tasks have been picked up, no uncomputed tasks can be found. If no other scheme is defined, two problems may impact on the termination: – tasks marked as remotely running by a crashed node will never be finished. – slow nodes may delay a task termination while faster nodes are idle. To prevent blocked computation due to tasks globally known as running on dead nodes, CONFIIT permits a node to pick up a remotely running task if no uncomputed tasks can be found. Thus, processors are in a race condition to finish a computation. Blocked tasks by crashed nodes will be solved, and fastest nodes will reduce the total execution time. This mechanism artificially increases the global cost of the computation since more than the original number of tasks will be computed (replicated tasks in previous section). Experimentally, replicated tasks are very rare during normal phase of computation, and appear only in the termination phase, when processors are starving. This way, we are able to reduce the overall computation length. 3.7.2 Token recovery The main trouble that can be encountered in CONFIIT framework occurs when a node crashes after a token reception but before sending it to its successor. In this case, token is lost and cooperation between nodes stops. CONFIIT solves this problem in launching a timeout delay each time a token is sent. If the timeout ends, a new token is sent (also with a new timeout delay). The same problem can occur for back-spreading tokens (see previous section): a topology alteration involves a token to circulate back to the ring, but it can be destroyed by a computer fault. This problem is solved by a similar procedure: when a node initiates a broadcast of a topology alteration, it launches a timeout delay, and re-sends the information if it doesn’t receive its own information before the timeout ends. The choice of the delay may be critical for a given network. A short delay could produce useless timeouts, and a long delay could reduce cooperation, and mainly induce replicated tasks since global computation status would not

12

be efficiently exchanged. This choice stays opened for our application since we tested it only on local area networks. In current version of CONFIIT, time is measured between sending and receiving the token, and the delay is set to twice this time. It appeared to be a good heuristic for small networks (less than 50 nodes). Token re-sending after a timeout will suppress cooperation ends. But several nodes can detect a (apparently) lost token. From our practical tests, more than 50% of the existing nodes detect a lost token in the same round. Such a situation can be harmful since it induces useless overloads in the system, and can disrupt termination detection. We define in CONFIIT, a mechanism of redundant tokens elimination: each token is marked with a sequence number (Seq) and the name of the node that sets the sequence number (N ame). Each node keeps a track of the highest sequence number (maxSeq) and the highest name (maxN ame) encountered during token rotation. Three cases can be discussed: (i) maxSeq > Seq: the considered token is obsolete since another one has been received with a higher sequence number. The token is ignored (and destroyed). (ii) maxSeq < Seq: the token has been regenerated by another node and seems to be up to date according to the local view. The receiver then memorizes the new maximal value and retransmits the token after local updates. (iii) maxSeq = Seq: the token is up to date according to the sequence number, but can be a redundant token. N ame is to be checked: (a) maxN ame = N ame (normal case). The token reaches the node for at least the second time. It is to be retransmitted after local updates. (b) maxN ame 6= N ame: the token is redundant and is to be ignored if maxN ame > N ame. If maxN ame < N ame, another token has been received and supposed to be correct, but it will be eventually suppressed by another node. When a node enters the ring, it sets maxSeq to 0 and waits for a token. The first node in the ring (the initiator ) sends the first token with Seq set to 1 and N ame to its own name. Initializing maxN ame is useless since it will be handled by the case (ii ).

4 Case Study: the car-sequencing problem The car-sequencing problem is an ordering problem in an assembly line of vehicles. Its aim is to find an order of production that respects certain specific constraints as frequency of options or colors. Actually, the problem has been proved to be NP-complete [19]. Thus resolution cost exponentially grows with the size of the problem. In a theoretical car-sequencing problem, capacity constraints give for each option, the maximal number q of cars with option i that can be product in a sub-sequence of p vehicles. A capacity constraint is thus expressed by the

13

ratio Ci = qi /pi for each option i in the problem. Actually, a car-sequencing problem is defined by a set of vehicles to be produced where same cars gather together in categories. A solution for the problem will be a production sequence respecting all the capacity constraints. An example of a car-sequencing problem is given in table 1. A binary matrix gives the options presented in each category of vehicle. For instance, cars from category 1 have option 2, and cars from category 2, options 1, 3 and 5. We choose to formalize the car-sequencing problem as a Constraint Satisfaction Problem, according to B. Smith in [25]: a variable Xi is a possible position of a car in the sequence S. Each variable is defined on a domain Di q containing all possible categories. For each capacity constraint pjj , no partition of size pj from S can have more than qj cars having option j. Another set of constraints forces the total amount of cars in each category to be equal to the requested number. Table 1 A car-sequencing problem [25]. Option 1 2 3 4 5 Total

Constraint 1/2 2/3 1/3 2/5 1/5

1 2 3 4 ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ 3 1 2 4

Categories 5 6 7 8 9 10 ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ 3 3 2 1 1 2

11 12 ∗ ∗ ∗ ∗ ∗ 2

1

Solving a car-sequencing problem with the CSP formalism consists in assigning a category from Di , to each variable Xi in the sequence S. Each assignment must satisfy all the constraints in the problem. The space of solutions can been seen as a tree where each node corresponds to the assignment of a category in a given position in the sequence. A level in the tree represents a position in the sequence, and the route from the root to a leaf is a solution of the problem. Thus, solving a car-sequencing problem corresponds to a depth-first search in its solution tree. We use an algorithm from the Forward-Checking family (FC) enhanced by a simple filtering technique [8] to solve the car-sequencing problem. Globally, such an algorithm prunes the domain of all non-instantiated variables by removing inconsistent values with the instantiation of a new variable.

4.1 Implementation in CONFIIT In our experiments, we used an existent car-sequencing solver, developed in C/C++. The main steps to adapt it to CONFIIT resolution mechanism are described below: – Division of the initial problem - Since solving a car-sequencing problem corresponds to a deep-first tree search, the most natural method is to

14

divide the tree using all possible instantiation of a given subset of variables. However, the car-sequencing solver contains its own ”divider” so we fed CONFIIT with the output from this divider, which contains the problem instances. – Computing a task - The external solver for car-sequencing problems needs two parameters: a string with the task instances and the maximum time allowed to solve it. This last parameter prevents losing of time in unproductive branches of the search tree. If a solution is found, the solver stores the solution, signalizes it and stops. If no solution is found, the solver simply returns a negative result. – Problem termination - As the car-sequencing problem consists of finding one good solution, execution can be stopped as soon as a solution is found. Therefore, we implemented the CONFIIT solver for the carsequencing problem in a work-stealing mode: the launcher divides the initial problem and a node asks for a task to solve. As soon as a node finishes a task, it sends the result to the launcher. If the result is negative, the launcher reduces the number of unsolved tasks. If a positive result is received, it writes it and stops the execution. 4.2 Experimental results The experimentations presented here had been performed on a small network of with Pentium 4 2.8 GHz machines with 512 MB of memory each. Problems tested are extracted from the CSPLib 3 , so they can easily be compared with other experiments. We divided our experiments into two groups: variation in the number of nodes, and variation in the depth and time allowed per task. 4.2.1 Variation in the number of nodes This group of problems is composed by 70 instances with 200 vehicles, and an average density from 60% to 90%. They are named 60-XX, 65-XX, ..., 90-XX in the CSPLib. Resolution was limited to 15 minutes per task (i.e., unsatisfiable problems will not be evaluated longer than 15 min). Only 59 problems have a solution in this framework. Table 2 shows the obtained results. Table 2 Results for the first group. # nodes exec. time

1 173 min 28 sec

2 94 min 43 sec

3 60 min 02 sec

In this group of experiments, the problems are divided according to the number of nodes. As a consequence, the Table 2 shows that the execution time reduces proportionally to the number of processors. A similar experiment with a parallel machine and 16 processors solved the same problems in 15 min and 36 seconds. 3

http://4c.ucc.ie/˜tw/csplib/

15

4.2.2 Variation in depth and time In this group of experiments, we tried different problems when varying both the instantiation depth and the maximum computation time by task, on a fixed network with 3 nodes. As a result, Table 3 presents the average time to find a solution in 10 different runs for each problem/time-depth combination. For the matter of comparison, the same problems when executed in a single processor (task) could not be solved in less than 2 hours. Table 3 Results for the second group. time / depth Problem 04-72 Problem 16-81 Problem 26-82 Problem 41-66

15 min / 1 14 min 14 sec 62 min 54 sec 32 min 07 sec 12 min 57 sec

2 min / 1 4 min 53 sec 15 min 01 sec 5 min 03 sec 3 min 20 sec

2 min / 2 13 min 26 sec 24 min 04 sec 9 min 39 sec 10 min 56 sec

Results are slightly different from an execution to another one in the first column because productive tasks are solved quickly while unproductive tasks (unsatisfiable tasks) need 15 minutes to stop. A two minutes timeout seems to ensure a good balance for these problems (column 2). Increasing the number of instances does not affect the overall time (column 3), as this also increases the number of unproductive tasks that cost 2 minutes each.

5 Improving CONFIIT: the GRAPP&S framework From the experience with both CONFIIT development and utilization, we learned a lot on how to construct a light and scalable computing middleware. Hence, we are setting now the milestones to improve CONFIIT: the GRAPP&S framework. GRAPP&S (for GRid APPlications & Services) aims to reorganize the internal hierarchy of CONFIIT, with especial concerns on adaptability, scalability and interoperability, especially in the case of grid computing. In the following paragraphs we present some of the improvements we are bringing to CONFIIT through the GRAPP&S framework: Modular hierarchy - Under CONFIIT, all nodes run the same protocol stack no matter their computer power. This approach has a clear impact as the token speed across the network varies in function of the processing node. Furthermore, if a multiprocessor machine wants to use all its processors, it must run as many instances of CONFIIT as necessary. The experience with the development of CONFIIT leaded us to define three roles a node can play, namely Communicator, Scheduler and Worker. A Communicator deals with token passing and message relaying to other Communicators, a Scheduler manages the lists of tasks and the Workers execute these tasks. In the GRAPP&S framework, these three roles must be played in different combinations according to the node capacity and needs.

16

Therefore, a multiprocessor machine may instantiate several Workers that report to a single Scheduler, improving the system efficiency. A slow machine, at the other side, may decide to run only a Worker and report to a Scheduler in another machine, or implement both Scheduler and Worker but not a Communicator. Another possibility is to run only a Communicator in a machine acting as Rendezvous point through a firewall. Figure 4 show some examples on this new approach.

S W

W

S WW

C S WWW

C S WW

W

Fig. 4 GRAPP&S modules distribution and interdependency.

Multi-site management - One of the problems with CONFIIT when running on multiple sites is that all involved networks must be configured to bypass firewall restrictions. The firewall management becomes therefore a strong obstacle to CONFIIT deployment. Another factor that may impact on the overall performance is the logical ring composition, which does not impose a geographic grouping. Successive connections/disconnections to the ring may lead to a ring arrangement where the token enters/leaves a subnetworks several times during its travel. To cope with both problems, the GRAPP&S framework relies on the aggregator role of Communicators. A Communicator may act as a Rendezvous point if need to traverse a firewall, routing messages to other Communicators. It also acts as a local area ”subscription desk” for nodes wanting to join the ring, which naturally improves nodes vicinity. Web-services and Multi-protocol integration - In order to improve the interoperability and language independence, elements from the GRAPP&S framework may be implemented as Web services where Workers (and eventually Schedulers) represent light-weight applications that are used to compose a computing service. This concept may also be extended to allow the integration of different protocols or middleware. The distinct roles of Communicator, Scheduler and Worker and the massive use of XML through XML-RPC make GRAPP&S easily extendable. Therefore, a wrapper implemented on the Scheduler allows a middleware such as DIET or ProActive to share tasks and results with each

17

other and with native GRAPP&S tasks, while beneficing from a light and fast intercommunicator structure represented by GRAPP&S.

6 Concluding remarks CONFIIT proposes a framework to easily distribute computations associated to a given application throughout wide-area networks. Its main characteristic, and benefit, is a fully asynchronous distributed environment. Through the extension of the FIIT interface, applications can easily benefit from CONFIIT properties such as communication efficiency and fault tolerance. Users do not have to worry about underlying management such as load balancing or logical structure: the system manages it on its own. CONFIIT was proven against different problems such as the Langford’s problem [22] or the car-sequencing problem. In the current version, tasks are fairly scheduled in a single computation framework with local information on the computation and data exchange with the token. The logical ring topology, however, demonstrates some limitations on large-scale networks. Real widearea networks with an important set of nodes will reduce efficiency of parallel distribution because nodes will have to wait a long time before receiving the token, and therefore global information on the computation. Aiming at the limitations from the first version of CONFIIT, we are working on a new implementation based on GRAPP&S. The GRAPP&S framework extends CONFIIT both on node management aspects and interoperability with other middlewares, making it fully enable to grid and massive distributed computing. Acknowledgements This work was partly supported by Romeo II, the high performance computing center of the University of Reims Champagne-Ardenne4 .

References 1. Allcock W, Chervenak A, Foster I, Pearlman L, Welch V, Wilde M (2001) Globus toolkit support for distributed data-intensive science. In: Computing in High Energy Physics (CHEP ’01) 2. Anderson D, Bowyer S, Cobb J, Gedye D, Sullivan WT, Werthimer D (1997) A new major SETI project based on project serendip data and 100,000 personal computers. In: In Astronomical and Biochemical Origins and the Search for Life in the Universe, Proc. of the Fifth Intl. Conf. on Bioastronomy 3. Anderson D, Cobb J, Korpela E, Lebofsky M, Werthimer D (2002) SETI@home: An experiment in public-resource computing. In: Communications of the ACM, vol 45, N. 11, pp 56–61 4. Anderson DP (2004) BOINC: A system for public-resource computing and storage. In: 5th IEEE/ACM International Workshop on Grid Computing 5. Androutsellis-Theotokis S (2002) A survey of peer-to-peer file sharing technologies. Tech. rep., Athens University of Economics and Business 4

http://www.romeo2.fr

18 6. Baduel L, Baude F, Caromel D, Contes A, Huet F, Morel M, Quilici R (2006) Grid Computing: Software Environments and Tools, Springer-Verlag, chap Programming, Deploying, Composing, for the Grid 7. Baratloo A, Karaul M, Kedem Z, Wyckoff P (????) Charlotte: Metacomputing on the web 8. Bessi` ere C, Meseguer P, Freuder E, Larrosa J (1999) On forward checking for non binary constraint satisfaction. Principles and Practice of Constraint Programming pp 88–102 9. Cappello F (2002) Calcul global pair ` a pair : extension des syst` emes pair ` a pair au calcul. La Lettre de l’IDRIS 4:14–25 10. Caron E, Desprez F, Lombard F, Nicod JM, Quinson M, Suter F (2002) A scalable approach to network enabled servers. In: Monien B, Feldmann R (eds) Proceedings of the 8th International EuroPar Conference, Springer-Verlag, Paderborn, Germany, Lecture Notes in Computer Science, vol 2400, pp 907–910 11. Dewdney A (1985) R´ ecr´ eation informatiques : un microscope informatique pour observer l’objet le plus complexe jamais d´ efini par les math´ ematiciens. Pour la Science 26:87–93 12. Fedak G, Germain C, N´ eri V, Cappello F (2001) XtremWeb: A generic global computing system. In: CCGRID2001, workshop on Global Computing on Personal Devices, IEEE Press 13. Flauzac O, Krajecki M, Fug` ere J (2003) CONFIIT: a middleware for peer to peer computing. In: Gravilova M, Tan C, L’Ecuyer P (eds) The 2003 International Conference on Computational Science and its Applications (ICCSA 2003), Lecture Notes in Computer Science, vol 2669 (III), Springer-Verlag, Montr´ eal, Qu´ ebec, pp 69–78 14. Foster I, Kesselman C (1997) Globus: A metacomputing infrastructure toolkit. Supercomputer Applications 11(2):115–128 15. Foster I, Kesselman C (1998) Computational Grids, Morgan-Kaufman, chap 2 16. Foster I, Kesselman C, Tuecke S (2001) The anatomy of the grid: Enabling scalable virtual organizations. International J Supercomputer Applications 15(3) 17. Foster I, Kesselman C, Nick J, Tuecke S (2002) Grid services for distributed system integration. Computer 35(6) 18. Hough P, Goldsby M, Walsh E (2000) Algorithm-dependent fault tolerance for distributed computing. Tech. Rep. Tech. Rep. SAND2000-8219, Sandia National Laboratories 19. Kis T (2004) On the complexity of the car-sequencing problem. Operation Research Letters 32:331–335 20. Krajecki M (1999) An object oriented environment to manage the parallelism of the FIIT applications. In: Malyshkin V (ed) Parallel Computing Technologies, 5th International Conference, PaCT-99, Lecture Notes in Computer Science, vol 1662, Springer-Verlag, St. Petersburg, Russia, pp 229–234 21. Krajecki M, Flauzac O, M´ erel PP (2004) Focus on the communication scheme in the middleware CONFIIT using XML-RPC. In: International Workshop on Java for Parallel and Distrubuted Computing (IWJPDC’04), Santa-Fe, New-Mexico 22. Krajecki M, Flauzac O, Jaillet C, M´ erel PP, Tremblay R (to appear) Solving an open instance of the Langford’s problem using CONFIIT : a middleware for peer-to-peer computing. Parallel Processing Letters 23. Li S (2003) JXTA 2: A high-performance, massively scalable P2P network. Tech. rep., IBM developerWorks 24. Sarmenta LFG, Hirano S, Ward SA (1998) Towards bayanihan: builing an extensible framework for volonteer computing using java. In: Proc. ACM Workshop on Java for High-Performance Network Computing 25. Smith B (1996) Succeed-first or fail-first: A case study in variable and value ordering. In: ILOG Solver and ILOG Schedule 2nd International Users’ Conference, Paris 26. St Laurent S, Johnston J, Dumbill E (2001) Programming Web Services with XMLRPC. O’Reilly, iSBN 0-596-00119-3 27. Willebeek-LeMair M, Reeves AP (1993) Strategies for dynamic load balancing on hightly parallel computers. IEEE Transactions on Parallel and Distributed Systems 4(9):979– 993