Forum OpenACS Development: Re: Blocking access to login based on repetitive hits by ip address?

hi there,

i have developed a small throttle and monitoring
package, we use permanently on our server. it is
written in XOTcl and uses Zoran libthread packages.
A controlling thread is created that recieves
information about requests (begin and end of request).
when the server is on high load and a user
requests within a time window to many requests,
the user is throttled. If he/she continues to
be eager, the user is kicked out (e.g. a
short error reply is sent back). In addion,
we keep a lot of statistics such as
graphs about active users, views per second or
hour, avg response time per minute, hour, etc.

on our system we have up to 3.5 mio hits per day,
around 15 dynamic views per second (sustained
avg over an hour, not counting images/css files).
The original need for the package was to cope
with users that like to mirror the whole content
of our site, especially, when the traffic is high.
Such "attacks" brought the system to a hold. Now
the problem is gone.

If there is interest, we can remove site specific
stuff and make it available...

-gustaf

  # This is a simple request-throttle application that
  # avoids simple DOS-attracks on an AOL-server.
  # The user (request key) can be specified via ipAddr or some other key,
  # such as an authenticated used.
  # Parameters:
  #  - timeoutMs: time window to keep statistics for a user
  #  - startThrottle: if user requests more than this
  #, he is throttled
  #  - toMuch: if user requests more than this
  #, he is kicked out
  #
  # The throttler is defined as a class to make to extensible
  # to define e.g. different kinds of throttling policies for
  # different kind of request keys. Note that the throttle thread itself
  # does not block, only the request thread blocks if necessary.

  Class ThrottleStat -parameter { type user_id timestamp ip_adress url }

  Class Throttle -parameter {
    {activeUserMinutes 10}
    {timeoutMs 2000}
    {startThrottle 3}
    {toMuch 7}
....
}

I think this looks quite interesting. You say it's a package...as in OpenACS singleton service? This would be a useful addition.
By all means Gustav. I'm looking forward for both a valuable package and the first XOTcl contribution.

/Bart

That rocks! It's also a great example of the flexibility of the aolserver infrastructure. I'm looking forward to seeing it.
Please provide this. After all, it will allow us to have a look at XOTcl and it's benefits for OpenACS. Thanks in advance
Collapse
11: Re: XOTcl (response to 10)
Posted by Mark Aufflick on
I hadn't particularly investigated XOTcl - there are after all a number of object extensions to Tcl, none of which have set the world on fire.

At the moment, nearly all my client work has been developing Object Oriented Perl - some systems over 50,000 lines of code. I have to say that after that, going back to Tcl REALLY HURTS.

XOTcl gets a way towards providing better software engineering options. Given that one of my biggest gripes with Tcl is the lack of advanced data structures and the necessity for upvar's, XOTcl would allow me to design object libraries to be data structures for me. While not nearly as cool as Perl, if we could implement, for example, the entire gang of four set of objects & methods then OpenACS will be able to present itself as a far more serious and mature development environment.

Any comments or flames?

Collapse
12: Re: XOTcl (response to 11)
Posted by Ola Hansson on
Mark,

Could you elaborate on why going back to Tcl, after having used Perl, really hurts? Is it the object orientation versus procedural style, or something else?

As for "upvar" ... it isn't much worse than pointers in "C", is it? And I bet that you use pointers all the time when you're doing stuff with C.

So "object orientation" is far more mature than procedural now? That's funny, I would have thought it was the other way around. 😉

Having said that, I think there's no doubt that OOP almost always provides a better way to write large programs than procedural programming does. But I am questioning if it is all that constructive to at this stage - given the established and well-proven structure OpenACS has today - introduce a new obstacle towards learning how existing packages work and how to develop new ones.

Putting an example package in contrib, that folks can look at for inspiration if they want to write custom code in OO style, is one thing (Herr Neumann, please do!) ... It is another thing to endorse XOTcl and divert scarse OACS developper resources to rewriting existing packages. That would have to be a fork of this toolkit, IMHO.