Bergmans Mechatronics LLC Bookmark and Share
  Home Combustion Control System HTML 5 WebSockets Project Portfolio LabVIEW Corner About BML

HTML5 WebSocket Application Research


HTML5 WebSocket is a communications interface that enables continuous, bi-directional data exchange between browsers and servers. These properties of the interface permit the development of dynamic, browser-based applications.

Examples of WebSocket-enabled applications that are often mentioned are stock quoting systems, games and chat rooms. In addition to these types of applications, however, WebSockets also enables entirely new types of browser-based applications. One such application is BML's LabSocket system which easily permits LabVIEW applications to be remotely accessed via a web browser.

Today's remarkable computing technologies, such as powerful web browsers; mobile devices; nearly ubiquitous high-speed Internet access; and, low-cost "cloud" servers, in combination with the WebSocket interface are producing significant advances in the use of the web.

BML is contributing to this trend by developing WebSocket-based products and demonstration applications, and promoting the use of WebSocket technology within the web development community.

On this Page

HTTP Request-Response Model

WebSocket: Interface for Continuous, Bi-Directional Communication

Browser Support for WebSockets

WebSocket-Compatible Message Brokers

Advanced WebSocket Interfacing

Quick Links
  • LabSocket - The LabSocket system uses WebSockets to automatically extend LabVIEW applications to the web.
  • SportJury - This White Paper describes the first application using the LabSocket system and the first known commercial LabVIEW application employing WebSockets.
  • collectdViewer - A high-frequency, browser-based server monitoring system using WebSockets.
  • GroupVote - A blog entry about a real-time, multi-user voting system prototype developed during MobileHackDays in 2011.
  • EarthControl - A presentation about a Real-Time, Multi-User Facebook Game Enabled by HTML5. (EarthControl is no longer in operation.)
  • HTML5 WebSocket Workshop - Learn how to develop WebSocket-based applications in this one-day course created and presented in cooperation with Kaazing.


    HTTP Request-Response Model


    The traditional HTTP request-response model involves a browser creating a request for data followed by a web server generating a response, normally in the form of a web page. In a typical arrangement, shown below, the browser resides on a user's desktop or mobile device and the web server software operates on a remote server platform. A back-end application on the server may also generate or process data as part of this interaction.


    HTTP Request-Response Model
    HTTP Request-Response Model


    This model has proven to be well-suited for serving static web pages. However, for dynamic web pages that require frequent server-initiated updates or intensive user interaction, certain limitations can occur, including:

    • Latency between user action and server response
    • Potentially large amounts of traffic generated by browser-initiated polling
    • Large amounts of header data traffic
    • Browser and server software complexity

    WebSocket: Interface for Continuous, Bi-Directional Communication


    In contrast to the HTTP request-response model, the WebSocket interface enables continuous bi-directional communication between browsers and servers. In a typical WebSocket application, shown below, a browser transmits data to a WebSocket-enabled message broker which then forwards the data on to a back-end application. The back-end application can use the message broker independently to transmit or "push" data to the browser.


    WebSocket Interface Model
    WebSocket Interface Model


    The significance of this bi-directional communication mechanism is that a browser can now be thought of as a real-time terminal for back-end applications. From this perspective, the WebSocket interface therefore allows the possibility of creating new browser-based applications with characteristics such as:

    • simultaneous data transfer between back-end software and large numbers of users using desktop or mobile browsers
    • high-speed, low-latency inter-browser communication and data transfer
    • user experience in a web application that is similar to that of a native application
    • nearly unlimited amounts of application data processing and storage on one or more servers

    The WebSocket interface is defined by both i) an Application Programming Interface (API); and, ii) a wire protocol. The WebSocket API is specified by the World Wide Web Consortium (W3C) and describes the JavaScript software that is used to implement the WebSocket interface in a web page. The wire protocol, specified by the Internet Engineering Task Force (IETF) in RFC 6455, describes the details of the message format that is used to transmit WebSocket messages over the Internet.


    Browser Support for WebSockets


    To establish communication over a WebSocket connection, a browser must have WebSocket support. Most modern browsers, including Chrome, Safari, Firefox, Internet Explorer and Opera now provide this capability. Additional information about browser support for WebSockets is listed at:


    WebSocket-Compatible Message Brokers


    Communication between a browser and back-end software typically passes through a message broker. The use of a message broker is beneficial because it can readily route messages between multiple client processes. For example, the setup and operation of a publish-subscribe messaging pattern is greatly simplified by the use of a message broker.

    To enable WebSocket communication between a browser and message broker, not only must the browser provide support for WebSockets, but the message broker must also be capable of using this protocol. Fortunately, support for WebSockets in message brokers is becoming more prevalent. For example, the Apache ActiveMQ and RabbitMQ open source message brokers both support communication via WebSockets.

    The ActiveMQ and RabbitMQ message brokers can process text-based commands and messages sent via WebSockets using the Streaming Text Orientated Messaging Protocol (STOMP). This property, along with existing JavaScript libraries for STOMP messaging over WebSockets (see ActiveMQ WebSockets and Introducing RabbitMQ-Web-Stomp), and back-end client libraries for a variety of programming languages, greatly simplify the development of WebSocket-based applications.


    Advanced WebSocket Interfacing


    For applications where advanced interfacing functions are required, the Kaazing WebSocket Gateway (KWG) ( can be a useful asset.

    As shown in the figure below, the KWG is placed between the browser client and message broker. From this location, the KWG can offer a number of important capabilities, including:

    • WebSocket emulation for legacy browsers without native WebSocket capability (eg. Internet Explorer versions as old as 5.5)
    • Javascript libraries that enable communications from the browser via the JMS, AMQP and XMPP protocols
    • Connection off-loading. This feature enhances system scalability by consolidating multiple identical client connections into a single message broker connection .

    Advanced WebSocket Interface Using Kaazing WebSocket Gateway
    Advanced WebSocket Interface Using Kaazing WebSocket Gateway


    The KWG has been incorporated into a number of commercial systems, perhaps the most notable of which is an HSBC foreign exchange trading system. Resources about the KWG are available at



    Back to Top of Page Top

    © 2004-2016 Bergmans Mechatronics LLC