(Vrtp) Design Rationale
Total Page:16
File Type:pdf, Size:1020Kb
Presented at Workshops on Enabling Technology: Infrastructure for Collaborative Enterprises (WET ICE): Sharing a Distributed Virtual Reality, Massachusetts Institute of Technology, Cambridge Massachusetts, June 18-20 1997. virtual reality transfer protocol (vrtp) Design Rationale Don Brutzman, Mike Zyda and Kent Watsen Mike Macedonia Code UW/Br, CS/Zk, CS/Wa Fraunhofer Center for Research in Naval Postgraduate School Computer Graphics Inc. Monterey California 93943-5000 USA 167 Angell Street 408.656.2149 voice, 408.656.3679 fax Providence Rhode Island 02906 USA [email protected] [email protected] 401.453.6363 voice, 401.453.0444 fax [email protected] [email protected] http://www.stl.nps.navy.mil/~brutzman/vrtp/vrtp_design.ps Abstract We propose a new protocol at the application layer, the The capabilities of the Virtual Reality Modeling virtual reality transfer protocol (vrtp). vrtp is intended to Language (VRML) permit building large-scale virtual significantly extend http in order to provide full support for environments (LSVEs) using the Internet and the World LSVE requirements by enabling a spectrum of functionality Wide Web. However the underlying network support between client-server and peer-peer, all optimized on local provided by the hypertext transfer protocol (http) is desktop computers and across the global Internet. insufficient for LSVEs. Additional capabilities for Years of effort on widely distributed interactive 3D lightweight peer-to-peer communications and network graphics applications have clearly identified networking monitoring need to be combined with the client-server issues as the critical bottlenecks preventing the creation of capabilities of http. To accomplish this task, we present a LSVEs. Those years have produced numerous important detailed design rationale for the virtual reality transfer virtual reality technologies (Durlach 95) (Zyda 93). We protocol (vrtp). vrtp is designed to support VRML in the believe the time is now right to put all of the network pieces same manner as http was designed to support HTML. Since together with all of the graphics pieces. vrtp is intended to vrtp must be highly optimized on individual desktops and accomplish this challenge. across the Internet, a Cyberspace Backbone (CBone) is also This paper presents the planned architecture of vrtp. needed for vrtp development and testing. vrtp appears to be Section 2 presents pertinent background networking a necessary next step in the deployment of all-encompassing concepts: key network capabilities for LSVEs, multicast and interactive internetworked 3D worlds. exploiting reality, the Distributed Interactive Simulation (DIS) protocol and the hypertext transfer protocol (http). Section 3 summarizes network considerations for the Virtual 1 Overview and Motivation Reality Modeling Language (VRML). Section 4 shows how an unrecognized spectrum of functionality exists between It is now possible to construct large-scale virtual client-server and peer-to-peer. Sections 5 and 6 define vrtp environments (LSVEs) comprised of internetworked and describe vrtp components: client, server, peer-to-peer graphics using the Virtual Reality Modeling Language and network monitoring. Finally Section 7 explains why a (VRML) version 2.0 (Carey 96). Such online interactive Cyberspace Backbone (CBone) will eventually be needed VRML worlds require diverse and powerful network for high-performance vrtp optimization and experimentation. capabilities to support user demands. The hypertext transfer protocol (http) (Berners-Lee 96) provides effective client- server support for many types of information transfer over 2 Background Networking Concepts the Web (Berners-Lee 94). However other types of network connections are also needed; examples include multicast Of necessity a variety of related networking topics must streaming of real-time audio, video and entity behavior data. be summarized as pertinent background for vrtp design. Furthermore these many capabilities are directly required by More detailed treatments are found in (Brutzman 95, 96b). all participants in LSVEs, rather than indirectly accessed via Four key network capabilities. Many types of separated client and server platforms. information can be distributed in a large-scale virtual 1 environment (LSVE). It is important to be able to group and partition information transfer capabilities into a small set of Light-weight Interactions. Messages composed well-defined primitives. By clearly stating network of state, event and control information as used in requirements, protocol design can efficiently and thoroughly DIS Entity State PDUs or other behavior reports. support virtual world requirements. We have found that all Implemented using unicast or multicast. Complete types of information transfer can be effectively mapped into message semantics are included in a single packet the categories listed in Figure 1 (Macedonia 94, 95) encapsulation without fragmentation. Light-weight (Brutzman 95, 96b). The primary usefulness of this interactions are received completely or not at all. approach is to clarify core requirements which need to be Network Pointers. Light-weight network resource well supported by the underlying global network for LSVEs. references, i.e. a global address space that can be Multicast and Exploiting Reality. Multicast is a crucial multicast to receiving groups. Can be cached so capability for scaling up network capabilities. Multicast that repeated queries are answered by group packets have class D Internet Protocol (IP) addresses which members instead of servers. Pointers do not permits individual packets to be routed to multiple recipients contain a complete object as light-weight without duplication on individual LANs (Deering 89). Host interactions do, instead containing only a reference machines must intentionally subscribe to a multicast address to an object. in order for incoming packets to be passed to the application. Thus multicast packets have particular strengths in Heavy-weight Objects. Large data objects minimizing bandwidth and minimizing processor cycles. requiring reliable connection-oriented Multicast capabilities are of fundamental importance when transmission. Typically provided as a web query considering networked real-time streams (Macedonia 94). response to a network pointer request. Since multicast currently uses only the User Datagram Real-time Streams. Live video, audio, DIS Protocol (UDP) and not the Transport Control Protocol behaviors, sequential graphics images or other (TCP) of the IP suite, multicast streams are a connectionless continuous stream traffic that requires real-time "unreliable" service. Lost MBone packets stay lost. No setup delivery, sequencing and synchronization. is required, no acknowledgments are used, and no guarantee Typically implemented using multicast channels. of delivery exists for this type of "best effort" service. Ordinarily this is a good thing for most real-time information Figure 1. Four key communications capabilities used streams (such as audio, video and behaviors) since it avoids in virtual environments (Macedonia 94, 95) delivery bottlenecks and unwanted overhead. Numerous (Brutzman 95, 96b). researchers are experimenting with "reliable multicast" transport protocols which try to achieve a different balance Distributed Interactive Simulation (DIS) and between reliability and potential congestion, typically by Behavior Protocols. For the past seven years, a major gaining occasional retransmission benefits without focus in networked virtual environments has been the unacceptable acknowledgment overheads (Crowcroft 96). Department of Defense's Distributed Interactive Simulation The Multicast Backbone (MBone) is one of the Internet's (DIS) standard, also know as IEEE 1278. The DIS standard most interesting capabilities since it is used for distribution (IEEE 95) describes the packet format for 27 protocol data of live audio, video and other packets (such as DIS) on a units (PDUs) specified for use in military combat global scale. In other words, the MBone interconnects the simulations. Of these only a few have general applicability. multicast capabilities of LANs across the Internet. MBone We are most interested in the widely used Entity State PDU is a virtual network because it shares the same physical (ESPDU). Entity state in this context includes linear and media as the Internet and is comprised of a network of rotational values for posture, velocity and acceleration in routers (mrouters) that support global multicast. combination with efficiently designed algorithms for dead Furthermore it is possible to partition the LSVE reckoning and track smoothing. The ESPDU is well suited communications space to exploit reality by assigning for relaying physically based model information among different communication channels to different multicast numerous interacting participants in real time. Meanwhile addresses, typically corresponding to geographic, temporal the DIS specification has been frozen and DoD development or functional areas of interest (AOI) (Macedonia 95, 96). work redirected toward a hybrid distributed client-server These considerations for reducing bandwidth and processor object broker model, the High-Level Architecture/Run-Time cycles while achieving global connectivity are critical when Infrastructure (HLA/RTI) (DMSO 96). scaling to arbitrarily large numbers of simultaneously The IEEE DIS protocol is robust and effective in interacting users on the network. multiuser environments and can