4 Comments

Summary:

Jonas Jacobi’s Kaazing is pushing forward a new protocol called web sockets. Rather than AJAX-type hacks to make web apps quick, web sockets are a full browser upgrade to better send and receive data between a web client and server.

Despite significant improvements to the responsiveness of web applications over the last few years, they remain hampered by the fact that web browsers can only communicate with servers over HTTP. “It’s as if everyone’s using fancy phones, but they’re still using ham radio to communicate with the server, where you have to hold the button down to talk,” is one metaphor Kaazing CEO Jonas Jacobi uses. He also described it as a kid on a car ride, asking, “Are we there yet? Are we there yet?” instead of just looking out the window to see whether they’ve arrived or not.

Jacobi relies on such metaphors because he’s trying to describe an as-yet-unseen paradigm shift in real-time web speed being pushed by his company, Mountain View, Calif.-based Kaazing, by way of a new protocol called web sockets. Rather than AJAX-type hacks to make web apps speedy, web sockets are a full browser upgrade to send and receive data between a web client and server simultaneously. That two-way communication is supposed to make web applications dramatically faster (and cheaper, too, because they require less infrastructure, says Jacobi). This could be super useful for things like chat, live event Twitter feeds and automatic lookup features like Google Suggest.

Kaazing’s team wrote the web sockets (aka TCP communications) proposal that was included nearly wholesale in HTML 5. Now, as it waits for browsers to implement web sockets (the latest Chrome version include it, and Mozilla is supposed to be next up), Kaazing is trying to build a business around real-time bi-directional communications. The company, founded in 2007 and privately funded (though raising venture capital now), already has customers in the financial services and gambling sectors — the kind where a difference of a split second on a site is material. Kaazing has built a web socket server and emulator so that users who visit web sites through older browsers can get a preview of what web sockets will provide.

Jacobi recently came by our office for a video interview to explain some of these concepts in person and talk about Kaazing’s place in such an early market.

Related research from GigaOM Pro (sub req’d):

Report: The Real-time Enterprise

  1. This is supposed to work for those behind firewalls and HTTP proxies how?

    Share
    1. WebSocket will pass through some firewalls/proxies, and as for the others… what are we supposed to do, just never improve the Web? At some point you have to move on.

      Share
      1. We’re supposed to find a more compatible way to accomplish the same goal.

        AJAX may be “clunky” but it works, which is more than I can say for this without caveat.

        Share
    2. Re. Proxy servers–while the HTML5 Web Socket protocol itself is unaware of proxy servers and firewalls, it features an HTTP-compatible handshake so that HTTP servers can share their default HTTP and HTTPS ports (80 and 443) with a WebSocket server.
      If a browser is configured to use a known or “explicit” proxy server then it will first issue an HTTP CONNECT method to that proxy server while establishing the WebSocket connection.
      In the case WebSocket traffic flows through an unknown “transparent” proxy server, the browser is unaware of the proxy server, so no HTTP CONNECT is sent. As a result, unencrypted connections (ws://) are likely to fail in practice today, but if an encrypted WebSocket Secure connection (wss://) is used, then, since the wire traffic is encrypted, intermediate transparent proxy servers may simply allow the encrypted traffic through, so there is a much better chance that the WebSocket connection will succeed if an encrypted WebSocket connection is used.

      Re. “AJAX may be “clunky” but it works” (I suppose you mean Ajax Polling or Comet solutions here)–Web Sockets provides a dramatic improvement from the “hacks” that are used to simulate a full-duplex connection in a browser. It reduces kilobytes of unnecessary header traffic data (for each poll to the server) to just 2 bytes and dramatically lowers latency.
      HTML5 Web Sockets is not just another incremental enhancement to conventional HTTP communications; it represents a huge advance, especially for real-time, event-driven web applications.
      It also “works” (today) in Google Chrome and will be in other browsers soon (WebKit/Firefox). On top of those improvements in native support, Kaazing (see article) provides a very fast, full emulation that works in all browsers.

      Share

Comments have been disabled for this post