1 / 69

Scalable Peer-to-Peer Virtual Environments

Shun-Yun Hu ( 胡舜元 ) (syhu@csie.ncu.edu.tw) ‏ CSIE, National Central University, Taiwan 2008/05/08. Scalable Peer-to-Peer Virtual Environments. M assively M ultiplayer O nline G ames. MMOGs are growing quickly Multi-billion dollar industry

yehuda
Download Presentation

Scalable Peer-to-Peer Virtual Environments

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. Shun-Yun Hu (胡舜元) (syhu@csie.ncu.edu.tw)‏ CSIE, National Central University, Taiwan 2008/05/08 Scalable Peer-to-Peer Virtual Environments

  2. Massively Multiplayer Online Games • MMOGs are growing quickly • Multi-billion dollar industry • 10 million subscribers for World of Warcraft • 600,000 concurrent users, but 3,000 per world • Can we scale to millions in the same world?

  3. Imagine you start with a globe

  4. Zoom in…

  5. To Phoenix..

  6. and Hyatt..

  7. Right now it’s flat…

  8. But in the near future…

  9. Virtual Environments (VEs): A Shared Space

  10. Issues for Creating VEs • Consistency • Interactivity multiplayer • Security • Scalability • Persistency massively multiplayer • Reliability

  11. Model for virtual worlds • Many nodes on a 2D plane • Message exchange with those within Area of Interest (AOI)‏ • How does each node receive the relevant messages? Area of Interest

  12. A simple solution (point-to-point)‏ But…too many irrelevant messages N * (N-1) connections ≈ O(N2) Not scalable! Source: [Funkhouser95]

  13. A better solution (client-server)‏ Message filtering at serverto reduce traffic N connections = O(N) server is bottleneck Source: [Funkhouser95]

  14. Current solution(server-cluster)‏ Still limited by servers. Expensive to deploy & maintain. Source: [Funkhouser95]

  15. The Problem • Client-server: resources limited by provisioning Resource limit [Funkhouser95]

  16. The Solution • Peer-to-Peer: resources grow with demand Resource limit [Keller & Simon 2003]

  17. Voronoi-based Overlay Network (VON)‏

  18. Design Goals • Observation: • for virtual environment applications, the contents we want are messages from AOI neighbors • Content discovery is a neighbor discovery problem • Specific goals: • Scalable  Limit per-node message traffic • Responsive  Direct connection with AOI neighbors

  19. If you talk with your AOI Neighbors directly… But how to discover new neighbors?

  20. Voronoi Diagram • 2D Plane partitioned into regions by sites, each region contains all the points closest to its site • Can be used to find k-nearest neighbor easily Neighbors Region Site

  21. Circle Area of Interest (AOI)‏ White self Yellow enclosing neighbor (E.N.)‏ L. Blue boundary neighbor (B.N.)‏ Pink E.N. & B.N. Green normal AOI neighbor L. Green unknown neighbor Design Concepts Use Voronoi to solve the neighbor discovery problem • Identify enclosing and boundary neighbors • Each node constructs a Voronoi of its neighbors • Enclosing neighbors are minimally maintained • Mutual collaboration in neighbor discovery

  22. Procedure (JOIN)‏ 1)Joining node sends coordinates to any existing node Join request is forwarded to acceptor 2)Acceptorsends back its own neighbor list joining node connects with other nodes on the list Joining node Acceptor’s region

  23. Procedure (MOVE)‏ 1) Positions sent to all neighbors, mark messages to B.N. B.N. checks for overlaps between mover’s AOI and its E.N. 2) Connect to new nodes upon notification by B.N. Disconnect any non-overlapped neighbor Non-overlapped neighbors Boundary neighbors New neighbors

  24. Procedure (LEAVE)‏ 1) Simply disconnect 2) Others then update their Voronoi new B.N. is discovered via existing B.N. Leaving node (also a B.N.)‏ New boundary neighbor

  25. Demonstration Simulation demo • Random movements (100 nodes, 1200x700 world)‏ • Local vs. global view • Dynamic AOI adjustment

  26. Simulation Method • C++ implementation of VON (open source VAST library) • World size: 1200 x 1200 (AOI: 100) • Trials from 200 – 2000 nodes • Connection limit: 20 • 3000 time-steps (~ 300 simulated seconds, assuming 10 updates/seconds) • Behavior model • Random movement: random destination • Constant velocity: 5 units/step • Movement duration: random (until destination is reached)

  27. Scalability: Avg. Transmission / sec

  28. Scalability: Max. Transmission / sec

  29. Scalability: Avg. Neighbor Size

  30. Reliability: Effects of Packet Loss

  31. Voronoi State Management (VSM)‏

  32. Voronoi State Management • VON deals only with positions, but we want to manage states stored in spatial objects (with x, y). • Let game states be managed by all clients • Each client has two roles: peers & arbitrators • i.e. Voronoi partitioning • Three problems: • O(n2) connections at hotspots • Some cells have large sizes • Constant ownership transfer

  33. VSM: solution ideas • Connection overload →Aggregators clustering • Large cell-size →Virtual peers incremental transfer • Constant transfers → Explicit ownership transfer

  34. VSM: Consistency control • Managing arbitratorreceives and processes events • Events are forwarded if necessary • Updates sent to affected arbitrators, then peers

  35. VSM: Load balancing • Traditional: high-capacity nodes first, then adjust • VSM: low-capacity nodes first, then cluster • Overload: ask for aggregator, submit control • Underload: disintegrate, release control

  36. VSM: Load balancing (2)‏ • Sphere of control adjustable • More than one aggregator → choose nearest

  37. VSM: Fault tolerance • Regular arbitrator: • Pick backup arbitrator, backup states • Backup transfers ownership to enclosing arbitrators • Aggregators: • Pick backup aggregators • Take over original if failed • Choose new backup

  38. Peer-to-Peer 3D Streaming

  39. Background • MMOGs today need CD installation (too slow!)‏ • But 3D data is huge • Content streaming is needed • 80% - 90% content is 3D (e.g., 3D streaming)

  40. 3D streaming • Object streaming [Hoppe 1996] • base • refinements • Scene streaming [Teler & Lischinski 2001] • multiple objects • object selection & prioritization

  41. 3D streaming vs. media streaming • Video / audio media streaming is very matured • User access patterns are different for 3D content • Highly interactive  Latency-sensitive • Behaviour-dependent  Non-sequential • Analogy • Constant & frequent switching of multiple channels

  42. Benefits of peer-to-peer • Scalable • Growing amount of total resources • Affordable • Commodity PCs • Feasible • Better client hardware (CPU, broadband networks)‏ • Availability of user-hosted machines

  43. Challenges for P2P 3D streaming • Appropriate peer grouping • Matching interests / needs • Matching capabilities • Dynamic group management • Interest groups are dynamic (non-sequential) • Real-time constraints (latency-sensitive) • Minimal server involvement • Visibility determination (object selection) • Request prioritization (piece selection)

  44. Observation • Limited & predictable area of interest (AOI)‏ • Overlapped visibility = shared content

  45. overlapped visibility = shared content

  46. Download content from AOI neighbors star: self triangles: neighbors circle: AOI rectangles: objects

More Related