CS4344 09/10 Lecture 6: P2P Synchronization
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

CS4344 09/10 Lecture 6: P2P Synchronization

on

  • 2,282 views

 

Statistics

Views

Total Views
2,282
Views on SlideShare
2,280
Embed Views
2

Actions

Likes
1
Downloads
48
Comments
0

1 Embed 2

http://www.slideshare.net 2

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

CS4344 09/10 Lecture 6: P2P Synchronization Presentation Transcript

  • 1. Lecture 6 Point-to-Point Architecture 1 March 2010 1
  • 2. Point-to-Point 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 Low Infrastructure Cost 4
  • 5. Collect Collect Game Simulate Game Simulate States States Render Render Wait Wait 5
  • 6. 6
  • 7. MiMaze from INRIA, France 7
  • 8. Age of Empire Series http://compactiongames.about.com/library/games/screenshots/blscreens-ageofkings.htm 8
  • 9. How to order events? 9
  • 10. Does received-order delivery work? Player A Player B Player C 10
  • 11. Does sending order delivery work? Player A Player B Player C 11
  • 12. idea: wait for messages from all players to arrive before executing 12
  • 13. Bucket Synchronization 13
  • 14. The game is divided into rounds (e.g. 25 rounds per second). Player A Player B Player C 14
  • 15. Players are expected to send an event in each round (e.g. 25 updates per second). Player A Player B Player C 15
  • 16. Players are expected to send an event in each round (e.g. 25 updates per second). Player A Player B Player C 16
  • 17. Every round has a “bucket” that collects the events. Player A Player B Player C 17
  • 18. 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 B Player C 18
  • 19. 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 B Player C 18
  • 20. In each round, the events in the bucket are processed (in order of time-stamp). Player A Player B Player C 19
  • 21. Two parameters needed : round length and lag. Lag depends on maximum network latency among the players; round length depends on rendering speed. lag Player A round length Player B Player C 20
  • 22. 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. lag Player A round length Player B Player C 21
  • 23. If events 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 22
  • 24. Alternative is to ensure every event is received before executing the bucket. What are the drawbacks? Player A Player B Player C 23
  • 25. Stop-and-Wait Protocol 24
  • 26. Synchronized Simulations 25
  • 27. Every player sees exactly the same states (but maybe at different time) 26
  • 28. 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. Collect Collect Game Simulate Game Simulate States States Render Render Wait Wait 27
  • 29. Clients may periodically exchange hash of game states to detect if a player has gone out- of-sync. Compare Compare Collect Collect Game Simulate Game Simulate States States Render Render Wait Wait 28
  • 30. Cheating 29
  • 31. Look-Ahead Cheat 30
  • 32. 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 31
  • 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 31
  • 34. 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 31
  • 35. Dealing with cheaters: 1. Prevent cheats (hard) 2. Detect cheats (easier) 32
  • 36. Detecting Look- Ahead Cheats 33
  • 37. “Mmm... player C always the last one that makes its move.” 34
  • 38. Time-stamp Cheat 35
  • 39. Player C (or a bot) can put in an earlier time- stamp in its messages. Player A Player B Player C 36
  • 40. Suppress-Update Cheat 37
  • 41. 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 38
  • 42. A C 39
  • 43. C stops sending update. A predicts C’s position. A 40
  • 44. C stops sending update. A predicts C’s position. A 41
  • 45. C stops sending update. A predicts C’s position. A 42
  • 46. C sends an update and shoots A. A 43
  • 47. Not my fault! My Cheater! packets were dropped.. 44
  • 48. Inconsistent Cheat 45
  • 49. Player C can send different events to different players. Player A Player B Player C 46
  • 50. With synchronous simulations, we can compare periodically the game states to detect inconsistency cheats 47
  • 51. Cheat-Proof Protocol 48
  • 52. Lock Step Protocol 49
  • 53. 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
  • 54. Lock Step Protocol 51
  • 55. Stage 1 (Commit): Everyone decide on its move x, and send f(x) to each other. Player A Player B Player C 52
  • 56. Stage 2 (Reveal): After f(x)s from all other players are received, sends x to each other. Player A Player B Player C 53
  • 57. f(x) is known as commitment to x. A player, once committed to its move, can’t change it. 54
  • 58. How does lock-step prevent: look ahead cheat? timestamp cheat? suppress-update cheat? 55
  • 59. Problem: Lock-step protocol is slow. 56
  • 60. lmax = maximum latency rmax = maximum frame (round) rate Lockstep Protocol 1/r = max{2lmax, 1/rmax} 57
  • 61. Idea: Use Interest Management Players only engaged in lock-step protocol when they influence each other. Otherwise their games proceed independently. 58
  • 62. This is known as Asynchronous Synchronization or Asynchronous Lock-step 59
  • 63. We may also stagger these two stages to improve frame rate. Multiple commitments can be sent out before we reveal the actions. Player A Player C 60
  • 64. A player can reveal its action in round i once it receives all commitment of round i from other players. Player A Player C 61
  • 65. A player can make p moves (send p commitments) without engaging in lockstep. Player A Player C 62
  • 66. This is known as Pipelined Lock-step 63
  • 67. lmax = maximum latency rmax = maximum frame (round) rate Lockstep Protocol 1/r = max{2lmax, 1/rmax} 64
  • 68. lmax = maximum latency rmax = maximum frame (round) rate Pipelined Lockstep Protocol 1/r = max{2lmax/p, 1/rmax} 65
  • 69. lmax = maximum latency rmax = maximum frame (round) rate We can pick optimal p as p = 2 lmax rmax 66
  • 70. Cheating in Pipelined Lock-step 67
  • 71. 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. Player A Player C 68
  • 72. 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. Player A Player C 68
  • 73. Fair if everyone do the same thing. But frame rate suffers. Player A Player C 69
  • 74. Fair if everyone do the same thing. But frame rate suffers. Player A Player C 69
  • 75. 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 Player A Player C 70
  • 76. 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 Player A Player C 70
  • 77. 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