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 > [email protected] > > 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 <[email protected]> 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.
