tags:

views:

104

answers:

1

I wander how do client side get response if the connection of request is not finished yet?

What's the principle?

In fact I've read quite a few posts on this subject:

http://stackoverflow.com/questions/333664/simple-long-polling-example-code

http://stackoverflow.com/questions/932415/how-does-the-live-real-time-typing-work-in-google-wave

But none of them solve my doubt

A: 

The answer depends on the technique used.

HTTP streaming, using the "hidden Iframe" technique, can do this. The technique is that the server sends <script> elements to the hidden iframe. Each script element will contain some executable JavaScript. This technique relies on the fact that browsers generally interpret an HTML element as soon as it is loaded. In this way, there is no need for any sort of polling code in the client; the script tags will contain the appropriate function calls, and the browser will execute those calls as soon as the script element is completely loaded.

BobS
I don't think you answered my question
You might need to reword the question then, because it sounds to me like he answered the question just fine.
musicfreak
My question is already in bold.
Indeed, you might need to be more specific, for example, about which comet technique you are referring to.As I said, most browsers interpret and execute a new <script> element as soon as it is loaded. This can be before the response connection is closed -- indeed, the server can push out <script> tags at intervals indefinitely, and the scripts will be executed one at a time. The one part that doesn't completely match what you are talking about is that it is really the scripts themselves that do the work, rather than client code detecting new data and acting on it.
BobS
But how can client side get response(which has `<script>` or whatever in it) from server before the connection is closed?
It's starting to sound like your question is more at the network level. I'm not an expert in this area. But a server *can* "flush" its output whenever it chooses, without closing the connection. At that point, the browser pretty much must accept whatever comes down the pipe, else that data would be lost. The browser could, if it wanted, just continually buffer the data it received, and wait for the connection to be closed, before processing the data. But the fact is that most browsers don't wait for the connection to be closed before processing this kind of data.
BobS
You can make a simple test like this to find that browsers will wait for the connection to be closed before processing:`<?phpecho("Hi! Have a random number: " . rand(1,10));/* Send a string after a random number of seconds (2-10) */sleep(20);`
To properly test this, you would need a server-side program that runs in a loop, and *flushes* the output each time it generates something worth flushing (I don't know php, can't help you out how to flush the output; I've used Java Servlets). What you've done probably buffers it on the server side until it's all ready to send. Try a simple php page that puts out part of the page at intervals, flushing after each portion. If you succeed, that should convince you that the client can get something before the connection is closed (and do something with that something).
BobS
I'm convinced it might be a weakness of PHP,which can't output response before closing connection.
Oops,I've found a way to output response before connection closed,but seems ajax request will hang:http://serverfault.com/questions/104648/is-this-http-servers-issue
Do you mean the flush works fine for a normal page request, but has problems when request is done through XmlHttpRequest (what I assume you mean by "ajax request")? Or do you mean (as the comments on the referenced page suggest can happen), that PHP just isn't cooperating when it comes to flushing? Or what?
BobS
It's the first case you mentioned.