Re: [offtopic FTP rant] [LARTC] HTB, bandwidth limiting for ftp

[Dhirendra Pal Singh <list@actiswitch.com>]

[-- Attachment #1: Type: text/plain, Size: 4999 bytes --]

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?)
> : <snip>
> :
> : 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.
>
>  
>