hi
i want to do a website on which i want to sell audio and video files.
i want customers to buy a certain amount of downloadable material.. for example.. 100mb or 500mb.. and then use it to download whatever they want .. perhaps after signing in with an account that i should provide after payments.

and maybe when the 100mb or so is over.. they can buy more space if they want to download more files.

so the question. could this be done easily? using php perhaps?

i think its a pretty cool way to sell my stuff.. it makes the customer feel more in control.

thanks for any input about this subject.

As I see it, the easiest way to achieve your goal is to store all your products in a MySQL database. The database will record the name of the file and its size in MB. Then, you will have a database of customers. This will contain their login details and the amount of credit (in MB) that they have earned/purchased. When they download a file, the script will call the database, ask how many MB's the file is, and then subtract the file size from their credit.

The code to achieve this is pretty simple. Once you know how the structure of the program will work, all you need is to buy a PHP book and learn. ;)

Good luck!

awesome! that was a great help :)

i actually started learning php.. but wanted to know whether this could be done with medium knowledge of the language or its a very complicated thing... and it looks pretty simple.

thanks a lot!

You probably would also need a method to determine if the download actually finishes. This may not be so easy.

Originally posted by grofinet
You probably would also need a method to determine if the download actually finishes. This may not be so easy.

Actually that will be easier..


When a person starts the download, make a session with the current time, when the person either closes the page or goes to another page, then check that sessoin subtract with current time and subtract that from the user's field..

oops.... :o there is actually more than that to consider :eek:

what is the user shuts down the computer..... pauses the movie for 3 hours... then there is a problem...

but they can be fixed... somehow..

peace,

ok i see.. thanks for the input. i'm not gonna start working on it now.. probably in a month then u will see me here again!

Actually the issue with unfinished/aborted downloads in such a case is imperative for a fair and honest system.
The best way to do this would be to actually write a ftp server from scratch, that connects to a mysql databases to log downloads, once they are finished. With individual user accounts.
Because the state-less nature of http means its close to impossible to account for partial downloads.

Originally posted by the--dud

The best way to do this would be to actually write a ftp server from scratch, that connects to a mysql databases to log downloads, once they are finished. With individual user accounts.

Gack! No no no. Just write a trivial HTTP server running on a nonstandard port which increments the users byte-count every n (kilo)bytes sent. It would only have to implement very simple GET requests, it really is trivial to do that.

Just have your main site (running PHP + Apache say) take the request to download, make a database record, symlink a unique link (to the file) into a directory for your custom server, then link to the file through the custom HTTP server, the custom server sends the file, recording the byte-count as it goes.

You could get real fancy and only record the maximum byte-count per "file request" so that people can re-download the file within a certain period of time for zero cost.

Stateless HTTP has nothing to do with this, the server still knows how much was sent when the connection goes away.

Say at 100kbytes/s with 200 users, that's 200 000 read/write to memory every single second if you plan on doing an increment per bytecount.

I thought of a much much easier way now.
Use a normal ftp client, one that has logs which keeps track of all connections/disconnections and all downloads. Parse this with a perl script crontabbed say every hour. Crontabbed at the end of every day you can clear the logs and add that to a mysql table which keeps track of total downloaded. Something like this at least... You get the general idea.
If you're good at writing perl scripts, this should be heck of a lot easier than writing either a http or ftp server from scratch :D

This is a tooll that I use on almost a daily basis. It is one of the best resources to do your math on bandwidth comparisons and transfer.

valkaryn.net/bwcalc/

Originally posted by the--dud
S
If you're good at writing perl scripts, this should be heck of a lot easier than writing either a http or ftp server from scratch :D

Here is a trivial HTTP server which fetches the file you request (full path required, this is proof of concept stuff) I wrote from scratch in the last 1/4 of an hour in Perl, and considering I havn't written any perl for years...

Use it like http://localhost:9237/full/path/to/file.jpg


#!/usr/bin/perl
use IO::Socket;
my $sock = new IO::Socket::INET (
LocalHost => 'localhost',
LocalPort => '9237',
Proto => 'tcp',
Listen => 1,
Reuse => 1,
);
die "Could not create socket: $!\n" unless $sock;

my $socket = $sock->accept();
$request = <$socket>;
$request =~ /GET ([^ ]*) /;

$filename = $1;
($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,$atime,$mtime,$ctime,$blksize,$blocks) = stat($filename);

open($file, $filename);
$sentBytes = 0;
while($length = read($file, $x, 1024))
{
$sentBytes += $length;
print $socket $x;
}
close($socket);

print "Wrote " . $sentBytes . "/" . $size . " of " . $filename . ".\n";


Can't get much simpler than that.

That is a neat little server, but it can only handle one download at a time right?

Originally posted by grofinet
That is a neat little server, but it can only handle one download at a time right?

It would be trivial to make it multi-threaded (just fork() after getting the socket, the child process can handle the request, the parent process will go around and start listening agan, probably adds 2 lines to the code).

I was just illustrating that an HTTP server is actually pretty simple when you get down to it, it's left as an exercise to the reader for making it actually useful (you'd have to multi-thread, and make it loop for the connections and check the result of print to make sure the connection doesn't go away, all less than 10 lines of code).