1 / 38

Understanding Network Architectures for Virtual Environments: A Consistency Perspective

This document explores various network architectures for virtual environments, including Peer-to-Peer, Client/Server, and Distributed systems. It analyzes performance metrics like bandwidth, computation resources, and latency impacts across different user scenarios. It discusses state consistency types—Total, Eventual, and Predicted consistency—and their implications on network performance. The findings highlight the trade-offs between consistency guarantees and network efficiency, providing a comprehensive view for developing robust virtual environments that can accommodate multiple players.

mele
Télécharger la présentation

Understanding Network Architectures for Virtual Environments: A Consistency Perspective

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related