Potential Games LLC

In Part 1 of this article, I defined non-blocking transaction processing in the game client. Part 2 discusses security concerns of concurrent transactions in the game server, which could expose cheating and exploits. A simple server-side sequential transaction approach is described that can fix the security issues. Part 3 will discuss how to safely perform server-side parallel processing, using two techniques. Security in this context is defined in terms of game rules. The security concern is that players may be able to exploit the transaction model to cheat the rules. For example, suppose two players' characters attempt to pick up the same item from the world surface. The failure case is that the server processes both transactions at the same time, placing the item into each character's inventory. Similarly, suppose one player finds a way to send two concurrent requests to pick up an item. This could result in the item showing up twice in inventory. This represents a common item duplication exploit in online games. To avoid the item-dupe exploit, the server must be more careful how it processes transactions. There are several potential approaches. The simplest technique is to serialize all transaction processing in the server. That is, each transaction is executed sequentially (one-at-a-time). No matter the timing between players picking up the item, the server will accept the first and deny the second. Notice that the order in which requests (e.g., to pick up an item) are processed depends on client and network timing. This is a fairness concern, rather than a transaction security issue, which is not addressed here. (Solving the fairness problem involves lots of interesting techniques, such as distributed coordinated game time. This would make a fine future discussion.) The simplest solution is the most secure, and should be used until proven insufficient. If performance testing proves that serial transaction processing is the bottleneck preventing the server from supporting the required number of online players, parallel transaction processing techniques can be employed, under the presumption that concurrency will provide greater transaction throughput. Concurrency always results in a multitude of really interesting (read: tricky) issues to deal with. In Part 3, I discuss safe server-side concurrent transaction processing, using resource locking and resource isolation.