Summary:
Different Builders now want to have its own way of writing or
appending write buffer. So let builders handle them.
This also add new APIs in BufWriter to copy data from IOBuf/BufQueue directly
into a destination IOBuf without cloning inbetween.
Reviewed By: mjoras
Differential Revision: D20821789
fbshipit-source-id: c0a24eb12378f64cf26c27d4232f610ed80fba84
Summary:
As title.
For now the buildPacket() api will still build out separate IOBufs for header and body even though they are just two separate IOBuf wrapping continuous memory. This is so that API in other layers don't have to change for now, and I can reuse all the existing packet builder unit tests for the new builder.
Reviewed By: mjoras
Differential Revision: D20781977
fbshipit-source-id: 64e5ed9fbcff102ca20d3730511b02e6e7426b40
Summary:
The encoding logic is the same no matter what builder and what IOBuf
manipulater we use. Make these functions reusable.
This requires the QuicInteger encode function to support both BufAppender and
BufWriter. Note that the template is on a callable object. Because later on we
will also need to support wrapped memcpy that isn't a member function.
Reviewed By: mjoras
Differential Revision: D20781979
fbshipit-source-id: 1b8cbdfd7580132c113b12687f932d47207a7cce
Summary:
Previously we stored an `IntervalSet` in each `WriteAckFrame`. We don't need to do this, as by the time we are writing an `ACK` the `IntervalSet` is complete. Instead of bothering with the `IntervalSet` operations, we can simply serialize it to a reverse-sorted `vector.`
Additionally this has some micro-optimizations for filling the ACK frame, with a new function for getting varint size.
Reviewed By: yangchi
Differential Revision: D19397728
fbshipit-source-id: ba6958fb36a4681edaa8394b1bcbbec3472e177d
Summary: By modifying `IntervalSet` a bit we can make it so it takes a `folly::small_vector` as the container. We expect that for real traffic there will not generally be a lot of ACK blocks per frame, so optimize for that.
Reviewed By: siyengar
Differential Revision: D18919975
fbshipit-source-id: 199a2ea9ba5003382e2d7d99fc7a6de7e8aafdca
Summary:
Don't use IOBufQueue for most operations in mvfst and use BufQueue instead. Since BufQueue did not support a splitAtMost, added it in instead.
The only place that we still use IOBufQueue is in crypto because fizz still requires it
Reviewed By: mjoras
Differential Revision: D18846960
fbshipit-source-id: 4320b7f8614f8d2c75f6de0e6b786d33650e9656
Summary:
Don't clone during decoding a stream frame.
This uses a BufQueue to manage the data instead of passing around cursors.
Reviewed By: yangchi
Differential Revision: D18827718
fbshipit-source-id: 7874d308bb5f43b983b9965b2862e733a2107039
Summary: As a part of Draft 17, application close frame has been removed, we use connection close frame to represent both application close and connection close.
Reviewed By: mjoras
Differential Revision: D18580856
fbshipit-source-id: d274fa2d3dbc59b926bca5a2b8a20328ae582703
Summary:
Get rid of IObufQueue usage in the PacketBuilder and replace it with a vanilla IOBuf.
This requires replacing QueueAppender with something else as well, so this diff adds a new class call BufAppender which does exactly the same things as a QueueAppender.
Having a BufAppender will allow us to avoid cloning the stream buffer in the future and avoid a clone during the write path.
Reviewed By: mjoras
Differential Revision: D18673517
fbshipit-source-id: 31fd7758688686371d038111514eb62d6b21672c
Summary:
Use the custom variant type for write frames as well, now that
we use them for read frames.
Reviewed By: mjoras
Differential Revision: D17776862
fbshipit-source-id: 47093146d0f1565c22e5393ed012c70e2e23d279
Summary:
Create a custom type for read frame types. This allows us to reduce size of code.
We use a macro to generate new variant types whenever we need to.
Reviewed By: yangchi
Differential Revision: D17266468
fbshipit-source-id: 59a1183dce728e71f0924f39f95a7b78449642b0
Summary:
Make a custom variant type for PacketHeader. By not relying on boost::variant
this reduces the code size of the implementation.
This uses a combination of a union type as well as a enum type to emulate a variant
Reviewed By: yangchi
Differential Revision: D17187589
fbshipit-source-id: 00c2b9b8dd3f3e73af766d84888b13b9d867165a
Summary:
Implement sending stream limit updates in a windowed fashion, so that as a peer exhausts its streams we will grant it additional credit. This is implemented by having the stream manager check if an update is needed on removing streams, and the api layer potentially sending an update after it initiates the check for closed streams.
This also makes some driveby changes to use `std::lower_bound` instead of `std::find` for the sorted collections in the stream manager.
Reviewed By: yangchi
Differential Revision: D16808229
fbshipit-source-id: f6e3460d43e4d165e362164be00c0cec27cf1e79
Summary:
Prior to this diff we would clone out an entire flow control's worth of data from the writebuffer and then clone out a smaller portion of that to write into the packet builder. This is extremely wasteful when we have a large flow control window.
Additionally we would always write the stream data length field even when we are going to fill the remainder of the packet with the current stream frame. By first calculating the amount of data that needs to can be written and writing the header, we can now omit the data length field when we can fill the whole packet.
Reviewed By: yangchi
Differential Revision: D15769514
fbshipit-source-id: 95ac74eebcde87dd06de54405d7f69c42362e29c
Summary: These were changed to varints. To support this we need to do some extra horrible version plumbing. I don't want to keep this long term but it works for now.
Reviewed By: yangchi
Differential Revision: D16293568
fbshipit-source-id: a9ea9083be160aa3e6b338a7d70d7f00e44ec5ab
Summary: post draft-17 it is interpreted as count not the max stream id
Reviewed By: mjoras
Differential Revision: D15523021
fbshipit-source-id: 779a1c5269eb8dbcdcd169303caa7a65e467339c
Summary:
The plan is to not treat probing frame as simple frame, but that is not
going to happen soon.
Reviewed By: sharma95
Differential Revision: D15176635
fbshipit-source-id: 62ac13cdb82a09161e9148dfc437cf7377a01c96
