| 5 | | Assuming we need some sort of 3rd-party transfer I see 3 options: |
| 6 | | |
| 7 | | 1. Live without dedicated 3rd-party transfer support in the DeliveryService. |
| 8 | | Server to server data transfer can be implemented on a per service basis using |
| 9 | | the DeliveryService in the standard client-server manner. |
| 10 | | |
| 11 | | 2. Implement 3rd-party transfer as a high-level service which calls the low-level data |
| 12 | | transfer (presumably bbFTP) underneath. Such a service would act as the server to a |
| 13 | | controling client and a client to the other party to the data transfer. |
| 14 | | |
| 15 | | 3. Implement 3rd-party transfer at the xFTP protocol level. See below for details about this. |
| 16 | | |
| 17 | | == Option 3. == |
| 18 | | |
| 19 | | Since GridFTP is supposed to do 3rd party data transfer I decided to take a look at the |
| 20 | | [http://www.globus.org/alliance/publications/papers/GFD-R.0201.pdf GridFTP specification] and was surprised to discover that the FTP protocol already supports 3rd party transfer in theory, it is just rarely implemented. |
| 21 | | |
| 22 | | Here is the relevant extract from [http://www.faqs.org/rfcs/rfc959.html RFC 959]: |
| 23 | | |
| 24 | | {{{ |
| 25 | | When data is to be transferred between two servers, A and B (refer |
| 26 | | to Figure 2), the user-PI, C, sets up control connections with |
| 27 | | both server-PI's. One of the servers, say A, is then sent a PASV |
| 28 | | command telling him to "listen" on his data port rather than |
| 29 | | initiate a connection when he receives a transfer service command. |
| 30 | | When the user-PI receives an acknowledgment to the PASV command, |
| 31 | | which includes the identity of the host and port being listened |
| 32 | | on, the user-PI then sends A's port, a, to B in a PORT command; a |
| 33 | | reply is returned. The user-PI may then send the corresponding |
| 34 | | service commands to A and B. Server B initiates the connection |
| 35 | | and the transfer proceeds. The command-reply sequence is listed |
| 36 | | below where the messages are vertically synchronous but |
| 37 | | horizontally asynchronous: |
| 38 | | |
| 39 | | User-PI - Server A User-PI - Server B |
| 40 | | ------------------ ------------------ |
| 41 | | |
| 42 | | C->A : Connect C->B : Connect |
| 43 | | C->A : PASV |
| 44 | | A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2 |
| 45 | | C->B : PORT A1,A2,A3,A4,a1,a2 |
| 46 | | B->C : 200 Okay |
| 47 | | C->A : STOR C->B : RETR |
| 48 | | B->A : Connect to HOST-A, PORT-a |
| 49 | | |
| 50 | | }}} |
| 51 | | |
| 52 | | I.e. One server is put in passive mode and one in active mode. A good explanation of the difference can be found [http://slacksite.com/other/ftp.html here]. GridFTP states support for 3rd-party transfer in the specification. In practice this means that both passive and active FTP commands are extended to support striping across multiple data ports. |
| 53 | | |
| 54 | | On a casual read of the specifications it appears that, provided a server supports active mode, the main issue is with the client. It must support making control connections to 2 servers simultaniously and issueing the necessary PASV, PORT, STOR and RETR commands. |
| 55 | | |
| 56 | | Unlike GridFTP, bbFTP is not an extension of RFC-959. However, it claims to support both passive and "non-passive" mode. Therefore, it may be possible to adapt the client to do 3rd party transfer along the lines shown above. This may be a significant ammount of work and any consideration of it should be balanced against the work required to make GridFTP support NDG Security. |
