-----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@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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> > > Another nice feature to add would be a "bandwidth" limit (so just anew> > > <limit> type entry).If you are running icecast2 on linux you can handle bandwidth limitations using QoS more specificly iproute2. That way icecast2 doesnt have to take up extra resources to handle bandwidth limitations. resources here cbq bash script http://aleron.dl.sourceforge.net/sourceforge/cbqinit/cbq.init-v0.7.3 the low down skinny on traffic shaping http://www.knowplace.org/shaper/resources.html Now if your on windows then Microsoft says it handles bandwidth better than linux and is cheaper than linux so i guess QoS works automagikly ;) then again i think linux just works the way its supposed 2 and windows doesnt :O) Hope that helps :) <p><p><p>Dave St John Mediacast1 Administrator ----- Original Message ----- From: "Mihai RUSU" <dizzy@roedu.net> To: <icecast-dev@xiph.org> Sent: Friday, February 13, 2004 12:17 AM Subject: Re: [icecast-dev] new features request <p>> -----BEGIN PGP SIGNED MESSAGE-----> Hash: SHA1 > > On Fri, 13 Feb 2004, Geoff Shang wrote: > > > Mihai RUSU wrote: > > > > > Another nice feature to add would be a "bandwidth" limit (so just anew> > > <limit> type entry). > > > > Problem with this is, what do you do once the limit has been reached?Who> > do you kick? Or do you just not allow anymore listeners? > > I just dont allow anymore listeners while current kbps (in the context > where the kbps limit applies) is >= than the maximum kbps of this context. > > That solves at least my needs :) > > > Geoff. > > - -- > Mihai RUSU Email: dizzy@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) > > iD8DBQFALHooPZzOzrZY/1QRApvYAJ0fMimzQTSQiN6QOHizIviM19+5ywCgx1Sp > XSOJKWXTcFVJalNrWWEmix0> =lzx0 > -----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@xiph.org'> containing only the word 'unsubscribe' in the body. No subject is needed. > Unsubscribe messages sent to the list will be ignored/filtered. ><p>--- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 13 Feb 2004, Geoff Shang wrote:> Mihai RUSU wrote: > > > Another nice feature to add would be a "bandwidth" limit (so just a new > > <limit> type entry). > > Problem with this is, what do you do once the limit has been reached? Who > do you kick? Or do you just not allow anymore listeners?I just dont allow anymore listeners while current kbps (in the context where the kbps limit applies) is >= than the maximum kbps of this context. That solves at least my needs :)> Geoff.- -- Mihai RUSU Email: dizzy@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) iD8DBQFALHooPZzOzrZY/1QRApvYAJ0fMimzQTSQiN6QOHizIviM19+5ywCgx1Sp XSOJKWXTcFVJalNrWWEmix0=lzx0 -----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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.