Kaazing: http is all wrong for interactive applications

Kaazing: http is all wrong for interactive applications

Summary: Today's Web-base applications need to be both interactive and work in real time. The hypertext transfer protocol was designed as a "call and response" tool to transfer static data. Kaazing thinks that it has a better way.


Vikram Mehta, CEO of Kaazing, introduced me to his company and its view of why so many Web-based applications do such a poor job of interactive processing. They make people wait unnecessarily. Why? Kaazing believes that it is largly due to the design of the hypertext transfer protocol (http) that is the foundation for all Web traffic. 


http was designed back in the 1990s to make the most efficient use of available systems. Client systems would request a page, a Web server would get that request, it would then look up the page, and send back a response. The Web server would then go about its business of answering other requests and forget about the interaction it just completed.

Interactive systems

Today's interactive systems are designed to allow individuals to collaborate with applications to accomplish a set of goals. Many times this means sending an ongoing stream of updates that allow the user to both see the application's progress and  interact with the program.

While this is straightforward when the individual is working directly with an application on his/her client system or when working with a properly designed client/server workload, it is rather difficult to achieve the same thing using http.

The developer has to develop a way to tract the state of the workload, that is, what requests have been made, what have been satisfied, and what work remains to be done. http wasn't designed to make it easy to maintain state or to update only a portion of the screen with new data.

Attempts to resolve this problem

Over time, the IT industry has attempted to address this problem. Many different Web development languages, application frameworks and even libraries of Javascript code have been deployed.

Kaazing's approach

Kaazing's founders thought that it would be wise to step back a bit from http and develop their own network communications protocol for real-time interactive Web applications. The company’s IoT gateway, a software-based web communications platform, was the first step. It was designed to enable mobile users, marketplaces and machines to connect and communicate in real-time, more reliably and at unprecedented scale. The next step was providing a set of tools and access methods so that developers could easily use the new communications platform.

Since sockets have been a standard networking approach in both the UNIX and Linux worlds for a very long time, Kaazing decided that implementing sockets and providing tools that make it easy to develop interactive applications using HTML5 would be the best approach.

Snapshot analysis

As a reformed software engineer, it was a delightful conversation that brought me back to my software engineering days. The approach that Kaazing is taking makes sense, and the demonstration performed very well. The list of companies that have already taken up Kaazing's approach is pretty impressive, too.

Kaazing's approach competes with those offered by quite a number of other suppliers. Each, of course, believes that their own approach is the best for any problem we'd care to name. While Kaazing's approach makes a great deal of sense, it would be best for enterprises needing to develop and support highly interactive Web-based applications to consider Kaazing along side of other approaches.

Topic: Enterprise Software


Daniel Kusnetzky, a reformed software engineer and product manager, founded Kusnetzky Group LLC in 2006. He's literally written the book on virtualization and often comments on cloud computing, mobility and systems software. In his spare time, he's also the managing partner of Lux Sonus LLC, an investment firm.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • It goes all the way down to TCP.

    Well, it goes all the way down to TCP. UDP is used a lot for realtime stuff when TCP won't do, and http I believe is only over TCP.

    Apps like Skype for real time video teleconferencing don't actually use http. This has really been known for some time; Kaazing isn't really talking anything new.
    • Re: TCP

      You're correct that HTTP only uses TCP. TCP (or something like it) is really all you should use on the Internet - pretty much everywhere now. It handles all the error-correcting and session information that make it easier for the app developers and security folks.
      Performance is hardly a concern now. Even NFS uses TCP now.

      HTTP is good if you have one long data transfer, but yes, if you are creating HTTP requests over and over to the same server, there is overhead in the connection setup/teardown. Even on the TCP side.

      A persistent connection is an interesting idea, but destroys the "statelessness" of HTTP. Statelessness is a pro and a con. Pro being you care less about the reliability of your connection. Con being you have to create new state each time by storing it in your browser and sending it all back to the server each time you connect.

      Be interesting to see how they work around that. I definitely think there's room for another methodology here.
  • Real-time networking for all

    Real-time infrastructure is not new, it is deployed by the likes of Skype, WebEx, World of Warcraft and Google Docs, to name a few. Today's true innovation is making an industrial-strength real-time network available to software developers, allowing them to reap the benefits of live data push and data sync for enhanced web/mobile user experience and device communication. Search for "global realtime apps" to find relevant examples.