Problems with FTP as a reliable grid transfer protocol: 1. Partial files. A server can't tell the difference between the end-of-file and a dropped/aborted transfer. This means that partial files will end up in the underlying mass storage system and this is not what the user wants. There is a server acknowledge back to the client at the end of a transfer, but this is not a handshake, so the server has no idea of whether the client is there or not. The size command gets around this problem, but is usually not required to transfer files. Imposing this restriction would cause not be generally compatible with the numerous ftp clients. Similarly, the ftp block mode contains enough information to determine if a complete file has been sent or if a transfer has been aborted. This mode is defined in the standard, but not in widespread use. In both cases (size and block), normal ftp installations are expected, although not required, to keep the partial files for the user to complete the transfer. For a grid connected to a storage system, these partial files are an added nuisance, although not a severe one (the system could just throw them away). In summary, the typical ftp clients do not transfer files in such a way so a server can tell the difference between a end-of-file and a partial transfer. 2. ACL timeouts. Many networks have ACL limitations imposed on them. A common ACL is the "reflexive" ACL. A connection is allowed by a remote client only if the connection has been initiated by the local side. These reflexive acls have timeouts usually in the minutes, but almost always less than 30 minutes. [There is a tradeoff between opening it up larger and security concerns.] Transfers that take a long time to complete (slow link, big files) are the problem. There is plenty of activity on the ftp data socket, but no traffic on the ftp control socket. The acl on the ftp control times out and the server can not send the client its acknowledgement. Moreover, the client can't send more commands (because the control port connection is broken) without stopping and restarting. 3. 3rd party passive transfers are not possible. Typically passive transfers are used in the cases of firewalls or reflexive acls. The ftp passive protocol requires that control and data ports be negotiated before the filename is sent. Since data could be in many places (different storage pools), the server has no way of negotiating ports for a unknown (and more than likely, different) computer. The only way around this is to introduce a "adaptor tunnel", whereby the file is 1st transferred from the storage pool to a known computer and then to the clients computer. This gets around the port negotiation, but introduces a scalability problem. There is a bottleneck introduced in the adaptor.