[cd34]

I looked at the script at the beginning of the thread -- it looks to me like you are using a cookie to prevent hotlinking of .wmv files. Preventing direct access to the file through .htaccess, requiring the file to be sent through php. One potential issue here is that if it takes more than 30 seconds to download the file, its possible that you'll exceed the max_execution_time default in php.ini and the connection would be closed prematurely. Also, since it is a php file, if your host has mod_gzip or mod_deflate configured based on file extension rather than mimetype, you'll corrupt data.

I'd have to dig through the php sources, but, I believe fpassthru uses the kernel sendfile, which, uses a zerocopy buffer on linux (not on Freebsd) -- that in itself would be almost as efficient as using pure apache. I don't know if readfile does, but, its possible.

The 80% duty cycle on ethernet is a bit high, but, considering a full duplex connection, and no transmission delays, 4000 users would quite easily be 500 seconds to download, but, lets consider that 4000 users is probably atypical and that you wouldn't reach that because it would probably exceed Apache's maxclients prior to that. I think the max I have ever seen maxclients set to has been 2048 on a public webserver and is typically 512 or less.

However, your method does bring one thing to mind. You mention .htaccess to protect your videos with a deny from all. This gives me two ideas, one of which replicates what I think you're trying to do, the other being a bit off the beaten path.

With mod_rewrite, you do have %{HTTP_COOKIE}, so, you really could write a rule that checks for the existence of a cookie & value to make sure they can download, and that would avoid php altogether. You'd set the cookie on your page using javascript or a .php file parsed that sets the cookie. Then, apache's mod_rewrite would check for the cookie and decide to serve. This of course eliminates those people using privacy software that don't accept cookies.

There is another way you could do it using php which is a bit different.

If you serve the gallery, you have the IP address of the surfer (or at least the publically available address that they would be sucking the file down from anyhow). You could put the page in a directory and the videos in a subdirectory. When the page is served, you would take the current surfer's IP and append it to the end of the .htaccess in the videos subdirectory along with some timestamp so you can clean it later. If you aren't using php to serve the page that the surfer sees, and I usually dislike using dynamic pages, you could wrap an img src so that it would write the file.

so you end up creating a .htaccess in your videos directory like:

order deny,allow
deny from all
allow from 1.2.3.4 ; timestamp
allow from 3.2.4.5 ; timestamp
allow from 4.5.6.2 ; timestamp

At this point, again, you have apache processing only your initial pageload, and then apache does the work of sending the files. Then once every few hours you clean out the .htaccess using the timestamps to expire 'old' entries.

You could write a mod_rewrite that uses an external ruleset to eliminate the read-write. You really need to figure out the duty cycle for the script and how many downloads/day you're really talking about to figure out which approach will work best.

If you get a Hun listing, the more processing you must do to determine how to prevent the hotlinking, the more trouble you'll end up with.