1

I have a browser game I made that runs in MVC3 .Net. Because everyone needs to be on a level playing field, to stop people using macros to click their mouse at a million miles per hour I simply added:

    if ($.active < 10) { //stuff }

to my javascript. Nifty enough and works fine, but since it's client side it's hard to trust. I'm trying to replicate this server side though and I'm having some trouble trying to come up with an equivalent. Is there anywhere else anyone can think of that would be better to move this type of setting to? A setting in IIS, a web.config setting? I've looked around the internet and can't really find anything that would be similar.

Thoughts?

Jeremy
  • 1
  • 85
  • 340
  • 366
boolean
  • 891
  • 2
  • 14
  • 23
  • Can you describe again what you're trying to do server side related to $.active? Per this thread http://stackoverflow.com/questions/3148225/jquery-active-function $.active is a measure of how many simultaneous jquery ajax requests are in flight which I don't see how it has anything to do with whether someone is using macros or not on the client. – jfriend00 Sep 16 '11 at 01:12
  • well each action the user does is a request back to the server. If they are using a macro they can queue up 200 requests in 200 milliseconds. Capping the .active I can limit this to 10, roughly 10 requests per 200 milliseconds. It's not foolproof but it at least caps the amount of clicks a user can send back to the server before they hit a click 'quota' limit and have to cool down. – boolean Sep 17 '11 at 03:25

1 Answers1

0

The usual server-side solution to this is called "rate limiting". You identify relevant requests at the server from a particular client, you keep track of how fast these requests arrive and you pick some maximum number of requests per second or requests per minute that you're going to allow. If that number is exceeded, you decide what strategy to deploy. You can delay them, return an error, disconnect them, logout the user, etc... Sometimes, it's advantageous to pick a strategy that keeps the client from knowing that it's being rate limited so it can't knowingly detect and adapt, still trying to maximize it's throughput.

You can get as detailed as you want, even picking different rate limiting strategies for different actions in the API if needed.

You try to pick a number for the rate limiting that a legitimate real user would never hit, but obviously one that keeps machines from abusing either your servers or the game logic.

jfriend00
  • 683,504
  • 96
  • 985
  • 979
  • Sometimes you just need the right terms to punch into google :) 'rate limiting' returns lots of articles covering exactly this! Thanks mate! – boolean Sep 17 '11 at 05:22