On detecting (and aborting) infinite loops in scripts

FYI. I'm still playing with this. I've learned a few things that don't work as well as I'd like :-) but nothing to submit for review, other testing or just commit because I'm awesome and never make judgements that turn out to be suboptimal.
 
Update. Not likely to happen. On my machine the processing time to record visited URLs and then look for x repetitions of a sequence of length y effectively doubled the wall clock time KoLmafia used while auto-adventuring. My motivation to profile or look for alternatives has evaporated :-)
 
fronobulax said:
Update. Not likely to happen. On my machine the processing time to record visited URLs and then look for x repetitions of a sequence of length y effectively doubled the wall clock time KoLmafia used while auto-adventuring. My motivation to profile or look for alternatives has evaporated :-)
Click to expand...
There are ways to speed that up, but the false positives vs false negatives tradeoff is what bothers me enough to give up.
 
I would still like to see a amount-of-requests throttle, because making requests too fast too long is likely to get you banned and therefore
1) never a false positive
2) an indicator (symptom) for a bunch of possible problems, some of which we haven't even encountered or thought of yet
 
I would guess that cannonfire40's fast casual ascensions are faster than 1 server hit per second for more than 1000 server hits. If that's considered a legitimate use case (and Jick doesn't seem to have a problem with it) then a general throttling setup seems complicated to implement.
 
Also good luck setting an appropriate threshold that won't hit legitmate adventuring a few ms from the server, but will hit looping on the other side of the planet.
 
Darzil said:
Also good luck setting an appropriate threshold that won't hit legitmate adventuring a few ms from the server, but will hit looping on the other side of the planet.
Click to expand...

I think xKiv's point was that distinction isn't important. If a user is sending so many requests in a short period of time that they're impacting KoL's server performance it doesn't really matter if it's "legitimate" or not. If the concern is reducing impact on KoL's servers then the first case should be throttled, and the second is irrelevant. The important metric is server hits per period of time. Regarding lost's post about casual ascension scripting, I'd assume a 1 hit per second average to be well below the threshold where this is a concern.
 
Yes, I am thinking more of a "this will get you banned" metric than "you have an infiniloop" metric. And anyway, if I have long ping, my loops will repeat fewer times before I get back and notice something's wrong.

Also, "you are actually spending turns" should probably figure somehow into it. Cannon is spending hundreds(?) of turns over those thousand(s) of hits. That's very different from doing 1000 hits without spending a turn, from both "get banned" and "inifiniloop" points of view.
 
I'd imagine yes, it's bad enough that there should be an upper limit on how fast you're spamming the server.
That said, with 10,000 requests if it's sending them fast enough to cause problems then it'll also be over relatively quickly.
If you were sending in excess of 100 requests a second for more than a minute or so then I wouldn't be surprised if it resulted in a ban.

It's the kind of thing you'd want TPTB's input on to get some idea of what are acceptable/non-acceptable levels of server spam.
 
Well, the answers from the developers are:
1) Not interested in doing work on this anymore, and
2) Seems complicated to implement, especially in a way that allows for fast-casual but not infinite undetectable loops that behave exactly like fast-casual except that they go on.

So I think the answer is that rather than telling them that you think it's still a good idea, if you want this to happen, you'd be better served by trying to figure out how to do this and give them a patch which they can evaluate which won't slow down normal legitimate adventuring.
 
You must log in or register to reply here.
Back
Top