Summary: The bug here is that we weren't accounting for the DSR state when checking if the stream should be closed. This causes the stream state to live until the connection closes.
Reviewed By: yairgott
Differential Revision: D36269711
fbshipit-source-id: 403268db1940b2f00130709243aa6df1d2af39cd
Summary: - helper methods to determine if a stream is server-unidirectional and client-bidirectional
Reviewed By: jbeshay
Differential Revision: D35267009
fbshipit-source-id: 20d3a77034cb70d1662c7b513594b58e675231dc
Summary: Provide observers with visibility into stream events triggered by local and peer (e.g., new stream opened locally or by peer).
Reviewed By: mjoras
Differential Revision: D31886978
fbshipit-source-id: 7556fef0f336bd0f190b4474f1a7b0120aae6ef1
Summary:
Real stream data and BufferMeta represented data will be scheduled by different
schedulers. For that reason, this diff adds another PriorityQueue into the stream
manager.
Reviewed By: mjoras
Differential Revision: D26132498
fbshipit-source-id: c69cb671c9a9f975d82efab8f1244a2f3c6c9297
Summary:
I think this should just work without the trailing `_E`. It was added
when we mixed up our own union based variant and boost::variant. Some compiler
flags didn't like that. Now we no longer have mixed up cases, this should be
fine
Reviewed By: lnicco
Differential Revision: D25589393
fbshipit-source-id: 6430dc20f8e81af0329d89e6990c16826da168b8
Summary:
This is following a similar pattern than what was done for the client side.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/160
Reviewed By: yangchi
Differential Revision: D23560951
Pulled By: xttjsn
fbshipit-source-id: 351417cbfa3230112fff4c4de59b307f88389cf6
Summary:
Adds support for timestamping on TX (TX byte events). This allows the application to determine when a byte that it previously wrote to the transport was put onto the wire.
Callbacks are processed within a new function `QuicTransportBase::processCallbacksAfterWriteData`, which is invoked by `writeSocketDataAndCatch`.
Reviewed By: mjoras
Differential Revision: D22008855
fbshipit-source-id: 99c1697cb74bb2387dbad231611be58f9392c99f
Summary:
Turns out we weren't removing all the state from closed streams that we should have been.
Additionally, getStream can return `nullptr`. It is up to the caller to either check this or check `streamExists` first.
Reviewed By: yangchi
Differential Revision: D21047999
fbshipit-source-id: b477d44cfb02d5e1e3e8a805ab94bba87f1e8f1b
Summary:
As it turns out, the extra indirection from storing a unique_ptr is not worse than the gain from using an `F14ValueMap` versus an `F14VectorMap`.
This reduces the `find` cost measurably in profiles, and doesn't appear to have any real negative effects otherwise.
Reviewed By: yangchi
Differential Revision: D20923854
fbshipit-source-id: a75c4649ea3dbf0e6c89ebfe0d31d082bbdc31fd
Summary: This isn't a huge source of cycles, but the flushing of the cache does show up in tperf. Turns out this is very easy to do, and exposed another minor problem which is that we were misusing `clear()` on the `IOBufQueue`. Instead we should have been using `move()` to reset it to being empty.
Reviewed By: siyengar
Differential Revision: D18758922
fbshipit-source-id: 6dcbc29e8bebd93b5787939176799e3df90ed94d
Summary:
The retransmission buffer tracks stream frame data we have sent that is currently unacked. We keep this as a sorted `deque`. This isn't so bad for performance, but we can do better if we break ourselves of the requirement that it be sorted (removing a binary search on ACK).
To do this we make the buffer a map of offset -> `StreamBuffer`.
There were two places that were dependent on the sorted nature of the list.
1. For partial reliablity we call `shrinkBuffers` to remove all unacked buffers less than an offset. For this we now have to do it with a full traversal of the retransmission buffer instead of only having to do an O(offset) search. In the future we could make this better by only lazily deleting from the retransmission buffer on ACK or packet loss.
2. We used the start of the retransmission buffer to determine if a delivery callback could be fired for a given offset. We need some new state to track this. Instead of tracking unacked buffers, we now track acked ranges using the existing `IntervalSet`. This set should be small for the typical case, as we think most ACKs will come in order and just cause existing ranges to merge.
Reviewed By: yangchi
Differential Revision: D18609467
fbshipit-source-id: 13cd2164352f1183362be9f675c1bdc686426698
Summary: The state machine logic is quite abstruse, this modifies it to make it more readable.
Reviewed By: siyengar
Differential Revision: D18488301
fbshipit-source-id: c6fd52973880931e34904713e8b147f56d0c4629
Summary:
The idea of having a sorted deque to do this makes some sense, but it ends up extremely inefficient for workloads that churn through a lot of streams.
Mitigate this by instead tracking the open streams with a `FastSet`. For a very small number of streams this will probably be slightly less efficient, but not measurably.
Reviewed By: kvtsoy
Differential Revision: D18409885
fbshipit-source-id: 2214640682926b4b4525700df85627f6125cabe8
Summary:
F14 should be faster and have lower memory urilization for near-empty sets and maps. For most H3 connections these are mosotly going to be near-empty, so CPU wins will likely be minimal.
For usecases that have extremely high numbers of streams, there are likely going to be CPU wins.
Reviewed By: yangchi
Differential Revision: D18484047
fbshipit-source-id: 7f5616d6d6c8651ca5b03468d7d8895d1f51cb53
Summary:
This will allow to be able to create different kind of handshake going forward.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/59
Reviewed By: siyengar
Differential Revision: D18088574
Pulled By: mjoras
fbshipit-source-id: 0732bb63a9e243fef77cdaf4f76e711fcb09ecdc
Summary: For protocols like HTTP/3, lacking an actual priority scheme, it's a good idea to write control streams before non control streams. Implement this in a round robin fashion in the same way we do for other streams.
Reviewed By: afrind
Differential Revision: D18236010
fbshipit-source-id: faee9af7fff7736679bfea262ac18d677a7cbf78
Summary:
The function indeed compares a Stream frame to a buffer, not an Ack
frame to a buffer.
Reviewed By: sharma95
Differential Revision: D18000632
fbshipit-source-id: fbbc36378404f8f52a199114af48b9020d0569e8
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:
With partial reliability we adjust retransmission queue on skips; we need to account for that when we match buffers in retransmission queue.
In fully reliable mode an ack frame must always match a single buffer from re-tranmission queue (offset, length and eom).
In partially reliable mode we can run into two more scenarios in addition to the above:
* re-transmisison buffer for which the ack frame arrived has been removed fully
* re-transmisison buffer for which the ack frame arrived has been removed partially
If full buffer is missing - ignore the ack.
If part of the buffer is missing, make sure that the adjusted offset and length match to that found in the ack frame.
Reviewed By: yangchi
Differential Revision: D15301304
fbshipit-source-id: f281fa30957c1c13c42c05684984f9a1acaa4e34
Summary: This is step 1 for removing reset on reset, since the send side may need to transition to waiting for a reset ack while the read side is an any state.
Reviewed By: lnicco
Differential Revision: D15075849
fbshipit-source-id: 1e094942a8a1ca9a01d4161cd6309b4136a9cfbf
