Yeah, there aren't a lot of options, and what else
there is other than Throttlebox is far more simplistic.
We wrote Throttlebox because we found that the existing
solutions were a tad TOO simplistic - they caused just
enough problems to not be worth it for the benefits.
It took a few years of experimenting and thinking, but
it seems to work pretty well now, and it has support
for different formulas to be easily added in. Certainly
it costs a lot less than the developer time to design,
implement, test, redesign, reimplement either home grown
module OR the admin interface to go with it.
--
Ray Morris
supp...@bettercgi.com
Strongbox - The next generation in site security:
http://www.bettercgi.com/strongbox/
Throttlebox - Intelligent Bandwidth Control
http://www.bettercgi.com/throttlebox/
Strongbox / Throttlebox affiliate program:
http://www.bettercgi.com/affiliates/user/register.php
On 12/09/2009 11:11:40 AM, partysoft wrote:
Ok, i see that's a complete solution, i like it, let me check with my
bosses
to get the money for this , but probably we will go for it, as we
haven't
found any solution so far but this one you suggested
Ray Morris wrote:
>
>
>
>> > This kind of functionality, in my opinion, is better
>> > implemented at transport level and not at application level.
>
>> Yes, well that was the main problem , doing it per user, of course
i
>> have on
>> the DB the ips of the users when they login, i even update that,
but
>> you
>> know how ips are, constantly changing, even more, they can be under
>> NAT on
>> some private network,
>> but no doubt making it under a lower OSI level would be great and
>> have a
>> good performance..
>> but i will have to rewrite the ipchains constantly...
>
>
> Indeed we sometimes see IPs change several times
> within a 15 minute window, and this will become more
> common as IPv6 is more widely used.
>
> Also, the point is to solve a business problem.
> It's technical solution to a business problem, so you
> have to think in terms of business as well as technically.
> When someone purchases downloads as in this application,
> you're looking at bandwidth over a period of time beyond the
> current instant. It's not that you're wanting to make the site
> sluggish for users, but that you want to control the abusive
> users. So isn't bits per second that is best controlled, but
> MB per hour or GB per 48 hours. You also MUST consider protocol
> specific considerations in order to have an effective solution
> to the business issue. One small example is that you want to
> control the download of the mp3 files, not make the site slow
> by causing the web page graphics to be slow or not load.
> The technician, thinking purely techincally, might just
> tc queuing policy, but they would be rightly lambasted by
> the business manager for making the sluggish rather than
> addressing the actual concern, which includes an appropriate
> message to the user.
> --
> Ray Morris
> supp...@bettercgi.com
>
> Strongbox - The next generation in site security:
> http://www.bettercgi.com/strongbox/
>
> Throttlebox - Intelligent Bandwidth Control
> http://www.bettercgi.com/throttlebox/
>
> Strongbox / Throttlebox affiliate program:
> http://www.bettercgi.com/affiliates/user/register.php
>
>
> On 12/08/2009 05:48:37 PM, partysoft wrote:
>>
>> Yes, well that was the main problem , doing it per user, of course
i
>> have on
>> the DB the ips of the users when they login, i even update that,
but
>> you
>> know how ips are, constantly changing, even more, they can be under
>> NAT on
>> some private network,
>> but no doubt making it under a lower OSI level would be great and
>> have a
>> good performance..
>> but i will have to rewrite the ipchains constantly...
>>
>>
>> Sorin Manolache wrote:
>> >
>> > On Tue, Dec 8, 2009 at 05:11, partysoft <partys...@gmail.com>
wrote:
>> >>
>> >> I am looking for a solution to limit the bandwith for the users
of
>> a site
>> >> that have access to some mp3 / subscription. I don't want to
serve
>> files
>> >> through PHP, but directly with some apache module..
>> >> do i have to count every bit? or how this should be handled. I
>> have all
>> >> the
>> >> info on a mysql DB.
>> >> Thank you so much for your replies.
>> >
>> > This kind of functionality, in my opinion, is better
implemented at
>> > transport level and not at application level.
>> >
>> > I've done something similar, but more primitive, i.e. the
cumulated
>> > bandwidth of all connections to port 80 was capped, using traffic
>> > shaping in the linux kernel.
>> >
>> > The network packets are classified with iptables and then each
class
>> > can be given a different queueing policy with tc. Check
>> > http://lartc.org/howto/, chapter 9. I didn't do it per user, but
I
>> > suppose one can easily do it per client IP address. I admit that
>> maybe
>> > this approach is not suitable when you identify users with some
data
>> > token at application level.
>> >
>> > S
>> >
>> >
>>
>> --
>> View this message in context:
>>
http://old.nabble.com/Bandwith-limit-per-user-from-mysql-tp26688437p26702936.html
>> Sent from the Apache HTTP Server - Module Writers mailing list
>> archive at Nabble.com.
>>
>>
>
>
>
--
View this message in context:
http://old.nabble.com/Bandwith-limit-per-user-from-mysql-tp26688437p26713855.html
Sent from the Apache HTTP Server - Module Writers mailing list
archive at Nabble.com.
