Ftp-WG: On new commands

> In our application (Fastream FTP++ P2P) we have multiple connection
> downloads (similar to Download Accelerator/GoZilla) with the help of REST
> command. I simply divide the file into segments and then merge the
> downloaded parts on the local-side.

Yeah.  Those are some of the applications causing the DoS complaints.  Sure,
they're not malicious DoS, but the network operators at your vict..er
download site are certainly noticing that you're choking their routers.

> I want to implement the same feature for remote part also. I mean multiple
> connection uploads. However, on the remote size, there is nothing like a
> merge command. There is the command APPE but it only appends a local file
to
> a remote file. Wouldn't it be nice if we add such a command to FTP?

There's some interesting research going on with that.  Most of them start
with a hacked up FTP daemon.  If you want I can root around my bookmarks,
but you'll probably find some of it faster if you Google for 'file transfer'
and 'satelite'.  The US Gov't has a spec which is basically 959 with
parallel transfers like you're wanting.

> Also, in our application, we have a command called SITE MD5 similar to
ones
> found in UNIX systems. But in our case, the MD5's are cached with a
> background thread. This enables KaZaA/iMesh like P2P functionality with
> multiple source-IP/port downloads. However lack of support from other
> applications limit the use to within FTP++-to-FTP++ only. As you may have
> understood, I propose this command also.

I put MD5 (and Unix checksums) into WU-FTPD some time ago, simply because I
thought it would be nice to be able to remotely verify signatures.  It met
with total and complete silence; noone asking how to enable it, no problems
with it, nothing.  I assume the demand is a very good approximation of zero.
I still like the idea, but I expect the users are satisfied enough with the
present reliability of downloads that they're not interested in the added
step.

In specific answer to your question, though, there's no reason the add a new
command to support MD5.  Adopt MLSx and simply add an MD5 fact to your
servers.  If you want, write a memo describing the fact.  Sorta like the way
new Telnet Options get done.