Icecast - Mar 2015 - Master/Relay, SSL and some Q's on setup...

On 03/12/2015 09:24 PM, Dean Sauer wrote:
> Looking at the documentation for 2.4.1 in regards to master/relay which 
> seems to outline what I want to do...
>
> Master = load balance/aribtrator for the relays where the sources connect.
>
>
> The questions:
>
> 1) Bandwidth - How does the master pass off things to the relays for the 
> clients??? 
It's a pure stream replication process.
Either all (master/slave) or explicit (per mount) streams are being
requested by slaves and made available as regular mountpoints.

If you want mountpoints to have specific features/options, then the
configuration on the slaves needs to have those. Mountpoint settings and
configuration are not propagated from the master.

Listener connections need to be directed to the slaves independently.
The master doesn't have provisions for that.
There are many ways to achieve this:
- round robin DNS (a FQDN resolves to several IP addresses)
- HTTP 302 based "bouncing" load balancing (can be dumb or incorporate
logic to account for bandwidth or listener numbers)
- playlist (several entries, very simple, but no good control over load
distribution)

If the servers have roughly the same bandwidth available, then going
with RR DNS is the easiest as it will achieve a statistically equal
distribution.
> 2) <on-disconnect> and <fallback> Mounts 
>
> Scripts for on-disconnect should run on the RELAY that the source 
> connects to, correct? Since it really never connects to the master for it 
> to notice it has dropped..
You have it backwards, the source connects to the Master. Slaves pull
the stream from the Master.

on-disconnect on the master will tell you when the source connection fails.
on-disconnect on the slaves will tell you if the particular connection
between master and slave is interrupted.

Fallbacks can be on any of the servers. You should keep in mind how
things will behave though:
If you have fallbacks on the master, then the relay slave will never see
a source disconnect, but will receive the data from your fallback, as
it's just a regular listener towards the master.
Even if you use master side fallbacks, it might make sense to have local
fallbacks on the slaves to account for situations where the connection
to the master fails.

> 3) SSL v. Non SSL
>
> While darkice doesn't natively support SSL, yet, and adding stunnel to 
> layer this may be an option till then but..
>
> So we set up IceCast to listen on 8443 for SSL, 8000 for non SSL..
>
> Now since 99.9999% of the clients are NON SSL.. IF the feed is sent in SSL 
> does IceCast translate it to NON SSL on 8000 ?? Or there has to be a SSL 
> feed and an non SSL feed???
The TLS connection is terminated at the server. This means that the
encryption is purely for the transport.
It is irrelevant for a listener if the source connects over TLS or plain
and vice versa.


Cheers

Thomas