We have class allocators for each QUIC frame types, but it would be better to use stack if we don't need to keep the generated frame instances.
Currently frames are kept in a vector until the packet that contain the frames is acked. If each frame generators could maintain information to regenerate frames until ack, we don't need to keep generated frame instances.
To do this, QUICStream need to keep data on its VIO until ack, which means we don't call consume() until ack. This makes sense because many unacked data would be buffered on a QUICStream if we read (consume) the VIO but the peer didn't ack. However, because packets can be lost, we cannot consume data sequentially, and we need a kind of random access interface for VIO.
We have class allocators for each QUIC frame types, but it would be better to use stack if we don't need to keep the generated frame instances.
Currently frames are kept in a vector until the packet that contain the frames is acked. If each frame generators could maintain information to regenerate frames until ack, we don't need to keep generated frame instances.
To do this, QUICStream need to keep data on its VIO until ack, which means we don't call consume() until ack. This makes sense because many unacked data would be buffered on a QUICStream if we read (consume) the VIO but the peer didn't ack. However, because packets can be lost, we cannot consume data sequentially, and we need a kind of random access interface for VIO.