[Icecast] icecast-2.3.2-kh17 versus icecast-2.3.2
karl at xiph.org
Sun Oct 18 18:00:03 PDT 2009
On 18/10/09 14:52, Klaas Jan Wierenga wrote:
> 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.
More information about the Icecast