Originally posted by KXRM
not true, streaming and downloading are only differenciated at the client not the server.
I don't want to get in the middle of a religious battle here, but there is a difference on the server. Yes, SHOUTcast uses TCP where other streamers use UDP... This alone cannot be the differentiation. Here is the difference in an example:
We have a playlist with five 100MB NSV files.
When streamed, the server makes the content available to the consumer (client) in pseudo-real time. Only the current chunk is available for the client to request and receive. Chunks before or after the current pseudo-time frame are not available.
When downloaded, via TCP, HTTP, FTP, whatever, the server provides it in non-pseudo-realtime and is client specific. If the client wants to receive the content as fast as possible, it will potentially fill up all available bandwidth to do so. Alternately, the client could opt to dig into the depts of the transfer protocol and request downloaded content as it is played. Another problem with static downloads is that if the consumer does not listen/watch the entire file, the bandwidth is wasted!
This example is, of course, only considering 'pull' type streaming. 'Push' streaming is a whole other ballgame.
Dangers: Streaming is by its nature, a little more difficult to save on the consumer's computer. In these copyright crazy times, this is an important distinction. That is a plus for streaming. Allowing content for download/play, like posting a static M3U playlist targeting static content on an Apache or IIS server gives the consumer ample opportunity to simply download your content.
Just my 2 cent's worth... If I'm wrong, just let me know!