What is it?

Third-party FTP involves a client and two servers. Instead of exchanging files directly with one server, the client causes the two servers to exchange files. The client can be on the same node as one of the servers or it can be somewhere else.

Why do we need it?

MySpace can make good use of third-party FTP. It's a way to migrate data between MySpace nodes.

Consider an application service a1 at node A that is commanded to operate on data currently at node B, where B has a MySpace server b0; the client commanding the operation is c at node C. Without third-party transfer there are two ways to get the data to B: either c copies first from B to C and then from C to A, or a1 talks directly to b0 to transfer from A to B. Neither of these solutions is ideal. The double-transfer wastes bandwidth and C may be outside the high-speed backbone of the network. Having a1 talk to b0 is efficient, but it makes a1 more complex. If there are many services a1..an at A, then it would be neater to just have one service a0 that corrsponds with b0.

Now suppose that a0 and b0 are both GridFTP servers. The client c can then tell a0 to collect and cache the data from b0. It can then tell a1 to operate on a URL that represents a local file.

Where do we get it from?

The GridFTP servers in the Globus Toolkit (GT2) can do third-party FTP if we can get them configured correctly. It may be that ordinary FTP servers can do it too; this is unclear at the moment.

An example

This is the generic form of the command (from the Unix shell) for GridFTP:

globus-url-copy gsiftp://aife.jb.man.ac.uk/tmp/sample gsiftp://cass111.ast.cam.ac.uk/tmp/sample

In principle, this works from anywhere; you don't have to be on aife or cass111 to do it.

In practice, the command fails like this:

gtr@cass123> globus-url-copy gsiftp://aife.jb.man.ac.uk/tmp/wibble gsiftp://cass111.ast.cam.ac.uk/tmp/wibble
error: the server sent an error response: 500 500 Illegal PORT Command

This means that one of the servers rejected a command to select a data port in the other server. It's a configuration problem: FTP servers don't like taking PORT commands from addresses other than that of the current client. The restrictions are controlled by the file $GLOBUS_LOCATION/etc/ftpaccess and this file needs to be changed to allow PORT commands from all addresses.

-- GuyRixon - 11 Oct 2002

---

An interesting idea.

'c' would presumably be the job control utility (JCU) in most cases. It would therefore need to know that service 'a1' is of a type that works best with the data local rather than read direct from B. Which would mean putting this in the service metadata to be interpreted. I guess it is better for the JCU to do this as it is more likely to be able to get at the bandwidth characteristics between the two sites.

I was thinking that maybe the workflow engine (WFE) should sort this out but it is better left with the JCU to determine the best way of completing a job at the time the job is run rather than the WFE which may have constructed the job days, weeks or months before (eg in the case of a standard job being run and rerun over time).

Thinking more - for those jobs where it is better to read the data from the source rather than copy it over (eg in a case where job 'a1' might stop after reading a dozen records from a 10 Tb file), should we set up a LocalReader service which provides access to any file and provides buffering and read-ahead, or are there technologies that do this efficiently anyway? Maybe we should create something like ADO, which can read from files, databases etc providing the appropriate driver is available and hides the complexities from the user? Or does this conflict with DAI?

I'll stop now - I'm waffling...

-- TonyLinde - 11 Oct 2002

---

See AstroGridMyPipe for a description of something like Tony's LocalReader . At the cost of double buffering each transfer, this effect could be got by copying the remote file into a local file that is a POSIX named pipe. I suspect that any service we wrote to buffer a streamed file in memory and supply bits of it on demand would be less efficient than the named pipe; however it might be more flexible. A custom service would make it easier to have the pipe self-destruct after reading.

It will certainly be necessary to state in the service metadata how a service is prepared to take its data. I suspect that "works best" could resolve to "works at all". The set of services that can run purely off read-once data-streams may be small.

-- GuyRixon - 24 Oct 2002

---

A progress update. Several AstroGrid sites have GT2.2 GridFTP-servers, and Cambridge now has one of these on cass123 (the server on cass111 is the old GT2.0 version). Using these servers and the ftaccess files supplied with GT2.2, third-party FTP is now working. I have tested these configurations:

• RAL to CASU, invoked from CASU (different CASU machines for client and server).
• RAL to JBO, invoked from CASU.
• CASU to JBO, invoked from CASU (different CASU machines for client and server).
• JBO to CASU, invoked from CASU (different CASU machines for client and server).

The client for this is globus-url-copy.

-- GuyRixon - 24 Oct 2002