77
Lecture 6 Point-to-Point Architecture 1 March 2010 1

CS4344 09/10 Lecture 6: P2P Synchronization

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: CS4344 09/10 Lecture 6: P2P Synchronization

Lecture 6Point-to-Point Architecture

1 March 2010

1

Page 2: CS4344 09/10 Lecture 6: P2P Synchronization

Point-to-Point Architecture

Role of clientsNotify clientsResolve conflictsMaintain statesSimulate games

2

Page 3: CS4344 09/10 Lecture 6: P2P Synchronization

Latency

Robustness

Conflict/Cheating

Consistency

Accounting

Scalability

Complexity

3

Page 4: CS4344 09/10 Lecture 6: P2P Synchronization

Lower LatencyNo Single Point of FailureLow Infrastructure Cost

4

Page 5: CS4344 09/10 Lecture 6: P2P Synchronization

Collect

Simulate

Render

Wait

GameStates

Collect

Simulate

Render

Wait

GameStates

5

Page 6: CS4344 09/10 Lecture 6: P2P Synchronization

6

Page 7: CS4344 09/10 Lecture 6: P2P Synchronization

MiMaze from INRIA, France

7

Page 8: CS4344 09/10 Lecture 6: P2P Synchronization

Age of Empire Series

http://compactiongames.about.com/library/games/screenshots/blscreens-ageofkings.htm

8

Page 9: CS4344 09/10 Lecture 6: P2P Synchronization

How to order events?

9

Page 10: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Does received-order delivery work?

Player C

Player B

10

Page 11: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Does sending order delivery work?

Player C

Player B

11

Page 12: CS4344 09/10 Lecture 6: P2P Synchronization

idea: wait for messages from all players to arrive

before executing

12

Page 13: CS4344 09/10 Lecture 6: P2P Synchronization

Bucket Synchronization

13

Page 14: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

The game is divided into rounds (e.g. 25 rounds per second).

Player C

Player B

14

Page 15: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Players are expected to send an event in each round (e.g. 25 updates per second).

Player C

Player B

15

Page 16: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Players are expected to send an event in each round (e.g. 25 updates per second).

Player C

Player B

16

Page 17: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Every round has a “bucket” that collects the events.

Player C

Player B

17

Page 18: CS4344 09/10 Lecture 6: P2P Synchronization

Events generated in the same round go into the same bucket of a future round. We know which round an event is generated in, based on time-stamp.

Player A

Player C

Player B

18

Page 19: CS4344 09/10 Lecture 6: P2P Synchronization

Events generated in the same round go into the same bucket of a future round. We know which round an event is generated in, based on time-stamp.

Player A

Player C

Player B

18

Page 20: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

In each round, the events in the bucket are processed (in order of time-stamp).

Player C

Player B

19

Page 21: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Two parameters needed : round length and lag. Lag depends on maximum network latency among the players; round length depends on rendering speed.

Player C

Player Bround length

lag

20

Page 22: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Players periodically ping among themselves and exchange latency information. They also measure the average time taken to render a frame and exchange that information to estimate lag and round length.

Player C

Player Bround length

lag

21

Page 23: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

If events from another player is lost (or late), we can predict its update (e.g. using dead reckoning) when possible.

Player C

Player B

22

Page 24: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Alternative is to ensure every event is received before executing the bucket. What are the drawbacks?

Player C

Player B

23

Page 25: CS4344 09/10 Lecture 6: P2P Synchronization

Stop-and-Wait Protocol

24

Page 26: CS4344 09/10 Lecture 6: P2P Synchronization

Synchronized Simulations

25

Page 27: CS4344 09/10 Lecture 6: P2P Synchronization

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

26

Page 28: CS4344 09/10 Lecture 6: P2P Synchronization

Collect

Simulate

Render

Wait

GameStates

Collect

Simulate

Render

Wait

GameStates

Getting all clients to simulate the exact same thing is tricky: must use same number of random calls with same seeds, same precision of floating point calculation etc.

27

Page 29: CS4344 09/10 Lecture 6: P2P Synchronization

Collect

Simulate

Render

Wait

GameStates

Collect

Simulate

Render

Wait

GameStates

Clients may periodically exchange hash of game states to detect if a player has gone out-of-sync.

CompareCompare

28

Page 30: CS4344 09/10 Lecture 6: P2P Synchronization

Cheating

29

Page 31: CS4344 09/10 Lecture 6: P2P Synchronization

Look-Ahead Cheat

30

Page 32: CS4344 09/10 Lecture 6: P2P Synchronization

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

Player A

Player C

Player B

31

Page 33: CS4344 09/10 Lecture 6: P2P Synchronization

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

Player A

Player C

Player B

31

Page 34: CS4344 09/10 Lecture 6: P2P Synchronization

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

Player A

Player C

Player B

31

Page 35: CS4344 09/10 Lecture 6: P2P Synchronization

Dealing with cheaters:

1. Prevent cheats (hard)2. Detect cheats (easier)

32

Page 36: CS4344 09/10 Lecture 6: P2P Synchronization

Detecting Look-Ahead Cheats

33

Page 37: CS4344 09/10 Lecture 6: P2P Synchronization

“Mmm... player C always the last one

that makes its move.”

34

Page 38: CS4344 09/10 Lecture 6: P2P Synchronization

Time-stamp Cheat

35

Page 39: CS4344 09/10 Lecture 6: P2P Synchronization

Player C (or a bot) can put in an earlier time-stamp in its messages.

Player A

Player C

Player B

36

Page 40: CS4344 09/10 Lecture 6: P2P Synchronization

Suppress-Update Cheat

37

Page 41: CS4344 09/10 Lecture 6: P2P Synchronization

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 C

Player B

38

Page 42: CS4344 09/10 Lecture 6: P2P Synchronization

A C

39

Page 43: CS4344 09/10 Lecture 6: P2P Synchronization

A

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

40

Page 44: CS4344 09/10 Lecture 6: P2P Synchronization

A

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

41

Page 45: CS4344 09/10 Lecture 6: P2P Synchronization

A

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

42

Page 46: CS4344 09/10 Lecture 6: P2P Synchronization

A

C sends an update and shoots A.

43

Page 47: CS4344 09/10 Lecture 6: P2P Synchronization

Cheater!Not my fault! My

packets were dropped..

44

Page 48: CS4344 09/10 Lecture 6: P2P Synchronization

Inconsistent Cheat

45

Page 49: CS4344 09/10 Lecture 6: P2P Synchronization

Player C can send different events to different players.

Player A

Player C

Player B

46

Page 50: CS4344 09/10 Lecture 6: P2P Synchronization

With synchronous simulations, we can compare periodically the

game states to detect inconsistency cheats

47

Page 51: CS4344 09/10 Lecture 6: P2P Synchronization

Cheat-Proof Protocol

48

Page 52: CS4344 09/10 Lecture 6: P2P Synchronization

Lock Step Protocol

49

Page 53: CS4344 09/10 Lecture 6: P2P Synchronization

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.

50

Page 54: CS4344 09/10 Lecture 6: P2P Synchronization

Lock Step Protocol

51

Page 55: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Stage 1 (Commit): Everyone decide on its move x, and send f(x) to each other.

Player C

Player B

52

Page 56: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Stage 2 (Reveal): After f(x)s from all other players are received, sends x to each other.

Player C

Player B

53

Page 57: CS4344 09/10 Lecture 6: P2P Synchronization

f(x) is known as commitment to x.

A player, once committed to its move, can’t change it.

54

Page 58: CS4344 09/10 Lecture 6: P2P Synchronization

How does lock-step prevent:

look ahead cheat?timestamp cheat?suppress-update cheat?

55

Page 59: CS4344 09/10 Lecture 6: P2P Synchronization

Problem: Lock-step protocol is slow.

56

Page 60: CS4344 09/10 Lecture 6: P2P Synchronization

lmax = maximum latency rmax = maximum frame (round) rate

Lockstep Protocol 1/r = max{2lmax, 1/rmax}

57

Page 61: CS4344 09/10 Lecture 6: P2P Synchronization

Idea: Use Interest Management

Players only engaged in lock-step protocol when they influence each other. Otherwise

their games proceed independently.

58

Page 62: CS4344 09/10 Lecture 6: P2P Synchronization

This is known as Asynchronous Synchronization

or Asynchronous Lock-step

59

Page 63: CS4344 09/10 Lecture 6: P2P Synchronization

We may also stagger these two stages to improveframe rate. Multiple commitments can be sentout before we reveal the actions.

Player A

Player C

60

Page 64: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Player C

A player can reveal its action in round i once it receives all commitment of round i from other players.

61

Page 65: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Player C

A player can make p moves (send p commitments) without engaging in lockstep.

62

Page 66: CS4344 09/10 Lecture 6: P2P Synchronization

This is known as Pipelined Lock-step

63

Page 67: CS4344 09/10 Lecture 6: P2P Synchronization

lmax = maximum latency rmax = maximum frame (round) rate

Lockstep Protocol 1/r = max{2lmax, 1/rmax}

64

Page 68: CS4344 09/10 Lecture 6: P2P Synchronization

lmax = maximum latency rmax = maximum frame (round) rate

Pipelined Lockstep Protocol 1/r = max{2lmax/p, 1/rmax}

65

Page 69: CS4344 09/10 Lecture 6: P2P Synchronization

lmax = maximum latency rmax = maximum frame (round) rate

We can pick optimal p as

p = 2 lmax rmax

66

Page 70: CS4344 09/10 Lecture 6: P2P Synchronization

Cheating in Pipelined Lock-step

67

Page 71: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Player C

C makes its 4-th move after seeing the first p moves from A. A’s first six moves are not based on C’s move.

68

Page 72: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Player C

C makes its 4-th move after seeing the first p moves from A. A’s first six moves are not based on C’s move.

68

Page 73: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Player C

Fair if everyone do the same thing.But frame rate suffers.

69

Page 74: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Player C

Fair if everyone do the same thing.But frame rate suffers.

69

Page 75: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Player C

We can enforce commit to arrive within a period of time (T < RTT) and treat late arrivals as cheaters. What are some drawback of this scheme?

T

70

Page 76: CS4344 09/10 Lecture 6: P2P Synchronization

Player A

Player C

We can enforce commit to arrive within a period of time (T < RTT) and treat late arrivals as cheaters. What are some drawback of this scheme?

T

70

Page 77: CS4344 09/10 Lecture 6: P2P Synchronization

lmax = maximum latency rmax = maximum frame (round) rate

Pipeline Lockstep Protocol (without late commit) 1/r = max{lmax/p, 1/rmax}

p = lmax rmax

71