DATA_BLOCKED frames should be sent in the same as the STREAM frames that
resulted in the connection becoming blocked on connection flow control.
If there's not enough space left in that packet, the DATA_BLOCKED frame
is sent in the next packet.
* refactor the framer to pack both control and STREAM frames
* refactor framer STREAM frame packing logic
* pack STREAM_DATA_BLOCKED in the same packet as the STREAM frame
This makes debugging easier (and is slightly more efficient). In the
pathological case where there is not enough space remaning in the packet
to pack the STREAM_DATA_BLOCKED frame, it is queued for the next packet.
* add an integration test
* avoid accessing the streams map when packing stream data
* avoid accessing the streams map when packing flow control frames
* remove streamGetter interface
Under normal circumstances, we should be able to send out control frames
right away, so we don't expect any queue to build up. To defend against
resource exhaustion attacks, we limit the control frame queue to 16384
elements.
* implement and use ringbuffer in framer
* Add comments for ring buffer
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
---------
Co-authored-by: Marten Seemann <martenseemann@gmail.com>
For the last STREAM frame we omit the Length field. When packing STREAM
frames, we need to account for this byte saving when calculating the
length of the payload.
