$.active 相当于非客户端的东西？
我制作了一个在 MVC3 .Net 中运行的浏览器游戏。因为每个人都需要处于公平的竞争环境中，为了阻止人们使用宏以每小时一百万英里的速度单击鼠标，我简单地添加了：
if ($.active < 10) { //stuff }
到我的 JavaScript 中。足够漂亮并且工作正常，但由于它是客户端，因此很难信任。我正在尝试复制这个服务器端，但在尝试提出等效方案时遇到了一些麻烦。还有其他任何人能想到将这种类型的设置移至更好的地方吗？ IIS 中的设置，web.config 设置？我浏览过互联网，但找不到任何类似的东西。
想法？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通常的服务器端解决方案称为“速率限制”。您可以在服务器上识别来自特定客户端的相关请求，跟踪这些请求到达的速度，并选择您允许的每秒最大请求数或每分钟最大请求数。如果超过该数字，您可以决定部署什么策略。您可以延迟它们，返回错误，断开它们的连接，注销用户等等...有时，选择一种策略是有利的，该策略可以让客户端不知道它受到速率限制，因此它无法故意检测和适应，但仍然试图最大化它的吞吐量。
您可以根据需要获得尽可能详细的信息，甚至可以根据需要为 API 中的不同操作选择不同的速率限制策略。
您尝试选择一个合法真实用户永远不会达到的速率限制数字，但显然可以防止机器滥用您的服务器或游戏逻辑。
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.