On Wed, Jun 08, 2022 at 09:22:31AM -0400, Glenn Strauss wrote:
> 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
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
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
On Wed, Jun 08, 2022 at 08:28:18AM +0200, Willy Tarreau wrote:
> On Tue, Jun 07, 2022 at 05:24:09PM -0400, Glenn Strauss wrote:
> > Yes, having the server merge the sizes of small DATA frames into a
> > larger WINDOW_UPDATE might be useful, too, but is independent and
> > complimentary to my patch
Hello Glenn,
On Tue, Jun 07, 2022 at 05:24:09PM -0400, Glenn Strauss wrote:
> On Tue, Jun 07, 2022 at 09:27:43AM -0700, Willy Tarreau wrote:
> > Hello Glenn,
> >
> > Thanks for your report, I understand the problem, that's very interesting.
> > I would say it's not even an optim, rather an
On Tue, Jun 07, 2022 at 09:27:43AM -0700, Willy Tarreau wrote:
> Hello Glenn,
>
> Thanks for your report, I understand the problem, that's very interesting. I
> would say it's not even an optim, rather an approach trying to help the whole
> ecosystem at a very low cost by preventing known
6 matches
Mail list logo
