]> git.ipfire.org Git - thirdparty/haproxy.git/commit
MINOR: mux-h2: create and initialize an rx offset per stream
authorWilly Tarreau <w@1wt.eu>
Tue, 27 Aug 2024 16:57:45 +0000 (18:57 +0200)
committerWilly Tarreau <w@1wt.eu>
Sat, 12 Oct 2024 14:29:15 +0000 (16:29 +0200)
commiteb0fe66c61359987ad5ee853b0a11699516b34b7
treeaf6280c057bb0b062d02180eac620575c83112f9
parent560e474cdde1efa306ea3e6b2d0dcd425db0f76e
MINOR: mux-h2: create and initialize an rx offset per stream

In H2, everything is accounted as budget. But if we want to moderate
the rcv window that's not very convenient, and we'd rather have offsets
instead so that we know where we are in the stream. Let's first add
the fields to the struct and initialize them. The curr_rx_ofs indicates
the position in the stream where next incoming bytes will be stored.
last_adv_ofs tells what's the offset that was last advertised as the
window limit, and next_max_ofs is the one that will need to be
advertised, which is curr_rx_ofs plus the current window. next_max_ofs
will have to cause a WINDOW_UPDATE to be emitted when it's higher than
last_adv_ofs, and once the WU is sent, its value will have to be copied
over last_adv_ofs.

The problem is, for now wherever we emit a stream WU, we have no notion
of stream (the stream might even not exist anymore, e.g. after aborting
an upload), because we currently keep a counter of stream window to be
acked for the current stream ID (h2c->dsi) in the connection (rcvd_s).
Similarly there are a few places early in the frame header processing
where rcvd_s is incremented without knowing the stream yet. Thus, lookups
will be needed for that, unless such a connection-level counter remains
used and poured into the stream's count once known (delicate).

Thus for now this commit only creates the fields and initializes them.
src/mux_h2.c