Re: "Too Busy" Error Needed (Robert Denny)
Date: Thu, 9 Jun 1994 18:28:50 +0200
Message-id: <>
Precedence: bulk
From: (Robert Denny)
To: Multiple recipients of list <>
Subject: Re: "Too Busy" Error Needed
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text/plain; charset=US-ASCII
Content-Type: text/plain; charset=US-ASCII
Mime-Version: 1.0
Mime-Version: 1.0
X-Mailer: ELM [version 2.4 PL23]
X-Mailer: ELM [version 2.4 PL23]
Marc --

> From: Marc VanHeyningen <>
> How long is the average transaction active?  I'd guess a second or two, tops.

Depends on how the server is connected to the net. My vision is to have
this server used on lots of personal machines running Windows, probably
tied in via PPP/SLIP connections. At least till ISDN gets past the
chicken-and-egg stage. Years, in other words. Connections could be more
like 10 seconds and up.

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

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

My approach tries its hardest to deliver a rational, easy to understand
alert message, and do it quickly so the incoming connection requests won't
pile up to the network package's limit and cause an ugly network failure
message to be delivered to the client.

    -- Bob