Summary:
**Context**
The `BufAccessor` is used to access a contiguous section of memory. Right now, it works with a `Buf` under the hood.
**Overall plan**
The plan is to change the `BufAccessor` to use a `uint8_t*` instead. Since we're using section of contiguous memory, there's no need to use a chained buffer abstraction here. This'll move us closer to deprecating the usage `folly::IOBuf`.
**What this diff is doing**
Most use cases of the `BufAccessor` look like the following:
```
auto buf = bufAccessor.obtain();
// Do something with buf, like calling trimEnd
bufAccessor.release(buf)
```
I'm adding APIs to the `BufAccessor` so that there's no need to `obtain()` and `release()` the `Buf`. We'd instead just call an API on the `BufAccessor`, which would call that same API on the underlying `folly::IOBuf`. Later on, we'll change the `BufAccessor` to use a `uint8_t*` under the hood.
I'm currently leaving in the `obtain()`, `release()`, and `buf()` APIs because Fizz and the AsyncUDPSocket expect `folly::IOBuf` as inputs in many of their APIs. Once those callsites are migrated off `folly::IOBuf`, we can remove these APIs.
Reviewed By: mjoras
Differential Revision: D60973166
fbshipit-source-id: 52aa3541d0c4878c7ee8525d70ac280508b61e24
Summary:
cast from 64bit pointer -> 32bit integer is causing UBSAN build warnings - which spam out actual problems.
Quick fix to address warning
These size mismatch warnings can result in compilation failure under C++20
Reviewed By: dmm-fb
Differential Revision: D56070011
fbshipit-source-id: eeeb82e8e79ee2057da4aab99cd75b12e6656258
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:
We've been using `--config mvfst.use_libev=true` to link in mvfst mobile instead of full mvfst into CLI tools etc. It allowed for fast initial development, but is a pain when integrating into actual apps (e.g. ig4a).
This change adds a separate set of "mobile" targets that can be used instead of the buck config option.
The main (new) target that will be used is `quic/client:client_mobile` - this is a high level one that will be included by MNS.
Here is a list of all of the new targets:
```
* quic/client:client_mobile
* quic/client:state_and_handshake_mobile
* quic/fizz/client:fizz_client_handshake_mobile
* quic/happyeyeballs:happyeyeballs_mobile
* quic/api:transport_mobile
* quic/api:quic_batch_writer_mobile
* quic/common:events_mobile
* quic/common:timers_mobile
* quic/common:looper_mobile
* quic/common:quic_async_udp_socket_wrapper_mobile
* quic/common:quic_async_udp_socket_impl_mobile
* quic/common:socket_util_mobile
```
Most of the new "*_mobile" targets share a lot of deps with existing non-mobile targets, and I'll collapse those in a separate diff.
Reviewed By: jbeshay, lhuang04
Differential Revision: D49779629
fbshipit-source-id: ec33d9f82244148f57d580d03894823ba6bb4947
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:
Since the socket can sometimes support SO_TXTIME, support storing this in the batch writer. This is just a way to plumb it, the transport is not yet setting it.
A time of zero effectively doesn't use the socket option.
Reviewed By: kvtsoy
Differential Revision: D48532725
fbshipit-source-id: d21b7035ecb465c614688131601c309651852bbf
Summary: There's no need to call write when there's only one packet, since write just wraps writeGSO. This simplifies the use of options and will allow for setting a TXTIME when there's only one packet to send.
Reviewed By: kvtsoy
Differential Revision: D48526018
fbshipit-source-id: d934ddce8d3a35febb58ff253fc7a9bed3ef975c
Summary: Use WriteOptions instead of a single int to allow for txTime setting too
Reviewed By: mjoras
Differential Revision: D48218906
fbshipit-source-id: 00a1d4905b54ec0614860f9cdd8b58c9d6e6ef9a
Summary:
QuicBatchWriterFactoryMobile.cpp will be compiled for mvfst mobile,
QuicBatchWriterFactory.cpp will be used for normal mvfst.
Reviewed By: jbeshay, mjoras
Differential Revision: D47113897
fbshipit-source-id: eeda30f6205a9eec380f0304fc442464e10b8653
