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 look into this aspect from the end-users point of view. And we should not
forget the fact that router capacity and bandwidth is growing exponentially.
So today's DoS, probably will be a small percentage increase in tomorrow's
traffic. And standards are designed for future, am I wrong?

>
> > 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.

Actually a NASA official demanded such feature from me, but since there were
a lack of standards, I replied that only for download it is possible.

>
> > 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.
>
>

Sorry but I am new to MLSx. Which RFC should I be looking for? (I am
currently using ICS under BCB for FTP engine)

Thanks.