httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ray Morris <supp...@bettercgi.com>
Subject Re: Bandwith limit/per user from mysql
Date Wed, 09 Dec 2009 00:38:37 GMT


> > 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
support@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 <partysoft@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.
> 
> 


Mime
View raw message