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:
This moves all the loop and timer callback operations back to the callbacks instead of relying the QuicEventBase to perform them. I.e. it's now Callback::cancelCallback() instead of QuicEventBase::cancelCallback(&callback).
To simplify the design, the lifetime of LoopCallbackWrapper and TimerCallbackWrapper has been changed. Previously these wrappers lasted for one iteration of the loop or the timer callback. In the new design the wrapper is created the first time the callback is scheduled and is only destroyed when the callback is destroyed. This significantly simplifies the lifetime management of the wrapper and the code overall.
While transitioning LibevQuicEventBase to this new design, this change also consolidates the QuicTimer functionality in the LibevQuicEventBase itself.
Reviewed By: hanidamlaj, mjoras
Differential Revision: D52217879
fbshipit-source-id: da7b95d592650ddc112813fdc3b9f5010d32e7fb
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:
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: Currently writePacketsGroup returns the number of packets it sent. Update it to return the number of bytes has been sent too.
Reviewed By: mjoras
Differential Revision: D34280604
fbshipit-source-id: 5cc4047401a00054a2bc0a0e7429a3beaa046f44
Summary: This doesn't belong in the generic state. Untangling it is a little difficult, but I think this solution is cleaner than having it in the generic state.
Reviewed By: JunqiWang
Differential Revision: D29856391
fbshipit-source-id: 1042109ed29cd1d20d139e08548d187b469c8398
Summary:
These are either no longer relevant, are unlikely to be done, or are spculative enough that they don't deserve code space.
Hope here is to make our search for TODOs higher signal.
Reviewed By: lnicco
Differential Revision: D29769792
fbshipit-source-id: 7cfa62cdc15e72d8b7b0cd5dbb5913ea3ca3dc5a
Summary: Since we try to write to two sockets it makes more sense to log both errnos.
Reviewed By: lnicco
Differential Revision: D29010998
fbshipit-source-id: 6c24007b45d83181a2d991e53c5a896aa3353200
Summary: Retriable is a bit of a misnomer here. It's more like "ignore these errors". Ignoring EMSGSIZE is probably not wise. That indicates the QUIC packets are being dropped. It may be a transient condition, but it's probably safer to just abandon this connection.
Reviewed By: lnicco
Differential Revision: D29008692
fbshipit-source-id: c2803804e24036e4b8b6ac0888cb2a917d83c15b
Summary: Without this we won't actually retransmit the 0RTT data on the second socket until they are declared lost after the handshake is done.
Reviewed By: JunqiWang
Differential Revision: D28942340
fbshipit-source-id: 192c9ca0544bfde9610720ca1b02322709f0e61e
Summary:
It doesn't and shouldn't modify it ever
(Note: this ignores all push blocking failures!)
Reviewed By: mjoras
Differential Revision: D27786706
fbshipit-source-id: fc57c434bd1d97e177e55ec529d4173b7e7d6086
Summary:
all it wants is just a pointer to the statsCallback member
(Note: this ignores all push blocking failures!)
Reviewed By: mjoras
Differential Revision: D27786211
fbshipit-source-id: 3364681348ee01684d6cb8d2837bee9549f64e3a
Summary:
It doesn't depend on the state of the IOBufQuicBatch. Move it out so
other writers can use this function in the future
Reviewed By: mjoras
Differential Revision: D21005960
fbshipit-source-id: b09f41f715a7908f74e490ca24eaec0e41f58a2c
Summary: We send conn close packets when network is un-rechable, this task fixes the issue and we no longer send conn close frames when network is un-rechable.
Reviewed By: yangchi, lnicco
Differential Revision: D18469028
fbshipit-source-id: 3090b6b3d63e1fc9448b8d945c645f4da8747ffc
Summary:
Becuase closeImpl will write again. Ideally in this case we should just
abandon the connection, but putting this bandage to prevent crash for now
Reviewed By: siyengar
Differential Revision: D15295421
fbshipit-source-id: d098e790c0c2609d817f5d1d3689858aa80a8b73
Summary:
Close the socket when fatal error occurred. This prevents quic transport from receiving readCallback from a bad socket.
Also, close the happy eyeball socket when transport is shutdown.
Reviewed By: siyengar
Differential Revision: D15264105
fbshipit-source-id: e6c33f626cdef6a4ebc6820e39ac78da525133d0
Summary:
Previously we decided to be conservative and error out the connetion
when either of the 2 sockets fails to write. This makes the happy eyeballs
component meaningless for e.g. IPv4 only network cases. This time we try to do it right.
The connection will keep track `shouldWrite` bool for both sockets. `shouldWriteToFirstSocket` is initialized to true and `shouldWriteToSecond` is initialized to false. Whenever **fatal** error occurs on a socket, the corresponding `shouldWrite` bool is changed to false. We are not finishing happy eyeballs state immediately but delaying this action to when we receive data back.
Reviewed By: siyengar
Differential Revision: D15261148
fbshipit-source-id: 3ee7de81a1d579e418be36bc2800d93d414abe3d
Summary:
Previously we tried continue on network down and it showed good
improvement. But there was a problem: it hurts UX for airplane mode users, it
didn't return error back to user immediately but after 30/60 seconds timeout.
This adds a timer for this feature and it only allows the transport to ignore
network unreachable error for 200ms. After 200ms, it throws and reports to user
if the error persists.
Reviewed By: siyengar
Differential Revision: D15089442
fbshipit-source-id: dd87f4f579187c4b45244a7ee0477d2a0cf1b5d7
