> 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.
