On Tue, 3 Dec 2013, William Chan (³ÂÖDzý) 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. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 4 December 2013 02:56:38 UTC