On 6/21/05, Ann W. Harrison <aharrison@...> wrote:

> Alexander Klenin wrote:
> >
> > In addition to examples already provided, I can give my own. One of my
> > projects is student testing system for the local university. It asks
> > students questions and monitors time taken to answer them -- so any
> > loss of responsiveness can have a direct effect on grades!
>
> You mean you're counting system time in addition to student think time?
> If I were a student, I'd be really annoyed. And if I were your
> instructor, I'd suggest that you rethink the application before you
> submitted it for a grade.

Well, I admit that I sometimes write stupid programs, but not THAT stupid ;-)
Sure, we try to count "think time", but that is not as easy as it sounds.
For example, the submit time is taken from database server for
security and consistency,
but the server could have a problem even answering a query like
SELECT CURRENT_TIMESTAMP FROM RDB$DATABASE.
Another problem is that not all clients are web-servers, there are
some Windows-clients connecting directly do database, so counting time
on web-server is not always even an option.
Moreover, the testing schedule is rather tight, (we have to test about
15000 students in a week), so not only time to answer a single
question, but also total test time is limited. So the situation where
every student is forced to wait extra 30 seconds after each question
is totally unacceptable.
Anyway, I could speak about this for hours :-) The point is -- yes,
the problem could be solved, for example, with a custom server process
which works as a filter between database server and external world,
but this would be too much pain.

> Which should not be a problem if your students were measured on their
> think-time rather than connect time.

See above -- they could simply have not enough time to complete the
test, even ignoring obvious usability issues.

> > This system currently uses quota-based proprietary database which
> > allows it to dynamically change quotas for "teacher" account depending
> > on the system load.
> Here's what I would expect to have happen in that case. I'm a teacher,
> I've got a big query, and I need the results. I submit my query, run
> out of quota and lose all benefit of the work done so far.

How do you loose anything? The time to select query parameters is
perhaps 10-15 seconds -- you will just see a message telling that the
system is overloaded and asking you to resubmit your query in a few
minutes.

> Irked, and
> on a deadline, I resubmit the query and continue in that loop, wasting
> huge numbers of cycles, until the query finally succeeds or somebody kills me.

This is not a problem -- the system is well-suited and tuned to handle
hundreds of quick queries -- the problem is in big and complex ones,
so we could simply temporarily cut quota even further in this case
(but this is not done now, and most of teachers do get the message
after one or two tries ;-)

> If that works for you, fine. Be careful of funny dates - I'll bet your
> application will have a grand time with 2005.0.15 and such MySQL
> specialties.

These are fixed too -- this is why we are considering 5.0, but not 4.x.

> Somehow I think the denial of service (DoS) attack recognition hasn't
> been moved into most databases yet.

I have only spoken about prevention -- recognition is of course the
whole other matter.

> > Yes, but should he sit at the terminal and monitor the database 24 hours/day?
>
> Well, we pretty much need to monitor our servers 24/7 because from time
> to time the phone company kills our line or the power company decides to
> do some work and we need to bring in battery backup in case the
> batteries on the UPS don't last as long as the interruption, or our
> up-stream ISP has a problem and we need to respond instantly for our
> clients. If you're offering major service, you've got to have somebody
> there to handle problems.

Hm, I admit the power and network here in Russia are problematic, but
still once-in-a-month power failure does not the same level of
attention as once-in-a-ten-minutes database-grinding query.

> > Such as the current situation, where any malicious or buggy client can
> > easily bring the whole database to a halt.
> I've never thought of DoS as a data security problem.

Then it is perhaps time to start thinking now ;-)

--
Alexander S. Klenin
Insight Experts Ltd.