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.