Hmmm... I would question the wisdom of running a service popular enough
to require use limits via a dialup, but it certainly will happen.
> > If you think it's necessary to define a hard upper limit on number of
> > simultaneous transactions, it would be much preferable to try to just block
> > and wait for an existing transaction to terminate if that's possible,
subject
> > to some sort of timeout error of course.
>
> Developer's choice.
>
> I chose to return a "too busy" message because I felt that the user on the
> other end is entitled to a prompt, rational explanation as to why the
> request wasn't satisfied. Creating a secondary queue (a queue of incoming
> connections waiting to complete) is prolonging the inevitable. That queue
> can run out (most sockets packages can queue 4-5, I believe).
Making explicit "too busy" messages has potential problems too, of course,
since those messages themselves take some load (probably an appreciable
fraction of the load of an ordinary request, since most documents are
generally fairly short and the request with all its accept headers can get
rather lengthy.)
It is, of course, inevitable that users will start clicking on "reload"
over and over to get past the "too busy" message given the high turnover of
sessionless HTTP, this is actually a fairly reasonable thing to do.
Eventually someone will design a client that does it automatically.
Then what?
> If the user gets back some obscure "connection refused" message, he's gonna
> think maybe the server's broken, the network is broken, his client is
> broken, the URL is broken, he is broken, who knows? I hate that. Kinda
> like "SYNTAX ERROR".
Yup. But I'd rather see the data a little late than a note to that effect.