Icecast - Oct 2009 - icecast-2.3.2-kh17 versus icecast-2.3.2

Hi,

I've been using icecast-2.3.1 for some time now and it is really  
working well for me, solid as a rock (no crashes) and running 100's of  
streams and 1000's of listeners, but in order to support  
authentication and have easier configuration I want to start using the  
url authentication (esp. the stream_auth) and mount-name wildcards  
that are supported by icecast-2.3.2-kh17.

I am unsure about the stability of icecast-2.3.2-kh17 when using url  
authentication for both stream and listener authentication. What are  
the major differences between icecast-2.3.2 and the kh17 branch and  
can you say anything about the stability of icecast-2.3.2-kh17 in  
production use?

Any feedback is very much appreciated.

Regards,

Klaas Jan Wierenga

On 18/10/09 14:52, Klaas Jan Wierenga wrote:
> Hi,
>
> I've been using icecast-2.3.1 for some time now and it is really
> working well for me, solid as a rock (no crashes) and running 100's of
> streams and 1000's of listeners, but in order to support
> authentication and have easier configuration I want to start using the
> url authentication (esp. the stream_auth) and mount-name wildcards
> that are supported by icecast-2.3.2-kh17.
>
> I am unsure about the stability of icecast-2.3.2-kh17 when using url
> authentication for both stream and listener authentication. What are
> the major differences between icecast-2.3.2 and the kh17 branch and
> can you say anything about the stability of icecast-2.3.2-kh17 in
> production use?
kh17 hasn't been out for that long but I've had no problems reported 
about it.  URL auth should be stable, there's been a fair amount of 
testing recently using URL auth because of the per-listener intro 
content feature recently added.

The main difference between them is the threading structure. With 
2.3.2/trunk you have one thread per stream setup, which is fine for low 
numbers of streams but some are running many streams which means the 
loading on the server can be a problem. In the kh branch, the threads 
are limited by the <workers> setting, so you get a lot less switching 
between threads if you have say 100+ streams.

There are other functional features that seem to be working well, like 
the wildcard mounts, average bitrate stats, bandwidth limiting per 
mount. Sending content from a fallback file is now throttled which was 
an issue under 2.3.2 for some people.  Relays can have multiple server 
references (for when one fails).  Some extra options are available for 
auth such as sending the listener to an alternative mountpoint on failure.

master/slave setups are handled differently now. A slave relay uses an 
/admin link to retrieve the content. This means two things, that the 
slave connection can bypass the usual limits (max-listeners etc) and 
that an auth can be applied for the connection meaning that each slave 
can have their own user/pass.

The stream auth support has already been merged into trunk although not 
for shoutcast style source clients. kh17 does allow a shoutcast source 
to use url auth.


karl.