Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Managing Dynamic Shared state


Published on

  • Be the first to comment

  • Be the first to like this

Managing Dynamic Shared state

  1. 1. Managing Dynamic Shared Space In Networked Virtual Environments Pallav Dhobley 09005012 Vihang Gosavi 09005016 Aditya Gupta 09005017 Ashish Yadav 09005018
  2. 2. Contents:• Introduction & Motivation• Dynamic Shared State• Consistency-Throughput tradeoff• Managing Shared States• Conclusion• References
  3. 3. Introduction & Motivation• The fundamental goal of a net-VE is to provide user with the illusion that they are all seeing the same things and interacting with each other within that virtual space
  4. 4. What is Dynamic Shared State?• Dynamic information maintained by multiple hosts about net-VE• Common context• Makes VE truly “realistic” & “multi-user”• Managing it is the most challenging part of building a net-VE
  5. 5. Virtual World Virtual World Model of Player1 Model of Player2 Player1 Player2 State change and Interaction event messagesNetwork
  6. 6. The Problem Throughput • Consistency-Throughput Tradeoff: – the fundamental rule of net-VE sharedReal-time Scalable state: “it is impossible to allow dynamic shared state to change frequently and Reliable guarantee that all hosts simultaneously access identical Constancy versions of that state.” We can either have a Dynamic world or a consistent world, but not both.
  7. 7. Managing Shared States More Consistency• Shared Repositories – All from the same well (Data Server)• Blind Broadcasting – Talk a lot! (Network Messages)• Dead Reckoning – Predict the future! (State estimation) More Dynamic
  8. 8. Shared Repositories• Maintaining shared state in centralized repositories• Using “lock” on data to ensure synchronizationThree techniques of centralised repositories :1. Shared file directory2. Repository in server memory3. Distributed repository/ Virtual repository
  9. 9. Shared file Directory• Directory containing files that hold shared states. – Absolute Consistency! – One host can write data to same file at a time – Scalability issues – Slow! 
  10. 10. Shared file Directory
  11. 11. Server memory• Server process which simulates the behavior of distributed file system – Faster than Shared File Directory – No need of locks, server arbitrates – Server-single point of failure – Bottleneck: Server Bandwidth – Need to maintain constant connection
  12. 12. Server memory
  13. 13. Virtual Repository• Hosts communicate directly with each other following a protocol of information sharing – Reduced bottleneck at server – Better fault tolerence – “Eventual” consistency
  14. 14. Virtual Repository
  15. 15. Blind Broadcasting• Asynchronous broadcasting of owned states at regular intervals• Clients cache the most recent update• Frequency compensates for data-lost.• Explicit Object ownership• Filter: Broadcast to those who are “seen” – VEOS epidemic approach: send-to-neighbors
  16. 16. Blind Broadcasting• Can support a larger number of users at a higher frame rate and faster response time.• Simple to implement• Jitter may lead to “jerky” visual behavior
  17. 17. Dead Reckoning• Transmit state updates less frequently by using past updates to estimate the shared state• Prediction: Estimation of current state based on previously received packets• Convergence: correction of estimated state on arrival of new packet
  18. 18. Dead Reckoning• No need of central server• Trading accuracy of shared state for more scalability
  19. 19. Dead Reckoning• Prediction: – Using derivative polynomials • Zero order derivative f(t+t0) = f(t) where f(t) is location at time “t” • First order derivative f(t+t0)=f(t)+v(t)*t0 where v(t) is velocity at time “t” • Hybrid polynomial
  20. 20. Dead Reckoning• Convergence: Algorithms – Zero order • Jumping from predicted position to corrected position – First order • Linear transition from predicted position to actual position• Choice of convergence algorithm may vary with the requirements
  21. 21. Dead Reckoning• Reduces bandwidth requirements• Can support large number of players• Calculations are done at the host, independently• Complex to develop and implement• Not all hosts share the identical state about each entity
  22. 22. Conclusion• Choice of shared share maintenance technique is a task that must balance a variety of issues including – Bandwidth – Computation – Latency – Data consistency – Reproducibility
  23. 23. Conclusion(ctd)• Shared state maintenance is governed by the consistency throughput tradeoff
  24. 24. References• Singhal, Sandeep and Zyda Michael. Networked Virtual Environments, New York: ACM Press. PP. 101-146• Zona Inc., and Executive Summary Consulting Inc, “State of MMOG 2002”, October 2002• Anupam, V., and C. Bajaj. Distributed and collaborative visualization , IEEE Multimedia 1(2):39-49,Summer 1994.• National Taipei University• Carlsson,C., and O. Hagsand. DIVE- A platform for multi- user virtual environments. Computers and Graphics 17(6):663:669 November-December 1993.