Tracking members per file bandwidth usage

This is an interesting topic, one that leads me to want to do tests later tonight to see what might work. If I find something that might be workable, I'll post it here (or if I can't will also). I have about 4 ideas I will try out.

-Greg

Is the file being transferred by a script? What I mean is: if your script takes the filename requested by the browser, loops over the file contents transferring it in chunks to the browser, it can keep a log of how much data has been transferred.

I looked this up on the Drupal API, http://api.drupal.org/api/function/file_transfer/6 It doesn't use a quota system, but probably makes more sense than my explanation, you can see how one could be implemented.

What jeeves mentioned is one of the things i was going to try tonight.

-Greg

I looked at that drupal code, would that be a burden on system resources if there were many users downloading at the same time?
It would be very easy to implement an individual file for each user to use, but wouldn't a lot of users running their script at once take up a lot of juice?

This is the reason why I am scratching my head really. I suppose I could spend more hours trawling the net and eventually find a tutorial that would do the job or close enough that I could alter it to do what I wanted.
But I really don't know if this sort of thing is gonna be resource friendly or not.
Maybe 3rd party software would be better? That would run on the server.

But I would be very interested if you have discovered anything GregK!

Another thing (off topic a bit) I wondered about people downloading large files with their browser dload manager. Having never tested this, I presume they are unreliable for members to start a say 100mb download, stop it, shut down pc and come back to it later?
So I presume I should make it clear it is important to use a 3rd party download manager?

I looked at that drupal code, would that be a burden on system resources if there were many users downloading at the same time?

Doubt it, I've never heard any complaints. If you think about it, all PHP is doing is grabbing a chunk of file and passing it on. Am pretty sure this is the only way you're going to able to monitor how much people are downloading.

You can vary the chunk size to tweak performance. Best advice I can give is load test, tweak and load test again. Remember that conversation we were having about siege? Setup a home server, then load it using Siege (over your local network), try it with both straight file downloads and downloads through PHP. See if the download times are very different and run top on the server to see whether the CPU is overworked.

My guess is that the hard drive and network connection will be a much bigger bottleneck than CPU in this case.

Another thing (off topic a bit) I wondered about people downloading large files with their browser dload manager. Having never tested this, I presume they are unreliable for members to start a say 100mb download, stop it, shut down pc and come back to it later?

Not sure I understand the question here. You're worried whether people with download managers will be able to resume downloads? Best bet is to test it out and see what happens, particularly if you run the download through PHP.

A simple way to prevent download managers from resuming or using multiple connections is to not send the file size. Download managers need to know the total filesize in order to determine where to distribute the chunks.

Quote: If you think about it, all PHP is doing is grabbing a chunk of file and passing it on.

You also have to consider the logging mechanism which would either be a file write or database transaction per section.

You also have to consider the logging mechanism which would either be a file write or database transaction per section.

Per-download, not per-chunk. That's not all that often, per-chunk could just be stored in a variable. Or am I missing something here?

Quote: Per-download, not per-chunk. That's not all that often, per-chunk could just be stored in a variable. Or am I missing something here?

If the download is canceled, the script is killed, and nothing is logged when you use variables.

Quote: If the download is canceled, the script is killed, and nothing is logged when you use variables.

I should probably take that comment back. There are ways to execute code when the script is done.

Method 1: An object's __desstuct() method.
Method 2: register_shutdown_function()

I guess the big question is whether it will run if the script in canceled. I know there is a setting to tell the script to keep going even if the user hits the Stop button in their browser.