Standardized Multi-protocol Data Management for Grid and Cloud GridRPC Frameworks - Data Management in Cloud, Grid and P2P Systems - page 69

L-S: The transfer is initiated locally.
M-S: The transfer is processed through a call to the remote transfer service.
S-L: The transfer is initiated locally.
S-M: The transfer is performed through a call to the distant transfer service.
L-L: The transfer is initiated and performed locally.
L-M: The library makes the local data available via the GridRPC middleware
inner data manager whose remote counter part will download afterwards.
M-L: The remote middleware is being asked to make the data available, this
data is then downloaded by the GridRPC middleware.
M-M: The source middleware is asked to make the data available so that the
destination middleware can download it when needed.
S-S: The library first tries to invoke a remote service on the destination server
to initiate the transfer. If the transfer fails, data is downloaded on the
library client, then transferred to the destination server. If there is no
available protocol to proceed to such transfers, the call fails returning an
error code.

4 Experimental Results

4.1 Multi-protocol and Dispatcher Scheduling/Mapping Validation

Table 1 lists the experiment deployment. We used 3 computing resources, 2
in Japan and 1 in France, on which we deployed iRODS and ssh servers, and
Diet components: a client, a dietAgent (the registry), and a server (matrix ad-
dition) written with the GridRPC APIs requirements together with our library.
Two matrices are defined with a list of input URIs depending on the running
test, described hereafter.

Tabl e 1. Resources involved in Experiment 1

Machine (location) Services Data (protocol)
Arcterix (JFLI - Japon) dietAgent, client, sshd matA ( ssh )
yume (JFLI - Japon) service ' + ', iRODS , sshd matA, matB ( ssh )
graal (Ens-Lyon - France) sshd matB ( ssh )

There are four tests, built with the scenario of getting the two matrices
through ssh , performing the addition, and uploading the result to an iRODS
server (here locally):

- Remote/Remote: the client does not include the URIs concerning the host
yume in the input list used for the remote call.
- Remote/Local: the client does not use the URI concerning matA on yume
in the input list used for the remote call.
- Local/Remote: the client does not use the URI concerning matB on yume
in the input list used for the remote call.
- Local/Local: all URIs are used for in remote call.