[icecast-dev] new features request

[Mihai RUSU]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 13 Feb 2004, Dave St John wrote:

> > > > Another nice feature to add would be a "bandwidth" limit (so just a
> new
> > > > <limit> type entry).
> If you are running icecast2 on linux you can handle bandwidth limitations
> using QoS
> more specificly iproute2.

You mistunderstood me. No, I cannot handle bandwidth limitations using QoS 
because QoS will see plain packets while I want to limit per source. And 
my limit has to be "functional". If I use QoS to rate-limit my icecast2 
then clients will start to get their stream "slower" then the actual 
stream bitrate which is completly wrong! We are not talking about file 
transfers here but about streams. Streams must be served at their constant 
bitrate (at least :)). What I want (because max_listeners isnt enough when 
you have variable bit rate streams) is to refuse clients when current kbps 
its over some configured limit.

>     That way icecast2 doesnt have to take up extra resources to handle
> bandwidth limitations.

Besides my initial ideea of adding a general lock into net/sock_write*() 
which I see it can be a resource hog not to mention it brakes the 
structure of the current icecast2 codes, I dont think this uses much 
resources.

The byte count computations could be conditioned if the max_kbps value is 
configured > -1 (which means if its activated). So that way the resource  
impact should be minimal...

- -- 
Mihai RUSU                                    Email: dizzy at roedu.net
GPG : http://dizzy.roedu.net/dizzy-gpg.txt    WWW: http://dizzy.roedu.net
                       "Linux is obsolete" -- AST
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFALIQyPZzOzrZY/1QRApUjAKDflRqZ09KdX4YfHpYPuVq1WjMR6gCgms3I
Qmdw8UIxmrJFIdf4LQ1yRjI=
=5OEP
-----END PGP SIGNATURE-----
--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.