You are definitely right, but there is one thing that you didn't knew and
I'm sure that you didn't take into account - usually the files on the server
will be DVD rip's that are typically 700MB~ in size, every second movie that
people will download will contain some interrupted pieces, although that
these small pieces won't affect the file that much in order to keep it out
from playing. Most of the video players know how to player these corrupted
files and will handle them good.
And for torrent - this is a good solution but this is not what I'm after,
I'm going to set up an HTTP file hoster, not a torrent tracker ;)
Any other ideas regarding serving the files and hosting them will be very
Thank you guys for all the ongoing help in this list ;)
On Thu, Apr 16, 2009 at 10:29 PM, Michael A. Peters <mpet...@mac.com> wrote:
> kyle.smith wrote:
>> How is 700MB too big for HTTP? Ever download a linux distro? Ever
>> benchmark FTP vs HTTP, the overhead is minimal...
> I download linux distro's all the time - er, whenever a new CentOS is
> It's not overhead that is the issue.
> It's being able to continue an interrupted download that is an issue.
> Some http clients may be able to, though I suspect that would require a non
> standard extension to http that both client and server understand.
> Also - many people use a temp filesystem (aka ram disk) for www downloads
> (I doubt a majority but those of us who are smart) - where the file is
> initially put until all the pieces have come down before it is finally saved
> to the destination. Using tempfs for that requires less disk IO because your
> www downloads are typically small, so no need to write to disk until you
> have it all when it can do the write at once.
> 700MB can easily fill that temp filesystem, depending upon the size of your
> tempfs (and what else it is being used for).
> Serving via ftp - virtually every ftp client out there knows how to resume
> an interrupted download, so it is much better suited for large downloads
> than http. And serving via ftp/torrent - the user is far less likely to be
> using a tempfs as a staging area that can result in a bad download.