I have three Icecast-2.0.0 servers up with possibly more coming online. I am trying to figure out how to do more intelligent load balancing between the three. Problem: There are bandwidth restrictions at a couple of the locations. Current Solution: Round-robin DNS (with very low TTL) and a restriction on the number of listeners on the servers where bandwidth is an issue. I am finding this solution to be sub-par. Client-side caching seems to be one of the culprits. When one of the bandwidth-constrained server IPs is selected, and it's full, it seems that the client never switches to another server on reconnect. Using Winamp as the client right now on Windows XP (for testing). Only flushing all the DNS caches up the chain (client, my Linux box) seems to fix this. Or waiting a really long time. Before I attempt to hack a solution together, I recall someone working on this issue, so I'd like to find out the status of that work. I can't be the only one with this need. Thanks, Dave http://www.liveatc.net <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Ahoj Jack, are you still in Hungary? Do you plan to visit Czech Republic again? Stepan Broz, Radio Akropolis www.radioakropolis.cz <p>--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Wed, 5 May 2004, Jack Moffitt wrote:> If the client limits are hit on the server, it sends back an HTTP > redirect with the location of a random mirror (not itself). This should > be transparent to clients and acheive the affect you want. You could > also combine with with round robin DNS to spread people over the servers > initially. > > Seems fairly elegant. Probably you want this configurable on a mount > level not a global server level, but it shouldn't be too hard to > implemenet. Just a config file addition plus some extra logic in the > main connect loop, similar to what happens on a 404.Most people like to use 301 (moved permanently) for redirection, and this is the one most likely to be supported by client. If one desires to adhere to the standard pedantically, one should use code 300 (multiple choices), 302 (found), or 307 (temporarily redirect) for load balancing. This logic doesn't need to be part of Icecast server. Any cgi script with access to stats.xml can act like a dispatching agent, and it can make pretty good decision to redirect the client. But what if the client doesn't support redirection? On Wed, 5 May 2004, Scott Manley wrote:> Th redirect should of course include some info in the redirect URL regarding > how many times it's been redirected - you don't want to get into a situation > where users are bounced around indefinately.This is generally the task of an user agent. liulk --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> I am finding this solution to be sub-par. Client-side caching seems to be > one of the culprits. When one of the bandwidth-constrained server IPs is > selected, and it's full, it seems that the client never switches to > another server on reconnect. Using Winamp as the client right now on > Windows XP (for testing). Only flushing all the DNS caches up the chain > (client, my Linux box) seems to fix this. Or waiting a really long time. > > Before I attempt to hack a solution together, I recall someone working on > this issue, so I'd like to find out the status of that work. I can't be > the only one with this need.Round robin DNS isn't really appropriate as you noticed. Something will have to be done among the icecast servers themselves, and what is coming to my mind really quickly is some kind of new config option to specify a list of mirror servers. If the client limits are hit on the server, it sends back an HTTP redirect with the location of a random mirror (not itself). This should be transparent to clients and acheive the affect you want. You could also combine with with round robin DNS to spread people over the servers initially. Seems fairly elegant. Probably you want this configurable on a mount level not a global server level, but it shouldn't be too hard to implemenet. Just a config file addition plus some extra logic in the main connect loop, similar to what happens on a 404. jack. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Th redirect should of course include some info in the redirect URL regarding how many times it's been redirected - you don't want to get into a situation where users are bounced around indefinately. Personally, I'd go a step further and collect performance data so that load balancing can make better decisions for redirects. No sense in redirecting a local connection to a remote site. <p><p>> Round robin DNS isn't really appropriate as you noticed. Something will> have to be done among the icecast servers themselves, and what is coming > to my mind really quickly is some kind of new config option to specify a > list of mirror servers. > > If the client limits are hit on the server, it sends back an HTTP > redirect with the location of a random mirror (not itself). This should > be transparent to clients and acheive the affect you want. You could > also combine with with round robin DNS to spread people over the servers > initially. > > Seems fairly elegant. Probably you want this configurable on a mount > level not a global server level, but it shouldn't be too hard to > implemenet. Just a config file addition plus some extra logic in the > main connect loop, similar to what happens on a 404. > > jack. > --- >8 ---- > List archives: http://www.xiph.org/archives/ > icecast project homepage: http://www.icecast.org/ > To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' > containing only the word 'unsubscribe' in the body. No subject is needed. > Unsubscribe messages sent to the list will be ignored/filtered. >--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.