I would argue that randomized DNS with relaying is a very good solution for load balancing live audio streams. It has an advantage over a single master server in that there is no single point of failure.
It would seem to be logical to me for liquidsoap to make sure that it is sending metadata to the origin server that it connected to so that relays can retrieve the metadata as well. Perhaps simply having a switch to turn IP caching for metadata lookups on and off would be a good way to stab this. If the general user community finds it to be unnecessary it can default to being off. Andrew On 2009-12-05, at 7:04 AM, Oliver Oli wrote: > It seems a quick workaround to solve your problems, but I don't think > it is the correct solution for the problem. You just get what you've > asked for: you have setup load balancing over several IPs and now the > client connects to different servers. If the servers cannot handle > this, it is not the fault of the client application. > > 2009/12/1 Andrew <and...@instantofficecenter.com>: >> Hi there, >> >> For load balancing and redundancy, I have several icecast servers in place. >> I have setup a DNS entry called icecast.domain.com which randomly points to >> different servers in the cluster and use relaying on-demand to make sure >> that each server has the ability to serve the stream. >> >> I have liquidsoap connecting to icecast.domain.com which gets a random IP >> address each time. However when I issue a metadata update it seems to do a >> new DNS resolution and as such it often connects to a relay server rather >> than the one it initially connected to, which has the original mountpoint. >> >> Would it be possible for liquidsoap to remember the IP address that it >> connected to and then use that for sending metadata updates rather than >> doing a new resolution? >> >> I would like liquidsoap to continue doing fresh lookups when it has to >> reconnect to a stream, but to cache the IP value of the hostname for >> metadata updates to ensure that updates are being sent to the server with >> the original mountpoint rather than a relay server. >> >> I hope that makes sense. >> >> Andrew > > ------------------------------------------------------------------------------ > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > _______________________________________________ > Savonet-users mailing list > Savonet-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/savonet-users ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Savonet-users mailing list Savonet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/savonet-users
