On Wed, Jun 08, 2022 at 02:42:10PM +0200, Willy Tarreau wrote: > On Wed, Jun 08, 2022 at 08:29:48AM -0400, Glenn Strauss wrote: > > > > Another approach might be to pre-emptively effectively double the > > > > window size by sending WINDOW_UPDATE with the entire window size (65535) > > > > back to the client upon receive of first DATA frame, and then keeping > > > > track on server-side until that 65535 is exhausted before sending > > > > another WINDOW_UPDATE. > > > > > > Sending too large stream window sizes is problematic when some streams > > > can be processed slowly, as it easily causes head-of-line blocking. If > > > the advertised window is larger than the available storage, a paused > > > stream will block other ones. > > > > <sigh> we know that poorly written code knows no bounds. Since the > > server is permitted to increase the window size, inability by the client > > to increase the window size is a bug in the client. The client need > > only track the window size -- the client need not actually use the extra > > window size if the client does not wish to do so. > > I was not speaking about the client but the server. If the server > advertises more than it can buffer itself, you can end up with blocked > streams: there's an elephant in the pipe that you can't pull completely > because you have nowhere to store it, and because of this you can't > access other frames that follow (the funniest ones being window updates > from the client that are expected to release some room on the response > side, but that basically only happens with echo servers). But you can > leave headers frames hanging making the client think the server is taking > time to process the requests while in fact the requests are not yet parsed, > they're just blocked.
The generic statement you make is true, but does not apply here unless the server would not have sent the WINDOW_UPDATE to replenish the window, in which case the answer is to defer sending the WINDOW_UPDATE. Since DATA frames might be in flight on the network, the server may want to be able to buffer twice the advertisted window size and defer sending WINDOW_UPDATE once the advertised window size is buffered. Doing so gives the elephant in the pipe just enough space for a well-behaved client adhering to the window size restrictions, and without the undesirable thought of delaying the send WINDOW_UPDATE frames by RTT. Cheers, Glenn
