Virtual Environments: Networked Virtual Environments Anthony Steed Department of Computer Science University College London http://www.cs.ucl.ac.uk/teaching/VE
• Part I: Goals • Part II: The Internet • Part III: Strategies • Part IV: Latency and Scalability 2
DIVE “London Demonstrator”, UCL & colleagues 1999 3
IEEE Virtual Reality 2009 programme committee meeting, autumn 2008 4
Burnout Paradise, Electronic Arts 5
Nature of a Networked Virtual Environment • Multiple user – geographically distributed • More types of interactions – Passive navigation – Single object/multiple user – Multiple objects/multiple users • Voice link between participants • Heterogeneous immersion devices 6
Demands • Provide up-to-date info to all participants – Users location – Support Interactions • Minimal delay update • Support multiple message type – Simple state – Voice/video 7
Consistency and Plausibility • Goal is the illusion of a consistent shared state • Local plausibility is the appearance of consistency of only local actions (e.g. physics & collision detection appears to work) • Shared plausibility is the appearance of properties being the same as observed by users – Objects that are in the background need not be consistent – Further: only things that might be the focus of joint attention can be discussed and be different • A local implausibility might be an obvious thing to talk about! 8
• Part I: Goals • Part II: The Internet • Part III: Strategies • Part IV: Latency and Scalability 9
Introduction • Networks at the heart of networked VR • Many network protocols are out there – TCP, UDP, multicast, RTP, etc – Choice based on needs • Properties of the Internet 10
Internet Protocol - IP DHCP, DIS, DNS, FTP, HTTP, IMAP, RTP, Application SMTP, SSH, Telnet Transport TCP, UDP, RSVP Network IP, ICMP, IGMP Link Ethernet, 802.11, ADSL copper wires, fibre-optic cable, radio Physical waves 11
Internet Protocol (IP) • Any particular inter-connect might guarantee delivery – Routers can get congested, for example when incoming links carry more traffic than outgoing – Dropping packets is the right solution to congestion! • Thus IP is a best effort protocol • Every node an internet must understand IP • Every node has an IP (IPv4) address of the form – 128.16.6.8 (32 bits) 12
Routing Application Application Transport Transport Network Network Network Network Link Link Link Link 13
Transport Protocols: UDP • Connectionless – No state is maintained – No setup time – Light-weight Postal Service • No Quality of Service – No guarantee delivery – No order delivery
TCP • Connection Oriented – State is maintained at routers – Setup Handshake – Heavy-weight • Quality of Service – FIFO delivery – Flow Control – Error Recovery • Mechanisms – Timers, Acknowledgements, etc 15
Application Application Destination Source Port Destination Source Port Port = 1901 Port = 1220 = 15000 = 15001 Transport Transport Network Network Link Link narok (128.16.13.118 ) seychelles (128.16.3.52 ) 16
Network properties • Latency (Round Trip Time) – Devices take time to send data (e.g. Modems) – Data takes time to transmit (speed of light) • Jitter – Routers insert bandwidth • Bandwidth (Capacity) – Bandwidth costs money – 8Mbps is fairly standard @£8/month • Loss (Congestion, Reliability) – Routers drop packets, links do go down, routes do 17 fluctuate
Variance of inter-packet arrival times Correct spacing Gaussian distribution Observed distribution Frequency of occurrence Interpacket arrival time
Application Programming: Socket • End-point for communication • Network connections based on sockets • Socket identified by – Host address – numeric or name – Port number • 0-1023 : well known services (e.g. http traffic on 80) • 1024-49151: registered ports (less well known) • 49152-65536: private applications or dynamic use 19
Socket communication Client Listener Needs to create a socket to connect to listening sockets Needs to create a socket to listen to incoming connection requests 20
The Client/Server logic Server Client Create socket for listening Create socket for incoming connections connecting to Server Request connection Listen Accept and create thread Send/Receive Send/Receive message message 21
XVR functions Server Client NetCreateChannelTCP( ) NetAcceptTCP ( ) NetConnectTCP( ) Accept and create thread NetSendToTCP() / NetSendToTCP() / NetReceiveFromTCP() NetReceiveFromTCP() 22
• Part I: Goals • Part II: The Internet • Part III: Strategies • Part IV: Latency and Scalability 23
Architectures • Peer-to-Peer • Client/Server • Hybrid 24
Simple Peer-to-Peer DB DB •Total replicated database •Other user’s input treated locally like a second set of keyboard and mouse •Simple extension to single users •One example is DOOM from id Software 25
Multiple Peer-to-Peer •Decoupled da 26
Client-Server Architecture DB Client Server • Database on Server with Shadow Copy on Clients • Current Online Games • Some VE (MASSIVE,Deva) 27
Client-Server Architecture Server Client Client Client Client 28
Hybrid Architectures DB Server pool • Multiple servers serving different regions • Multiple service types & service layers 29
How do these architecture measure up? • Up-to-date information – Synchronisation in peer-to-peer impossible – no absolute reality! • Interaction – Client/Server provides central locus of control – constraint resolution • Consistency! 30
Consistency : Reality • GOLDEN RULE • Information propagation IS NOT instantaneous It is not possible for EVERY user to share the EXACT same state at EVERY instance 31
State Consistency: Case 1 (Total Sync) Client A Client B T = t Acknowledge every update Propagation delay is 100ms 32
State Consistency: Case 1 Client B Client A T = t + 50ms 33
State Consistency: Case 1 Delta T Client B Client A T = t + 50 ms + 100 ms 34
State Consistency: Case 1 Delta T Client B Client A T = t + 50ms + 100ms + 50ms + 100ms T = t + 300ms After 300ms Client A may move again!!! 35
State Consistency: Case 2 (Async) Client B Client A T = t Local update every 150ms Propagation delay is 100ms 36
State Consistency: Case 2 Client A Client B T = t + 100ms 37
State Consistency: Case 2 Client B Client A T = t + 150ms 38
State Consistency: Case 2 Delta T Client B Client A T = t + 250ms 39
State Consistency: Case 2 Client B Client A T = t + 300ms 40
State Consistency: Case 2 Delta T Delta T Client A Client B T = t + 400ms Inconsistency!!! 41
State Consistency: Problem • Would like to send data at the rate it is changing • Network is congested → retransmission – BUT this makes congestion more likely Update Consistency Frequency 42
State Consistency: Total Consistency Provided by Client/Server Architecture • 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 43
State Consistency: Total Consistency Pros • Guaranteed ordered event processing • Implicit ownership Cons • Latency penalty: 2 Round Trip Time • Reliability not always compatible with real-time (msg + ack) • Poor scalability – Server is bottleneck • Server is single point of failure 44
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 45
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 46
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 47
State Consistency: Predicted Consistency • Dead reckoning I Ghost A Client B Ghost B Movement Model: P(t) = P(t 0 ) + v*t P(t) = P(t 0 ) + v*t + 0.5 * a * t 2 Client A 48
State Consistency: Predicted Consistency • Dead reckoning II If new pos does not exceed error threshold then do nothing If new pos does exceed Simulation error threshold then send Client A new position 49
State Consistency: Predicted Consistency • Dead reckoning III - convergence OR T = t T = t T = t+1 T = t+2 50
Recommend
More recommend
