Ajax, Comet, HTML 5 Web sockets

Ajax provides a good solution for the HTTP Communication model. It asynchronously polls server events on the client. Server events are arranged in the queue to be processed in sequence and transmitted
In this way, the browser simulates the communication initiated by the server and transmits messages in real time between polling time gaps. Therefore, relying solely on Ajax makes it impossible for us to implement real-time communication.

 

The optimization introduced by comet is aimed at the initial HTTP Communication, which adopts the "push" communication style based on HTTP. Several techniques provided by comet can be sent without a client
The server sends the request to the browser. If an additional HTTP connection is added, comet can even implement two-way communication over two HTTP connections. However
The stumbling block of comet lies in the fact that various browser providers have different levels of support for the xhr and iframes-data blocks required to implement comet, and there is no unified implementation standard. In addition,
From the network or development perspective, the cost of managing the two connections in comet is huge. The direct impact of these overhead is the transmission latency in the comet application, which limits the Real-Time
Information accuracy.

---->

Developing with Comet poses many challenges. It is not impossible to implement your own solution, but this requires the development of JavaScript class libraries, using frame and xhr
Streaming and many other technologies to maintain continuous connections. At this time, the problem is that different browsers have different implementations for these technologies. Worse, they often rely on server-side code push.
JavaScript code segments not only increase the complexity of the entire implementation, but also introduce the portability problem.

Fortunately, there are several frameworks that provide the abstraction of the transmission and simplify comet development. The most famous one is sitepen's cometd, which implements full Parameters
Test bayuex specifications. The bayuex Specification defines the comet publish-subscribe model. Jetty's recent version also includes a Java-based Server
Bayeux implementation.

Bayuex and cometd have simplified comet, but there is still a lot of controversy over its API and wire protocols. There is a "coliding comet: Battle of the bayuex" series on the comet daily to discuss in depth various issues about bayuex.

 

HTML 5 websocket represents a new round of attempts by Comet and Ajax to promote HTTP Communication. HTML 5
As defined in the websocket specification, full-duplex (or bidirectional) transmission is used between the browser and the server to push and pull information. This not only avoids
Existing connection and portability problems can also provide more efficient solutions than Ajax round robin. Currently, HTML 5 websocket is the main mechanism to promote full-duplex real-time web communication.

---->

Although both comet and AJAX can provide end-user experience for desktop applications, and the transmission latency can be reduced to a level that users cannot perceive
Sockets can truly provide precise and efficient stream events for the browser, ensuring that the transmission delay is negligible. This is the best solution for sending real-time information through the Web.
Case. It not only provides complete asynchronous duplex channel stream communication through a single TCP/IP connection, but also applies new HTTP headers, more importantly, it supports the use of the same
Format.

Most comet implementations depend on the Bayeux protocol. This Protocol requires that the messages sent by the source service must be converted to the formats supported by the Bayeux protocol.
Instead, the entire system becomes more complex. Developers have to process a message format (such as JMS, IMAP, and XMPP) on the server, and process another message format (such
Bayeux, JSON ). In addition, the code for converting the source protocol to Bayeux is hard to parse and process the message itself before sending the message, which adds unnecessary negative performance to the system.
. If you use web sockets, you will not have to worry about the performance because the code conversion increases the complexity of the system.

A common problem with websockets is its feasibility. Currently, browsers cannot directly support this technology. But in a few months it will certainly be okay, like
WebKit, Firefox, and opera
5. features such as canvas, postmessage, offline storage, and server-side message sending (SSE) are quickly responded and support is added in a timely manner.

Websockets also requires a certain degree of support from the server, because an existing HTTP connection needs a starting "handshake" for HTTP to be updated to a new connection ". Kaazing
The open-source Gateway project implements the first server that supports this action and has the scalability required to support thousands of persistent connections. Kaazing
The gateway vendor kaazing also provides a javascript class library that allows all current Web browsers to support websockets. Therefore, currently
Websocket support can also be said to be ready.

To support HTML 5 websockets, kaazing released kaazing gateway 8.09 _ 2 Atlanta, an open-source HTML 5 websocket server, it can be used under the OSI approved common public Attribution license (cpal) derived from the Mozilla Public License:

Kaazing Gateway provides a javascript class library to simulate HTML 5 websocket. developers can now use websockets and deploy applications created with the websocket interface in both the current and future browsers.

A single node of the ultra-high-performance server behind the kaazing gateway can support thousands of concurrent connections. Multiple instances use traditional HTTP load balancing or DNS
Round robin algorithm cluster classification, so it can support countless continuous customer connections. In addition to a large number of connections, kaazing
Gateway's high-performance and hierarchical event-driven architecture (SEDA) also enables it to handle high data throughput.

The release of the Atlantis of kaazing gateway is also a popular messaging service (such as Apache
Activemq, rabbittmq) and XMPP services (such as openfire, jabberd, and other popular chat servers) package Javascript
Client. In this way, it is easier to create web-based chat applications, stock matrixes, online transaction platforms, online games, and other message sending applications.

The planned release of kaazing gateway 8.12 targets more HTML 5 features, such as server-sent events and more advanced security services, extended support for XMPP (jabber) and stomp (such as activemq, rabbitmq or openmq:

The class library provided by it enables current browsers to support HTML 5 servers to send events. The introduction of HTML 5
The support of postmessage makes it easy to transmit messages across documents. Kaazing's HTML 5 Class Library also includes
5. Supports offline storage and provides a simple and Dom-based storage solution. Kaazing
Gateway and its customer class libraries now support W3C access control for Cross-Site requests. This mechanism allows clients to initiate cross-site requests.
Xmlhttprequests.

In addition to HTML 5 extension support, kaazing Gateway
8.12 also provides more advanced XMPP features, such as group chat. This release also introduces STOMP-JMS adapters, therefore, combined with kaazing
Gateway can also adapt to any existing Java Message Service (JMS) (such as JBoss messaging and tibco
EMS, openmq, swiftmq, WebSphere MQ, etc ).

 

Original English:HTML 5 Web sockets vs. Comet and Ajax