Skip to content

Make waitStream update connection flow control window.#75

Merged
lucasdicioccio merged 3 commits intohaskell-grpc-native:masterfrom
Concordium:conn-window-update
Jan 13, 2021
Merged

Make waitStream update connection flow control window.#75
lucasdicioccio merged 3 commits intohaskell-grpc-native:masterfrom
Concordium:conn-window-update

Conversation

@abizjak
Copy link
Contributor

@abizjak abizjak commented Jan 9, 2021

From RFC 7540


   Flow control in HTTP/2 is implemented using a window kept by each
   sender on every stream.  The flow-control window is a simple integer
   value that indicates how many octets of data the sender is permitted
   to transmit; as such, its size is a measure of the buffering capacity
   of the receiver.

   Two flow-control windows are applicable: the stream flow-control
   window and the connection flow-control window.  The sender MUST NOT
   send a flow-controlled frame with a length that exceeds the space
   available in either of the flow-control windows advertised by the
   receiver.  Frames with zero length with the END_STREAM flag set (that
   is, an empty DATA frame) MAY be sent if there is no available space
   in either flow-control window.

   For flow-control calculations, the 9-octet frame header is not
   counted.

   After sending a flow-controlled frame, the sender reduces the space
   available in both windows by the length of the transmitted frame.

   The receiver of a frame sends a WINDOW_UPDATE frame as it consumes
   data and frees up space in flow-control windows.  Separate
   WINDOW_UPDATE frames are sent for the stream- and connection-level
   flow-control windows.

   A sender that receives a WINDOW_UPDATE frame updates the
   corresponding window by the amount specified in the frame.

In particular waitStream did not automatically update the connection flow
control window, leading to stalls, and reliance on external updates (i.e.,
another background thread had to periodically send connection window updates),
which is less than ideal.

Closes #74

From RFC 7540

```

   Flow control in HTTP/2 is implemented using a window kept by each
   sender on every stream.  The flow-control window is a simple integer
   value that indicates how many octets of data the sender is permitted
   to transmit; as such, its size is a measure of the buffering capacity
   of the receiver.

   Two flow-control windows are applicable: the stream flow-control
   window and the connection flow-control window.  The sender MUST NOT
   send a flow-controlled frame with a length that exceeds the space
   available in either of the flow-control windows advertised by the
   receiver.  Frames with zero length with the END_STREAM flag set (that
   is, an empty DATA frame) MAY be sent if there is no available space
   in either flow-control window.

   For flow-control calculations, the 9-octet frame header is not
   counted.

   After sending a flow-controlled frame, the sender reduces the space
   available in both windows by the length of the transmitted frame.

   The receiver of a frame sends a WINDOW_UPDATE frame as it consumes
   data and frees up space in flow-control windows.  Separate
   WINDOW_UPDATE frames are sent for the stream- and connection-level
   flow-control windows.

   A sender that receives a WINDOW_UPDATE frame updates the
   corresponding window by the amount specified in the frame.

```

In particular `waitStream` did not automatically update the connection flow
control window, leading to stalls, and reliance on external updates (i.e.,
another background thread had to periodically send connection window updates),
which is less than ideal.
`creditDataFrames` is run as part of the main dispatch loop already, and does
the job of crediting, but not sending the updates.
@lucasdicioccio
Copy link
Member

Looks good, would you mind: adding some Changelog entry (especially, to credit yourself).

I'll do some tests over next week and do some release (will need to bump the version).
We'll need to update http2-client-exe and http2-grpc-client in a not-too-distant future.

@abizjak
Copy link
Contributor Author

abizjak commented Jan 11, 2021

Yes, will do.

@abizjak
Copy link
Contributor Author

abizjak commented Jan 12, 2021

I added additional documentation and a changelog entry, as well as created two PRs in the repos you mentioned

@lucasdicioccio
Copy link
Member

Looks great! will need to do some manual checks before releasing but will be merging. Thanks, and making the other PRs is grand!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Issue with waitStream connection window updates

2 participants