Question about server load.
Community Forums/General Help/Question about server load.
| ||
| I'm still working out some of the design issues with my project. There is a part of the game, a pretty critical component, where a reasonably heavy calculation, or series of calculations is performed and then the result shared with other users. It is perfectly possible to do this calculation on the user's local device and it takes a couple of seconds at most. However that does leave that part of the process open to cheating...Although admittedly it would require a fairly intelligent user to do so (at least until the exploit became known). So one option is for the server to handle that calculation. Now I know on a little android device it takes a couple of seconds. Assuming a similar time for a server....and assuming let's say during peak time there were 10 of these calculations produced per hour per user...so we are looking at say a total processing time of 30 seconds per user per hour during peak times.... How many users could different types of server handle. Think in a turn based game such as the old combat mission series where a replay is generated by fairly complex physical simulation and then sent to the relevant users. That's kind of what I'm working on. Am I over thinking this? Would it be easier just to let users report(suspected) cheats (in public games) and simply temporarily ban users whose "suspicious activity" score reached a threshold, |
| ||
| Something else you can consider: Trust, but verify. The first couple of times a user needs the calculation, do it on the server AND have to user do it. If the results match, trust the next couple of calculations, then do another side-by-side verify every so often to make sure they didn't start cheating later. If the results don't match, you can take action by doing more frequent verification -- if there's a pattern of discrepancy, take action by either having the server take care of all calculations for that particular user defeating their cheating, or simply banning the user completely to send a message and prevent future cheating by him or others. At least that will help you offset some of the load to the user, and your server can handle more users overall. Oh, and keep in mind: if your calculation depends on floating point variables at all, you may see some very slight variations in the results depending on the processor or other computer architecture. You may want to built in a slight fudge-factor when comparing the calculation end results, e.g. as long as the results are at least 99.5% similar, treat them as genuine. |
| ||
| Yes they do use floating point math which is a bit of a problem in this case because the calculations form part of a series. I imagine any small discrepancies will cause the two simulations to diverge pretty quickly. I think what I will do is trust users in private games (if they want to cheat with their mates then that's their issue) but for public games I will probably allow users to enable an option that lets them flag cheats like I was saying. |
| ||
| I will probably allow users to enable an option that lets them flag cheats like I was saying. You may still want to have a way to verify cheating, because if you have users with greatly mis-matched skill levels, it won't take much for the great user to be repeatedly accused of 'cheating' even when he/she isn't... And unfairly banning them for it will only alienate that part of your user base. |
| ||
| What about some validation hashes? Each client hashes the input factors and the result. The servers from time to time validate the given result and factors too. If the factors hash is already invalid, the server does not need to calculate results. You can grain it finer and finer by submitting inbetween hashes of deterministic results ... I mean calculations using game provided data (unit levels, health points). So you might save time when validating (hash <> hash instead of a more complicated calculation using 20 deterministic factors). bye Ron |
| ||
| Possibly. This weekend I'll continue the interface stuff hopefully have a complete working interface between front and back end. Still ahead of schedule. I tested 1000 users on my local machine all logging in and creating joining games etc....worked ok....in reality I'm not going to get that many login and hammer the server in such a short space of time. It's probably going to be a kind of subscription model. ...low monthly fee to create new games but no fee to join existing ones....or something like that. |
   |