One fairly good reason from my perspective: drftpd and glftpd supports it, which really is the closest comparisons to iofpd. In fact, not being able to move data that only recently got uploaded to the server puts io at a huge disadvantage when it comes to spreading xx bytes in the fastest possible way. When it comes to incompletes and interrupts, they're rarely a problem as they don't really occur that often. In any case, the zipscript would take care of it.
I don't see why you have to buffer up all the data from the upload tho. It should be fine accessing the file from the hdd directly. Example VideoLAN access to a file being written to.
In comparison with glftpd and drftpd, io speeds come out poorly, especially on busy sites where the first bytes that hits the server is likely to get 10+ download requests the same second as file upload starts.
Included, but not limited to:
Rar files (15-500mb)
Small zip files (5mb)
Audio files, both small and large (100mb+)
Video files (15-500mb)
A live example is 200mb getting uploaded in 2s divided in 20 equally large files by multiple threads. This also means that after 2s the files are rendered old, and invaluable for further uploads. In this scenario ioftpd is utterly useless in comparison with drftpd and glftpd... and to be frank, this really is the ioftpd niche 'marked'
I'm not saying ioftpd has to copy/mimic the behaviour of all other daemons out there, but in my opinion it doesn't hurt to stay competetive in enviroments where speed is one of the most important factors.
|