From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dhirendra Pal Singh Date: Fri, 14 Mar 2003 18:45:46 +0000 Subject: Re: [offtopic FTP rant] [LARTC] HTB, bandwidth limiting for ftp MIME-Version: 1 Content-Type: multipart/mixed; boundary="------------030505090504020501000809" Message-Id: List-Id: References: In-Reply-To: To: lartc@vger.kernel.org --------------030505090504020501000809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hey Martin... Thanks for this detailed info... I liked reading it till the end... Actually one of the developer of FTP Protocol lives in Bay area(California) itself and I happen to know him(not personally). Its good to know the drawbacks of this protocol..sometime if we run into discussion may be I can talk... ;-) And anyhow my iq has increased, again after reading your post... Thanks Dp Martin A. Brown wrote: > : > Yes. I think FTP should be summarily executed. It has been plaguing us > : > since the beginnings of firewalls and NAT. Sadly, another spiritually > : > impoverished but well-known operating system has two basic options for > : > file transfer: HTTP ("the Internet", of course!), and FTP (for experts!). > : > Of course, on the other side of the divide, people (ab)use ssh for all > : > sorts of nefarious purposes....... (anybody remember a recent article in > : > some print periodical detailing NFS over ssh?) > : > : > : Not trying to be argumentative or start a useless tangential thread > >I engaged this tangential thread. Hook, line and sinker. > > : here, but none other than Frank da Cruz provides his reason why he > : thinks ftp is better than ssh/scp at the following link: > : > : http://www.columbia.edu/kermit/ftpclient.html > >Hm. Never read this before. I've never heard of Frank da Cruz before >either. I have heard of kermit, and remember using it a good deal in the >bad ol' days. [ expression courtesy of a friend ] > > : Note he is coming at this as the developer of the most capable comm > : program ever. > >And I approach the problem from the perspective of an annoyed, grouchy, >and underfed dragon...er um...network administrator who has to deal with >broken FTP server and client implementations and installations on a >regular basis. > >I have to admit that the original design of FTP is not that bad. But >PASV? That's a jury-rigged solution to a problem which cropped up long >after the original design! And we have been stuck with essentially two >very different network layer characteristics for a "simple" protocol over >an eternity of Internet time because people can't live without their FTP >servers. I don't even want to talk about FXP. > >Now--just think about all of those "Internet-enabled" applications with >embedded FTP clients and servers, not all of which conform to or conform >to the same parts of the various FTP RFCs. A quick look at this link [1] >will show you the base materials on the FTP RFCs. > >I ponder on the number of humans who have spent innumerable hours trying >to design proxies, packet filter code, and NAT code for a protocol >designed before NAT and firewalls. Surely there is a better way for us to >spend our time. Jettison FTP. But, sadly, that won't be happening >anytime soon. > >My counterarguments to Frank da Cruz in the matter of FTP versus another >protocol are from the perspective of a network administrator, not a >communications software programmer. I'll use HTTP as an example foil for >FTP in the argument: > > - SSL can be used with HTTP (and many other application layer protocols) > - HTTP is scriptable (wget, perl libwww aka LWP::simple and friends, > python urllib, among others, if you don't like using nc and lots of > shell) > - I wouldn't consider that FTP's ASCII vs binary mode has an advantage > over MIME-types which are part of HTTP > - HTTP/1.1 (commonly, although not universally deployed) supports byte > ranges, for file download resumption > >If I were to suggest a replacement protocol for (scriptable) FTP, however, >I would suggest rsync (InterMezzo seems young yet--and it, amusingly, >travels over HTTP): > > - rsync is a superior solution to HTTP or FTP for bulk push or pull file > transfer, allowing resumption, file permissions, dates, and (sym)links > - rsync supports the notion of users, as do FTP (and HTTP) > - rsync can tunnel over ssh (I classify this technique as an abuse of > ssh, although I liberally employ this same strategy.) > >Frank da Cruz's arguments have unbeatable validity though in that FTP is a >much more widely supported protocol in clients and servers on uncommon, >embedded, or non-commodity operating systems and devices--exactly where >they are a problem for network administrators. Conversely, my convenience >might very well be his frustration. > >Many technologies are abused, overused, employed in a manner radically >different from their design or extended beyond usefulness. FTP's lifetime >has been tremendously extended. HTTP and SSH are the problems of our >future (if not today).... > >With all of the above said, I would not begrudge a user the use of FTP, >as it is a widely supported protocol. > >I would simply like to see FTP wither and die on the vine of progress. > >-Martin > > [1] http://www.wu-ftpd.org/rfc/ > >P.S., I think I just exceeded my rant quota for calendar year 2003. > Apologies in advance to those who suffered through it. > > > --------------030505090504020501000809-- _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/