From: "Martin A. Brown" <mabrown-lartc@securepipe.com>
To: lartc@vger.kernel.org
Subject: [offtopic FTP rant] [LARTC] HTB, bandwidth limiting for ftp
Date: Fri, 14 Mar 2003 05:16:51 +0000 [thread overview]
Message-ID: <marc-lartc-104761906615340@msgid-missing> (raw)
: > 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.
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next reply other threads:[~2003-03-14 5:16 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-14 5:16 Martin A. Brown [this message]
2003-03-14 18:45 ` [offtopic FTP rant] [LARTC] HTB, bandwidth limiting for ftp Dhirendra Pal Singh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-104761906615340@msgid-missing \
--to=mabrown-lartc@securepipe.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.