[[...]] [FTP] command issued as part of setting up a transfer with the connection direction being in the same direction as the command channel (i.e. the FTP server creates a temporary server socket and it is up to the client to connect to it.) Why do this? Generally--very generally--it's to get through a [firewall]. Why not just use [HTTP]? It's not clear. There's folklore about FTP being faster, in some sense, and there are the usual legacy reasons, too. As of February 2003, [tcllib]'s ftp implements PASV, but [ftpd] does not. ---- [DKF] - When setting up a firewall, it is generally best if you can only let through selected protocols, ideally in both directions (outgoing is usually more permissive than incoming, but the aggressively paranoiac impose similar rules in both directions.) Some protocols (like HTTP) only use a single socket, and it is easy enough to write rules to handle this, but other protocols (FTP is the most common one) use a control channel and potentially multiple data channels. These data channels can potentially be on any socket, which is not good from a firewall PoV since it is difficult to write rules to handle this; some firewall software systesm, like [iptables] in [Linux], include special modules to handle this sort of thing, but the fundamental problem is that the protocol is not restricted to a single port. And to make things worse, for FTP the data channels are opened in the "opposite direction" to the command channel; the server socket for the data channels is on the FTP client! By using PASV, you can make all data connections in the same direction as the command connections and (IIRC) to a known port as well. This makes FTP much easier to fit in with a standard firewall configuration. The folklore about FTP being faster than HTTP is not quite that. It depends on some of the TCP connection parameters which it is easier to set up differently on separate channels (I do not recall the precise details; they're not a detail of sockets currently exposed at the Tcl level in any case) though these things are in truth dynamically configurable anyway, so heavy-duty webservers shouldn't face the hit when shifting large amounts of data. IOW, it's not entirely folklore, but there's not really all that much basis to it at the high-end. Tcl isn't quite there yet though, but not for either protocol... :^) ---- http://compnetworking.about.com/library/glossary/bldef-pasv.htm "The PASV ... verbs" [http://cr.yp.to/ftp/retr.html] [RFC] 478 [http://www.faqs.org/rfcs/rfc478.html]: "Server-Server Interaction" RFC 1579 [http://www.faqs.org/rfcs/rfc1579.html]: "Firewall-friendly FTP" RFC 959 [http://www.faqs.org/rfcs/rfc959.html]: "File Transfer Protocol" "The difference between PASV FTP and Normal FTP" [http://war.jgaa.com/ftp/?cmd=show_page&ID=ftp_pasv] <> Internet