The server has a new message that is actively pushed to the client browser

Usually, when you open a Web page or app to query or refresh, the client makes a request to the server and then returns the data, the client and the service side of the pattern is: Client Request-server response, and in some cases, the server will actively push some information to the client, such as: News subscriptions, weather reminders, etc. So in this mode, there are some questions to consider:

1. How the application server determines which device each application resides in

2. Where the server pushes the message, the client does not have a fixed address like the

What is the process of proactively pushing a server to a client?

Combined with an actual problem analysis:

Issue: Takeaway app, business in the background need real-time access to new orders, some words are several; this demand is similar to the daily use of QQ or when the new information reminders, as long as there is new information need to remind

Recently encountered a scene in the business, business in the background need real-time access to new orders, some words are several; this requirement is similar to the daily use of QQ or when the new information reminders, as long as there is new information need to remind; businesses are basically used on the PC, all kinds of browsers have: IE series (7.0,8.0,9.0 and above), Chrome kernel, Firefox, etc., the feature belongs to the deployment on Tomcat 6.0, if the technical needs can be deployed to Tomcat 7.0;

We first do technical research, this kind of browser and server in real-time communication ways.

Ajax polling

This is what we most naturally think of. With regular Ajax polling, every 10s or 30s polling, you can determine how many new orders entered, and this time interval is acceptable for message reminders. This technology is very simple to implement, the current machine is machine-ready, front-end browsers are also supported.

However, this approach will have a very serious problem, is the need to constantly send a message to the server to inquire, if there are 1w businesses open the browser, using 10s polling, the server will assume 1000 of the QPS, this 1w business may have only 10 order notification This approach can cause significant performance waste to the server.

There is also a similar poll that uses the JSONP cross-domain request polling, which differs in implementation, but the rationale is the same, as the client constantly initiates requests to the server.

Advantages

Simple to implement.

Disadvantages

This is through the simulation server initiated communication, not real-time communication, regardless of the state of the application changes and blindly check the update, resulting in a waste of server resources, and will aggravate the network load, drag the server.

Comet

Comet is a web-enabled push technology that enables the server to deliver updated information to the client in real time, without requiring the client to make a request, and there are two implementations:

Long polling (polling)

Long polling is maintained after opening a connection, waiting for the server to push the data to shut down again, can take the HTTP long polling and XHR long polling two ways.

Long polling for HTTP and Jsonp methods

Attach the script tag to the page for scripting to execute. The server suspends the connection until an event occurs, sends the script content back to the browser, and then re-opens another script tag to get the next event, thus implementing the long-polling model.

XHR Long Polling

This is the way to use a much longer polling mode.

The client opens a server-side AJAX request and waits for a response; the server side needs some specific functionality to allow the request to be suspended, and whenever an event occurs, the server sends back the response in the pending request and closes the request. The client-side JavaScript response handler functions after processing the information returned by the server, making a request again to reestablish the connection;

The browser has now supported Cros cross-domain requests, so long polling for HTTP and Jsonp is a technology that is slowly being phased out, and it is recommended to use XHR long polling.

Long polling pros and cons

Advantages

It is easy for clients to implement a good error handling system and time-out management, similar to the way Ajax polls are implemented.

Disadvantages

A special feature is required on the server side to temporarily suspend the connection. When the client initiates a large number of connections, the server side will maintain multiple connections over a long period of time, with some risk.

Iframe

An IFRAME is an early HTML tag that, by embedding a hidden frame in an HTML page, then sets the SRC attribute of the hidden frame to a request for a long connection, and the server can continuously input data to the client.

Advantages:

This way each data transfer does not close the connection, the connection will only be in the event of an error in communication, or when the connection is rebuilt (some firewalls are often set to discard too long connections, the server can set a time-out period, time-out to notify the client to reestablish the connection and close the original connection).

Disadvantages

ie, Morzilla Firefox at the bottom of the progress bar will show that the load is not completed, and the icon above IE will not stop rotating, indicating that the load is in progress.

Google's geniuses use an ActiveX called "htmlfile" to solve the load display problem in IE and use this method in the Gmail+gtalk product. Alex Russell at "What else was burried down in the depth's of Google's amazing JavaScript?" This method is described in the article. Zeitoun Web site provides the comet-iframe.tar.gz, encapsulates an IFRAME and Htmlfile based JavaScript Comet object, support IE, Mozilla Firefox Browser, can be used as a reference.

The gtalk of our popular web version is this approach, and Google's developers have used an ActiveX called "htmlfile" to solve the load display problem in IE.

Comet Implementation Framework COMETD

The CometD framework is an HTTP-based event-driven communication solution that uses the Bayeux Communication protocol, provides a Java server part and a Java client part, and a JavaScript client library based on JQuery and Dojo.

Bayeux communication protocol is mainly based on HTTP, which provides the responsiveness of bidirectional asynchronous communication between client and server. The Bayeux protocol communicates based on a channel that routes and sends messages from the client to the server, from the server to the client, or from the client to the client (but through the server). Bayeux is a "publish-subscribe" protocol.

The CometD is bound together with three transport protocols: JSON, JSONP, and WebSocket. They all rely on the Jetty continuations and Jetty WebSocket APIs. By default, specification can be used in Jetty 6, Jetty 7, and Jetty 8 and all other services that support Servlet 3.0 CometD.

Servers and internal artifacts

Atmosphere Frame

Atmosphere provides a common API for using Comet and the many WEB servers (including Tomcat, Jetty, GlassFish, Weblogic, Grizzly, Jbossweb, JBoss, and Resin) WebSocket characteristics. It supports any WEB server that supports Servlet 3.0 specification.

Atmosphere provides a JQuery client library that makes connection settings easier, and it detects the best transport protocol (WebSockets or CometD) that can be used. The use of the atmosphere JQuery plugin is similar to the HTML5 WebSockets API.

Pushlet

Pushlet uses the Observer model: the client sends a request, subscribes to an event of interest, and the server assigns a session ID to each client as a token, and the event source sends the newly generated event to the subscriber's event queue in a multicast manner.

Pushlet was last updated on February 5, 2010, and has not been updated since then.

See the sample code (HTTPS://GITHUB.COM/BRUCEFENGNJU/COMETDATOMS) for the Cometd and atmosphere frameworks.

Comet Implementation Essentials

Do not use more than two HTTP long connections on the same client at the same time

The HTTP 1.1 specification specifies that the client should not establish more than two HTTP connections to the server, that new connections will be blocked, and that such rules are strictly adhered to in Internet Explorer.

Server-side performance and scalability

The general Web server creates a thread for each connection, and if you use Comet in a large commercial application, the server side needs to maintain a large number of concurrent long connections. In this application context, server-side needs to consider load balancing and clustering technology, or on the server side for a long connection to make some improvements.

Maintain "heartbeat" information between the customer and the server

Maintaining a long connection between the browser and the server creates some uncertainty for communication: Because the data transfer is random, the client does not know when the server will be able to transmit data. The server side needs to ensure that the resources allocated to this client are freed when the client is no longer working, preventing memory leaks. So a mechanism is needed to make both parties aware that both are working properly.

The server side sets a time limit for blocking reads, which blocks the read call when it expires and sends a heartbeat message to the client that no new data arrives. At this point, if the client is closed, the server writes data to the channel with an exception, and the server will release the resources allocated to the client in a timely manner.

If the client uses an AJAX-based long polling method, the server returns data, closes the connection, and, after a certain time period, does not receive a request from the client, it will assume that the client is not working properly and will release the resources allocated and maintained for this client.

When the server handles information anomalies, it needs to send an error message to notify the client while releasing the resource and closing the connection.

WebSocket

WebSocket is a protocol that HTML5 begins to provide full-duplex communication on a single TCP connection. The WebSocket communication protocol was established as the standard RFC 6455,websocketapi by the IETF in 2011. In the WebSocket API, the browser and server only need to do a handshake, and then a fast channel is formed between the browser and the server. The data can be transmitted to each other directly between the two.

Browser support

Browser	Version Support
Chrome	4 +
Firefox	4 +
Ie	+
Opera	+
Safari	5+

See more Browser Compatibility

Realize

There are many versions of the WebSocket implementation, and you can view the demo in detail.

Summarize

Summing up the long polling is not a good solution, but also for the server is risky, and the support WebSocket protocol browser is relatively new, the ratio is IE requires more than 10 version, and our business is for the merchant side, the merchant's browser version is relatively low, Many of the websocket are not supported; In contrast, comet's approach is more appropriate, there is a corresponding implementation framework, the realization of the lowest cost; So finally we decided to use Comet's way to achieve, after the online run for a period of time to introduce to you.

Reprint note This article address: http://www.ablanxue.com/shtml/201603/31892_1.shtml

The server has a new message that is actively pushed to the client browser