Summary:
There is a bug in how we decide if we should schedule a write loop due
to sending Acks. Currently if one PN space has needsToWriteAckImmediately to
true and another PN space has hasAcksToSchedule to true, but no PN space
actually has both to true, we will still schdeule a write loop. But that's
wrong. We won't be able to send anything in that case. This diff fixes that.
Reviewed By: JunqiWang
Differential Revision: D15446413
fbshipit-source-id: b7e49332dd7ac7f78fc3ea28f83dc49ccc758bb0
Summary: Just to make it consistent with other var names in quic
Reviewed By: siyengar
Differential Revision: D15415528
fbshipit-source-id: 917159d6ccf86cf34612386d128d6b6d5bf62de6
Summary:
Using FOLLY_MOBILE macro to be able to exclude
quic trace generation on mobile
Reviewed By: mjoras
Differential Revision: D14609755
fbshipit-source-id: 2d5d624703a5b58c28cb533e3c2cc20d3a5c3d45
Summary: To conform to the current specs.
Reviewed By: mjoras
Differential Revision: D15215018
fbshipit-source-id: 4dcc495aea1cd7cebf2bc84f7367cb2e4a55df19
Summary:
So this trace is shared by all CongestionControllers. This also
changes what we log into the trace.
Reviewed By: siyengar
Differential Revision: D15184916
fbshipit-source-id: 6cbeb02ee2d24a6bf8d705ff883f5a57603988e7
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
