Summary:
^
This parameter was added in d-21. Default value is 0 meaning no provided
connection id apart from the initial ones. This limits the amount of connection
ids the peer provides via `NEW_CONNECTION_ID` frame.
Diff to set this value will be added in later, along with `NEW_CONNECTION_ID`.
Reviewed By: JunqiWang
Differential Revision: D17532007
fbshipit-source-id: 5b86f69a8d3372fbcb7e0882508ea2661a9d4864
Summary:
Fixes include
1. Added packet_sent qlog event where it should be.
2. Reinitialize the qLogger after retry.
3. Fix issue where retry fails because packetNum can't be found.
Reviewed By: mjoras
Differential Revision: D16403221
fbshipit-source-id: 9288c1b24e98dc11e3b83575f58ca05445261ae3
Summary: These were changed to varints. To support this we need to do some extra horrible version plumbing. I don't want to keep this long term but it works for now.
Reviewed By: yangchi
Differential Revision: D16293568
fbshipit-source-id: a9ea9083be160aa3e6b338a7d70d7f00e44ec5ab
Summary:
Fixed QuicClientTransportIntegrationTest:
SetUp() shouldn't set maxStreams manually. Instead, client should read serverTransportParams after 1 rtt.
The tests used to call createBidiStream right after client->start(), changed that to only sending data after onTransportReady.
Reviewed By: mjoras
Differential Revision: D15293209
fbshipit-source-id: 88e739d72f1fad76666af003d446d068e6d5fac7
Summary:
Draft-19 onwards effectively punted version negotiation to QUICv2. Now receiving version negotiation on clients is treated as an immediate termination of the connection.
The transport parameter format has also changed to no longer include any reference to the QUIC version. To avoid us (Facebook) having to turn off QUIC traffic in production, our server needs to be able to parse these transport parameters from our older clients. To achieve this when parsing the transport parameters we will, as a temporary measure, check for the Facebook QUIC version to determine which transport parameter format we are parsing. Luckily for us the version we chose maps nicely to an implausible length for the transport parameters (0xface).
Note that this diff still has the client send the old transport parameter format, so that the rollout can be staged.
Reviewed By: yangchi
Differential Revision: D15203481
fbshipit-source-id: dfaaddc3acc76434461b04430b82a0902138c060
Summary: This changed in to be in milliseconds d19 forward.
Reviewed By: yangchi
Differential Revision: D15183837
fbshipit-source-id: 561218321dcb51ec41093cafbdb967db2d4b3660
Summary:
This diff implements the handling of retry packets. As per the spec:
1. A client MUST accept and process at most one Retry packet for each connection attempt. After the client has received and processed an Initial or Retry packet from the server, it MUST discard any subsequent Retry packets that it receives.
2. Clients MUST discard Retry packets that contain an Original Destination Connection ID field that does not match the Destination Connection ID from its Initial packet. This prevents an off-path attacker from injecting a Retry packet.
3. The client responds to a Retry packet with an Initial packet that includes the provided Retry Token to continue connection establishment.
4. A client sets the Destination Connection ID field of this Initial packet to the value from the Source Connection ID in the Retry packet. Changing Destination Connection ID also results in a change to the keys used to protect the Initial packet. It also sets the Token field to the token provided in the Retry.
Reviewed By: mjoras
Differential Revision: D14464508
fbshipit-source-id: 212539a588378fb0d795caaec150959680172781
