Icecast Streaming Media Server

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

kh8 is uploaded although kh9a was the last one before the big thread changes.

kh24.16 looks like it will become kh25. I'm not sure what you mean by limits here as all these scheduling changes are subsecond responses so if there are disconnections then it has nothing to do with those, unless you are saying it's an accumulated starvation issue. If you can provide something specific setup that shows an issue then maybe I can investigate it.

karl.

m3gab0y · Joined: 15 Aug 2009 Posts: 47 Location: London, UK

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

I think that you were being hit by the longer delay on stall case. I've shortened that so It should be quicker now and not cause any excessive retrying on stalled cases. On win32 though you should try to increase the send buffer size to allow for more bandwidth on the link, win32 has traditionally been rubbish in that regard so add <so-sndbuf>16384</so-sndbuf> in the <listen-sock> (try with different numbers as I understand that 8k is the default).

karl.

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

kh25 is up. The possible flv frame skipping should be gone now and quicker rescheduling for clients. A couple of possible crash cases have been fixed and some internal code cleanup, less locking etc.

karl.

m3gab0y · Joined: 15 Aug 2009 Posts: 47 Location: London, UK

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

I don't know the full extent of the memory allocation on win32 but with these send buffers, 1000 icecast connections each with 1 Meg send buffer will be at least 1 Gig of ram, so be wary of the usage. I think I should be able to migrate this option to a per-mount one as these large buffers won't be needed typically, many just have low bandwidth streams.

Most Unix-like boxes these days use TCP window scaling so having fixed window sizes is generally not an issue but for some reason that capability under win32 (that I've tried) seems to be missing and the default is poor for this sort of application. Thankfully these sorts of hacks/workarounds are rare. It wasn't documented because I wasn't sure on whether that would be the end option but it does seem to help win32 users better.

karl.

m3gab0y · Joined: 15 Aug 2009 Posts: 47 Location: London, UK

m3gab0y · Joined: 15 Aug 2009 Posts: 47 Location: London, UK

btw. a GREAT idea will be to add a feature that limits the concurent connections from a single IP to the icecast server and to a specific mount.

The idea is not to allow 100s of "listeners" from one IP and limit this to reasonable value Smile

Karl, please, consider this.

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

You could use auth scripts to manipulate the deny IP file but that will add latency on the new connection for acceptable IPs.

I suppose this sort of thing could use the internal ban function, like the ban-client does now but don't 403 the client afterwards. The issue there is that it's temporary and dropped over xml reload. You probably want that per-mount not server wide as web pages tend to trigger several parallel requests (eg images, css etc)

karl.

m3gab0y · Joined: 15 Aug 2009 Posts: 47 Location: London, UK

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

The limit is such cases would be 1, because the ban would drop a connection immediately, no reading or 403 either. It would allow one onto a mountpoint but not allow subsequent connections, but could be made available when client disconnects.

The redirect option works already, just setup a slave icecast with the
<master> <redirect>true</redirect> <server>....<...> </master>
settings. You can use the relay-user/pass on the master to match or define an authenticated mount for /admin/streams to allow for multiple usernames.

karl.

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

kh26 is now up. There were a couple of last minute fixes so if you saw a kh26 before this then re-download it. The main fixes of kh25 are possible corruption for non-ogg metadata if bandwidth limit reached and hidden streams were being listed for slaves.

karl.

ab-tools · Joined: 07 Sep 2010 Posts: 2

Hello Karl,

first thank you for your great work on IceCast in your KH branch.

We're currently using the default 2.3.2 version of IceCast, but due to some performance issues I have a look on your version at the moment.

It's a very good idea to have multiple worker threads. This way a multi-core CPU can be used much more efficiently.

But I came across one question:
while on-demand playback (normal file serving) is used all clients are allocated evenly across the worker threads, but when playing a relayed stream all clients are allocated to the thread of the source client.

I saw in code ("source.c"=>"send_listener()"=>"do we migrate this listener to the same handler as the source client") already that this is done with intent, but I still don't understand exactly why it's better if all listeners are in the same worker thread as the source client:
however, I guess the multiple worker threads should prevent from performance problems when it takes too long to send the data to all clients in the same thread which would result in buffering in the players. Does this problem not occur for relayed streams or why are all listeners assigned to the same thread as the source client in case of relayed streams? What's the advantage of this solution?

Best regards and thanks in advance for your support
Andreas

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

The listeners get moved to the same worker thread as the client reading the stream, this help reduce lock contention. Also the clients reading the stream can move to less busy workers if doing so would spread load. This migration allows for changes in workload such as streams disappearing or many listeners disconnecting or workers being added or removed.

karl.