PHP Serverpush (push) technology

A request to replace Ajax

Transferred from: http://blog.163.com/bailin_li/blog/static/17449017920124811524364/

Demand:

I want to be a member of the site notification function. Do not want to use the previous Ajax query, heard that there is a push technology. The following article describes the good, from reprint,

==================================================================================

discussion on push (push) technology in PHP [Http://vistaswx.com/blog/article/php-server-push]

With the increasing demand for instant Web applications, Server push (push) technology has emerged as a core of data flow for real-time applications in areas such as chat, message alerting, and especially social networking. This log attempts to explore the various implementations of the push that are appropriate for PHP and their pros and cons.

1. What is server Push

Imagine in the chat application, if the use of traditional Ajax to assume the message of the incoming, then generally through a certain time to pull the information of the way to achieve, but in fact, this way there is a lot of query is wasted. Web applications such as chat require the server to proactively inform the front-end of new messages (Push) at a specific time, rather than the front-end asking the server: "Did you get the message?" "(pull). This is why this technique is often called reverse Ajax.

Other aliases: Comet, reverse Ajax

2. How to implement push

In fact, the so-called push technology is not how complex, now there are 3 kinds from the big class, one is still based on Ajax, there is a framework based on the last one abandoned the traditional HTTP protocol, using Flash or HTML5 websockets technology. The next step is to explore the different ways in which these three categories are produced.

1) Ajax Long polling

Ajax long polling is still essentially a pull, but it is a good push implementation because of the high real-time and much less useless requests. But it only reduces the unnecessary consumption on the network.

Core: The client initiates an AJAX request that the server will request to shelve (pending) or suspend until it has reached the timeout (timeout) or needs to be pushed, and the client waits for the Ajax to return and process the data before initiating the next Ajax request.

Advantages: high compatibility, simple implementation

disadvantage: for the language of PHP, if you want to do real-time, then the server will have to withstand much greater pressure, because when it is often uncertain, it is necessary for each time the PHP script shelved a while loop.
Of course, if the server refreshes every second level, that is acceptable, but in real-time degradation.

Note: The browser has a limit on the number of connections. I came to the conclusion that if there is an AJAX request on the current page waiting to return, other AJAX requests will be shelved (Chrome, Firefox has been tested). What if the page has general AJAX requirements? The workaround is to open a framework in which the comet long polling under another domain name requires attention to cross-domain issues.

PHP Implementation: jquery+php implementation of Comet

Related: Ajax cross-domain and JS cross-domain Solutions

2) Frame Long connection

Inspired by Ajax, there is a long connection under the frame.

Core: A normal request is initiated in frame, the server holds it, and the output is executed directly when push is required.
Script, and then continue to remain connected. If you are concerned about the time-out problem can be changed to frame inquiry.

Pros: high compatibility with 1

Cons: The biggest problem is that if the framework is loaded, then the browser will always show "load in", which is weak (see the relevant reading resources at the end of the article). The same server can hold a lot of loops ... In addition, there are no same domain connection restrictions that are not tested.

3) FLASH/HTML5 WebSockets

Use Flash to launch websockets, seconds to kill all the problems before.

Advantages: standardization, RealTime, Push

Disadvantage: The server needs to be able to deal with websockets, and if there is no flash and does not support HTML5 how to do?

PHP Implementation: Start Using HTML5 WebSockets Today

6) Using a compatible packaging layer (Socket.io)

Each of these approaches has pros and cons, so the ultimate solution is to be together! Can websockets time on the websockets, does not support the HTML5 feature degradation to flash, no flash is degraded to Ajax long polling. That's the way my rainbowfish used to be.

Pros: highly packaged, very easy to write, almost no need to care how to achieve it. Real-time, ultra-low load, high concurrency.

Cons: actually not a disadvantage, Socket.io server-side requirements are node. js, not PHP.

personal Opinion: If you are an independent host and can run the program, then socket.io with node. JS is a very efficient option. Why is it? Because it can also avoid the high load of PHP service side.

Rainbowfish's messaging system is implemented in this way: All clients are hung on the Nodejs server via Socket.io (note: Just hang up, no loops required because it is event-driven), and the server communicates with Nodejs if the message is to be pushed ( such as access to an address to achieve), tell it what to push the message to where, Nodejs received a push signal, the real-time transmission of data through Socket.io to the browser. This is actually a one-way road, because the NODEJS server does not have the ability to communicate with PHP, in fact, do not need, the page directly connected to PHP.

3. Concluding remarks

In fact, the first method (Ajax Long pull) is a good way to do it, but if you use PHP, the server load is a bit large, but it's a common problem. , and the final list of Socket.io scenarios completely avoids this problem because it belongs to a different architecture, and this combination can be implemented with almost all scripting languages.

For applications with very high real-time requirements, perhaps using PHP to implement real-time parts is not a good choice, and will face very large server loads (which can be solved by writing an extension that supports waiting events), and if it is just a message prompt, you can adjust the refresh interval on the server down to the second level. The load is acceptable. But whatever the use, it may be the best option to work with non-blocking languages.

4. Related Reading

How to implement COMET with PHP

Start Using HTML5 WebSockets Today

Comet (Wikipedia)

Ajax cross-domain and JS cross-domain Solutions

jquery+php implementation of Comet

==============================================================================================

Comet Research [http://lync.in/research-on-comet/]

In the Web application, the client's Ajax technology is very common and very popular, but at the same time, other applications, such as online monitoring, real-time data display, instant messaging, etc. need to change the background data in real time to the foreground, This kind of server push behavior (which might make you think of BlackBerry) requires another solution, which is the comet--of this article that does not need to install a plugin to keep the HTTP long-connected server push scenario.
The following two points are to be taken into account in the programme.

1. Browser versatility, support for a variety of different implementations of structural models.
2. The use of long connections for server resources, and the ability of the server to withstand .

Comet's client-to-server interaction flow

The industry has two main solutions for Comet implementations:

1. Ajax-based polling (long polling) mode

   This is the way the client makes an AJAX request, and then the server blocks the request until it responds or times out. The client responds and makes a new request after receiving instructions from the server.

   At the implementation level, when the state of XMLHttpRequest is 4, the state of load is handled by the client, while Gecko (Firefox) and WebKit (Chrome, Safari) currently supports reading when readystate is 3 (of course it can only read all the strings that have been returned by the request, so it is necessary to determine the bounds of the instruction itself), and Trident (IE) will throw an error if it is read halfway. Using Xdomainrequest in IE8 can solve this problem appropriately (see Eric Law's Comet streaming in Internet explorer[]).

   At present, happy net adopts this kind of way.

2. Stream (streaming) mode based on IFRAME and Htmlfile

   This approach is to use the mechanism of the IFRAME, and then make the IFRAME request a specific URL, and through the loading of this page constantly from the server to grasp the data, where the data from the server is mostly the reference and operation of the page's current JavaScript functions.

   One obvious disadvantage of this scenario is that the page will always show that it is loading, which is more noticeable on IE. Google's geniuses have thought of a solution to the problem with Htmlfile ActiveX controls, which are described in detail in the "What else is burried" down "in the depth ' s Amaz ing JavaScript?

   Currently, Renren and Gtalk are using this approach.

In addition to the generality and performance mentioned in the text, there are a few things that need to be considered.

1. The format of the data interchange. Because the form of data exchange is push, so inevitably there will be a command queue, so the data structure is required before and after the detailed agreement, execution instructions and data directives need to be strictly defined, generally speaking, the JSON scheme is more common.
2. Limit the number of connections to the browser itself. The HTTP 1.1 specification declares that the client should not establish more than two HTTP connections to the server, and IE strictly adheres to this point, so the foreground needs to be cautious in controlling the number of requests when processing requests.

In fact, comet technology in Ajax rounds 2005 years after 2006 years is the industry a very hot point of discussion, the current two methods are very mature, in the dojo,dwr and other front-end framework has such a realization, And the advent of the Bayeux agreement has essentially set an industry standard.

Comet's framework front-end has pushlet,dwr and dojo and so on, the service side has jetty,meteor,orbited,glassfish,alpha, the Realization product language also covers the Java,c++,python,perl,ruby, Erlang. NET, and so on.

The WebSocket in the next generation of HTML5 will be a new starting point for comet, but until then, there should be no further discussion and technology at the non-plug-in web level.

This article is just a general overview of the comet technology, the rough is not inevitable, in the following article will be a certain explanation and demonstration of WebSocket.

Resources:

• Here's an example of a PHP comet, how to implement comet with PHP. I want to see this.
• This is an introduction to Comet on Developerworks.
• Here are some of the products and introductions that are currently on the server side of Comet.
• Of course, Wikipedia's interpretation of comet is also very detailed.
• You can also take a look at some of the introductions above ajaxpatterns.
• Finally, Cometdaily is a place worth learning about the latest comet news and knowledge.
• =====================================================================================================

Comet: "Server Push" technology based on HTTP long connections

[http://www.ibm.com/developerworks/cn/web/wa-lo-comet/]

PS: The above article should be enough for you to see clearly. Use a bar. But I'm not yet in the project with push technology, for reasons that haven't had time to toss, but the local tests are normal.

The following is an example of a code implementation of Protype and jquery +php. [Example code from the Web, has been tested through. Easy

Http://bbs.php100.com/read-htm-tid-290215-ds-1.html

PHP Serverpush (push) technology