On Sun, 2004-06-20 at 14:48 -0500, Jeff Vian wrote: > Rui Miguel Seabra wrote: > >Two ports for what? One of them just for carrying data? yuck! > >Can't you do the same with HTTP? Some clients even talk to HTTP in a way > >that it "looks" like an FTP site (hint: lftp). > > > >FTP is in the same class as TELNET... obsolete, redundant, less secure, > >etc... :) > > > So I am to assume you wish everything we do to be based on a web browser > (http).? No. You're getting me wrong. Just that if you want features, FTP is traditionally not your friend. > In my experience too often I see a very slow transfer with web browser > even using the ftp protocol (ftp://ftpserver/filename ). When I switch > to the ftp client it speeds up dramatically. ( 8kb/s using the browser > can easily become 120kb/s or more using the ftp client ) YMMV You might have transparent proxies over your http connection which may not be able to handle the load. > And just how much do you know about the programming and technology that > makes the ftp protocol (using 2 ports) work so well that makes you > complain about it? I'm a sysadmin that has to handle with great security a complex network. The way FTP works is just totally borked. You could have two ports (I wouldn't mind that much) if they were well behaved ports, like HTTP. Client connects to a fixed port, server handles it. Unfourtunately, it is not so. > Too many people want a multifunction "one size fits all" memory and > resource huingry tool (ala Windows); rather than using multiple tools > each of which is small and does its job very well and efficiently(ala *nix). > There are many techniques that benefit from using multiple ports > although few are as specific and bandwidth hungry as ftp. It is > efficient *because* it uses 2 ports. I don't buy that. I think that's more belief than anything else. Rui
Attachment:
signature.asc
Description: This is a digitally signed message part
