Author S Guide for 2009 Spring SIW Conference
Total Page：16
File Type：pdf, Size：1020Kb
A Javascript Implementation of the Binary DIS Protocol
Don McGregor Curtis Blais Don Brutzman MOVES Institute, Naval Postgraduate School 700 Dyer Road Watkins Ext. 265 Monterey, CA 93943 (831) 656-7605, (831) 656-3215, (831) 656-2149 [email protected], [email protected], [email protected]
Keywords: Javascript, Distributed Interactive Simulation, DIS, Websocket, Web-based Simulation, WebLVC
ABSTRACT: Simulation applications running in a web browser offer the potential for simplified simulation management and distribution. The Websocket and WebRTC standards allow applications running in web pages to communicate with the server, or even directly with other web pages, but a format to use for message exchange in distributed simulations has not been widely agreed upon. Javascript Object Notation (JSON) text format has been used by some applications, but retaining interoperability creates a requirement for standardizing a JSON message format for simulation applications. We have implemented a Javascript library that instead uses the IEEE standard Distributed Interactive Simulation (DIS) binary format, and that runs in all recent major browsers. The DIS binary Javascript library is able to process up to several thousand Protocol Data Units (PDUs) per second. The library simplifies the integration of existing simulation applications with web based simulation applications.
1. Background Distributed simulation applications must exchange state information and the Websocket and WebRTC For the last decade or more business applications have Javascript APIs are a mechanism to allow this. The two been migrating away from the paradigm of installing APIs resemble, respectively, the TCP sockets and UDP applications on desktop machines and towards web- sockets used in conventional desktop simulation based applications running in the web browser. This applications. As with conventional TCP/IP socket began with simple applications that were easy to programming, the API is silent about the format or migrate to HTML, and the advent of Asynchronous content of the messages passed. It is up to the Javascript and XML (AJAX), fast browser Javascript programmer to choose a format to pass simulation state language implementations, and HTML5 technologies information, and cooperating applications must agree have accelerated the process. The economics are to use a mutually intelligible message format. On the compelling: applications can be deployed once on the desktop a number of APIs and protocol wire formats server side, run in ubiquitous web browsers that are have been adopted for simulation applications, already installed, and can scale out on the cloud. The including Distributed Interactive Simulation (DIS), web applications are often cross platform across High Level Architecture (HLA), and Test and Training Windows, Unix, Apple OS X, and mobile devices. Enabling Architecture (TENA). Web-based simulation However, Distributed simulation applications, because applications are still in their infancy and formats for of their demanding requirements for low latency, exchanging information have not yet been widely graphics, and computation, have generally not shared adopted or standardized. For example, HLA has no in this trend. This is likely to change as new Javascript API and the lack of an interoperable over- technologies such as WebGL [1], Websockets, [2] and the-wire network format means that various proprietary WebRTC [3] are deployed more widely. WebGL binary encodings cannot be consistently sent or enables the creation of 3D virtual simulations, and received. websockets and WebRTC allow applications access to high bandwidth, low latency networking, relative to In the absence of a standard method for exchanging older polling technologies such as AJAX. Faster web state information most web-based simulation browser Javascript engines and more sophisticated applications have used the Javascript Object Notation Javascript libraries are also enabling more capable web (JSON) format. JSON is human-readable, text-based, applications. This can allow Live, Virtual, and and lightweight format for describing the content of Constructive (LVC) applications to be run entirely Javascript objects. A parser to convert data in the within a web page, using no other applications or JSON format to Javascript objects is included in most plugins. Javascript implementations; this feature makes it easy to rapidly prototype and implement message exchange. An example representing an update to the state of an Javascript applications adopted the JSON format in entity using JSON format is shown in figure 1. part because Javascript, as a language, did not do the sort of binary manipulations required to encode and { decode binary messages well. However new Javascript MessageKind : 1, API features have made it more practical to encode and ObjectName : “F-16 Alpha”, decode the packed binary messages used by DIS. The ObjectType : Javascript Typed Array API [5] feature allows “WebLVC:PhysicalEntity”, programmers to encode and decode packed byte arrays. EntityIdentifier : [1,2,1], This gives programmers the tools to implement binary EntityType : [1,2,225,1,3,0,0], protocols such as DIS. WorldLocation : [4437182.0232, -395338.0731, 873923.4663], Javascript web programming is always an adventure in VelocityVector : [57.04, 32.77, cross platform compatibility; Javascript language 89.263], implementations are embedded in the web browser, Orientation : [-1.65, 2.234, browser vendors add new APIs at different times, and -0.771], the browser version deployed at customer sites may lag Marking : “F-16”, from the most recent released version. Deployed browser support for the Typed Array API in various DamageState : 0 } browsers is shown in figure 2 [6]. These browsers Figure 1. DIS Object Update Expressed in JSON account for about 80% of the browsers in use on the Format internet in general today, though specific market segments such the Navy-Marine Corps Internet This example is taken from the WebLVC SISO study (NMCI) may have less support. For the most part web group [4], an effort to standardize message exchange browsers released since 2011 or 2012 support the formats using JSON that is closely patterned on the feature. In any event as browsers are upgraded support Real Time Platform Reference Federation Object will steadily increase. Model (RPR-FOM). Fields in the example include the semantic information specified in the SISO Encoded Internet Firefox Chrome Safari Bit Values (EBV) document, such as the entity type, Explore and other conventions such as the entity location, r expressed in the earth-centered, Cartesian world Supported 10.0 4.0 7.0 5.1 location used by DIS and RPR-FOM. Since Version JSON has surprisingly good performance, but also has some unavoidable drawbacks. Because its design goals Figure 2. Web Browser Support for Typed Arrays include being human readable it uses text to describe the contents of objects. Because of the tag-value The JSON format is workable, but the DIS binary approach used by JSON, both the sender and receiver format has a significant practical advantage: the must agree on the field names used in the messages. standard has already been approved. If it can be Including the field name in the message takes more implemented in Javascript then practitioners may be space, but does allow the application code to be more able to avoid creating a new wire protocol standard. flexible when the format is still in flux. Using JSON Support for the DIS standard is also ubiquitous. Many effectively requires the standardization of a text format existing simulation applications directly support DIS, wire protocol of the sort discussed by WebLVC. and for those that don’t, there are usually protocol gateways that can convert application state information DIS takes a different approach: the simulation state to the DIS format. This simplifies interoperability with values are saved in an array of packed binary values. existing applications. The fields in the message are not tagged with a name, but instead use the position of fields in the message, as The task we set ourselves was to implement the DIS specified by the protocol external to the message. The protocol in Javascript. The potential outcome is web messages sent in a binary protocol are typically smaller simulation applications that can directly interoperate than the same information sent in JSON format, and in with existing simulation applications in an efficient principle are more efficient to encode and decode, way, without the extra layer of a syntactic binary-to- since the data does not need to be converted between JSON gateway and the requirement to create a new text format and a binary representation. As a result the standard. Implementing DIS in Javascript also allows messages are more compact, and in theory fewer CPU us to explore the current state of the art and tradeoffs in instructions can be used to decode them. In the Javascript protocol implementations. example shown in Figure 1, the update message takes about 300 bytes of text, while a DIS entity state 2. Implementation Protocol Data Unit (PDU) (which carries similar though different data) takes about 144 bytes. 2.1 Client Side We implemented the Javascript version of the DIS websocket.send(trimmedData); library using the Open-DIS project [7]. Open-DIS Figure 4. Encoding and Sending an Entity State contains an XML file that describes the fields, types, PDU Object and layout of the DIS version 6 and 7 PDUs. The code to implement a PDU is mostly boilerplate. The This example writes data to a typed data buffer that is Javascript object PDUs must be able to marshal and large enough to allow it to hold any likely Entity State unmarshal themselves to the IEEE 1278.1 DIS standard PDU used in this context. After it is written to a binary binary format, and the data fields of the DIS PDUs buffer and we know how much space it consumes we must be accessible to other Javascript code. With the create an array that is trimmed to fit the actual size of information contained in the XML file a relatively the PDU, and then send it to the websocket server. small Java program can generate the corresponding Javascript code that implements DIS PDUs and the Different languages have different conventions for code to marshal and unmarshal to DIS. The code, for accessing object values. The most common Javascript both the generator and the generated Javascript code, is programming convention is to not use getter or setter available at sourceforge.net and has a non-viral BSD methods, and to instead access an attribute directly open source license. using dot notation, such as entityStatePdu.entityLocation. We Example code for creating and decoding an Entity adopted this convention in our Javascript DIS State PDU from a binary source in Javascript is shown implementation in order to be aligned with industry in figure 3. practice. Since the Javascript code is generated, the code generator can be modified to adopt other websocket.onmessage = function(msg) programming conventions if so desired. { var disMessage = Reducing web application page load time and new dis.EntityStatePdu(); optimizing web applications can be a subject in and of var is = itself. The generated DIS protocol file is about 10,000 new dis.InputStream(msg.data); lines of Javascript code and has a size of about 400K. disMessage.initFromBinaryDIS(is); The Javascript DIS code must be downloaded to the web browser on page load. Application programmers Figure 3. Creating an Entity State PDU from in a production environment often run their Javascript Binary Data files through a “minify” step that strips out code comments, eliminates whitespace, and takes other steps This shows the Websocket API’s onmessage() to reduce the size of the file. This will usually reduce function, which passes in an argument containing data the size of the Javascript file by half or more. The web received from the websocket server. The Javascript browser and web server can also negotiate compression object passed as an argument has a property called of the Javascript file before sending it, which will data, which contains the binary PDU data in IEEE reduce the size further. A minified and compressed 1278.1 DIS format. A new Entity State PDU is created, DIS protocol implementation is about 20K bytes. The and then initialized from an InputStream object. server and browser can negotiate client-side caching techniques that prevent repeated downloads of the file The InputStream (and its converse, OutputStream) are from the web server; after the first download the modeled on the Java standard library classes of the Javascript DIS implementation file is cached by the same name. They read data from the binary Typed web browser using local storage, and subsequent page Array and maintain a pointer to the current read loads by any web applications that access the position in the binary buffer. As each value is read the Javascript resource do not have to retrieve the file from current read pointer advances by the size of the data the server. The Javascript resources can also be stored type just read. on a Content Distribution Network (CDN) to reduce load times. The initFromBinaryDIS() function is written by the Javascript code generator, as is the reverse It should be noted that the Javascript language uses function, encodeToBinaryDIS(). For example to weak data typing, and that “classes” in Javascript do encode an EntityStatePdu to a DIS PDU format the not exist in the same sense as they do in Java or C++. code in figure 4 would be used. Javascript is a prototypical object language with weak (or non-existent) typing. Object instances are just var dataBuffer = new collections of attribute-value pairs. Creating a new ArrayBuffer(1000); instance of a “class” in Javascript creates an object var os = with a certain starting set of attributes, and attributes or new dis.OutputStream(dataBuffer); functions can be added to or removed from that espdu.encodeToBinaryDIS(os); instance. For example the EntityStatePdu object var trimmedData = created above may have completely new attributes dataBuffer.slice(0, added to it, such as a date attribute called “lastHeardFrom,” and it may have existing attribute os.currentPosition); values such as “entityLocation” removed. This means two objects that were instantiated as EntityStatePdus network. The Jetty server acts as a hub for all traffic to may not have identical data fields or functions after use the web-connected clients. This can provide a central in the application program. This is in contrast to Java, point for performing area of interest management or where all instances of a class must have the same distributed data management, but the ability to do this attributes and all share the same methods. is unexplored for now.
Receiving and decoding DIS PDUs on the client side Websockets are in fact TCP sockets with a slightly and being able to send IEEE 1278.1 compliant PDUs is different API, and have all the inherent advantages and only part of the battle. The client must also make sense disadvantages of any other TCP socket. This means of the entity position value decoded. DIS uses a that while they are reliable, they also have on average Cartesian, geocentric coordinate system with its origin higher jitter, and may have “freeze” periods if state at the center of the earth to describe object locations. update packets are dropped and the websocket goes Many applications must position entities using other through a timeout/resend cycle. coordinate systems, such as latitude, longitude, and altitude. Virtual worlds typically use a local coordinate 3. Results system set up on a plane tangent to a given location on the earth’s surface. In Java or C/C++ language 3.1 Performance Benchmarks environments we could make use the SEDRIS Spatial Reference Model (SRM) software development kit It is important to benchmark performance on multiple (SDK) [8], but there is as of yet no Javascript browsers because each browser has its own implementation of this valuable tool. We were forced implementation of a Javascript engine and Javascript to implement a few classes that do basic standard libraries, and results can vary dramatically. transformations among earth-centered (geocentric) Javascript engine performance has been the subject of coordinate systems, local tangent plane cartesian intense R&D over the last several years and most coordinate systems, and latitude/longitude/altitude current browsers implement some version of a hotspot coordinate systems. compiler/interpreter. Most commercial browsers currently implement a Just-In-Time (JIT) compiler for 2.2 Server Side Javascript, but implementing JITs is challenging and performance characteristics can vary. When and For the server implementation we used Jetty, a whether the JIT actually optimizes code can also configurable Java-based implementation of a web depend on code characteristics for even micro server and servlet container. It can also implement Java benchmarks. This means making general claims of Server Pages (JSP) and act as a websocket server side performance in all web browsers difficult. At best only implementation. The Jetty server listens on the server’s general outlines can be described, and even that may be local network on a Java UDP socket for DIS traffic. deceptive. When a PDU is received it sends it out on each connected websocket to a web page, as shown in figure A series of test cases to compare the performance of 5. JSON and binary DIS formats has been made available at a public site [9], and users can benchmark their own browser and hardware there. The results are shown below in figures 6 and 7.
Figure 5. Relay of DIS Messages Figure 6. Performance Benchmark Results The Semi-Automated Forces (OneSAF) application shown in the diagram represents an existing, unmodified DIS application; PDUs will be read by the Jetty server via the native UDP socket and then forwarded to each recipient. Likewise, the web pages can send DIS PDUs, and the Jetty server will distribute them to other web pages and to the server’s native Figure 7. Performance Benchmark Results
Longer bars in figure 4 represent better performance. Chrome, Netscape Firefox, Internet Explorer 11 (Labeled as “Other” above), and Safari running on a OSX Laptop, Windows 8.1 laptop, Samsung Note 2 tablet, and on an iPhone 5 mobile device were tested. The blue and red bars are the results for decoding binary DIS. Blue bars show the results for decoding into a complex Javascript Entity State PDU (ESPDU) object that contains separate objects for fields such as the entity type, entity location, and other records, while Figure 8. DIS vs WebLVC Update Message red shows results for decodes into a Javascript object that is “flattened” with no contained objects, just This repeats the results of the earlier Chrome uniquely named fields. Orange and green bars show the benchmark—JSON and binary were both decoded results for two techniques of decoding JSON-formatted about as fast. The WebLVC JSON message was DIS information. Orange represents the use of decoded much faster than either, probably a reflection eval(jsonText), while green uses of the smaller number of Javascript objects created and less information contained in the message. JSON.parse(jsonText). Eval() is an older technique for parsing JSON that is still fairly widely The low level benchmarks used here can be used, despite security concerns. JSON.parse() is misleading. In reality a simulation application will be the preferred solution. doing other things, such as physics, artificial intelligence (AI), and graphics, in addition to receiving It is readily apparent that the browser’s implementation and parsing network messages. Some of the CPU of Javascript matters, both in absolute performance and cycles used by the simple benchmark code above will in which approach works best within a given browser. instead by used by these tasks. Safari’s Javascript performance was quite good, probably a reflection on the engine currently used by 3.2 Example Application that browser, and binary formats were faster than JSON formats by a considerable margin. Internet We implemented a simple Google Maps Javascript API Explorer 11 and Chrome 35 web browsers apparently application using the binary DIS implementation [11]. have an optimized native JSON parser that decodes a The web page loads the Google Maps Javascript API, JSON representation of an ESPDU as quickly as it displays a map, and then displays the positions of DIS does a Javascript binary format message. (Or, entities visible to the server’s network using the alternatively, the binary typed array libraries aren’t as architecture shown in figure 5. In addition the web well optimized as those of Safari and Firefox.) page uses the browser’s geolocation API and sends Decoding the binary DIS message in Firefox 30.0 was entity state PDUs back to the server to demonstrate faster than decoding a DIS PDU encoded in JSON— two-way communications. The web application works 41,000 operations per second for JSON vs 70,000 on Mozilla Firefox, Google Chrome, Apple Safari, and operations per second for the binary DIS IOS (iPhone/iPad) mobile Safari. A screen shot is representation, though both were smaller on an shown in figure 9 absolute level than Safari using any format.
Other results are unsurprising. Mobile devices are slower than desktop devices. Still, modern mobile phones can decode a respectable number of PDUs in either format.
We also benchmarked decoding the WebLVC update message shown in figure 1. Again, the benchmarks are available for inspection at the jsperf.com site [10]. This message contains less information than a DIS entity state PDU, but is larger—roughly 300 bytes for the message displayed in figure 1, vs 144 bytes for a standard binary DIS PDU. Results for Chrome are shown in figure 8. 4. Conclusions
Either JSON or binary DIS messages can be used to display Live/Virtual/Constructive information in the web browser. JSON is fast enough for most applications, and some browsers decode JSON messages as fast as they do binary. Binary formats have the advantage of being more compact for messages with the same content.
Web application architects should be aware of the web browser being targeted. Javascript engines vary both in absolute performance and in what tasks they do best. Some decode JSON very well; others are better at decoding binary. The efficiency of the Javascript Figure 9. AIS Ship Locations Displayed in Google implementation can have a significant impact on the Maps. performance of the web application.
This displays the results of an Automatic Identification Unification of mobile and desktop web applications is System (AIS) feed. AIS is a real time location system possible, at least for some types of applications. that the Coast Guard and other agencies around the Application architects need to be aware of what world require to be present on commercial ships. The features are missing from mobile platforms. For AIS feed has been piped into Joint Simulation Bus example, WebGL is not generally supported on (JBUS), a gateway that can translate between several Apple’s IOS for mobile devices. protocols. JBUS converts the AIS messages into DIS and sends it on the local network on broadcast UDP Binary DIS formats have one significant advantage: the port 3000. The websocket server application reads the standard has already been specified. JSON formats, in DIS and forwards it, in binary format, to the web page, either WebLVC format or in JSON format DIS, do not where the DIS entity state PDUs are decoded. Pins are have a widely recognized standard. Using binary added to the map that represent each ship reported by format DIS reduces or eliminates the need for protocol AIS. DIS’s geocentric position was converted to translation gateways, and reduces the need for latitude and longitude to place the pins. Information standards group efforts to define an acceptable JSON about each ship can be displayed by clicking on the message format. The appeal of using the binary format pin. The application is able to decode approximately for DIS in Javascript is straightforward: it’s already a 3000 DIS Entity State PDUs per second while standard, while a JSON format is not. Existing displaying the map information when running on a gateways can convert protocols like AIS to DIS, and a laptop. The primary limitation seems to be map number of gateways exist that convert HLA RPR-FOM overhead and memory rather than the speed at which to DIS. Javascript simulation applications in the client the application can decode DIS PDUs. browser can be coded using the well-known DIS specification without having to develop and maintain a We have also implemented small 3D virtual worlds new protocol. using WebGL and Three.js. Small virtual worlds of up to perhaps a few dozen entities in a simple scene can 5. Future Work be implemented. In a distributed simulation web application the program It is realistic to expect that web applications on modern logic can span two locations: the client side and the desktop devices can process PDUs in the mid-four server side. For example in a web application we could digits per second range, depending on what else the configure the server side to forward only new or application is doing. 3D graphics applications will be changed entity state PDUs to the web page; this would much lower; those that only collect summary statistics eliminate the need for heartbeat PDUs to be forwarded will be at the high end of this range; and map across the bandwidth-constrained websocket link to the applications will fall between these two extremes. web page, while also remaining compliant with the DIS standard from the standpoint of external DIS applications. This illustrates the more general case of Distributed Data Management (DDM) or Area of Interest Management (AOIM) on the server side.
Modern commercial web applications such as Google Mail or web-based games are cloud-based, and server- side web applications can dynamically scale as demand goes up. From an architectural standpoint, CPU capacity available on the server side is essentially unlimited. The implications of this insight have not [9] Don McGregor: “Javascript DIS Native vs JSON,” been thoroughly explored. It may make sense to http://jsperf.com/javascript-dis-native-vs-json/2. migrate more computation to the server side and Retrieved June 12 2014. offload mobile devices, or provide richer computation [10] Don McGregor: “DIS vs WebLVC,” for applications by exploiting the resources available in http://jsperf.com/dis-vs-weblvc. Retrieved June 12 the cloud. 2014. [11] Don McGregor: “Web-Based DIS Map,” The WebRTC API standard is just beginning to emerge https://movesinstitute.org/DIS/. Retrieved June 12 from the standards process, and implementations exist 2014. on the most recent Chrome and Firefox browsers. WebRTC allows access to UDP sockets, the traditional mechanism for exchanging state information in distributed simulations. WebRTC also allows direct peer-to-peer communications between web browser pages. This capability is an obvious avenue for future research.
Support for the Extensible 3D (X3D) Graphics International Standard DIS nodes (EspduTransform and Signals PDUs) will next be demonstrated by integrating these capabilities into the open-source X3DOM javascript library. X3DOM provides plugin- free X3D rendering within HTML pages, allowing direct composition of X3D and HTML in a single web page (http://www.x3dom.org).
A web-based architecture can also be subject to other factors, such as the latency inherent in communications between the client and server. The tradeoffs have not been fully explored.
References [1] The Khronos Group, “OpenGL ES 2.0 for the Web,” https://www.khronos.org/webgl. Retrieved June 10 2014. [2] Internet Engineering Task Force, “RFC-6455: The Websocket Protocol”. http://tools.ietf.org/html/rfc6455. Retrieved June 10 2014. [3] World Wide Web Consortium, “WebRTC 1.0: Real-time Communication Between Browsers,” W3C Editor’s Draft 10 April 2014. http://dev.w3.org/2011/webrtc/editor/webrtc.html. Retrieved June 10 1014. [4] Simulation Interoperability Standards Group, “Web Live, Virtual, Constructive Study Group”, http://www.sisostds.org/StandardsActivities/Study Groups/WebLVCSG.aspx, Retrieved June 10 2014. [5] Khronos Group, “Typed Array Specification” www.khronos.org/registry/typedarray/specs/latest. Retrieved June 10 2014. [6] Anonymous, “Can I Use Typed Arrays?”, http://caniuse.com/typedarrays. Retreived June 10 2014. [7] McGregor, Don; Brutzman, Don: “Open-DIS: An Open Source Implementation of the DIS Protocol for C++ and Java”. SISO Interoperability Workshop 2007. [8] SEDRIS: “Spatial Reference Model”. http://www.sedris.org/srm_desc.htm. Retrieved June 12 2014 Author Biographies application of web-based technologies for M&S interoperability.
DON MCGREGOR is a member of the research DON BRUTZMAN is Technical Director for 3D faculty in the Naval Postgraduate School Modeling, Visual Simulation and Networked Virtual Virtual Environments, and Simulation (MOVES) Environments in the MOVES Institute. As an Institute. His research interests include cloud Associate Professor at the Naval Postgraduate School computing, web programming, and network protocols. in Monterey, California he is a member of two Academic Groups: Undersea Warfare and Modeling, CURTIS BLAIS is a member of the research faculty in Virtual Environments and Simulation. He is an the Naval Postgraduate School MOVES Institute. He investigator in the NPS Center for Autonomous has over 40 years of experience in management, Underwater Vehicle Research. His research interests specification, design, development, and application of include underwater robotics, real-time 3D computer M&S for training, analysis, and mission planning, and graphics, artificial intelligence and high performance in M&S education. His research interests include networking.