On Sat, Mar 21, 2015 at 1:15 AM, Stuart Douglas <stuart.w.douglas@gmail.com> wrote: > Very much so. Per stream flow control is essential for buffer management > on the server. > > Basically my server implementation has to keep reading from the socket, to > make sure that any new messages are received and acted on in a timely > manner, and to allow multiplexing to work correctly. Consider the case of a > client uploading a large file, where for whatever reason the end user > application is slow to read the data (perhaps it is doing some database > operations before it starts to read the file data). If we did not have per > stream flow control I would only have three options: > > - buffer a potentially unbounded amount of data > - stop reading from the socket (HOL blocking) > - kill the connection > > All these options suck, but with per stream flow control I know I will > never have to buffer more than the window size (as we don't send > WINDOW_UPDATE until the application has consumed the data). > > Another good example of why per stream flow control is necessary is a load > balancer, with a fast connection to backend servers, and a slow connection > to the remote clients. If we did not have per stream flow control the > backend servers would just dump all their data straight to the load > balancer, forcing it to either block or buffer (you implied that TCP level > flow control should be sufficient for this case, however this is only true > if your load balancer maintains a 1:1 connection between the client and a > backend server, which is generally not the case. > This is an excellent writeup! It captures exactly the tradeoffs which led to the addition of per-stream flow control to the protocol. Well said!
Received on Saturday, 21 March 2015 23:37:52 UTC