You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Bert Huijben <be...@qqmail.nl> on 2015/12/04 22:27:23 UTC
RE: No H2 Window updates! (Probably a Serf issue!)
> -----Original Message-----
> From: Bert Huijben [mailto:bert@qqmail.nl]
> Sent: vrijdag 4 december 2015 21:45
> To: dev@httpd.apache.org
> Subject: RE: No H2 Window updates!
>
>
>
> > -----Original Message-----
> > From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> > Sent: vrijdag 4 december 2015 21:36
> > To: dev@httpd.apache.org
> > 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.
Bert
Re: No H2 Window updates! (Probably a Serf issue!)
Posted by Stefan Eissing <st...@greenbytes.de>.
Thanks for the quick update and the good news.
> Am 04.12.2015 um 22:46 schrieb Bert Huijben <be...@qqmail.nl>:
>
>
>
>> -----Original Message-----
>> From: Bert Huijben [mailto:bert@qqmail.nl]
>> Sent: vrijdag 4 december 2015 22:27
>> To: dev@httpd.apache.org
>> Subject: RE: No H2 Window updates! (Probably a Serf issue!)
>>
>>
>>
>>> -----Original Message-----
>>> From: Bert Huijben [mailto:bert@qqmail.nl]
>>> Sent: vrijdag 4 december 2015 21:45
>>> To: dev@httpd.apache.org
>>> Subject: RE: No H2 Window updates!
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
>>>> Sent: vrijdag 4 december 2015 21:36
>>>> To: dev@httpd.apache.org
>>>> 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
>
RE: No H2 Window updates! (Probably a Serf issue!)
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Bert Huijben [mailto:bert@qqmail.nl]
> Sent: vrijdag 4 december 2015 22:27
> To: dev@httpd.apache.org
> Subject: RE: No H2 Window updates! (Probably a Serf issue!)
>
>
>
> > -----Original Message-----
> > From: Bert Huijben [mailto:bert@qqmail.nl]
> > Sent: vrijdag 4 december 2015 21:45
> > To: dev@httpd.apache.org
> > Subject: RE: No H2 Window updates!
> >
> >
> >
> > > -----Original Message-----
> > > From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> > > Sent: vrijdag 4 december 2015 21:36
> > > To: dev@httpd.apache.org
> > > 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