Peer-to-Peer Architecture

Size: px

Start display at page:

Download "Peer-to-Peer Architecture"

Eugenia McKinney
6 years ago
Views:

1 Peer-to-Peer Architecture 1

2 Peer-to-Peer Architecture Role of clients Notify clients Resolve conflicts Maintain states Simulate games 2

3 Latency Robustness Conflict/Cheating Consistency Accounting Scalability Complexity 3

4 Lower Latency No Single Point of Failure 4

5 MiMaze from INRIA, France 5

6 Age of Empire Series 6

7 Without a server with authority, we can easily get into inconsistent states. Player A Player B Player C 7

8 Problem: order of messages received are wrong. Player A Player B Player C 8

9 Idea: If we synchronize the clocks of all players and timestamp each message, we can know the right order of execution. Player A Player B Player C 9

10 Problem: When to execute? (Is there another message generated earlier than this that is still on its way here?) Player A Player B Player C 10

11 (old) Idea: Delay processing of messages 11

12 Bucket Synchronization 12

13 Make the game into a turn-based game.. 13

14 .. with very fast turns. 14

15 The game is divided into rounds (e.g. 25 rounds per second). Player A Player B Player C 15

16 Players are expected to send an update in each round (e.g. 25 updates per second). Player A Player B Player C 16

17 (and therefore is only suitable if we have a small number of players..) 17

18 Players are expected to send an update in each round (e.g. 25 updates per second). Player A Player B Player C 18

19 Every round has a bucket that collects the update messages. Player A Player B Player C 19

20 Messages generated in the same rounds goes into the same bucket of a future round. Player A Player B Player C 20

21 We know which rounds a message is generated based on time-stamp. Player A Player B Player C 21

22 When it is time to execute a round, the messages in the bucket is processed (in order of time-stamp). Player A Player B Player C 22

23 Which future bucket to go into depends on the latency among the players. (Hopefully not too far in the future else responsiveness will suffers). Player A Player B Player C 23

24 If messages from another player is lost (or late), we can predict its update (e.g. using dead reckoning) when possible. Player A Player B Player C 24

25 Inconsistency still arises due to prediction. 25

26 Alternative is to ensure every update is received before executing the bucket. Player A Player B Player C 26

27 Stop-and-Wait Protocol 27

28 Synchronized Simulations 28

29 Every player sees exactly the same states (but maybe at different time) 29

30 Players can tell each other their processing time and latency among players, so that turn length and lag can be adjusted. 30

31 Cheating 31

32 Look-Ahead Cheat 32

33 Player C (or a bot) can peek at A s and B s actions first, before deciding his/her moves. Player A Player B Player C 33

34 Dealing with cheaters: 1. Prevent cheats (hard) 2. Detect cheats (easier) 34

35 Detecting Look- Ahead Cheats 35

36 Mmm... player C always the last one that make its move 36

37 Time-stamp Cheat 37

38 Player C (or a bot) can put in an earlier timestamp in its messages. Player A Player B Player C 38

39 Suppress-Update Cheat 39

40 If dead reckoning is used, Player C can stop sending update and let others predict its position. C then sends an update at appropriate time to surprise other players. Player A Player B Player C 40

41 A C 41

42 C stops sending update. A predicts C s position. A 42

43 C stops sending update. A predicts C s position. A 43

44 C stops sending update. A predicts C s position. A 44

45 C sends an update and shoots A. A 45

46 Not me! My packets Cheater! were dropped.. 46

47 Cheat-Proof Protocol 47

48 Lock Step Protocol 48

49 One-Way Function f: Given x, we can compute f(x) easily. Given f(x) it s hard to find out x if x is random. 49

50 Lock Step Protocol 50

51 Two stages needed for each round of stopand-wait updates. Stage 1. Everyone decides on its move x, and send f(x) to each other. Player A Player B Player C 51

52 Stage 2. After f(x) from every other player is received, sends x to each other. Player A Player B Player C 52

53 How does lock-step prevent: look ahead cheat? timestamp cheat? suppress-update cheat? 53

54 f(x) is known as commitment to x. A player, once committed to its move, can t change it. 54

55 Problem: Lock-step protocol is slow. 55

56 Idea: Use Interest Management Players only engaged in lock-step protocol when they influence each other. Otherwise their games proceed independently. 56

57 This is known as Asynchronous Synchronization or Asynchronous Lock-step 57

58 Let s call the two stages in lock-step protocol as commit and reveal stages. Commit Reveal Player A Player B Player C 58

59 We may also stagger these two stages to improve responsiveness. Multiple commitments can be sent out before we reveal the actions. Player A Player B Player C 59

60 1. A player can reveal its action in round i once it receives all commitment of round i from other players. Player A C1,A M1,A Player C C1,C M1,C 60

61 2. A player can make p moves (send p commitments) without engaging in lockstep. C4,A Player A C1,A C2,A M1,A Player C C1,C C2,C M1,C C4,C 61

62 This is known as Pipelined Lock-step 62

63 lmax = maximum latency rmax = maximum frame (round) rate Lockstep Protocol 1/r = max{2lmax, 1/rmax} 63

64 lmax = maximum latency rmax = maximum frame (round) rate Pipeline Lockstep Protocol 1/r = max{2lmax/p, 1/rmax} 64

65 lmax = maximum latency rmax = maximum frame (round) rate We can pick optimal p as p = 2 lmax rmax 65

66 Cheating in Pipelined Lock-step 66

67 C makes its 4-th move after seeing the first p moves from A. A s first six moves is not based on C s move. C4,A Player A C1,A C2,A M1,A C4,C Player C C1,C C2,C M1,C 67

68 C makes its 4-th move after seeing the first p moves from A. A s first six moves is not based on C s move. C4,A Player A C1,A C2,A M1,A Player C C1,C C2,C M1,C C4,C 68

69 But it s fair if all players do the same. C1,A C2,A M1,A C4,A C1,C C2,C M1,C C4,C 69

70 Player C can t peek at extra moves if C4,C is received within 2lAC of sending M1,A 2lAC C1,A C2,A M1,A C1,C C2,C M1,C C4,C 70

71 We can detect late commit if we know the latency between players. 2lAC C1,A C2,A M1,A C1,C C2,C M1,C C4,C 71

72 lmax = maximum latency rmax = maximum frame (round) rate Pipeline Lockstep Protocol (without late commit) 1/r = max{lmax/p, 1/rmax} p = lmax rmax 72

73 Player can lie about latency! 73

74 C can pretend to be on a slow network when measurement of lac is done (e.g. using ping). Fake 2lAC Actual 2lAC C1,A C2,A M1,A C1,C C2,C M1,C C4,C 74

75 If fake lac is larger than lmax, then we increase p, limiting the cheat to one round. Fake 2lAC Actual 2lAC C1,A C2,A M1,A C1,C C2,C M1,C C4,C 75

76 You Are Here CS4344 Client/Server Architecture Synchronization Protocols Interest Management Peer-to-Peer Architecture Cheat-proof Synchronization Protocol 76

Centralized Server Architecture

Centralized Server Architecture Synchronization Protocols Permissible Client/ Server Architecture Client sends command to the server. Server computes new states and updates clients with new states. Player