GMILIEFS@MITVMA.MIT.EDU ("Gary S. Miliefsky") (10/06/89)
======================================================================== 36 I will be implementing MPUT and MGET in an FTP Client and have not been able to find an RFC for these two commands. If an RFC or a draft of some sort does exist, I would appreciate knowing about it. If not, I would like to of your interest in the formal documentation of these commands in a new RFC. Comments and suggestions are most welcome. Thank you in advance. Sincerely, Gary S. Miliefsky gmiliefs@mitvma.mit.edu
nagle@well.UUCP (John Nagle) (10/09/89)
Points to know about FTP history: 1) 3-cornered FTP (source, destination, and control points on different hosts) never worked. 2) Transferring many small files in succession tends not to work. If you try to reuse the data connection immediately, it won't reopen, even though the TCP spec says it should. This is a bug in the spec. Most current FTP implementations use the PORT command to get a new data connection for each file, leaving the old one to time out in TIME_WAIT state. This can result in resource exhaustion when many small files are being transferred. This problem can be worked around, at some cost in throughput in the many-tiny-file case. John Nagle
roy@phri.UUCP (Roy Smith) (10/09/89)
In article <14005@well.UUCP> nagle@well.UUCP (John Nagle) writes: > 1) 3-cornered FTP (source, destination, and control points on > different hosts) never worked. I'm curious as to why third-party FTP was ever invented. It's sort of neat, but always seemed to me to be complicated and unnecesary. Was it envisioned that it would be a poplular thing? -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
dyer@spdcc.COM (Steve Dyer) (10/09/89)
In article <14005@well.UUCP> nagle@well.UUCP (John Nagle) writes: > 1) 3-cornered FTP (source, destination, and control points on > different hosts) never worked. I *seem* to remember 3-cornered FTP working on NCP hosts, while I was at BBN, but then I might just be prematurely senile... -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
skl@van-bc.UUCP (Samuel Lam) (10/09/89)
In article <14005@well.UUCP> nagle@well.UUCP (John Nagle) writes: > 1) 3-cornered FTP (source, destination, and control points on > different hosts) never worked. I had to use it in a few past occasions and it worked for me, although it's a bit tedious to use since I couldn't find a FTP client that will do it and ended up talking to the two remote servers manually over a couple of Telnet calls. Or did you really mean "it was never a popular thing?" (That I agree.) ...Sam -- Samuel Lam <skl@wimsey.bc.ca> or {uunet,ubc-cs}!wimsey.bc.ca!skl
braden@VENERA.ISI.EDU (10/10/89)
Points to know about FTP history:
1) 3-cornered FTP (source, destination, and control points on
different hosts) never worked.
John,
Huh?? The UCLA MVS TCP/IP package ("ACP"), like its predecessor NCP
FTP package, used "3-cornered" FTP successfully, starting in 1974. It
still does. ISI recently wrote the BFTP program (see RFC-1068) to
perform background file transfers using "3-cornered FTP"; it has been
successful, and has been quite widely distributed. Where did this
"never" come from?
Bob Bradennagle@well.UUCP (John Nagle) (10/10/89)
I'm sorry, I had no idea that UCLA MVS was capable of that.
The systems decended from either BBN or Berkeley code generally didn't
have that capability, and the original FTP spec was rather hazy about
how it was supposed to work.
But it's nice that it's starting to work now.
John Naglepostel@VENERA.ISI.EDU (10/10/89)
1) 3-cornered FTP (source, destination, and control points on different hosts) never worked. The above claim notwithstanding, however, see RFC 1068 on BFTP. --jon.
sra@lcs.mit.edu (Rob Austein) (10/10/89)
Date: 8 Oct 89 19:16:41 GMT From: nagle@well.UUCP (John Nagle) ... 3-cornered FTP (source, destination, and control points on different hosts) never worked. What about BFTP (RFC-1068)? I don't know how widely used it is, but it certainly works. --Rob Austein, MIT
romkey@asylum.sf.ca.us (John Romkey) (10/10/89)
I knew people who used third party FTP in order to transfer files to their Imagen printers. The Imagen's would allow you to just open a TCP connection to a certain point and blat a file over the connection, which they would then print. - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com "Live the life you love, Use a god you trust, and don't take it all too seriously." - Love & Rockets
CERF@A.ISI.EDU (10/10/89)
The 3-way FTP was used for various kinds of RJE management (remote job entry) in the early days of ARPANET when we still had a fair amount of batch processing going on. Remember, this was in the early 1970's. The access control complications in today's networking environment make this more complicated, but having a program on one machine manage the activities of programs on other machines seems useful even today (and not merely in the RJE context). One might choose other tools than 3-point FTP (i.e. more modern ones), of course. Vint Cerf
Mills@UDEL.EDU (10/10/89)
John, Harrumpth. Fuzzballs do it, too; even RFC-1068. Why, we use it at least once per year. Dave
ado@BBN.COM (Buz Owen) (10/11/89)
MGET and MPUT aren't explicitly specified in the FTP protocol spec (RFC 959) because these commands a matter "local" to the user ftp program -- only the language used between the FTP server program and the FTP user program is standardized by the protocol spec. Here are some hints though: For MPUT, the user FTP program should accept an argument which designates a group of local files to be sent -- a directory or subdirectlry name or file group specifier, expressed according to the host's local convention, and execute "STOR" commands for each of the files indicated. If the local system contained system calls or subroutines for interpreting file group specifiers, these facilities should be used to give standard local semantics to the argument. For MGET, the user program should accept a string argument (with no local interpretation), submit an NLST command with this string as its argument to the server to obtain a list of files on the server which match the argument, and then execute one RETR command for each filename in the list received from the server, retrieving each of the files in turn. A point to watch out for here is that (a naive implementation of) the FTP server might only respond to NLST with whole directory or subdirectory listings -- i.e. fail to implement its own local group name convention, or the server's operating system might not have a file group naming convention. In any case, it is the user's responsibility to know the remote syntax for designating a group of files, not the ftp user program's responsibility. MGET and MPUT will work better if the user FTP program is prepared to create local directories implicitly when doing MGET, and to execute MKD, CWD and CDUP commands when doing MPUT to transfer a file hierarchy, since there is no guarantee that a server will create necessary (sub) directories when given a filename containing directory components in a STOR command. When transferring to or from a system with differing filename syntax, the user FTP program might also (attempt to) give help in adjusting or translating filenames, although this can't be done in a fully general way. The original implementation of MGET and MPUT at BBN contained heuristics to translate between unix file name syntax and Tenex/TOPS20 or Multics file name syntax. This involved optional stripping of trailing version numbers, case translation, delimiter translations, (e.g. ">" to "/" for Multics), and removal of the directory component, under control of various flags. The discussion in RFC 959 under the NLST, MKD, PWD, and CDUP commands may be of some help here. The advice in in RFC 1123 under the same topics and also under "user interface" is also relevant. With apologies for possibly belaboring the obvious, hope this helps. Buz
epsilon@wet.UUCP (Eric P. Scott) (10/11/89)
In article <14005@well.UUCP> nagle@well.UUCP (John Nagle) writes: > 1) 3-cornered FTP (source, destination, and control points on > different hosts) never worked. Excuse me, when did it ever not work? I'm not being facetious here. If what you say is true, what's this "proxy" command doing in user-FTP? > > 2) Transferring many small files in succession tends not to work. > If you try to reuse the data connection immediately, it won't > reopen, even though the TCP spec says it should. This is a bug > in the spec. Most current FTP implementations use the PORT > command to get a new data connection for each file, leaving the > old one to time out in TIME_WAIT state. Read the spec again. In the default (STRU F/MODE S) you can't reuse the socket since closure is used to indicate end of file. Maybe I should bring my "why are there so many MINIMAL implementations" gripe over here from Info-Nets... -=EPS=-