Re: avoiding reinventing the wheel on file transfer.

["David B. Coningham" <dbc-pub%vandyke.com@localhost>]

> > So, I have this concern that we're going to spend a whole lot of time
> > on the file transfer draft, and in the process reinvent a couple
> > wheels which have already been built.
> > 
> > Here's a half-formed suggestion for the working group...
> > 
> > file transfer involves a bunch of really ugly issues (newline
> > conventions, binary/ascii/... modes, i18n of filenames, etc., etc.).
> > Many of these problems have already been tackled by FTP.
> > 
> > A radically different and simpler approach (from a standards-writing
> > viewpoint, at least) may well be to define a way to tunnel "normal"
> > ftp through a collection of ssh channels, so we can avoid refighting
> > all the battles which were fought over FTP... i.e., you start off with
> > one channel for the FTP control channel, and then open up new ssh
> > channels where "normal" FTP would open a new TCP connection....
> 
> As a point of reference, I believe SecureFX from vandyke does
> exactly this by using creative PORT commands and dynamic remote 
> port forwarding against an existing FTP daemon on the sshd host.

Thank you for pointing this out.  SecureFX does indeed perform FTP
transfers over a single SSH connection (establishing one channel for
the control connection and one channel each time a data connection is
required).

One minor point of correction to the above statement is that SecureFX
uses PASV to establish the data connection rather than PORT.  PORT
currently cannot be used very effectively because of a limitation with
the remote port forwarding mechanism: it does not provide a way to
determine the actual port number to which the listening socket is bound
(if 0 is requested).

For this reason it would be desirable to see the remote port forwarding
response changed to include the port number.

---
David Coningham
dbc-pub%vandyke.com@localhost