[Icecast] fallback-to-file caveat

[Ian A. Underwood]

Joern Nettingsmeier wrote:
> Karl Heyes wrote:
> 
>> On Tue, 2005-04-12 at 14:44, gARetH baBB wrote:
>>
>>> How is fallback to file actually meant to work ?
>>
>>
>>
>> just state a filename within webroot. The server creates a source thread
>> so that it interacts with the existing fallback mechanism.  No timing
>> goes on with the data stream, and usual rules for fallbacks apply, ie
>> same format and same parameters.
>>
> 
> a word of warning: the fallback files will be served untimed, i.e. as 
> fast as the receiving end can process them.
> if it's a relay, then this will eat up your entire bandwidth. i've seen 
> loads of 30+ mbit/s with just two relays.
> 
> if all your clients are actual players, you will be fine, but even one 
> wget will really warm your uplink :)

This might seem like a stupid question, but how hard would it be to 
implement timing for a backup file, even if it had to be configured?  It 
would be preferable to have icecast serve the backup file than using 
ezstream to achieve it...if for just the simplicity of running one program.

Unfortunately, this kind of fallback could potentially be used to launch 
a DoS attack on anyone who can manage to disrupt the source stream if 
timing isn't in place.

-I