At 1/6/04 1:23 PM, WebWiz wrote:

>That's quite a leap to say that because they don't invoke any 
>restrictions until you cause problems, they must be "underconfiguring 
>and dumping the blame on a user".

Well, the trouble with a "you can do whatever you want unless you cause 
problems, then we'll kick you off" policy is twofold.

First of all, resellers clearly have no idea what will cause problems. 
One request every five seconds? Five requests a second? If Tucows doesn't 
say, it's hard to know if what you're doing is going to be okay, which 
means that people with even good intentions can be punished. It's like 
taking down all the speed limit and school zone traffic signs and saying 
"just don't go too fast," then throwing people in jail when they drive 
quickly past a school they didn't know was there. Rules help everyone.

The second problem is that the policy doesn't protect other people. If 
people aren't stopped from abusive behavior until after the abuse has 
been in progress for a while, then other people (who quite definitely 
aren't being abusive of the system, such as me with a few requests an 
hour) are paying the price in reliability. If Tucows defined limits that 
ensured no load problems, my business would run more smoothly.

I have no problem with the idea that people might be allowed to exceed 
the set limit if the system detects that it's not busy and there are 
going to be enough guaranteed RAs (or whatever) for any reasonable load 
that occurs in the next ten seconds (or whatever), but if there's any 
doubt at all about resources (which there clearly is sometimes), people 
should be throttled back to x transactions per second to make sure all 
the resources aren't used. And x should be a published number so that 
people who aren't abusers can rely on having decent connectivity if they 
don't exceed x.

I strongly suggest that Tucows declare a firm policy on it. If it's just 
going to be left in its currently unreliable state, I don't see why I 
should keep using it in an attempt to be helpful to others; why should I 
care more about keeping things stable for other resellers than Tucows 
cares about keeping things stable for my scripts? I am dismayed to find 
out that the "we deal with it only when it's already broken" policy at 
Tucows is probably the reason that the batch server has been this 
unreliable all along. There should have been load limits from day 1 to 
ensure that any reseller using it for only a few requests an hour would 
very rarely have trouble.

I'm pretty sure I remember being told that all automated scripts needed 
to be run against the batch server, which is why I started doing it. 
Tucows, is it officially okay now to run light-duty automated scripts 
(those that only make a few requests an hour) against the primary server?

-- 
Robert L Mathews, Tiger Technologies      http://www.tigertech.net/

"I am not able rightly to apprehend the kind of confusion of
 ideas that could provoke such a question."  -- Charles Babbage

Reply via email to