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:
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: The check should be < not <=.
Reviewed By: mjoras, kvtsoy
Differential Revision: D15279146
fbshipit-source-id: adb4c315aab269d595caa186591eeb5e82e3223c
Summary: This is no longer part of the spec. It's up to the application how to handle reset
Reviewed By: lnicco
Differential Revision: D15107164
fbshipit-source-id: 2a1fe0c552bd7f054e84ef86a01a78c379b0a483
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
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
