The "root" icecast server doesn't need to live on the same box. You could
still deploy it to a public location, and always push to that icecast
server. The cluster members can pull from that root server, then you don't
have to keep track of IP's.
DJ box ---> root icecast server <--- cluster members.
On Tue, Dec 1, 2009 at 1:52 PM, Andrew <and...@instantofficecenter.com>wrote:
> Unfortunately that won't work in my case, as the encoding computer running
> liquidsoap is at a different location from the servers that listeners listen
> to.
>
> Running a local icecast isn't feasible as a public IP is not an option at
> the encoder site, and as I understand it, Icecast can't do push-based
> relaying to push the stream to the outside cluster.
>
>
>
> On 2009-12-01, at 11:46 AM, Brandon Casci wrote:
>
> I may not understand your scenario totally, but would it make sense to have
> a local icecast server that Liquidsoap sources? Then each of the other
> icecast servers in the cluster, which I'm assuming are for listening, all
> pull from that one mount point on the Liquidsoap box.
>
> On Tue, Dec 1, 2009 at 1:04 PM, Andrew <and...@instantofficecenter.com>wrote:
>
>> 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
>>
>
>
>
> --
> =========================================
> I'm having a bout of spondylosis, so I can't hammer away at the keyboard
> too long. Please don't mistake short e-mails for rude e-mails..
> =========================================
>
>
>
--
=========================================
I'm having a bout of spondylosis, so I can't hammer away at the keyboard too
long. Please don't mistake short e-mails for rude e-mails..
=========================================
------------------------------------------------------------------------------
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
