httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: No H2 Window updates! (Probably a Serf issue!)
Date Fri, 04 Dec 2015 21:50:44 GMT
Thanks for the quick update and the good news. 

> Am 04.12.2015 um 22:46 schrieb Bert Huijben <bert@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 
> 

Mime
View raw message