Thanks for the quick update and the good news.
> Am 04.12.2015 um 22:46 schrieb Bert Huijben <[email protected]>: > > > >> -----Original Message----- >> From: Bert Huijben [mailto:[email protected]] >> Sent: vrijdag 4 december 2015 22:27 >> To: [email protected] >> Subject: RE: No H2 Window updates! (Probably a Serf issue!) >> >> >> >>> -----Original Message----- >>> From: Bert Huijben [mailto:[email protected]] >>> Sent: vrijdag 4 december 2015 21:45 >>> To: [email protected] >>> Subject: RE: No H2 Window updates! >>> >>> >>> >>>> -----Original Message----- >>>> From: Stefan Eissing [mailto:[email protected]] >>>> Sent: vrijdag 4 december 2015 21:36 >>>> To: [email protected] >>>> Subject: Re: No H2 Window updates! >>>> >>>> The code increases the window by the difference between max and >>> current >>>> so that the client has exactly the max value. nghttp2 accepts this on >> the >>> client >>>> side. It rejects any larger value as you described. >>>> >>>> So we seem to have a difference in calculation between nghttp2 and > serf. >>>> which values do you see? some data would be helpful here. >>> >>> The values are completely in the log file at the bottom of this mail. >>> >>> I open a connection and the server announces a default window of 65535. >>> >>>>> I: DBG: Allocated 131 bytes for window on stream 0x1 (left: 65404, >>> 65404) >>> I send a request with a DATA frame with a payload of 131 bytes, which >>> updates the stream and windows size with -131. >>> >>> So both the stream and connection windows are no longer default, but >>> 65404. >>> Logged for easy reading >>> >>> >>> Then I receive a WINDOW_UPDATE frame >>>>> I: DBG: Connection window update of 2147483392 to -2147418500 >>> Which tries to add 2147483392 to the existing window. >>> >>> Which doesn't fit, because the total outgoing window has to fit in >> 2^31-1... >>> See the RFC. >> >> Ok, I think I found a -and provably THE- problem in serf... >> >> There is a bug in decoding the window update frames... >> >> >> Reviewing and testing some bits there now. > > From r1718038 > > [[ > --- serf/trunk/protocols/http2_protocol.c (original) > +++ serf/trunk/protocols/http2_protocol.c Fri Dec 4 21:35:11 2015 > @@ -619,7 +619,7 @@ http2_handle_stream_window_update(void * > window_update = (const void *)data; > > value = (window_update->v3 << 24) | (window_update->v2 << 16) > - | (window_update->v2 << 8) | window_update->v0; > + | (window_update->v1 << 8) | window_update->v0; > > value &= HTTP2_WINDOW_MAX_ALLOWED; /* The highest bit is reserved */ > ]] > > This bug (also copied in another location) also explains the unusually small > window updates I received earlier... Most likely I missed a few interesting > bits in that second byte of the value, while the small window in httpd kept > the highest two bytes at 0. > > > The overflow of the max value is resolved by this patch... and the current > 2.4.x code goes through the test now without any windowing delays. > > > You might want to change the initial window back to something like 1MB or > 16MB now, to at least test cases where a further update is necessary. > > > I certainly don't get connection window updates after the first one now in > my usual testing. I don't test uploading over 2 GB in a usual Subversion > test run. > > > Bert >
