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 :)
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
On Fri, 2005-04-15 at 21:36, Ian A. Underwood wrote: ...> > > > 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.The implementation is just for testing the functionality, it's a trivial implementation which works like a source thread to drive the data through. While it would be possible for ogg to be timed, other formats would not be, so there would be a consistency issue there.> 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.if someone manages to disrupt a source stream then DoS has already been achieved. Ideally I would want fserve to take over but the fallback/override mechanism isn't in place currently, and it probably wouldn't help the link saturation. I'm sure more tuning can be done but I haven't decided on the way forward with it yet. What I'll do for now is just disable the burst trigger on fallback file only, so it will pause on th loop. we probably need some flexible settings really but it should help. karl.