- From: 陈智昌 <willchan@chromium.org>
- Date: Tue, 3 Dec 2013 19:05:56 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: Michael Meier <mm@sigsegv.ch>, whatwg@lists.whatwg.org, Takeshi Yoshino <tyoshino@google.com>, Nicholas Wilson <nicholas@nicholaswilson.me.uk>
On Tue, Dec 3, 2013 at 6:56 PM, Ian Hickson <ian@hixie.ch> wrote: > On Tue, 3 Dec 2013, William Chan (陈智昌) wrote: > > > > > > If the server is generating data in response to some real-time query, > > > e.g. the results of a search on Twitter or some such, then what is the > > > server going to do with backpressure? Drop the data on the floor? > > > Whether the client drops the data on the floor or the server drops the > > > data on the floor doesn't much affect the user, though obviously if > > > the client is dropping it then the bandwidth is being wasted. > > > > Buffer the data. Read from the backend when the flow control window > > opens up. I mean, that's what would happen if there was packetloss in > > the network, leading to retransmissions, and possibly the TCP receive > > window shrunk to 0. Irrespective of whether or not the browser websocket > > client has some way to instruct the browser to stop reading from the > > socket, there's always a possibility of the receive window shrinking to > > 0, and the server *must* deal with it, in order to be a compliant TCP > > implementation. > > The context of this thread is that the application (server+client) is > expected to do something _other_ than just buffering, because the premise > is that the client will never be able to process the data at the rate that > the client is receiving it, which is (presumably) the rate the server is > generating it. Just buffering doesn't help. > I assume you mean it has to do something other than just buffer, because it runs out of memory. At that point, it must stop generating data. Flow control must be applied through the system. I was just pointing out that there are multiple reasons that the sender (the server) may need to stop sending. It could be because the client can't process as fast as possible (it could be the browser network stack is slow, or it could be the web app is slow). Or it could be the lossy network. It doesn't matter, the server portion of the app needs to buffer and perhaps stop generating data (stop reading from a filesystem or backend or whatever). > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Received on Wednesday, 4 December 2013 03:06:24 UTC