I’ve always had this common-sense assumption, but I want to verify it:
Say you offer streaming media on your website. One person plays it again and again. Each time he/she does so it’s a whole new whack of bandwith right?
Example/ I wrote a Christmas opera with full orchestra (hey, why not, it’s hypothetical, so I can make it as lavish as I want) – the files size of the media is 2 Megs. One listener loves it and plays it 20 times in a row.
That means he put a 40 Meg dent in my monthly bandwidth allotment right?
As you explained it, no. Unless you were streaming the file and did allow caching, the listener would have a local copy after the first listen, and that would be the source if it was looped 40 times.
Depending on the user’s settings, the file might or mught not remain cached, so if the visitor returned every day to listen , you might have to send it each time.
As you explained it, no. Unless you were streaming the file and did not allow client side caching, the listener would have a local copy after the first listen, and that would be the source if it was looped 40 times.
Depending on the user’s settings, the file might or might not remain cached, so if the visitor returned every day to listen , you might have to send it each time.
That’s what I was wondering. With streaming audio (not a download to the hard drive), is it cached for the length of the browser session, or is the file streamed anew with each play?
If the listener closed the restarted his broswer, he’d need to go back to the site to stream the file again, but if he just hit “play… play… play…” is he putting an unnecessary burden on my bandwidth or just listening to a version cached in his buffer?
Caching gets tricky when you are talking about streaming. What technology you choose makes a huge difference.
In general, the cached file should be held as long as any other cached internet file; often at least three days. Assuming the server doesn’t generate a dynamic name for each stream, it is possible that the local copy would be used everytime. This also assumes the user is visiting the site (and playing the file) every day.
As for repeatedly hitting play, unless you are using a technology that doesn’t cache, or you have specified an encoding that is ‘cache-less’ that should play from the local copy.
Thanks that’s sort of what I thought, but then I stopped to actually think about it and thoroughly confused myself. Kinda like when someone asks “what side of your mouth do you chew on?” and you then screw up your face and chew awkwardly because they made you stop and think about it.
It makes no sense at all to restream the file from server to local machine each time you hit play in a single session – it would be a bandwidth sucker from hell! But then, I suddenly got thoroughly befuddled by the notion of permanent downloads vs. cached files.
:smack:
BTW- Welcome to the boards! The “edit” function was disabled, I think, from preventing naughty posters from being, well, naughty. You won’t be able to edit your posts once they’ve been submitted. So the next best thing is the oft fogotten “preview.”
Don’t feel too bad; it becomes pretty complicated in reality. Between servers that generate a unique name for each stream (rendering the cached file worthless), people who delete their entire cache daily, and impatient people who start the download ten times and then abort it because ‘it took too long’, bandwith will be used much faster than you expect.