Path: utzoo!utgpu!watserv1!watmath!att!tut.cis.ohio-state.edu!ucbvax!LCCMAIL.OCF.LLNL.GOV!Sam_Coleman.NSD From: Sam_Coleman.NSD@LCCMAIL.OCF.LLNL.GOV (Sam Coleman) Newsgroups: comp.protocols.tcp-ip Subject: FTP enhancements Message-ID: <9012160626.AA14268@ucbvax.Berkeley.EDU> Date: 12 Dec 90 22:49:38 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 71 Subject: Time:8:39 AM OFFICE MEMO FTP enhancements Date:12/5/90 We at LLNL are looking at requirements for future file transport between various Unix machines. We use FTP now and we've looked at Background FTP. In our environment, these seem to fall short in several areas that I'll describe below. I'd appreciate your corrections and additions. We'd like to stick with "standard" interfaces, maybe enhancing FTP and/or BFTP. I'm wondering if anyone has encountered similar problems, developed better solutions, or is interested in working with us to develop something better. I haven't heard anything lately concerning the RFC for BFTP. Is anything happening there? The chair of IETF (Internet Engineering Task Force), Phill Gross, is not aware of any active FTP development. Would it be reasonable to form a working group under IETF to enhance FTP and/or BFTP? Would an enhanced FTP protocol make it easier to produce standard higher-level command or graphical interfaces like HyperFTP and FTA? Sam Coleman Lawrence Livermore National Lab coleman@llnl.gov Some comments on FTP and BFTP ----------------------------- Passwords - Both FTP and BFTP require clear-text passwords. Our security folks won't allow clear-text passwords to be stored in files. Is Kerberos a solution? Persistence - FTP has none; if a transfer fails, the user has to retry. Background FTP has a simple retry mechanism. Performance - File transfers go through the FTP client and TCP/IP. Is there a faster way to do the actual data transfers? Notification - BFTP sends mail to the client when a transfer completes. Is this the best way to handle notification in production environments? Synchronous operation - FTP does one thing at a time. The user can give BFTP multiple jobs, but BFTP seems to plug through these synchronously if they are invoked using wild cards. Thus you can't take advantage of parallelism that might be available in the file system (e.g. mounting tapes concurrently). Flow control - FTP servers generally have no mechanisms to inhibit file transfers during heavy load; file movement slows to a crawl as the load on the server increases, then they reject log-ons, and then connections are refused (maybe it's a good thing that FTP is synchronous?). We would like to put flow control in the FTP server to delay file transfers when necessary, but allow log-ons and short commands (like ls). Perhaps priority could be given to small and/or fast transfers? Tape files - FTP doesn't handle well the case where there is a delay accessing a file, e.g. when the file is on tape. Should there be a way to configure FTP? A .FTPRC file to allow the user to specify his own defaults. Error reporting in some clients could be improved. Clients - there are differences between various FTP clients. Perhaps a working group could help standardize them? Missing functions - Some useful functions, like chmod, are provided by Unicos FTP but not by other clients. When FTP is the primary interface to an archive, it would be nice to have more complete file system functionality. Wild cards - FTP provides MGET, MPUT, and MDEL (why not GET *, etc?), but functions like chmod don't support wild cards. I would suggest wider and more consistent semantics. Should the server prompt the user rather than the client?