On Wed, Jun 08, 2022 at 08:29:48AM -0400, Glenn Strauss wrote:
> > I agree that it's independent but it's the one that is not expected to
> > cause any regression with any possible client. That's why I'd like to
> > have the two. First that one because it should be durable. Second, your
> > patch as an optimization, and if anyone complains about trouble with it
> > we can safely revert it or decide what to do without worrying about all
> > deployed curl clients that will not be updated.
> Were this to cause a theoretical regression, this default initial window
> size can be configured in haproxy, so the workaround is to configure the
> value back to 65535.

Sure, that can be a workaround. But when it causes regressions in the
middle of a stable branch and affects users, the correct fix is to revert
and keep it only for major releases, with release notes advertising the
change of behavior.

> > > The upcoming lighttpd 1.4.65
> > > does just that, collecting updates until 16384 is reached, and then
> > > sending a WINDOW_UPDATE for 16384.  Cost: a single 1-RTT delay in
> > > sending a WINDOW_UPDATE to continue uploads larger than 112k-1.
> > 
> > It can definitely cause some inefficient clients to hang if they need
> > their buffer to be fully acked and their size is not a multiple of the
> > frame size. Be careful about this.
> I ended up adjusting this before releasing lighttpd 1.4.65.
> For the same few instructions, lighttpd 1.4.65 now sends WINDOW_UPDATE
> for 16384 when lighttpd receives the first DATA frame containing data
> (1-16384 bytes), and then does not send WINDOW_UPDATE until the next
> 16384 block is started.  This avoids any delay in sending WINDOW_UPDATE,
> though it does (temporarily) increase the window size allowed in the
> client if the client has not already sent data consuming the window.


> > > 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.


Reply via email to