LSVE: A Network Perspective

1. LSVE: A Network Perspective Manuel Oliveira Computer Science Department University College London

2. Problem Domain

3. Problem Domain

4. Contents • Architectures • Peer to Peer • Client/Server • Distributed • State Consistency • Total Consistency • Eventual Consistency • Predicted Consistency • Discussion

5. Architectures: Scenario • 15 frames per second • 1 packet per frame • Packet is DIS state PDU = 144 bytes (1152bits) • No packet loss -> no retransmission

6. Architectures: Peer to Peer • Total Replicated Database • Simple Extension to Single Player Users • Initial Multi-Participant Virtual Environment

7. Architectures: Peer to Peer

8. Architectures: Peer to Peer Analysis • Bandwidth = 2 * (n - 1) players * 1152 * 15 • For 2 you get 34560 bps = 35 Kbps • For 8 you get 241920 bps = 242 Kbps • Most modems are 56 Kbps • Computation Resources • You need (n-1) * state of one player • You need CPU cycles to process at least 2 * (n-1) packets • Latency Impact (CPU processing and network)

9. Architectures: Client/Server Client Server • Database on Server with Shadow Copy on Clients • Current Online Games • Some VE (MASSIVE, RING, Internet based)

10. Architectures: Client/Server Server Client Client Client Client

11. Architectures: Client/Server Analysis • Bandwidth = 2 * n * 1152 * 15 • For 2 you get 69120 bps = 69 Kbps • For 8 you get 276480 bps = 276 Kbps • Bottleneck is at server (capacity/ n) • Computation Resources • You need n * state of one player • You need CPU cycles to process at least 2 * n packets • Latency Impact (twice CPU processing and network)

12. Architectures: Distributed • Total Replicated or Partial Database • Most Virtual Environments (DIVE, NPSNET)

13. Architectures: Distributed

14. Architectures: Distributed Analysis • Bandwidth = (n - 1) * 1152 * 15 • For 2 you get 17280 bps = 17 Kbps • For 8 you get 120960 bps = 121 Kbps • Computation Resources • You do not keep network state of remote players • You need CPU cycles to process at least n-1 packets • Latency Impact (CPU processing and network)

15. Architectures: Comparison P2P C/S D 2 players 35 69 17 BW Kbps 8 players 242 276 121 State n-1 n 0 CR Process 2(n-1) 2n n-1

16. It is not possible for EVERY user to share the EXACT same state at EVERY instance State Consistency: Reality GOLDEN RULE Information propagation IS NOT instantaneous

17. State Consistency: Case 1 Client B Client A T = t Acknowledge every update Propagation delay is 100ms

18. State Consistency: Case 1 Client B Client A T = t + 100ms

19. State Consistency: Case 1 Delta T Client B Client A T = t + 200ms

20. State Consistency: Case 1 Delta T Client B Client A T = t + 300ms After 300ms Client A may move again!!!

21. State Consistency: Case 2 Client B Client A T = t Update every 150ms Propagation delay is 100ms

22. State Consistency: Case 2 Client B Client A T = t + 100ms

23. State Consistency: Case 2 Client B Client A T = t + 150ms

24. State Consistency: Case 2 Delta T Client B Client A T = t + 250ms

25. State Consistency: Case 2 Client B Client A T = t + 300ms

26. State Consistency: Case 2 Delta T Delta T Client B Client A T = t + 400ms Inconsistency!!!

27. State Consistency: Problem • Network propagation > 100ms • Network is congested -> retransmission • Players >> 2 Consistency Update Frequency

28. State Consistency: Total Consistency Client/Server • Server controls total consistency of database • Communication is reliable • Each Client reads from Server • Client sends updates to Server (dirty cache) • Events are totally ordered • Tuple Space • Total replication of the database • Total consistency provided by infrastructure

29. State Consistency: Total Consistency Cons/Pros • Guaranteed ordered event processing • Implicit ownership • Latency penalty: 2 RTT • Reliability not always compatible with real-time (msg + ack) • Poor scalability Client/Server • Simple programming model • Server is bottleneck • Server is single point of failure Tuple Space • Infrastructure kills real-time

30. State Consistency: Eventual Consistency • Clients just send periodic updates • Discrepancy is tolerated if: • Does not exceed a given time threshold • Does not dramatically a perceptual error threshold • Clients do not need acknowledgements • A client is unawares of other clients • Inconsistency inversely proportional update frequency

31. State Consistency: Eventual Consistency • Pros: • Minimum latency • No infrastructure -> reduced processing overhead • Simple to upgrade a single user system to multi users • No bottleneck • Fault tolerant (no packets -> remove entity) • Cons: • Explicit ownership • Bandwidth hungry (high frequency for low inconsistency) • Better scalability but still poor

32. State Consistency: Predicted Consistency Facts: • Users are not aware of other users • Total consistency is not a requirement • But eventual consistency has problems • Possible solution: • Dead reckoning • High level behaviours

33. State Consistency: Predicted Consistency • Dead reckoning I Ghost A Client B Ghost B Movement Model: P(t) = P(t0) + v*t P(t) = P(t0) + v*t + 0.5 * a * t2 Client A

34. If new pos does not exceed error threshold then do nothing If new pos does exceed error threshold then send new position State Consistency: Predicted Consistency • Dead reckoning II Simulation Client A

35. OR T = t T = t+1 T = t+2 State Consistency: Predicted Consistency • Dead reckoning III - convergence T = t

36. State Consistency: Predicted Consistency • High level behaviours (Games) Position B Position A • At each game interval send current position packet • If path takes 30 seconds and game tick is 10 per second • You have 300 packets being sent

37. State Consistency: Predicted Consistency • High level behaviours (Games) Position B Position A • Just send Destination Position B • Use path finding to compute best path • Not all users will see same path • But all will see final result • Send 1 packet only with parameters

38. Discussion