1 / 52

VON: A Scalable Peer-to-Peer Network for Virtual Environments

VON: A Scalable Peer-to-Peer Network for Virtual Environments. Shun-Yun Hu ( 胡舜元 ) (syhu@yahoo.com) CSIE, National Central University, Taiwan 2005/10/19. Outline. Introduction Voronoi-based Overlay Network (VON) Simulation Results Analysis Conclusion.

fathia
Download Presentation

VON: A Scalable Peer-to-Peer Network for 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. VON:A Scalable Peer-to-Peer Networkfor Virtual Environments Shun-Yun Hu (胡舜元) (syhu@yahoo.com) CSIE, National Central University, Taiwan 2005/10/19

  2. Outline • Introduction • Voronoi-based Overlay Network (VON) • Simulation Results • Analysis • Conclusion

  3. What is Networked Virtual Environment (NVE)? • Virtual Reality + Internet • 3D environment with people (avatar), objects, terrain, agents • Military simulations (’80)  Massively Multiplayer Online Games (mid-‘90) • Trends: larger scale, more realistic simulation

  4. NVE: A Shared Space

  5. Issues for Creating NVE • Consistency (events/states) • Responsiveness multiplayer • Security • Scalability • Persistency massively multiplayer • Reliability (Fault-tolerance)

  6. The Scalability Problem • Many nodes on a 2D plane ( > 1,000) • Message exchange with those within Area of Interest (AOI) • How does each node receive the relevant messages? Area of Interest

  7. A simple solution (point-to-point) N * (N-1) connections ≈ O(N2)  Not scalable! Source: [Funkhouser95]

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

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

  10. Scalability Analysis • Scalability constrains • Computing resource (CPU) • Network resource (Bandwidth) Non-scalable system vs. Scalable system Resource limit x: number of entities y: resource consumption at the limiting system component

  11. Server-cluster issues • Insufficient total resource Hardware provisioning over-provision! • High user density (crowding) User limits limits scale & realism! • Excessive inter-server communications Less load balancing difficult balance!

  12. What Next? • Strategies • Increase resource  More servers • Decrease consumption  Message filtering • Architectures Scale • Point-to-point (LAN) tens 10^1 • Client-server hundreds 10^2 • Server-cluster thousands 10^3 • ? millions 10^6 … Peer-to-Peer

  13. What is Peer-to-Peer (P2P)? [Stoica et al. 2003] • Distributed systems without any centralized control or hierarchical organization • Runs software with equivalent functionality • Examples • File-sharing: Napster, Gnutella, eDonkey • Distributed Search: Chord, CAN, Tapestry, Pastry • VoIP: Skype

  14. Peer-to-Peer Overlay A P2P overlay network source: [Keller & Simon 2003]

  15. Promise & Challenge of P2P • Promises • Growing resource, decentralized  Scalable • Commodity hardware  Affordable • Challenges • Topology maintenance  dynamic join/leave • Efficient content retrieval no global knowledge

  16. Issues for Creating P2P NVE • Consistency (events/states) • Responsiveness multiplayer • Security • Scalability • Persistency massively multiplayer • Reliability (Fault-tolerance) • Consistency (topology)  P2P NVE

  17. Related Work (1):DHT-based: SimMUD [Knutsson et al. 2004] (UPenn) • Pastry + Scribe • Regions • Coordinators (super-nodes) • Fixed-size region • Relay overhead

  18. Related Work (2):Neighbor-list Exchange [Kawahara et al. 2004] (Univ. of Tokyo) • Fully-distributed • Nearest-neighbors • List exchange • High transmission • Overlay partition

  19. Related Work (3): Mutual Notification: Solipsis [Keller & Simon 2003] (France Telecomm R&D) • Links with AOI neighbor • Mutual cooperation • Inside convex hull • Potentially slow discovery • Inconsistent topology

  20. Outline • Introduction • Voronoi-based Overlay Network (VON) • Simulation Results • Analysis • Conclusion

  21. Design Goals • Observation: • for virtual environment applications, the contents we want are messages from AOI neighbors • Content discovery is a neighbor discovery problem • Solve the Neighbor Discovery Problem in a fully-distributed, message-efficient manner. • Specific goals: • Scalable  Limit & minimize message traffics • Responsive  Direct connection with AOI neighbors

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. Dynamic AOI Crowdingwithin AOI can overload a particular node It’s better if AOI-radius can be adjusted in real time

  28. Adjustment Conditions • AOI-radius decrease • Number of connections > connection limits • AOI-radius increase • Maximum connections not exceeded • Current AOI-radius < preferred AOI-radius • Mutual awareness rule • Do not disconnect a neighbor who sees me

  29. Demonstration Simulation video • General movements (40 nodes, 800x600 world) • Local vs. global view • Dynamic AOI adjustment

  30. Outline • Introduction • Voronoi-based Overlay Network (VON) • Simulation Results • Analysis • Conclusion

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

  32. Consistency Metrics • Topology Consistency [Kawahara, 2004] observed AOI neighbors actual AOI neighbors • Drift Distance [Diot, 1999] Distance between observed position and actual position (average over all nodes)

  33. Scalability: Avg. Transmission / sec

  34. Scalability: Max. Transmission / sec

  35. Scalability: Avg. Neighbor Size

  36. Consistency: Topology Consistency

  37. Consistency: Drift Distance

  38. Reliability: Effects of Packet Loss

  39. Outline • Introduction • Voronoi-based Overlay Network (VON) • Simulation Results • Analysis • Conclusion

  40. Analysis of Design Scalability • Bounded resource consumptiondynamic AOI Consistency (Topology) • Topology is fully connected enclosing neighbors Reliability • Self-organizing  distributed neighbor discovery Responsiveness • Lowest latency  direct connection, no relay

  41. P2P NVE Comparisons

  42. Problems of Voronoi Approach • Message traffic • Circular round-up of nodes • Redundant message sending (inherent to fully-distributed design) • Incomplete neighbor discovery • Can happen with inconsistent / incorrect neighbor list • Fast moving node • Limited AOI • Direct connections

  43. Outline • Introduction • Voronoi-based Overlay Network (VON) • Simulation Results • Analysis • Conclusion

  44. Summary • NVE scalability is achievable with P2P architecture and is a neighbor discovery problem • A promising solution: Voronoi-based P2P Overlay • Leverage knowledge of each peer to maintain topology • Properties • Scalable: fully-distributed, dynamic AOI • Efficient: low irrelevant messages, zero relay • Simple: simple protocol and procedure

  45. Potential Applications • Online games Position updates in current MMOGs, Voice-chats • Military Enable large-scale, affordable military training simulation • 3D Web Provide multi-user interactivity to static 3D world • Scientific simulations Distribute spatial simulation requiring frequent synchronization

  46. Future Perspectives • Short-term • Distributed event/state consistency • Customizable AOI (Heterogeneity in P2P) • Recovery from overlay partition and fast-moving nodes • Long-term • Persistency issue (P2P-based database) • Security issue (protection from malicious nodes) • 3D content distribution (3D streamingon P2P) Massive, persistent 3D environment sharable by all!

  47. Acknowledgements • Dr. Jui-Fa Chen (陳瑞發老師) • Tsu-Han Chen (鄭子涵) • Members of the Alpha Lab, TKU CS • Dr. Chin-Kun Hu (胡進錕老師) • Guan-Ming Liao (廖冠名) • LSCP, Institute of Physics, Academia Sinica • Joaquin Keller (France Tele. R&D, Solipsis) • Jon Watte (there.com) • Kuan-Ta Chen (陳寬達, NTU)

  48. Q&A Thank you! syhu@yahoo.com http://vast.sourceforget.net (http://vast.sf.net)

  49. Inconsistency caused by dAOI

More Related