Gabriel Antoniu

Mathieu Jan

David Noblet

A practical example of convergence of P2P and grid computing: an evaluation of JXTA's communication performance on grid networking infrastructures

As the size of today's grid computing platforms increases, the need for self-organization and dynamic reconfiguration becomes more and more important. In this context, the convergence of grid computing and peer-to-peer (P2P) computing seems natural. However, grid infrastructures are generally available as a hierarchical federation of SAN-based clusters interconnected by high-bandwidth WANs. In contrast, P2P systems usually run on the Internet, on top of random, generally flat network topologies. This difference may lead to the legitimate question of how adequate are the P2P communication mechanisms on hierarchical grid infrastructures. Answering this question is important, since it is essential to efficiently exploit the particular features of grid networking topologies in order to meet the constraints of scientific applications. This paper evaluates the communication performance of the JXTA P2P platform over high-performance SANs and WANs, for both J2SE and C bindings. We discuss these results, then we propose and evaluate several techniques able to improve the JXTA's performance on such grid networking infrastructures.

Introduction

Nowadays, scientific applications require more and more resources, such as processors, storage devices, network links, etc. Grid computing provides an answer to this growing demand by aggregating processing and storage resources made available by various institutions. As their sizes grow, grids express an increasing need for flexible distributed mechanisms allowing them to be efficiently managed. Such properties are exhibited by peer-to-peer (P2P) systems, which have proven their ability to efficiently handle millions of interconnected resources in a decentralized way [START_REF] Chawathe | Making gnutella-like p2p systems scalable[END_REF]. Moreover, these systems support a high degree of resource volatility. The idea of using P2P approaches for grid resource management has therefore emerged quite naturally [START_REF] Foster | On Death, Taxes, and the Convergence on Peer-to-Peer and Grid Computing[END_REF][START_REF] Talia | Toward a Synergy Between P2P and Grids[END_REF].

To our knowledge, the very few practical attempts of convergence between P2P and grid computing have taken two different paths. One approach consists in implementing P2P services on top of software building blocks based on current grid technology (e.g., by using grid services as a communication layer [START_REF] Talia | A P2P Grid Services-Based Protocol: Design and Evaluation[END_REF]). Conversely, P2P libraries can be used on physical grid infrastructures as an underlying layer for higher-level grid services [START_REF] Amoretti | Service Discovery in a Grid-based Peer-to-Peer Architecture[END_REF]. This is a way to leverage scalable P2P mechanisms for resource discovery, resource replication and fault tolerance. In this paper, we focus on this second approach.

Grid applications often have important performance constraints. In most cases, grids are built as cluster federations. System-Area Networks (SANs), such as Giga Ethernet or Myrinet (which typically provide Gb/s bandwidth and a few microseconds latency), are used for connecting nodes inside a given high-performance cluster; whereas Wide-Area Networks (WANs), provide a typical bandwidth of 1-10 Gb/s, but a higher latency (typically of the order of 10-20 ms), are used to connect the clusters. Consequently, sending a small message between two nodes within the same SAN may be 1,000 times less expensive then doing the same operation across a WAN. Such a discrepancy cannot be neglected, since the efficient use of the network characteristics is a crucial issue in the context of performance-constrained scientific applications.

In contrast, P2P applications generally do not have important performance constraints, as they usually target the edges of the Internet (with low-bandwidth and high-latency links, such as Digital Subscriber Line (DSL) connections). In such a context, the latency between arbitrary pairs of nodes does not exhibit a high variation. Therefore, most published papers on P2P systems generally model the communication cost as a distance based on the number of logical hops between the communicating entities, without taking into account the underlying physical topology. When running P2P protocols on grid infrastructures, this factor clearly has to be considered in order to efficiently use the capacities of the available networks to provide the performance required by the applications. Therefore, using P2P libraries on grid infrastructures as building blocks for grid services is a challenging problem, since this is clearly an unusual deployment scenario for P2P systems. Consequently, it is important and legitimate to ask: are P2P communication mechanisms adequate for a usage in such a context? Is it possible to adapt P2P communication systems in order to benefit from the high potential offered by these highperformance networks, in order to meet the needs of scientific grid applications?

Most of the few attempts to realize the P2P-grid convergence have been based on the JXTA [START_REF]The JXTA project[END_REF] open-source project (see the related work below). In its 2.0 version, JXTA consists of a specification of six language-and platform-independent, XML-based protocols that provide basic services common to most P2P applications, such as peer group organization, resource discovery, and inter-peer communication. This paper discusses the appropriateness of using the JXTA P2P platform for high-performance computing applications, running on grid infrastructures. This case is challenging for JXTA, as it evaluates to what extent its communication layers are able to leverage highperformance (i.e. Gigabit/s) networks. For the purpose of our evaluation, we use the well-known bidirectional bandwidth benchmark, widely used to evaluate networking protocols. This paper focuses on the evaluation of JXTA-J2SE and JXTA-C 1 over high-performance SANs and WANs. It also proposes and discusses several solutions to improve the raw performance observed.

The remainder of the paper is organized as follows. Section 2 introduces the related work: we discuss some JXTAbased attempts for using P2P mechanisms to build grid services and we mention some past performance evaluations of JXTA. Section 3 provides an overview of the communication layers of both JXTA-J2SE and JXTA-C. Section 4 describes the experimental setup we used for SAN and WAN benchmarks. Sections 5 and 6 present the benchmark results of JXTA over these three types of networks. In Section 7, we discuss the measurements from a global perspective through a comparison with other middleware typically used for building grid applications. We also provide some hints on how to efficiently use JXTA's communication layers. Finally, Section 8 concludes the paper and discusses some possible future directions.

Related Work

Several projects have focused on the use of JXTA as a substrate for grid services. The Cog Kit JXTA Project [START_REF]Cog Kit JXTA project[END_REF] and the JXTA-Grid [START_REF]JXTA-Grid project[END_REF] project are two examples. However, none of these projects are being actively developed and none has released any prototypes. The Service-oriented Peer-to-Peer Architecture [START_REF] Amoretti | Service Discovery in a Grid-based Peer-to-Peer Architecture[END_REF] (SP2A) project aims at using 1 The only two bindings compliant to JXTA's specifications version 2.0 P2P routing algorithms for publishing and discovering grid services. SP2A is based on two specifications: the Open Grid Service Infrastructure (OGSI) and JXTA. None of the projects above has published performance evaluations so far. Finally, JUXMEM [START_REF] Antoniu | JuxMem: An adaptive supportive platform for data sharing on the grid[END_REF] proposes to use JXTA in order to build a grid data-sharing service. All projects mentioned above share the idea of using JXTA as a low-level interaction substrate over a grid infrastructure. Such an approach brings forth the importance of JXTA's communications performance, which may be critical for scientific grid applications.

In this paper, we focus on the communication layers of the main two bindings of JXTA: JXTA-J2SE and JXTA-C. The performance of the widely-used pipe communication layer of JXTA-J2SE has been the subject of many studies [START_REF] Halepovic | The Cost of Using JXTA[END_REF][START_REF] Halepovic | JXTA Performance Study[END_REF][START_REF] Seigneur | Jxta Pipes Performance[END_REF][START_REF] Seigneur | P2P with JXTA-Java pipes[END_REF][START_REF] Halepovic | JXTA Messaging: Analysis of Feature-Performance Tradeoffs[END_REF][START_REF] Shudo | P3: Personal Power Plant[END_REF] and has served as reference for comparisons with other P2P systems [START_REF] Baehni | OS Support for P2P Programming: a Case for TPS[END_REF][START_REF] Junginger | The Multi-Ring Topology -High-Performance Group Communication in Peer-to-Peer Networks[END_REF][START_REF] Tran | JXTA and TIBCO Rendezvous -An Architectural and Performance Comparison[END_REF]. However, these studies are primarily based on JXTA 1.0 [START_REF] Halepovic | The Cost of Using JXTA[END_REF][START_REF] Halepovic | JXTA Performance Study[END_REF] or even older [START_REF] Seigneur | Jxta Pipes Performance[END_REF][START_REF] Seigneur | P2P with JXTA-Java pipes[END_REF]. The most recent evaluations of both main JXTA bindings are [START_REF] Antoniu | Performance evaluation of jxta communication layers[END_REF] and [START_REF] Antoniu | Enabling the p2p jxta platform for high-performance networking grid infrastructures[END_REF]. The main focus of [START_REF] Antoniu | Performance evaluation of jxta communication layers[END_REF] is a performance evaluation of JXTA-J2SE in a LAN environment using Fast Ethernet. It also provides the first evaluation of JXTA-C and gives hints on how to use both bindings of JXTA in order to get good performance on this kind of networks. In [START_REF] Antoniu | Enabling the p2p jxta platform for high-performance networking grid infrastructures[END_REF], the same benchmark code is used but in a very different context: performance evaluations are performed on grid infrastructures consisting of SAN-based clusters interconnected by high-bandwidth WANs. To the best of our knowledge, [START_REF] Antoniu | Enabling the p2p jxta platform for high-performance networking grid infrastructures[END_REF] is the first attempt to discuss the appropriateness of using the JXTA P2P platform for highperformance computing on grid infrastructures. This paper presents an extended and updated version of the results preliminarily presented in [START_REF] Antoniu | Enabling the p2p jxta platform for high-performance networking grid infrastructures[END_REF], which are synthesized and discussed from a larger perspective. We include some new performance figures for SAN and WAN benchmarks, using a more recent version of JXTA-C (2.1.1), which exhibits significant improvements compared to previous performance measurements published in [START_REF] Antoniu | Enabling the p2p jxta platform for high-performance networking grid infrastructures[END_REF]. In the context of the convergence of P2P and grid computing, these updated results can help the user to draw a clear picture of the potential of JXTA-C on high-performance networks available on grid infrastructures.

Overview of JXTA Communications Layers

JXTA provides three basic transport mechanisms for inter-peer communication, each providing a different level of abstraction.

At the lowest level, information is exchanged between peers in discrete units known as JXTA messages. JXTA specifies two possible wire representations for a JXTA message: binary, where a transport protocol such as TCP is available; and XML, in case the underlying transport protocol is not capable of transmitting binary data. In either case, a JXTA message is comprised of a series of named and typed message elements [START_REF]JXTA specification project[END_REF], any number of which may be required by the transport protocol or added by the application as the message payload. These message elements can be of any type, including, for example, an XML document.

The bottom layer: the endpoint service The endpoint service is JXTA's point-to-point communication layer. It provides an abstraction for the available underlying transport protocols (called endpoints) which can be used to exchange data between one peer and another. Currently, supported transport protocols common to both implementations of JXTA are TCP and HTTP. However, regardless of the underlying transport protocol, all communications at the endpoint level, are asynchronous, unidirectional and unreliable.

In general, the endpoint service should not be utilized directly by applications, but rather indirectly through the use of one of the upper communication layers, such as the pipe service or JXTA sockets. Therefore, the aim of benchmarking the endpoint service is primarily to gather performance data on the endpoint service for the purpose of explaining the performance measured for these upper layers.

The core communication layer: the pipe service The pipe service supplements the endpoint service by incorporating the abstraction of virtual communication channels (or pipes). The aim of the pipe service is to provide the illusion of a virtual endpoint that is independent of any single peer location and network topology, as stipulated by JXTA specifications. Like peers, each pipe also has an identifier unique to the JXTA virtual network; this is known as the Pipe ID and is used by the pipe service to bind peers to pipe-ends. Before a message is transferred between peers, each end of the pipe is resolved to an endpoint address, through the use of JXTA's pipe binding protocol, and the endpoint service is used to handle the actual details of transferring messages between peers (the resolution is only done once for each pipe and is subsequently checked from time to time).

Like endpoint communications, pipe communications are also asynchronous and unreliable. However, the pipe service offers two modes of communication: point-to-point (unicast pipes) and propagate mode (propagate pipes). In propagate pipes, a single peer can simultaneously send data to many other peers. In this study we focus on unicast pipes because of their general-purpose nature and because they serve as a basis for the implementation of the higher-level JXTA sockets.

Enabling sockets over P2P: JXTA Sockets The JXTA sockets introduce yet another layer of abstraction on top of the pipes and provide an interface similar to that of the more familiar BSD socket API. Compared to the JXTA pipes, JXTA sockets add reliability and bi-directionality to JXTA communications. Additionally, JXTA sockets transparently handle the packaging and un-packaging of applicationspecific data into and out of JXTA messages, presenting a data-stream type of interface to each of the communicating peers. However, it should be noted that this layer is not part of the core specifications of JXTA and has not been implemented in JXTA-C so far. It was introduced in JXTA-J2SE 2.0, with reliability support added in 2.1.

The data-stream interface also introduces another interesting parameter which can be used to tune JXTA sockets. Indeed, it is possible to configure the size of the output buffer of a JXTA socket. This value has an impact on the way the socket packages the data it receives for transmission into a series of separate JXTA messages that can be sent using the pipe service. This is significant because the JXTA socket creates a new JXTA message every time the buffer becomes full or the buffer is explicitly flushed by the application. In all versions of JXTA, the default buffer size is 16 KB.

Description of the Experimental Setup

For all reported measurements we use a bidirectional bandwidth benchmark (between two peers), based on five subsequent time measurements of an exchange of 100 consecutive message-acknowledgment pairs sampled at the application level. We chose this test as it is a well-established metric for benchmarking networking protocols, and because of its ability to yield information about important performance characteristics such as bandwidth and latency. Moreover, such information is necessary in order to evaluate JXTA's adequacy for performance-constrained grid applications. Both bindings of JXTA were configured to use TCP as the underlying transport protocol.

When benchmarks are performed using JXTA-J2SE, the Sun Microsystems Java Virtual Machine (JVM) 1.4.2 is used and executed with -server -Xms256M -Xmx256M options.

Note that when the J2SE binding of JXTA is benchmarked, an additional warm-up phase based on 1000 consecutive message-acknowledgment pairs is performed, to make sure that the Just-In-Time (JIT) compiler is not disturbing the measurements. The JXTA-C benchmarks are compiled using gcc 4.0 for the SAN and WAN benchmarks. In both cases, the O2 level of optimization is used. Finally, note that all source codes required to perform the benchmarking of each communication layer of JXTA-J2SE and JXTA-C have been made available via the web sites of the JDF [START_REF] Cheng | JXTA Distributed Framework[END_REF] and JXTA-C [START_REF]Project JXTA-C[END_REF] WAN benchmarks. The platform used for the WAN benchmarks is the Grid'5000 French national grid platform [START_REF] Bolze | Grid'5000: a large scale and highly reconfigurable experimental grid testbed[END_REF]. Tests were performed between two of the Grid'5000 clusters located in Rennes and Toulouse. On each side, nodes consist of machines using dual 2.2 GHz AMD Opteron processors, outfitted with 1 GB of RAM each, and running a 2.6 version Linux kernel. The two sites are interconnected through a 1 Gb/s link, with an average measured latency of 11.2 ms. We used the same versions of JXTA as for the SAN experiments. In this case too, we configured JXTA peers to enable direct exchanges.

Performance Evaluation of JXTA over System-Area Networks

This section analyzes the performance of JXTA's communications layers on SANs. Note that for Myrinet, the Ethernet emulation mode of GM 2.0.11 is used and configured with jumbo frames. This mode allows Myrinet to carry any packet traffic and protocols that can be transported by Ethernet, including TCP/IP. Although this capability is bought at the cost of losing the main advantage of a Myrinet network (the OS-bypass mode), it allows the same socketbased benchmarks to be run unmodified. On this configuration, the bandwidth and latency of plain sockets is around 155 MB/s and 60 µs respectively, whereas on Giga Ethernet it is around 115 MB/s for the bandwidth and 45 µs for the latency. These values are used as a reference performance bound.

JXTA-J2SE: Analysis

JXTA-J2SE endpoint service. Figure 1 shows the bandwidth of the JXTA 2.3.2 endpoint layer, which does not saturate the potential bandwidth of the networks. This is explained by a new implementation of the endpoint layer that shipped with JXTA 2.3. The profiling of JXTA has pointed out that this drop of performance since JXTA 2.2.1 is due to the mechanism used for limiting the size of messages sent by the endpoint layer. We therefore removed this limit to enable our measurements. Table 1 shows that the latency of the JXTA 2.3.2 endpoint service over Giga Ethernet reaches a value under 300 µs. Moreover, it goes down even further to 268 µs and 229 µs when using the SUN 1.5 JXTA-J2SE unicast pipe. In addition, Figure 1 illustrates the bandwidth available with the JXTA-J2SE unicast pipes. Overall, the small performance degradation as compared to the endpoint layer is explained by the composition of a pipe message: the presence of an XML message element requiring a costly parsing prevents this layer from reaching the performance of the endpoint layer. Moreover, as shown on Table 1, this extra parsing required for each pipe message also affects latency results: compared to the endpoint layer, latencies increase by more than 400 µs. However, unicast pipes are still able to achieve latencies in the sub-millisecond range, at least on Giga Ethernet.

JXTA-J2SE sockets. As opposed to the lower layers, JXTA sockets are far from reaching the performance of plain Java sockets. In their default configuration (e.g. with an output buffer size of 16 KB), JXTA sockets 2.2.1, for instance, attain a peak bandwidth of 12 MB/s over a Myrinet network. We were able to significantly improve the bandwidth and achieve 92 MB/s by increasing the size of the output buffer to 512 KB, as shown on Figure 2. Similar results were obtained over Giga Ethernet (for the sake of clarity, they are not represented on the Figure). Figure 2 also clearly shows the performance degradation between JXTA sockets 2.2.1 and 2.3.2. The irregular shape of JXTA sockets 2.2.1 curves has not been explained so far. Again, we suspect the first drop is due to an inefficient thread scheduling policy. The next drop, when the message size is about the size of the output buffer, seems to be due to bugs discovered in the reliability layer since JXTA-J2SE 2.3.2. To the best of our knowledge, some progress has been made on these issues even if it can still be observed in JXTA 2.3.3. Table 1 highlights the progress being made by JXTA Sockets 2.3.2 as regards latency: on Giga Ethernet it is able to reach a latency under one millisecond.

Discussion. In conclusion, JXTA-J2SE 2.3.2 communication layers do not saturate saturate SANs (as opposed to previous versions [START_REF] Antoniu | Enabling the p2p jxta platform for high-performance networking grid infrastructures[END_REF]. In contrast, latency results have largely improved since JXTA 2.2.1, but without reaching reasonably good performance for SANs. Finally, this evaluation has also highlighted that, in their default configuration, JXTA sockets achieve a very poor bandwidth. However, this result can significantly be improved by increasing the output buffer size. This requires the JXTA socket programmer to explicitly set this parameter in the user code. Based on these results, we can conclude that JXTA-J2SE can be adapted in order to benefit from the potential offered by SANs, at least as bandwidth is concerned. On Myrinet, this is an increase by 30 MB/s compared to results published in [START_REF] Antoniu | Enabling the p2p jxta platform for high-performance networking grid infrastructures[END_REF]. This highlights the improvements that have been made since JXTA-C 2.1. Based on these encouraging results, we have optimized JXTA-C 2.2 communication layers by implementing a message element caching mechanism. Message elements including source and destination information of messages are no longer included in each message sent by the endpoint service. Each peer is indeed aware of this information through the setting-up of the communication. In addition, we have removed an unneeded message element as direct exchanges between peers are possible (so called direct connection optimization). These aforementioned optimizations have a little impact on the peak bandwith of JXTA-C 2.2 on Giga Ethernet: both layers reach 100 MB/s, a small increase compared to JXTA-C 2.1.1. However and as expected, our optimizations have a major impact on the latency results, as shown on Table 2. On a Giga Ethernet network, the latency of JXTA-C 2.2 reaches 84 µs (endpoint service) and 90 µs (unicast pipe service). Compared to JXTA-C 2.1.1, this is a decrease by more than 200 µs for the latency of a unicast pipe and of 53 µs for the endpoint service. At the endpoint layer, the improvement is mainly explained by the caching mechanism of message elements. For unicast pipes, further improvements are explained by the so called direct connection optimization. However, the latencies are still higher than the latency of plain sockets over Giga Ethernet (39 µs).

JXTA-C: Analysis

Based on this evaluation, we can conclude that, in their current implementation, the communication layers of JXTA-C are nearly able to saturate SANs, by reaching bandwidths values above 1 Gb/s. In addition, let us note that on the latency side, major improvements have made throughout JXTA-C releases, especially if we include our optimizations. To summarize, a path towards an efficient use of SAN capacities have been opened, even if work remain on the latency side.

Performance Evaluation of JXTA over Wide-Area Networks

This section analyzes the performance of JXTA's communications layers on WANs. Note that we had to tune the network settings of the nodes used for this benchmark. Our default maximum TCP buffer size initially set to 131072 bytes was limiting the bandwidth to only 7 MB/s. Based on the bandwidth * delay law, we computed a theoretical maximum size of 1507328 bytes and increased this value by an arbitrary factor of 1.2. Therefore, we set the maximum TCP buffer sizes on each node to 1959526 bytes; ttcp configured with this value measured a raw TCP bandwidth of 107 MB/s, a reasonable level of performance.

JXTA-J2SE's performance. As for Giga Ethernet SAN benchmarks, Figure 5 shows that the endpoint layer and unicast pipes of JXTA-J2SE are able to perform similarly to plain sockets over a high-bandwidth WAN of 1 Gb/s. This level of performance was reached by modifying JXTA-J2SE's code in order to properly set the TCP buffer sizes. Using the default setting, a bandwidth of only 1 MB/s was reached for JXTA 2.3.2.

JXTA-C's performances. Figure 6 shows that the peak bandwidth for both communication layers of JXTA-C 2.1.1 over WANs are 94 MB/s, for a message size of 4 MB. As for the the SAN benchmarks, these higher results compared to results published in [START_REF] Antoniu | Enabling the p2p jxta platform for high-performance networking grid infrastructures[END_REF] are explained by the improvements made since JXTA-C 2.1. However, this level of performance was only reached by modifying JXTA-C's code in order to properly set the TCP buffer sizes.

Discussion. Based on this evaluation, we can conclude that JXTA's communication layers, when used on highbandwidth WANs, are able to reach the same bandwidths as for SAN benchmarks. JXTA-J2SE is able to efficiently use the bandwidth available on the links used for interconnecting sites of a grid. However, JXTA sockets are unable to successfully exploit the bandwidth available on WANs, even if JXTA sockets 2.3.2 achieve some improvement compared to previous versions [START_REF] Antoniu | Enabling the p2p jxta platform for high-performance networking grid infrastructures[END_REF].

Discussion

JXTA aims at providing generic blocks for building P2P services or applications. Such services or applications may have various requirements with respect to the performance of inter-peer communications, but also with respect to the desired guarantees. It is, therefore, necessary to pick the appropriate communication layer according to the application requirements, and to properly configure it in order to efficiently use JXTA.

The fastest layer of JXTA is clearly the endpoint service. However, direct use of the endpoint service is not recommended, as communications are unreliable and only suitable for static point-to-point interactions. Moreover, this layer may be subject to short-term modifications, which may result in large amounts of work when upgrading to newer versions of JXTA. On the other hand, this layer provides the developer with full control of the logical topology and therefore allows one to implement alternative routing schemes. Therefore, a direct use of this layer is reserved to JXTA experts willing to develop highly specific P2P systems.

As regards the upper layers, using JXTA sockets or JXTA pipes is not an easy choice, at least on SANs and WANs. More specifically, the overhead introduced by the JXTA sockets on LANs compared to the underlying unicast pipes is low, if we take into consideration the features offered by this layer: reliable, bidirectional communications and the availability of a data-stream mode. Note however that this overhead is low only when JXTA sockets are configured to use larger output buffer size. In contrast, on SANs and WANs, the performance degradation of JXTA sockets compared to unicast pipe is high, therefore choosing unicast pipes seems more appropriate.

The good performance of JXTA for Fast Ethernet LANs [START_REF] Antoniu | Performance evaluation of jxta communication layers[END_REF] and high-speed WANs, at least in terms of bandwidth capability, makes JXTA a particularly good candidate for many wide-area Internet applications dealing with large data transfers over such networks. We can therefore say that JXTA-based collaborative platform such as JXCube [START_REF]JXCube -Jxta eXtreme Cube project[END_REF] or projects supporting distributed computing on large data sets such as P3 [START_REF] Shudo | P3: Personal Power Plant[END_REF] or JNGI [START_REF] Verbeke | Framework for Peer-to-Peer Distributed Computing in a Heterogeneous, Decentralized Environment[END_REF], to name a few, have made a reasonable choice by using JXTA.

Different considerations need to be taken into account when using JXTA as a means of achieving a form of convergence of P2P and grid middleware. In this context, it is an important challenge to allow JXTA-based applications targeting grid infrastructures to transparently exploit these high performance networks. We have shown that, if is correctly tuned, the JXTA platform can deliver adequate performance (e.g., over 1 Gbit/s bandwidth and low latency for JXTA-C at least). Furthermore, we explain how this performance can be improved thanks to specialized external libraries. The overall conclusion is that JXTA may provide adequate communication performance that are required by grid computing applications.

However, these evaluations have revealed some weaknesses of JXTA's communication layers: 1) with JXTA-J2SE, the bandwidths of all layers have degraded since JXTA 2.3, hindering JXTA from saturating SAN links; 2) the communication layers of JXTA were not optimized for direct connections between peers therefore limiting the bandwidth but more importantly latency results on SANs. Therefore, we have successfully optimized JXTA-C 2.2 in order to be able to fully exploit SANs capacities.

By way of comparison with other middlewares, let us cite a few latency results results for various platforms typically used for building grid applications. We use [START_REF] Demarey | Benchmarking the round-trip latency of various java-based middleware platforms[END_REF] as a reference paper for the latency results of J2SE-based middlewares. However, given that the hardware setup used in this study is not identical to ours, we can only sketch rough trends. In [START_REF] Demarey | Benchmarking the round-trip latency of various java-based middleware platforms[END_REF], three types of platforms are benchmarked: Object Request Brokers (ORB), component-oriented platforms and web services. We can see that at least the 294 µs latency of JXTA 2.3.2's endpoint service outperforms middlewares in all three categories (517 µs for Java RMI over IIOP, 633 µs for OpenORB 1.4.0 and 2070 µs for ProActive 2.0, to name one in each category). Nevertheless, some ORB middlewares and component-oriented platforms, like ORBacus (115 µs) or Java RMI over JRMP (123 µs) and Fractal RMI (151 µs) respectively, achieve better results. Note however that, for a fair comparison, componentoriented platforms and web services should be compared to the higher communication layers of JXTA, such as unicast pipes and JXTA sockets. In that case, JXTA-J2SE layers do not range in the top any longer, even if they still outperform some platforms based on web services (4742 µ for Apache Axis 1.1). As regards JXTA-C, according to results available with the CORBA benchmark project [START_REF]CORBA Benchmarking[END_REF], the endpoint and pipe layers can achieve better results than OmniORB 3.0 (173 µs) or ORBacus 4.0 (338 µs). However, they are still a little bit behind the performances of OmniORB 4.0 (52 µs). Overall, we can however conclude JXTA's communication layers performs reasonably well given the provided functionalities.

Conclusion

In the context of the current efforts for building grid services on top of P2P libraries, an important question is: to what extent is it reasonable to rely on P2P mechanisms to support the dynamic character of the grid? Are P2P techniques only useful for resource discovery? Or is there a way to take one step further, and efficiently exploit P2P data communication mechanisms? The question of the adequacy of P2P communication mechanisms for performanceconstrained usages is therefore important in this context.

In this paper, we focus on benchmarking a key aspect of one widespread P2P open-source library: the performance of JXTA communication layers. We provide a detailed analysis and discussion of the performance of these layers for the most advanced bindings of JXTA (J2SE and C) over networks typically used for building grid infrastructures, such as SANs and WANs. We show that the JXTA platform can deliver adequate performance on grid infrastructures (e.g., over 1 Gbit/s bandwidth and low latency, at least for JXTA-C) if it is correctly tuned and optimized. Moreover, we explain how this performance can be further improved thanks to specialized external libraries. We also give some hints to designers of JXTA-based applications or services on how to efficiently use each layer. This should allow developers to build higher-level services based on building blocks whose costs are known and optimized, which should lead to reasonable implementation choices.

However, these evaluations have revealed some weaknesses of JXTA in both SAN and WAN areas. JXTA-J2SE peak bandwidth values has degraded since JXTA 2.3, hindering JXTA from saturating SAN links. Moreover, the communication layers of JXTA are not optimized for direct connections available on SANs. Therefore, we have improved JXTA-C in order to be able to fully exploit capabilities of SANs. More precisely, we have optimized message composition emits by JXTA-C when direct communications are available as well as use a caching mechanism for some message elements. In addition, we have optimized the message path throughout the JXTA-C stack as well as implemented a zero-copy mode. In further preliminary experiments on a Myrinet 10-G network we could reach a bandwith of 850 MB/s for both communication layers of JXTA-C 2.3, while plain sockets reach 925 MB/s.

Even if this paper explored the impact of multiple factors, this research is not an exhaustive evaluation of all aspects that may impact on JXTA's communication performance. In particular, the work presented in this paper could be extended by using different virtual network topologies, involving more complex communication schemes.

Figures 3 and 4 Figure 3 .

 43 Figures3 and 4show the bandwidth measurements of all the communications layers of JXTA-C 2.1.1 over SANs. Note that, as in the previous section, C sockets are used as an upper reference bound. The peak bandwidth values we measured for the endpoint service over Myrinet and Giga

Figure 4 .

 4 Figure 4. Bandwidth of each layer of JXTA-C 2.1.1 as compared to C sockets over a Giga Ethernet network.

Figure 5 .Figure 6 .

 56 Figure 5. Bandwidth of each layer for JXTA-J2SE 2.3.2 compared to Java sockets over a high-bandwidth WAN.

Table 1 . Latency results for JXTA-J2SE 2.3.2 on SAN

 1 projects.SAN benchmarks. The networks used for the SAN benchmarks are Giga Ethernet and Myrinet-2000 (GM driver, version 2.0.11). When the network layer is Myrinet, nodes consist of machines using 2.4 GHz Intel Pentium IV processors, outfitted with 1 GB of RAM each, and running a 2.4 version Linux kernel. For Giga Ethernet, nodes consist of machines using dual 2.2 GHz AMD Opteron processors, also outfitted with 1 GB of RAM each, and running a 2.6 version Linux kernel. Benchmarks were executed using versions 2.2.1 and 2.3.2 of the J2SE binding of JXTA. In this paper, we mainly report figures for the 2.3.2 version. For the C binding, version 2.1.1 was used. In all cases, direct communication between peers has been enabled, since . this feature is usually available among the nodes of a SANbased cluster within currently deployed grids.

	Version of JXTA	JXTA-J2SE 2.3.2
	Network	Myrinet Giga Ethernet
	Endpoint service	624 µs	294 µs
	Unicast pipe	1.7 ms	711 µs
	JXTA socket	2.4 ms	977 µs

Bandwidth of JXTA-J2SE sock- ets 2.2.1 and 2.3.2 over a Myrinet network for two different output buffer sizes, compared to Java sockets.

		160
		120 140	JXTA socket 2.2.1 (512 KB) Java Socket JXTA socket 2.3 (16 KB, default) JXTA socket 2.3 (512 KB) JXTA socket 2.2.1 (16 KB, default)
	Throughput (MB/s)	60 80 100
		40
		20
		0	0.5	1	2	4	8	16	64	256	1MB	4MB	16MB
			Message size in KB
	Figure 2.

1 as compared to C sockets over a Myrinet network.

	JXTA-C	2.1.1	2.2
	Network	Myrinet GEther. GEther.
	Endpoint service	310 µs	137 µ	84 µs
	Unicast pipe	690 ms	298 µs	90 µs

Table 2 . Latency results for JXTA-C 2.1 and 2

 2 Ethernet are 135 MB/s and 103 MB/s respectively. The upper layer (unicast pipe) reaches bandwidths of 133 MB/s and 96 MB/s over Myrinet and Giga Ethernet, respectively.

.1.1 on SAN (Giga Ethernet noted GEther.).


Gabriel Antoniu
email: gabriel.antoniu@irisa.fr

Eddy Caron
email: eddy.caron@ens-lyon.fr

Frédéric Desprez
email: frederic.desprez@ens-lyon.fr

Aurélia Fèvre
email: aurelia.fevre@ens-lyon.fr

Mathieu Jan
email: mathieu.jan@lri.fr

Towards a Transparent Data Access Model for the GridRPC Paradigm

As grids become more and more attractive for solving complex problems with high computational and storage requirements, the need for adequate grid programming models is considerable. To this purpose, the GridRPC model has been proposed as a grid version of the classical RPC paradigm, with the goal to build NES (Network-Enabled Server) environments. In this model, data management has not been defined and is now explicitly left at the user's charge. The contribution of this paper is to enhance data management in NES by introducing a transparent data access model, available through the concept of grid data-sharing service. Data management is totally delegated to the service, whereas the applications simply access shared data via global identifiers. We illustrate our approach using the DIET GridRPC middleware and the JUXMEM data-sharing service. Notably, our experiments performed on the Grid'5000 using a real-life application show the efficiency of using JUXMEM for managing persitent data in the GridRPC model: application execution times in a grid environment are of the same order as in a cluster environment.

Introduction

Computational grids have recently become increasingly attractive, as they adequately address the growing demand for resources of today's scientific applications. Thanks to the fast growth of high-bandwidth wide-area networks, grids efficiently aggregate various heterogeneous resources (processors, storage devices, network links, etc.) belonging to distinct organizations. This increasing computing power, available from multiple geographically distributed sites, increases the grid's usefulness in efficiently solving complex problems. Multi-parametric applications, for instance, which consist in applying the same algorithm to different input data, can benefit from an efficient use of grid computing infrastructures.

Running such applications on large-scale grid infrastructures requires the use of adequate programming paradigms. The Grid Remote Procedure Call (GridRPC) [START_REF] Seymour | Overview of GridRPC: A Remote Procedure Call API for Grid Computing[END_REF] approach provides such a paradigm, which extends the classical RPC model by enabling asynchronous, coarse-grained parallel tasking. GridRPC seems to be a good approach to build NES computing environments (for Network-Enabled Servers). In such systems, clients can submit problems to one (possibly distributed) agent, which selects the best server to use among a large set of candidates.

A team of researchers of the Global Grid Forum (GGF 1 ) has defined a standard API for the GridRPC paradigm [START_REF] Nakada | The End-User and Middleware APIs for GridRPC[END_REF]. However, in this specification, data management has been left as an open (although fundamental) issue. For instance, data transfer in the distributed environment is left to the user, who must explicitly move them back and forth between clients and servers. This clearly increases the program complexity, especially as the number of servers used to solve a problem increases.

In this paper, we define a model for transparent access to shared data in GridRPC environments. In this model, the data-sharing infrastructure automatically manages data localization, transfer, as well as consistent data replication. We illustrate our approach with an implementation using the DIET [START_REF] Caron | DIET: A Scalable Toolbox to Build Network Enabled Servers on the Grid[END_REF] GridRPC middleware and the JUXMEM [START_REF] Antoniu | JuxMem: An Adaptive Supportive Platform for Data Sharing on the Grid[END_REF] grid data-sharing service. We evaluate our approach through experiments realized on the Grid'5000 [START_REF] Bolze | Grid'5000: a large scale and highly reconfigurable experimental grid testbed[END_REF] testbed.

The remainder of the paper is organized as follows. Section 2 introduces the GridRPC model, presents the requirements of a sample application with respect to data management, then briefly describes previous attempts to solve data management issues in NES systems. Section 3 describes our transparent data access approach provided by our concept of grid data-sharing service. Section 4 presents the implementation of our proposal, using JUXMEM and DIET. Section 5 presents and discusses our experimental results using a real-life application. Finally, Section 6 concludes the paper and suggests possible directions for additional research.

Data management in the GridRPC model

Various programming models have been proposed in order to reduce the programming complexity of grid applications. The GridRPC model is such an ongoing work carried out by the Open Grid Forum (OGF), with the goal of standardizing and implementing the Remote Procedure Call (RPC) programming model for grid computing.

The GridRPC model

The GridRPC model enhances the classical RPC programming model with the ability to invoke asynchronous, coarse-grained parallel tasks. Requests for remote computations may indeed generate parallel processing, however this server-level parallelism remains hidden to the client.

The GridRPC approach has been defined in the GRIDRPC-WG [START_REF] Lee | Grid Remote Procedure Call WG (GRIDRPC-WG)[END_REF] working group of the GGF. The goal of this group is to specify the syntax and the programming interface at the client level [START_REF] Seymour | Overview of GridRPC: A Remote Procedure Call API for Grid Computing[END_REF]. This is meant to enhance the portability of GridRPC applications to various GridRPC middleware.

The GridRPC model aims at serving as a basis for software infrastructures called Network-Enabled Servers (NES). Such infrastructures allow multiple applications to concurrently run on a shared set of grid resources. Examples of middleware that implement the GridRPC specification are Ninf-G [START_REF] Tanaka | Design, implementation and performance evaluation of gridRPC programming middleware for a large-scale computational grid[END_REF], NetSolve [START_REF] Arnold | Users' Guide to NetSolve V1[END_REF], GridSolve [START_REF] Yarkhan | Recent Developments in Grid-Solve[END_REF], DIET [START_REF] Caron | DIET: A Scalable Toolbox to Build Network Enabled Servers on the Grid[END_REF], and OmniRPC [START_REF] Sato | OmniRPC: a Grid RPC System for Parallel Programming in Cluster and Grid Environment[END_REF].

Note that the GridRPC model knows the target server. Nevertheless some GridRPC middleware proposes to discover the best server automatically. In this case, servers register services to a directory. To invoke a service, instead of using the server given by GridRPC call function, clients bypass this parameter and look for a suitable, possibly "the best" server according to some performance metric. This selection is made out of a set of candidates proposed by the directory. GridRPC does not define any standard for the underlying resource discovery mechanism. The server selection is performed by one or several agents pr schedulers. The decision is usually made based on performance information provided by an information service. Informations can be static, such as processor speed or size of the memory, but also dynamic: available services, server load, input data location, etc. Based on this information, the agents make their decisions so as to optimize the overall throughput of the platform.

Two fundamental concepts in the GridRPC model are the function handle and the session ID. The function handle represents a binding between a service name and an instance of that service available on a given server. Function handles are returned by agents to clients. Once a particular function-to-server mapping has been established, all GridRPC calls of a client will be executed on the server specified by that function handle. A session ID is associated to each asynchronous GridRPC call and allows to retrieve the status of the request, wait for the call to complete, etc. Based on these two concepts, the interface of the GridRPC model mainly consists of the following two functions: grpc_call and grpc_async, which allow to make synchronous and asynchronous GridRPC calls respectively.

As regards data, most GridRPC middleware systems specify three access modes (also known as access specifiers) for parameters of a GridRPC call: 1) in data for input parameters that are not allowed to be modified by servers; 2)inout data for input parameters that can be modified by the server; 3) out data for output parameters produced by the server.

Requirements for data management in the GridRPC model

To illustrate the requirements related to data management in the GridRPC model, we have selected the Grid-TLSE project [START_REF] Daydé | An Overview of the GRID-TLSE Project[END_REF]. This application aims at designing a Web portal exposing expertise about sparse matrix manipulation. Through this portal, the user may gather statistics from runs of various sophisticated sparse matrix algorithms on specific data. The input data are either submitted by the user, or picked up from a matrix collection available on the site. In general, matrix sizes can vary from a few megabytes to hundreds of megabytes. The Grid-TLSE application uses the DIET GridRPC middleware to distribute tasks over the underlying grid infrastructure. Each such task consists in executing a parallel solver, such as MUMPS [START_REF] Amestoy | A fully asynchronous multifrontal solver using distributed dynamic scheduling[END_REF], over a matrix, with fixed parameters. We focus on the MUMPS solver for our experiments (see Section 5.2).

When using Grid-TLSE, a typical scenario consists in determining the ordering sensitivity of a class of solvers, that is, how performance is impacted by the matrix traversal order. It consists of three phases. Phase 1 exercises all possible internal orderings in turn. Phase 2 computes a suitable metric reflecting the performance parameters under study for each run: effective FLOPS, effective memory usage, overall computation time, etc. Phase 3 collects the evaluation of this metric for all combinations of solvers/orderings and reports the final ranking to the user. If phase 1 requires exercising n different kinds of orders with m different kinds of solvers, then m × n executions are to be performed, using the same input data. If the server does not provide persistent storage, the matrix has to be sent m×n times to the server! If the server provided persistent storage, the data would be sent only once. Second, if the various pairs solvers/orderings are handled by different servers in phase 2 and 3, then transparent and consistent data transfer or replication across servers should be provided by the data management service. Finally, as the number of solvers/orderings is potentially large, many nodes are used. This increases the probability for faults to occur, which makes the use of fault tolerant algorithms to manage data mandatory. Based on this application example, we can draw the requirements for a data management service for the GridRPC model.

Persistent storage.

Clients should be able to invoke services on input data that is already present on the grid infrastructure, to avoid repeated data transfers to servers. Passing arguments by reference for shared data. This is a consequence of the above requirement, as clients need a means to reference data which is shared by multiple GridRPC calls. Consequently, data consistency must be guaranteed in case of concurrent accesses. Transparent data localization and transfer. Such a transparency would simplify the use of the GridRPC paradigm at a large scale, as developpers would no longer need to explicitly move data. Efficient communication. An efficient use of the available bandwidth for data transfers requires to adequatly manage data granularity: only the data needed to perform computations should be copied or moved. GridRPC interoperability. Any solution addressing the previous issues needs to be compatible with the existing core API of the GridRPC model. Thus current applications can take advantage of any improvement in data management without modifications.

Current proposals for data management in the GridRPC model

In the current GridRPC model, as defined by OGF, data persistence is not yet provided and has been left as an open issue. Therefore, output data of a computation (inout and out) are systematically sent to the client, whereas input data (in) are destroyed on the server. Hence, data needs to be transfered again if needed for another computation. Moreover, if data are required on multiple servers at the same time, multiple transfers from the client are needed.

The issue of data management in the GridRPC model has however been recognised as a topic of major interest. The very first proposal related to data management relies on the concept of request sequencing [START_REF] Arnold | Request Sequencing: Optimizing Communication for the Grid[END_REF]. This feature consists in scheduling a sequence of GridRPC calls made by a client on a given server. In the client program, a sequence is identified by keywords begin_sequence and end_sequence. Data movements due to dependencies in calls between such keywords are then optimized. Request sequencing has been implemented in NetSolve and Ninf. To enable the calls of a sequence to be solved in parallel on two different servers, NetSolve has been enhanced [START_REF] Desprez | Improving the GridRPC Model with Data Persistence and Redistribution[END_REF] with data redistribution between servers (which however requires explicit calls in the NetSolve client application).

Another approach for data management relies on distributed storage infrastructure, such as Internet Backplane Protocol (IBP [START_REF] Bassi | The Internet Backplane Protocol: A Study in Resource Sharing[END_REF]). In this approach, clients send data to storage servers, which retrieve data as needed. NetSolve has been modified in such a way. However, data is still explicitly transfered to/from the storage servers at the application level. Besides, no support for data replication and consistency management, nor for fault tolerance is provided.

Finally, other GridRPC systems have developped ad-hoc, specific mechanisms for data management. The OmniRPC GridRPC middleware supports a static persistence model for input data of a set of GridRPC calls [START_REF] Nakajima | Performance Evaluation of Om-niRPC in a Grid Environment[END_REF]. The user has to manually define a initialization procedure to indicate which input data should be sent and stored prior to computations. Then, these data can be reused for subsequent calls. In an earlier version, the DIET GridRPC middleware relies on an internal data management system, called Data Tree Manager (DTM), which allows to store persistent data [START_REF] Fabbro | Data management in grid applications providers[END_REF] on the computing servers. However, as in both cases ad-hoc solutions are used to handle data persistence, GridRPC interoperability cannot be guaranteed, as data cannot be shared among multiple GridRPC middleware frameworks. Besides, none of these solutions addresses fault tolerance and consistent replication.

Based on such preliminary efforts, an attempt to standardize data management in NES is currently being pursued within the framework of the GridRPC working group of the OGF [START_REF] Nakada | The End-User and Middleware APIs for GridRPC[END_REF]. It relies on the concept of data handle, which abstracts a given data as well as its location. In addition to the possibility of referencing data stored inside external storage systems, transparent access to data is also envisioned. However, replication, consistency guarantees and fault tolerance issues have not been addressed yet.

3 Our approach: a transparent data access model

The concept of data-sharing service

Let us recall that one of the major goals of the grid concept is to provide an easy access to the underlying resources, in a transparent way. The user should not need to be aware of the localization of the resources allocated to applications. When applied to the management of the data used and produced by applications, this principle means that the grid infrastructure should automatically handle data storage and data replication and/or transfer among clients, computing servers and storage servers as needed. It should also transparently provide fault tolerance and data consistency guarantees in such dynamic, large-scale, distributed environments.

In order to achieve a real virtualization of the management of large-scale distributed data, a step forward has been made by the proposal of a transparent data access model, as a part of the concept of grid data-sharing service [START_REF] Antoniu | GDS: An Architecture Proposal for a grid Data-Sharing Service[END_REF]. In this transparent data access approach, the user accesses data via global identifiers, which allow to do argument passing by reference for shared data. The service which implements this model handles data localization and transfer without any help from the programmer. The data sharing service concept is based on a hybrid approach inspired by DSM systems (for transparent access to data and consistency management) and peer-to-peer (P2P) systems (for their scalability and volatility tolerance). An illustration of this concept has been realized through the JUXMEM software experimental platform [START_REF] Antoniu | JuxMem: An Adaptive Supportive Platform for Data Sharing on the Grid[END_REF]. The service specification includes three main properties.

Persistence. The data sharing service provides persistent data storage and allows the applications to reuse previously produced data, by avoiding repeated data transfers between clients and servers. Data consistency. Data can be read, but also updated by the different codes. When data is replicated on multiple sites, the service has to ensure the consistency of the different replicas, based on previously defined consistency models and protocols.

Fault tolerance. The service has to keep data available despite disconnections and failures, e.g. through the transparent use of failure detection mechanisms and replication techniques.

Let us note that these properties match well the requirements for data management in the GridRPC model, as discussed in Section 2.2. We therefore propose to jointly use the two approaches. In this paper, we show how persistence can be provided in a transparent way. Data consistency is ensured by providing a multi-protocol framework allowing various consistency models and protocols to be implemented. JUXMEM currently supports the entry consistency model through a hierarchical, fault-tolerant protocol. A description of the concepts and technical details related to data consistency and fault tolerance is beyond the focus of this paper. The corresponding mechanisms have been detailed in [START_REF] Antoniu | How to bring together fault tolerance and data consistency to enable grid data sharing[END_REF].

Overview of the JUXMEM data-sharing service

The JUXMEM [START_REF] Antoniu | JuxMem: An Adaptive Supportive Platform for Data Sharing on the Grid[END_REF] software experimental platform illustrates the concept of data-sharing service. The architecture of the service has been designed so as to address the properties mentioned in Section 3.1. JUXMEM's architecture mirrors a grid consisting of a federation of distributed clusters and it is therefore expressed in terms of hierarchical groups. The goal is to accurately take into account the latency hierarchy of the physical network topology, to take advantage of the low-latency links within the clusters and reduce higher-latency, inter-cluster communications. All nodes participating to the data-sharing service network overlay are members of the JUXMEM group. All members of the JUXMEM group that belong to the same physical cluster form a cluster group.

Manager Node

Group "cluster A"

Group "data"

Group "cluster B"

Group "cluster C" Any cluster group consists of provider nodes which supply memory for data storage. Each cluster group is managed by a special peer, called a manager. Managers make up the backbone of a given JUXMEM overlay and handle the propagation of memory allocation requests. Any node (including providers) may use the service to allocate, read or write data as clients, in a peer-to-peer approach. Any data stored in JUXMEM is transparently accessed through a global, location-independent identifier, which designates a specific data group that includes all replicas of that data. These replicas are kept consistent despite possible failures and disconnections [START_REF] Antoniu | How to bring together fault tolerance and data consistency to enable grid data sharing[END_REF]. This software architecture has been implemented using the JXTA [START_REF] Traversat | Project JXTA 2.0 Super-Peer Virtual Network[END_REF] generic P2P platform.

JUXMEM from the user's perspective

The programming interface proposed by the JUXMEM grid data-sharing service provides users with classical functions to allocate and map/unmap memory blocks, such as juxmem_malloc, juxmem_calloc, etc. When allocating a memory block, the client has to specify: 1) on how many clusters the data should be replicated; 2) on how many providers in each cluster the data should be replicated; 3) the consistency protocol that should be used to manage this data. The allocation operation returns a global data ID. This ID can be used by other nodes in order to access existing data through the use of the juxmem_mmap function. It is the responsibility of the implementation of the grid data-sharing service to localize the data and perform the necessary data transfers based on this ID. This is how a grid data-sharing service provides a transparent access to data.

According to the entry consistency model implemented by JUXMEM, processes that need to access data need to properly synchronize by acquiring a lock associated to that data. This is done by calling juxmem_acquire_read (prior to a read access) or juxmem_acquire (prior to a write access). Note that juxmem_acquire_read allows multiple readers to simultaneously access the same data. The juxmem_release primitive must be called after the access, to release the lock. These synchronization primitives allow the implementation to provide consistency guarantees according to the consistency protocol specified by the user at the allocation time of the data.

To make local data globally available in JUXMEM, the juxmem_attach function can be used. This function creates the corresponding data replicas (similarly to the juxmem_malloc primitive) and returns a data ID which is used by other nodes to get access to the data. When they no longer need to access the shared data, clients can remove their local data copies using the juxmem_unmap primitive. Finally, to keep the local data copy while removing it from the control of the grid data-sharing service, clients must use the juxmem_detach primitive.

Using JUXMEM for transparent data sharing in the DIET GridRPC middleware

To illustrate how a GridRPC system can benefit from transparent access to data, we have implemented the proposed approach inside the DIET GridRPC middleware, using the JUXMEM data-sharing service. Note however that the concept of grid data-sharing service can also be used in connection with other GridRPC middleware.

An overview of a GridRPC middleware framework: DIET

The Distributed Interactive Engineering Toolbox (DIET) platform [START_REF] Caron | DIET: A Scalable Toolbox to Build Network Enabled Servers on the Grid[END_REF] is a GridRPC middleware, whose architecture is described on Figure 2. It relies on the following en- tities. A Client is an application which uses DIET to solve problems. Agents receive computation requests from clients. A request is a generic description of the problem to be solved with data information (type, size, etc.). Agents collect the computational capabilities of the available servers, and selects the best server according to the given request. Eventually, the reference of the selected server is returned to the client, which can then directly submit its request to this server. As opposed to other GridRPC middleware, for scalability purpose, agents can be organized in a set of trees forming a forest of local agents (LA) rooted at a master agent (MA). The Server Daemon (SeD) encapsulates a computational server and makes it available to its parent LA. It also provides the potential clients with an interface for submitting their requests. Like other GridRPC middleware, DIET specifies three access modes for each data involved in a computation (see section 2.1).

How DIET uses JUXMEM to manage data

In our work, DIET internally uses JUXMEM whenever a data is marked as persistent. However, we distinguish two cases for persistent data. If the DIET client needs to access persistent data at the end of the computation, the persistence mode is set to PERSISTENT_RETURN. Otherwise, it is set to PERSISTENT.

Listings 1.1 and 1.2 show an example of how DIET internally uses JUXMEM to manage data for the multiplication of two matrices A and B. The output of the computation produces the matrix C. Figure 3 presents the entities involved: one DIET client D, one DIET SeD S1 and two JUXMEM providers F 1 and F 2 2 . Let us assume that all matrices are persistent. First, input matrices are stored into JUXMEM by the client (step 1 of Figure 3, lines 5 and 6 of Listing 1.1), and their IDs ID(A) and ID(B) are sent in the computational request to S1 (step 2, line 8). On the server side, these IDs are used to locally map and acquire the input matrices in read mode (step 3, lines 5 to 8 of Listing 1.2). Then, the computation produces matrix C (line 10). Therefore, the read lock on matrices A and B is released (lines 12 and 13), and matrix C is attached inside JUXMEM (step 4 and line 14). Its identifier (ID(C)) is sent back to the client D (step 5), 2 For the sake of clarity on the figure, however in practice F 2 can be equal to F 1. so that it can be locally mapped and acquired in read mode by the client (steps 6, lines 10 to 12 of Listing 1.1). 4.2 summarizes the interaction between DIET and JUXMEM in each case, depending on the data access mode (e.g. in, inout, out) on both client/server side. In the previous example, matrices A and B are in data, and matrix C is an out data. Note that for inout and out data, calls to JUXMEM are executed after the computation on the client side only if the persistent mode is PERSISTENT_RETURN. Modifications performed inside the DIET GridRPC middleware to use JUXMEM for the management of persistent data are small. They consist of 200 lines of C++ code, activated whenever DIET is configured to use JUXMEM. Consequently, DIET is linked with the C/C++ binding of JUXMEM. In our setting, DIET clients or SeDs use JUXMEM's API to store/retrieve data, thereby acting as JUXMEM clients. Note also that our solution supports GridRPC interoperability, DIET simply uses JUXMEM's API, with no extra code for data management.

Experimental evaluations

In this section, we present the experimental evaluation of our JUXMEM-based data management solution inside DIET.

Experimental conditions

We performed tests using 4 clusters (Rennes, Orsay, Toulouse and Lyon) of the French Grid'5000 testbed [START_REF] Bolze | Grid'5000: a large scale and highly reconfigurable experimental grid testbed[END_REF], using a total number of 3 sites simultaneously for a total number of 129 nodes. Grid'5000 is an experimental grid platform consisting of 9 sites (clusters) geographically distributed in France, whose aim is to gather a total of 5,000 CPUs in the near future. The nodes used for our experiments consist of machines using dual (2.2, 2.4, 2.6 GHz) AMD Opteron, outfitted with 2 GB of RAM each, and running a 2.6 version Linux kernel; the network layer used is a Giga Ethernet (1 Gb/s) network inside each cluster of Grid'5000. Between clusters, links of 10 Gb/s are used and the latency ranges from 4,5 ms to 10 ms.

Tests were executed using JUXMEM 0.3 and DIET 2.1. All benchmarks are compiled using gcc 4.0 with the -O2 level of optimization. As regards deployment, we used the ADAGE [START_REF] Lacour | Generic application description model: Toward automatic deployment of applications on computational grids[END_REF] generic deployment tool for JUXMEM and GoDIET [START_REF] Caron | GoDIET: A Deployment Tool for Distributed Middleware on Grid[END_REF] for DIET.

Experiments using MUMPS: a sparse parallel solver

Our goal is to demonstrate and measure the benefits of the management of persistent data by JUXMEM, in terms of impact on the overall execution time of a real-life application. We focus on MUMPS ("MUltifrontal Massively Parallel Solver"), a package for solving systems of linear equations of the form Ax = b, where A is a square sparse matrix that can be either asymmetric, symmetric positive definite, or general symmetric. MUMPS uses a multifrontal technique which is a direct method based on either the LU or the LDL T factorization of the matrix. We refer the reader to the paper [START_REF] Amestoy | Hybrid scheduling for the parallel solution of linear systems[END_REF] for full details of these techniques.

We performed 3 sets of experiments using MUMPS (noted E1, E2 and E3). E1 has been performed in a one-cluster environment, whereas E2 and E3 are performed in a multi-cluster environment, using the Grid'5000 testbed, with E3 at a larger scale compared to E2. In all our experiments, a client loops 32 times on a synchronous GridRPC call to MUMPS, with the aforementioned linear equation to solve. A and b are input data (data access mode set to in) whereas x is an output data. Between each GridRPC call, b is changed according to the resolution needs while A is unchanged and its persistence mode is set to PERSISTENT. Therefore note that when JUXMEM is used by DIET for the management of matrices A, DIET calls JUXMEM primitives according to the first row of Table 4.2. For all experiments we used 2 different sizes for the A matrix: a medium size of 22 MB (A1) and a larger size of 52 MB (A2). Let us stress the difficulty of setting up such kind of experiments for a real-life, complex application, using an environment which relies on 2 different runtime software (JUXMEM and DIET), based on different technologies (JXTA and CORBA respectively) and using different deployment tools that need to interact with each other.

As a first experiment performed inside a single Grid'5000 cluster, we simply deployed a DIET hierarchy made of 1 MA, 1 LA and 1 SeD, as well as a JUXMEM network made of 1 provider and 1 manager. The goal of this experiment E1 is to measure the overhead of using JUXMEM for data management. Results show that if DIET is configured to use JUXMEM to store persistent data, the total execution time of all calls slightly increases, compared to DIET configured without JUXMEM: from 36.6 to 41.3 seconds with A1 and from 957 to 961 seconds with A2. We can argue that the overhead of using JUXMEM for data management of large matrices inside DIET is therefore low: it is less than 1 % with A2. Note however that this overhead increases when using smaller matrices, e.g. it reaches 13 % for matrix A1.

In a second experiment, our goal is to measure the (expected!) benefits of using JUXMEM for transparently managing persistent data in grid environment (however at a small scale). To do this, we deployed a 3-cluster configuration. In each cluster, we deploy a DIET hierarchy made of 1 LA and 1 SeD and a JUXMEM network made of 1 provider and 1 manager. We use 3 clusters of the Grid'5000 testbed, namely Lyon, Toulouse and Rennes. Results show a clear advantage to use JUXMEM, as the total execution time of the application is reduced by 42 % with A1 and by 38 % with A2, compared to results obtained for DIET configured without JUXMEM (see Table 5.2). Compared to the E1 experiment, the smaller execution time with A2, when JUXMEM is used, is explained by the difference of processor performance on the three sites that are used for the computations.

Finally, we performed a third experiment (E3) similar to E2, where we increased the configuration sizes, by using 32 SeDs and 8 JUXMEM providers in each cluster. The goal of this experiment is to measure the impact of an increasing number of SeDs on the performance of JUXMEM (as this leads to an increasing number of JUXMEM clients accessing the data). With A1, the total execution time is the same for both configurations (DIET configured with or without JUXMEM): 103 seconds. With the larger A2 matrix, this time is reduced by 38 % when JUXMEM is used (843 seconds), compared to DIET configured without JUXMEM (1358 seconds). Note that these results are averaged based on 4 runs, since the DIET agent may take different scheduling decisions by choosing different nodes (and clusters) from one computation to another. This also explains the difference between results obtained for A2 in this experiment and experiment E2: the number of GridRPC calls performed on 1 site may change between runs. Finally, Table 5.2 summarizes obtained results for experiments E1, E2 and E3 based on MUMPS. Notably, these results demonstrate the advantage to use JUXMEM for managing persistent data in the GridRPC model in a grid environment: the execution time of a MUMPS application is kept to its value as in a cluster execution, despite the high-latency WAN connections. As explained previously, the reduced times (rows 2 and 3 of last columns of Table 5.2) come from the difference in processor speeds of nodes used for the various computations across the sites.

Conclusion

Programming grid infrastructures remains a significant challenge. The GridRPC model is the grid form of the classical RPC approach. It offers the ability to perform asynchronous coarse-grained parallel tasking, and hides the complexity of server-level parallelism to clients. In its current state, the GridRPC model has not specified adequate mechanisms for efficient data management. One important issue regards data persistence, as multiple GridRPC calls with data dependencies are executed.

In this paper, we propose to couple the GridRPC model with a transparent data access model. Such a model is provided by the concept of grid data-sharing service. Data management (persistent storage, transfer, consistent replication) is totally delegated to the service, whereas the applications simply access data via global identifiers. The service automatically localizes and transfers or replicates the data as needed.

We have illustrated our approach by showing how the DIET GridRPC middleware can benefit from the above properties by using the JUXMEM grid data-sharing service. Experimental measurements on the Grid'5000 testbed show that introducing persistent storage has a clear impact on the execution time. Using a real-life application based on a sparse matrix parallel solver, experiments performed on the Grid'5000 testbed show that the use of JUXMEM allows to keep an execution time as if the application was executed in a cluster, despite the high-latency WAN connections.

The main contribution of our approach compared to related work having dealt with data persistence in GridRPC environments consists in showing that efficiency can be obtained through the use of a generic data-sharing service, providing locationtransparent data access. Moreover, our approach also allows to transparently benefit from replica consistency and fault-tolerance mechanisms. We did not develop these aspects in this paper (they have been illustrated in [START_REF] Antoniu | How to bring together fault tolerance and data consistency to enable grid data sharing[END_REF] in a more general way). A GridRPC-specific study of these aspects could be addressed in future work. For instance, it would be interesting to evaluate the impact of using the fault tolerance mechanisms provided by JUXMEM on application execution time, in presence of data storage failures.

To extend our contributions to data management in NES through the features offered by JUXMEM, several directions can be pursued. First, we plan to provide data placement information to the request scheduling algorithms. This would make it possible to balance more precisely the load among available servers. Then, we would like to implement a cache mechanism inside JUXMEM clients to avoid fetching data from providers at each GridRPC call. In addition, JUXMEM consistency and fault-tolerance mechanisms have been tested using synthetic benchmarks [START_REF] Antoniu | How to bring together fault tolerance and data consistency to enable grid data sharing[END_REF], outside the GridRPC model. We would like to further evaluate them by using other real-life DIET applications which exhibit such requirements, such as climate modeling and cosmology simulations. Besides, we also plan to compare JUXMEM with non location-transparent data access solutions, such DIET DTM for instance. Finally, the implementation of a classical file-system API over JUXMEM would allow applications based on this API to transparently leverage JUXMEM's functionalities. We have already started such a work, called JUXMEMFS, by relying on the FUSE library [START_REF] Szeredi | Filesystem in Userspace (FUSE)[END_REF] available on Linux systems.

Fig. 1 .

 1 Fig. 1. Hierarchy of the entities in the network overlay defined by JUXMEM.

Fig. 2 .

 2 Fig. 2. The hierarchical organization of DIET.

Fig. 3 .

 3 Fig. 3. Multiplication of two matrices by a DIET client configured to use JUXMEM for persistent data management.

1 grpc_error_t 2 Listing 1 . 1 .Listing 1 . 2 .

 121112 grpc_call (grpc_function_handle_t * handle) { 3 grpc_serveur_t * SeD = request_submission(handle); 4 ... 5 char * idA = juxmem_attach(handle->A, data_sizeof(handle->A)); 6 char * idB = juxmem_attach(handle->B, data_sizeof(handle->B)); 7 ... 8 char * idC = SeD->remote_solve(multiply, idA, idB); 9 ... 10 juxmem_mmap(handle->C, data_sizeof(handle->C), idC); 11 juxmem_acquire_read(handle->C); 12 juxmem_release(handle->C); 13 } Internal DIET client code related to JUXMEM for the multiplication of two persistent matrices A and B on a SeD. 1 char * 2 solve (grpc_function_handle_t * handle, 3 char * idA, char * idB) { 4 ... 5 double * A = juxmem_mmap(NULL, data_sizeof(handle->A), idA); 6 double * B = juxmem_mmap(NULL, data_sizeof(handle->B), idB); juxmem_attach(C, data_sizeof(handle->C)); 15 } Internal DIET SeD code related to JUXMEM for the multiplication of two persistent matrices A and B on a SeD. Table

Table 1 .

 1 Use of JUXMEM inside DIET for in, inout and out persistent data on client/server side, before and after a computation. The juxmem prefix has been omitted.

		Client side	SeD side
	Computation	Before	After	Before	After
	in	attach; msync; detach;		mmap; acquire_read;	release; unmap;
	inout	attach;	acquire_read;	mmap;
		msync;	release;	acquire;
	out		mmap;		attach;
			acquire_read;		msync;
			release;		unmap;

Table 2 .

 2 Total execution time in seconds of a MUMPS application when DIET is configured to use JUXMEM or not, for 2 different matrices A1 and A2.

	Matrix	A1		A2
	DIET configured Without JUXMEM With JUXMEM Without JUXMEM With JUXMEM
	Experiment E1	36.6	41.3	957	961
	Experiment E2	92.6	53.7	1420	880
	Experiment E3	103	103	1358	843

GGF, recently merged with EGA (Enterprise Grid Alliance) to create the OGF (Open Grid Forum)

Acknowledgements

Experiments presented in this paper were carried out using the Grid'5000 experimental testbed, an initiative from the French Ministry of Research through the ACI GRID incentive action, IN-RIA, CNRS and RENATER and other contributing partners (see https://www.grid5000. fr/. The work has been partially supported by the GDS (ACI MD) grant and by the LEGO (ANR-CICG05-11) grant.