Jump to content

  • Log In with Google      Sign In   
  • Create Account


Preventing cheating on game's server side


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 YyYo   Members   -  Reputation: 137

Like
0Likes
Like

Posted 05 June 2014 - 03:38 AM

HI...

 

A few weeks ago I started to implement my first multiplayer game(Java/Android)

The game is turn-base game similar to tic-tac-toe and players can Chat during the game.

The server always knows who is the current player.

since I need to support chatting no matter who's turn it is, I collect ALL messages from both players.

Chat messages are stored in a dedicated queue and broadcast to players.

Game messages are also stored in a dedicate queue.

 

Now comes the problematic part:

Lets say one of the player is cheating, and manage to send a "move" message to server even though its not is turn, how can I "recover" from this situation.

I have a solution for it, by start polling messages from game queue. if the message is not belong to current player i ignore it. if the message is belong to current player, I update game and switch turn to next user.

Is this solution is the correct one or there is something more simpler/elegant ???

 

I added a snapshot of pseudo code:

package ServerGame;

import java.util.Iterator;
import java.util.Queue;

class GameManager extends Thread{
	Player currentPlayer;
	Queue<Player> players;
	Queue<String> chatMessages;
	Queue<String> gameMessages;
	public void run(){
		String message;
		while(true){
			for(Player player : players){
				if(player.isReadAvailable()){		// check if there is a message sent from client 
					message = player.doRead();		// read message content
					router(message);				// route the message according to its type: game | chat
				}
			}
			broadcastChatMessages();				// send chat messages to all players
			updateGame();							// update game
		}
	}
		
	private void updateGame(){							
		for(Iterator<String> iterator = gameMessages.iterator() ; iterator.hasNext() ; ){
			String message = iterator.next();
			if(currentPlayer.isYours(message)){
				// handle message
				if(message.type ==”move”){				
					updateBoard();			// process the move and do a switch turn to opponent
					
				}
				switchTurn();
			}
			else{							// ignore messages that are not belong to current player(avoid cheating)
				iterator.remove();
			}
		}
	}
	
	private void broadcastChatMessages(){
		for(String message : chatMessages){
			for(Player player : players){
				player.doWrite(message);
				}
			}
	}

	private void router(String message){
		if(message == null){
			return;
		}
		if(message.proprietary == “CHAT”){
			chatMessages.add(message);
		}
		else if(message.proprietary == “GAME”){
			gameMessages.add(message);
		}
		else{
			// ignore message - maybe log it 
		}
			
	}

	
}


Sponsor:

#2 DiegoSLTS   Members   -  Reputation: 1173

Like
1Likes
Like

Posted 05 June 2014 - 06:34 AM

I think that's OK, if the cheat is sending a message to the queue when it's not their turn, checking and discarding those messages is the solution that makes more sense.

 

Another option could be to prevent the board to be updated 2 consecutive times by the same player (inside updateBoard), but it doesn't make sense that you proccess everything needed to make a move if you can detect the move isn't valid when it arrives.



#3 YyYo   Members   -  Reputation: 137

Like
0Likes
Like

Posted 05 June 2014 - 06:51 AM

First thanks for the fast response.

 

didn't understand what doesn't make sense

 but it doesn't make sense that you proccess everything needed to make a move if you can detect the move isn't valid when it arrives.

 

what I do in updateGame is to loop all "movement" messages in queue, and ignore messages not belonging to current player.

Can you please explain again?



#4 YyYo   Members   -  Reputation: 137

Like
0Likes
Like

Posted 05 June 2014 - 06:59 AM

BTW: isn't it better to CLEAN gameMessages queue after I make a move for the current player??

 

Since it is a turn-base game, which each player can make a single move, isn't it better to empty gameMessage queue?

It can prevent for cheater which try to 'attack' the game, by sending multiple messages to game when its not their turn.

I will adopt your idea which each player can't 

 

 

updated 2 consecutive times by the same player

 

but then the gameMessage queue will still contain "garbage" messages

 

am I right ??


Edited by YyYo, 05 June 2014 - 04:28 PM.


#5 hplus0603   Moderators   -  Reputation: 5187

Like
1Likes
Like

Posted 05 June 2014 - 09:37 AM

If you process the next message in the input queue as soon as it is there, and discard messages that are against the rules, then the "cleaning" will happen by itself, because if someone sends a second message, that will immediately be discarded (because it's against the rules.)


enum Bool { True, False, FileNotFound };

#6 DiegoSLTS   Members   -  Reputation: 1173

Like
1Likes
Like

Posted 05 June 2014 - 10:41 AM

First thanks for the fast response.

 

didn't understand what doesn't make sense

 but it doesn't make sense that you proccess everything needed to make a move if you can detect the move isn't valid when it arrives.

 

what I do in updateGame is to loop all "movement" messages in queue, and ignore messages not belonging to current player.

Can you please explain again?

Sorry, I meant that it wouldn't make sense. If you decide to ignore the move inside updateBoard instead of your current solution, you'll be processing the message when you could have detected it was invalid before. Maybe here it doesn't make much difference when you do it, but consider this: You decide to track data from each player, and part of that data is how many movements a player does. If you only check for cheats before updating the board you may update that player stats with invalid data. You can move the check to the tracking then and do something to prevent the movement too, but what if you add more features before the tracking? Discarding the message as soon as possible looks like the best option to me, check if it's valid before doing anything else.

 

Maybe I shouldn't have mentioned an option that I think it's bad, sorry if I confused you.

 

 

BTW: isn't it better to CLEAN gameMessages queue after I make a move for the current player??

 

Since it is a turn-base game, which each player can male a single move, isn't it better to empty gameMessage queue?

It can prevent for cheater which try to 'attack' the game, by sending multiple messages to game when its not their turn.

I will adopt your idea which each player can't 

 

 

updated 2 consecutive times by the same player

 

but then the gameMessage queue will still contain "garbage" messages

 

am I right ??

Cleaning the whole queue could be a problem if you can have 2 valid moves at some time in it. Maybe that can't happen in this case, but if you can always clear all the message queue maybe you don't really need a queue. As hplus0603 said, if you check and discard messages you'll basically be cleaning the queue, but you have more control than a .clean() method.

 

I'd stick with your current solution, ignoring the message if it doesn't belong to the current player.



#7 YyYo   Members   -  Reputation: 137

Like
0Likes
Like

Posted 05 June 2014 - 05:09 PM

Ok... lets take following scenario.

There 2 player: playerA & playerB

Current Player: playerA

Lets say both players are cheating and sends the following message order: [ B4 , A3 , A2 , B3 , A1 , B2 , B1] -> pollFirst()

If I decide to discard message before insert them to quaue, the following will happend in main loop:

1th iteration: B1 will be discarded and updateBoard wont do nothing(since queue is empty)

2th iteration: B2 will be discarded and updateBoard wont do nothing

3th iteration: A1 will be accepted and updateBoard will make the move and change the turn to playerB

4th iteration: B3 will be accepted and updateBoard will make the move and change the turn to playerA

5th iteration: A2 will be accepted and updateBoard will make the move and change the turn to playerB

6th iteration: A3 will be discarded and updateBoard wont do nothing.

7th iteration: B4 will be accepted and updateBoard will make the move and change the turn to playerA

 

is this what you ment to discard message before insert them to queue?

 

 

Discarding the message as soon as possible looks like the best option to me, check if it's valid before doing anything else.

 

Another thing raises while writing the scenario above(discarding message before adding to queue...)

It seems that the first valid message is processed immidiatly by updateGame(), and when finish updating, it pass the turn to next player.

It seems that the queue always have single valid message in queue at any time, so I guess I don't ready need the queue.

Am I wright or I'm starting to get a little confused ???


Edited by YyYo, 05 June 2014 - 05:12 PM.


#8 hplus0603   Moderators   -  Reputation: 5187

Like
0Likes
Like

Posted 06 June 2014 - 01:57 PM

My experience is that the simplest solution is the most robust.

Thus, when you receive a message, all you do is enqueue it in the message queue, and you're done.

The message queueing process then simply runs a loop that dequeues messages and handles them, one at a time.

Part of handling a message is determining "do the game rules allow this message at this time?"

If the game state has the value "it's red's turn" and you dequeue a message that says "blue makes a turn," then that's against the rules, and gets rejected by that logic.

The good news here is that each step is very focused, and knows what to do; there is no diffusion of state between different stages. If you have to have the network code "know" whose turn it "will be" in order to insert a message or not, you have a back pointing arc in your flow/dependency diagram, that will cause structural problems (and sometimes even deadlocks.)


enum Bool { True, False, FileNotFound };




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS