Summary:
There are many files in this diff, but the relevant ones are:
* quic/api/QuicSocket.h
* quic/api/QuicSocketLite.h
* quic/api/QuicTransportBase.h
* quic/api/QuicTransportBaseLite.cpp
* quic/observer/SocketObserverContainer.h
The purpose of this is to include the observer functionality within the Lite class. Ideally, we'd remove it from the Lite class, but that's going to require some more detailed changes to the interfaces we're using, because observers are used quite a lot within common code (for example, AckHandlers.cpp).
I'll make those changes some time after the QuicTransportBase split, as they're going to take a while.
Reviewed By: jbeshay, mjoras, kvtsoy
Differential Revision: D65685667
fbshipit-source-id: feb07bcf35d6af2e5c2b538ff463b01b67c6aff9
Summary:
I have need of these in the proxygen WebTransport implementation, and don't want the full dependency on QuicSocket.
Also refactored WriteCallback into StreamWriteCallback and ConnWriteCallback, leaving the original WriteCallback as both for now.
Reviewed By: hanidamlaj
Differential Revision: D63486821
fbshipit-source-id: 4b16ad871c4deac4e262c12835ad5c457e9240da
Summary: We have a lot of optionals that are either integral values or std::chrono::microseconds. These end up wasting memory, where we can instead store sentinel values to encode whether the value is there or not. This reduces the effective range of the type by one value, but that is an acceptable tradeoff.
Reviewed By: kvtsoy
Differential Revision: D57684368
fbshipit-source-id: b406b86011f9b8169b6e5e925265f4829928cc63
Summary:
The idea here is to make it so we can swap out the type we are using for optionality. In the near term we are going to try swapping towards one that more aggressively tries to save size.
For now there is no functional change and this is just a big aliasing diff.
Reviewed By: sharmafb
Differential Revision: D57633896
fbshipit-source-id: 6eae5953d47395b390016e59cf9d639f3b6c8cfe
Summary: So client conn can be queried
Reviewed By: mjoras
Differential Revision: D56787895
fbshipit-source-id: fbd76aed35910e36075739d3e6f1775d6600c225
Summary:
std::deque by default allocates a large block on the heap for managing its state. This has a fixed memory cost both per connection (because of the crypto streams) and per stream. CircularDeque by comparison does not have this overhead and is only 32 bytes per structure.
For example:
```
"size": 656,
"name": "readBuffer",
"typePath": ["a0", "conn_", "ptr_val", "cryptoState", "ptr_val", "initialStream", "readBuffer"],
"typeNames": ["std::deque<quic::StreamBuffer, std::allocator<quic::StreamBuffer>>"],
```
This should save about 6kB per connection with no streams, and additional memory per stream.
Reviewed By: jbeshay, hanidamlaj
Differential Revision: D56578219
fbshipit-source-id: ab2b529fa9a4169bea6862b11ccbf178c6f5abb1
Summary:
std::deque by default allocates a large block on the heap for managing its state. This has a fixed memory cost both per connection (because of the crypto streams) and per stream. CircularDeque by comparison does not have this overhead and is only 32 bytes per structure.
For example:
```
"size": 656,
"name": "readBuffer",
"typePath": ["a0", "conn_", "ptr_val", "cryptoState", "ptr_val", "initialStream", "readBuffer"],
"typeNames": ["std::deque<quic::StreamBuffer, std::allocator<quic::StreamBuffer>>"],
```
This should save about 6kB per connection with no streams, and additional memory per stream.
Reviewed By: kvtsoy
Differential Revision: D56496459
fbshipit-source-id: ec4049614939f885f64481bd374c81e74ad47c66
Summary: I'm putting this up to get some initial feedback. I'm writing a function to get the peer transport parameters so that we can get them in the HQSession and set the QUIC fingerprint.
Reviewed By: hanidamlaj
Differential Revision: D54399572
fbshipit-source-id: 594294c26a5b34bc99a8d286a66be9cdbe7fff02
Summary: Adding virtual method getSelfCertificate to QuicSocket that's overriden in QuicServerTransport that returns the server cert.
Reviewed By: mjoras
Differential Revision: D54234662
fbshipit-source-id: fcef6399bc660ff41243336aacdfadd6e8975193
Summary:
This is the major transition that updates mvfst code to use the new interfaces. The new Folly implementations of the interfaces maintain all the existing behavior of folly types so this should not introduce any functional change. The core changes are:
- Update the BatchWriters to use the new interfaces.
- Update the FunctionLooper to use the new interfaces.
- Change QuicServerTransport to take the folly types and wrap them in the new types for use in the QuicTransportBase.
The rest of the diff is for updating all the existing uses of the QuicTrasnport to initialize the necessary types and pass them to the QUIC transport instead of directly passing folly types.
Reviewed By: mjoras
Differential Revision: D51413481
fbshipit-source-id: 5ed607e12b9a52b96148ad9b4f8f43899655d936
Summary: Move the callback to before the stream is destroyed.
Reviewed By: jbeshay
Differential Revision: D52127833
fbshipit-source-id: 1a9dbcf9ad92dbdb4e15409a418307dc6852b091
Summary: This is potentially useful to an application to know when the underlying stream state has been freed by the transport.
Reviewed By: jbeshay
Differential Revision: D52048888
fbshipit-source-id: e7b2d33c3702ce8aa348459a37094198d16af60f
Summary:
`connSetupCallback_` and `connCallback_` in `QuicTransportBase.h` are raw pointers, which delegates the responsibility to keep these callbacks alive to the caller.
There are use cases where it would be convenient to be able to tie the lifetime of the callback to the Quic transport, e.g,. as long as the Quic transport is alive, it keeps the callbacks alive as well.
This diff uses MaybeManagedPtr to achieve this lifetime tie if desired. A MaybeManagedPtr intialized with a shared pointer manages lifetime of the contained object, whereas a MaybeManagedPtr initialized with a raw pointer does not manage lifetime of the contained object. This way caller can decide to pass in a shared ptr or raw pointer and achieve the desired behavior.
Note that we cannot simply use a shared_ptr for that. Using a shared_ptr would potentially mean that callbacks passed are destroyed when the transport is destroyed. Callbacks would not be destroyed if they were managed by a shared_ptr already, but this is something we cannot assume for every case. This would thus be a change in semantics to the current implementation, where the callbacks can outlive the transport.
Reviewed By: mjoras
Differential Revision: D49502381
fbshipit-source-id: 771a9328b99dc4f94f8e9679f9caf98af9180428
Summary:
This diff changes `QuicAsyncUDPSocketWrapper` so that it is an abstraction layer that inherits from `QuicAsyncUDPSocketType`, instead of simply being a container with aliases.
- Key changes in `QuicAsyncUDPSocketWrapper.h`, the rest of the updates switch us from using `QuicAsyncUDPSocketType` to `QuicAsyncUDPSocketWrapper`.
- It's difficult to mock the UDP socket today given that we expose the entire `folly::AsyncUDPSocket` type to the higher layers of the QUIC stack. This complicates testing and emulation because any mock / fake has to implement low level primitives like `recvmmsg`, and because the `folly::AsyncUDPSocket` interface can change over time.
- Pure virtual functions will be defined in `QuicAsyncUDPSocketWrapper` in a follow up diff to start creating an interface between the higher layers of the mvfst QUIC stack and the UDP socket, and this interface will abstract away lower layer details such as `cmsgs` and `io_vec`, and instead focus on populating higher layer structures such as `NetworkData` and `ReceivedPacket` (D48714615). This will make it easier for us to mock or fake the UDP socket.
This diff relies on changes to `folly::MockAsyncUDPSocket` introduced in D48717389.
--
This diff is part of a larger stack focused on the following:
- **Cleaning up client and server UDP packet receive paths while improving testability.** We currently have multiple receive paths for client and server. Capabilities vary significantly and there are few tests. For instance:
- The server receive path supports socket RX timestamps, abet incorrectly in that it does not store timestamp per packet. In comparison, the client receive path does not currently support socket RX timestamps, although the code in `QuicClientTransport::recvmsg` and `QuicClientTransport::recvmmsg` makes reference to socket RX timestamps, making it confusing to understand the capabilities available when tracing through the code. This complicates the tests in `QuicTypedTransportTests`, as we have to disable test logic that depends on socket RX timestamps for client tests.
- The client currently has three receive paths, and none of them are well tested.
- **Modularize and abstract components in the receive path.** This will make it easier to mock/fake the UDP socket and network layers.
- `QuicClientTransport` and `QuicServerTransport` currently contain UDP socket handling logic that operates over lower layer primitives such `cmsg` and `io_vec` (see `QuicClientTransport::recvmmsg` and `...::recvmsg` as examples).
- Because this UDP socket handling logic is inside of the mvfst transport implementations, it is difficult to test this logic in isolation and mock/fake the underlying socket and network layers. For instance, injecting a user space network emulator that operates at the socket layer would require faking `folly::AsyncUDPSocket`, which is non-trivial given that `AsyncUDPSocket` does not abstract away intricacies arising from the aforementioned lower layer primitives.
- By shifting this logic into an intermediate layer between the transport and the underlying UDP socket, it will be easier to mock out the UDP socket layer when testing functionality at higher layers, and inject fake components when we want to emulate the network between a mvfst client and server. It will also be easier for us to have unit tests focused on testing interactions between the UDP socket implementation and this intermediate layer.
- **Improving receive path timestamping.** We only record a single timestamp per `NetworkData` at the moment, but (1) it is possible for a `NetworkData` to have multiple packets, each with their own timestamps, and (2) we should be able to record both userspace and socket timestamps.
Reviewed By: jbeshay, hanidamlaj
Differential Revision: D48717388
fbshipit-source-id: 4f34182a69ab1e619e454da19e357a6a2ee2b9ab
Summary: An interface which will be extended by throttling detectors and will provide throttling signal to CCAs. This interface can be set through `QuicSocket` and can be accessed via `QuicConnectionStateBase`.
Reviewed By: silver23arrow, jbeshay
Differential Revision: D47027498
fbshipit-source-id: 6a2b9ee51ca54395e10500dd7c9787968cc281d4
Summary:
A wrapper for `folly::EventBase` to be used throughout mvfst library.
Right now it's simply a `using QuicEventBase = folly::EventBase` in the new `quic/common/Events.h`, so no functional changes.
The change to the wrapper usage is constrained to QuicTransportBase and the code around for now - basically excluding top level client and server code that is still using `folly::EventBase` directly.
Subsequent changes will introduce a proper wrapper implementation getting rid of `using QuicEventBase = folly::EventBase` in the new class.
Reviewed By: mjoras
Differential Revision: D44757549
fbshipit-source-id: 5a0dd120ec319a474452eaec64a27f660144acdf
Summary: Classifying loss as `byPto` is confusing because it is not related to Probe Timeouts (PTO). This changes the occurrences of this name in the transport code to `byTimeout`.
Reviewed By: mjoras, kvtsoy
Differential Revision: D45788216
fbshipit-source-id: 9900b928d3f44572a21d6ed7e76be658e21451c7
Summary:
## Context
Context: see summary for D43854603.
## In this diff
In this diff, make way for easily adding new elements to Priority struct.
Reviewed By: afrind
Differential Revision: D43882907
fbshipit-source-id: f74f6ec41162a970dcd666bfa5192676f968d740
Summary:
Eventually we'd like to replace mvfst's policy on how/when streams are reaped.
Currently, streams are reaped when we deliver eof to callback or callback is uninstalled via `setReadCallback(id, nullptr)`. We're working on removing the eof delivered to callback as a predicate to reaping streams.
Reviewed By: mjoras
Differential Revision: D43544949
fbshipit-source-id: 7ef84aefe702ae8686ccb95265a25060830b7013
