llHttpRequest Documentation to improve script efficiency.

First off, I am really pleased that you implemented llHttpRequest! This opens a whole new world of posibilities. That said, I would appreiate it if someone could tell me how long, it takes for a llHttpRequest throttle to time out. I could greatly simplify my scripts. I don't need an exact number just a time after which it is 100% guaranteed that the throttle will be removed and it is safe to retry. Of course the closer to the actual time, the better user experience I can provide

For further details on why I need this information see my comment at:
http://secondlife.com/badgeo/wakka.php?wakka=llHTTPRequest

As it stands I will be forced to do a bunch of time keeping and defensive programming to prevent a throttle (and potential loss of user input). Getting throttled would make it very difficult to prevent my scripts from getting locked into a state they can't get out of.

what I want to do is (pseudo code)

while (key != null) {
key = llHttpRequest(stuff)
if (key == null) { // <--- We got throttled!
sleep(throttleExpriationInterval);
}
}

Of course I can work around the unknown throttle time, but it all requires a more programming work for me, and more processing time for your servers. I could also spend some time in the test sim and determine the time empirically, but then any undocumented changes could totally hoze me. Since player actions cause requests I can't control the rate of requests directly. As it stands I can't even tell the user try again in X seconds cause I don't know what X is.

I expect throttling to be a rare case, but an important one for me to handle correctly. I'm not building anything that is likely to generate frequent throttles, just something I don't want to die if it does happen.

Thanks,
Sai Harbinger

P.S. Other better solutions for future patches include an event that can be caught to detect the unthrottle conditions, and an option to opt for blocking calls that don't return until the the request has been sent (thereby handling a throttle automatically). Another posibility is a function that tests to see if a throttle will be imposed, and returns the time one must wait to avoid a throttle. Really just anything that lets my script know how to not cause problems gracefully. Obviously not all of those are needed, but at least one would be nice.

UPDATE: The basic mechanics have not changed but the actual rates changed since this was posted. The new rates are 25 requests per 20 seconds and are per object, not per owner per region. If the object making the requests hits the limit then stopping for 40 seconds will clear the throttle.

Short answer: If all objects you own in the sim stop making requests completely, the throttle will completely clear in 200 seconds.

Medium answer: You can start making requests again sooner, however you may also hit the throttle sooner.

Long answer: The throttle uses a moving window to continue to block things that don't slow down. Starting with the first request, requests are counted in 100 second buckets. For 100 seconds from the first request all requests go into a single bucket, 100 seconds later a new bucket is started ... but the last bucket is kept around. If the current bucket has more than the throttle limit (20) then requests will be blocked. If the current total + (% of time remaining in this bucket * total from last bucket) is more than the throttle (20) then requests are blocked.

Simple eh?

So, you don't want to do while(key!=null) loops because you will just hit the throttle quick then be blocked. I would recomend just spacing out each request at least 5 seconds, or if bursts are needed then spacing 5*(requests / burst) seconds.