I was talking to the maintainer of http://a.scarywater.net, mxs, and he suggested an alternative download method I could use. Instead of running the download through a download script (which has significant cons and only a few pros), he suggested a symlink method.
A symlink method would allow you to download the server directly through the webserver rather than through the download script. The good thing about this is that this will allow you to use any download agent to start the download (multiple connections included)! The bad thing would be that I would probably implement some sort of queue that you'd have to wait through, sort of like FilePlanet, and that you'd have to start the download within a minute or so of the opening otherwise your slot will be given to someone else.
Personally, I don't like waiting in queues and stuff but I suppose that's what you're doing now since you have to wait till the turn of the hour for more transfer to free up.
--added
Okay, how about this? You wait in line for a little bit (15 minutes, who knows) but after that, you can start your download. The custom http server that handles this would be able to support resumes and stuff and you would be able to start/resume that download without waiting in line again. Multiple connections MAY or MAY NOT be supported depending on the results of load testing (multiple connections use up more server resources). You don't have to start the download immediately but the file would only be available for up to 24-48 hours before the symlink is removed. If the symlink is removed and you want to resume a partially downloaded file, then you'll have to wait in line.
Oh, no rate limits either. Currently, all the downloads are rate limited to about 100kb/s for the ftp and about 70 for the http.
The download locking code for this system would be a little different. It would allow you to download the same file you tried to download earlier without any problems BUT if you changed download locks to another episode while downloading, your current download would terminate (i think).
This proposed system relies on the use of high-bandwidth server and won't be supported by the current distribution server right now.
I'd like to hear your opinion, as you're the one who's going to use this.
A symlink method would allow you to download the server directly through the webserver rather than through the download script. The good thing about this is that this will allow you to use any download agent to start the download (multiple connections included)! The bad thing would be that I would probably implement some sort of queue that you'd have to wait through, sort of like FilePlanet, and that you'd have to start the download within a minute or so of the opening otherwise your slot will be given to someone else.
Personally, I don't like waiting in queues and stuff but I suppose that's what you're doing now since you have to wait till the turn of the hour for more transfer to free up.
--added
Okay, how about this? You wait in line for a little bit (15 minutes, who knows) but after that, you can start your download. The custom http server that handles this would be able to support resumes and stuff and you would be able to start/resume that download without waiting in line again. Multiple connections MAY or MAY NOT be supported depending on the results of load testing (multiple connections use up more server resources). You don't have to start the download immediately but the file would only be available for up to 24-48 hours before the symlink is removed. If the symlink is removed and you want to resume a partially downloaded file, then you'll have to wait in line.
Oh, no rate limits either. Currently, all the downloads are rate limited to about 100kb/s for the ftp and about 70 for the http.
The download locking code for this system would be a little different. It would allow you to download the same file you tried to download earlier without any problems BUT if you changed download locks to another episode while downloading, your current download would terminate (i think).
This proposed system relies on the use of high-bandwidth server and won't be supported by the current distribution server right now.
I'd like to hear your opinion, as you're the one who's going to use this.