Summary:
This commit converts IntervalSet to use CHECKs instead of throwing exceptions and provides safe tryInsert methods that return quic::Expected for error handling.
**Core Problem Solved:**
IntervalSet was throwing `std::invalid_argument` exceptions in two scenarios:
1. When constructing an Interval with `start > end`
2. When interval bounds exceed the maximum allowed value
This change eliminates exceptions in favor of CHECKs (for internal validation) and Expected-based error handling (for caller validation).
**Implementation Details:**
**1. IntervalSet Core Changes:**
- Replaced `throw std::invalid_argument` with `CHECK_LE` in Interval constructor
- Replaced `throw std::invalid_argument` with `CHECK_LE` in `insert(start, end)`
- Added `IntervalSetError` enum for error classification
- Added `folly::Expected` include
**2. Safe API Layer:**
- Added `tryInsert(interval)` method returning `Expected<Unit, IntervalSetError>`
- Added `tryInsert(start, end)` method with pre-validation
- Added `tryInsert(point)` method
- Added static `Interval::tryCreate()` method for safe interval construction
**3. Updated Code:**
- **QuicWriteCodec.cpp**: Updated `fillFrameWithPacketReceiveTimestamps` to use `tryInsert`
- Returns `QuicError` if interval validation fails
- Maintains existing error handling patterns
- **QuicTransportFunctions.cpp**: Updated `implicitAckCryptoStream` to use `tryInsert`
- Logs errors and continues processing other packets
- Robust error handling for crypto stream implicit acks
Reviewed By: kvtsoy
Differential Revision: D76792362
fbshipit-source-id: 5bd7c22e69a91d60cc41c603a1f2380893f4c8a0
Summary:
* Now, we have the notion of a "zone". The zone is a uint8_t, and is meant to be a bitmask (i.e. it can take on values 0x1, 0x2, 0x4, 0x8, ...)
* We've added the zone to the client transport parameter associated with direct encap.
* Now, the server's transport settings have a "supported zones" bitmask. For example, it a server supports zones 0x1 and 0x4, the value of the bitmask would be 0x1 | 0x4.
* The server responds to a client with its direct encap address only if the client is in a supported zone.
Reviewed By: jbeshay
Differential Revision: D79480555
fbshipit-source-id: ef9ed8aafd82cb9fb3677ca79c052d930f8bf5b5
Summary:
This makes the following changes:
* Make the onFullHandshakeDone function fire client-side, when the final transport parameters from the peer have been received.
* Make the onFullHandshakeDone function take in an optional vector of peer transport parameters
Reviewed By: jbeshay
Differential Revision: D77902403
fbshipit-source-id: 024f278c9204bb870add6fb0b1ad717944899929
Summary:
Meta:
This is unused, also it may be confusing now that we have code for 0-RTT
priming
Reviewed By: hanidamlaj
Differential Revision: D77626412
fbshipit-source-id: 6e0fd1bdb7bd2ee5fd656e5e1cc2bfba12255398
Summary: Continuing the theme, removing them from the CryptoFactory and translating to Expected.
Reviewed By: kvtsoy, jbeshay
Differential Revision: D74676120
fbshipit-source-id: 715b497e68a4e3004811038cba479c443d5398fd
Summary: Continuing the theme, this time the TransportParameters
Reviewed By: jbeshay
Differential Revision: D74491343
fbshipit-source-id: 15f8bc0014f7163e674eb7adaf81727cbf2f35d6
Summary: This primarily involved making the constructors private and changing the callers of the factory functions. The crashing factory is only expected to be used by tests.
Reviewed By: kvtsoy
Differential Revision: D74347638
fbshipit-source-id: 4c0dd7fabaa233c8a3460c359462a22642d26f5b
Summary:
This is an API break, but it should mostly be a manageable one. We want to be able to compile mvfst internally without exceptions, and folly::Optional is one dependency that makes this challenging. Additionally, we already have an imported secondary optional type for performance/struct size reasons, tiny-optional.
This second optional interface is mostly compatible in an API sense (including the use of std::nullopt) with std::optional. Thus our approach is to remove the dependency on folly::Optional, and offer a quic::Optional instead.
The next diff will properly vendor tiny-optional so that quic::Optional is an independent version of it.
Reviewed By: sharmafb, kvtsoy
Differential Revision: D74133131
fbshipit-source-id: 715f8bb5043ba3bb876cacfe54236887e0686b30
Summary:
When the transport is in priming mode it saves all packets instead of writing them on the wire, and feeds them to a callback for the caller to get the data.
Meta:
Priming mode is used to get all packets before 1-RTT cipher is available, in order for them to get replayed later.
Reviewed By: kvtsoy
Differential Revision: D71290230
fbshipit-source-id: 230650cb1e5901069dda4ef850c9c724bf33b6be
Summary: use std::function in base transport
Reviewed By: mjoras
Differential Revision: D73380174
fbshipit-source-id: 2e51c8bd28c3b7387908cfb04008836f0e6daccf
Summary:
Previously,
* `RawBuf` was a typealias for `std::unique_ptr<folly::IOBuf>`
* `Buf` was a typealias for `folly::IOBuf`
In this diff,
* `Buf` is a typealias for `folly::IOBuf`
* `BufPtr` is a typealias for `std::unique_ptr<folly::IOBuf>`
Reviewed By: hanidamlaj
Differential Revision: D73206576
fbshipit-source-id: 454bf6ccfce3d6571e5e931889263ed98cc24af3
Summary: Continuing the theme. This removes it from client and server handshakes.
Reviewed By: kvtsoy
Differential Revision: D73335422
fbshipit-source-id: 262bad17c1ebd2bcef623b1185e38e6a63ec714b
Summary: More in the theme of returning Expected instead of throwing. For the folly case, we keep the try/catches in there and translate to Expected. For Libev, we convert directly to Expected.
Reviewed By: kvtsoy
Differential Revision: D73217128
fbshipit-source-id: d00a978f24e3b29a77a8ac99a19765ae49f64df8
Summary: This introduces a more generic typealias so that we can, for instance, write `BufHelpers::createCombined` instead of `folly::IOBuf::createCombined`.
Reviewed By: jbeshay
Differential Revision: D73127508
fbshipit-source-id: d585790904efc8e9f92d79cbf766bafe0e84a69f
Summary: As in title, this is more of a theme on adding an Expected return.
Reviewed By: kvtsoy
Differential Revision: D72579218
fbshipit-source-id: 25735535368838f1a4315667cd7e9e9b5df1c485
Summary: I started with the QuicStreamManager, but it turns out that the path from the manager up to the close path touches a LOT, and so this is a big diff. The strategy is basically the same everywhere, add a folly::Expected and check it on every function and enforce that with [[nodiscard]]
Reviewed By: kvtsoy
Differential Revision: D72347215
fbshipit-source-id: 452868b541754d2ecab646d6c3cbd6aacf317d7f
Summary:
**Context**: adding more debugging to catch the 0RTT bug.
Wonder if the client is down to read more data. There could presumably be some bug with 0RTT + happy eyeballs where the socket isnt working.
Reviewed By: lnicco
Differential Revision: D72266611
fbshipit-source-id: 6420017efcb200dd04bb7070c6c31049bcee8148
Summary: Continuing the theme, remove throws and translate them to expected returns.
Reviewed By: hanidamlaj
Differential Revision: D72254169
fbshipit-source-id: 7de13d733802eef70660cf014f642883586b0850
Summary: This is a step towards removing exceptions entirely from this path. Mostly involves a mass conversion to folly::Expected and adding a CodecResult that conveys the errors.
Reviewed By: kvtsoy
Differential Revision: D71704941
fbshipit-source-id: a35825b75bf53e252cef8cbf851e2e670209e8de
Summary: Cache the negotiated config for what ACK type to write and which fields to use once the peer transport parameters are available. This avoids computing the config with every ack frame being written.
Reviewed By: sharmafb
Differential Revision: D70004436
fbshipit-source-id: 79354f5137c77353c3a97d4c41782a700622e986
Summary:
This introduces a new frame type for acks (ACK_EXTENDED) that can carry optional fields depending on the features supported by the peer. The currently supported features set will include ECN count fields, and Receive Timstamp fields. This enables a quic connection to report both ECN counts and receive timestamps, which is not possible otherwise because they use different frame types.
Support for the extended ack as well as the set of features that can be included in it is negotiated through a new transport parameter (extended_ack_supported = 0xff0a004). Its value indicates which features are supported by the local transport. The value is an integer which is evaluated against the following bitmasks:
```
ECN_COUNTS = 0x01,
RECEIVE_TIMESTAMPS = 0x02,
```
This diff introduces the transport parameter and negotiates the supported features between the peers of the connection. The parameter is cached in the psk cache so the client can remember the server config. It is also encoded inside the 0-rtt ticket so the server can reject it if its local config has changed.
The following diffs add reading and writing the frame itself.
The ACK_EXTENDED frame itself will have the following format
```
ACK_EXTENDED Frame {
Type (i) = 0xB1
// Fields of the existing ACK (type=0x02) frame:
Largest Acknowledged (i),
ACK Delay (i),
ACK Range Count (i),
First ACK Range (i),
ACK Range (..) ...,
Extended Ack Features (i),
// Optional ECN counts (if bit 0 is set in Features)
[ECN Counts (..)],
// Optional Receive Timestamps (if bit 1 is set in Features)
[Receive Timestamps (..)]
}
// Fields from the existing ACK_ECN frame
ECN Counts {
ECT0 Count (i),
ECT1 Count (i),
ECN-CE Count (i),
}
// Fields from the existing ACK_RECEIVE_TIMESTAMPS frame
Receive Timestamps {
Timestamp Range Count (i),
Timestamp Ranges (..) ...,
}
Timestamp Range {
Gap (i),
Timestamp Delta Count (i),
Timestamp Delta (i) ...,
}
```
Reviewed By: sharmafb
Differential Revision: D68931151
fbshipit-source-id: 44c8c83d2f434abca97c4e85f0fa7502736cddc1
Summary:
All according to plan: https://fburl.com/gdoc/pebccgi1
Changing function definitions to return errors while still throwing.
Reviewed By: sharmafb
Differential Revision: D69567329
fbshipit-source-id: 5d40ee32fe185d5674785632a9a13e4cef996988
Summary: For now, we're going to throw an exception when we get a RESET_STREAM_AT frame, which would terminate the connection. Later on, this logic is going to be gated on whether we and the peer support reliable resets (and we get to know this through the transport parameters).
Reviewed By: jbeshay
Differential Revision: D67866393
fbshipit-source-id: 6b2888c026fadf0f2aa5dad52314ed8250959cf6
Summary: This diff adds the reliable_stream_reset transport parameter to mvfst.
Reviewed By: hanidamlaj
Differential Revision: D65383676
fbshipit-source-id: cb2f6a1a90004ea489447b67ed3cfc12ca90b804
Summary:
With normal resets, we transition from `StreamSendState::ResetSent` to `StreamSendState::Closed` when we get an ACK for a RESET_STREAM frame.
With reliable resets, this is going to be a little more complicated. We can't automatically transition from `StreamSendState::ResetSent` to `StreamSendState::Closed` when we get an ACK for a RESET_STREAM_AT frame because it's possible that the peer hasn't yet received all data until the reliable reset offset.
My idea is the following: Keep track of the `minReliableSizeAcked`, which is the lowest value of the reliable size in any RESET_STREAM_AT frame that was ACKed by the peer. We set it to 0 if a RESET_STREAM frame was ACKed by the peer.
Then, we can transition from `StreamSendState::ResetSent` to `StreamSendState::Closed` if any one of the following two events happen:
* We get an ACK for a RESET_STREAM_AT or a RESET_STREAM frame, and all data until the `minReliableSizeAcked` has been ACKed by the peer.
* We get an ACK for stream data, and this puts us in a state where all data until the `minReliableSizeAcked` has been ACKed by the peer.
Note: This diff doesn't have any functional change. The only change is that we're keeping track of the `minReliableSizeAcked`, but aren't using it anywhere.
Reviewed By: mjoras
Differential Revision: D66781199
fbshipit-source-id: 2aa5138a18f70e9801e59e747460558ba706939c
