Summary:
(1) Receiving a valid retry packet is a HappyEyeballs signal. We should
use that to update the happy eyeballs state.
(2) HappyEyeballs state should also be preserved when we undo client connection
state for retry.
Reviewed By: mjoras
Differential Revision: D25728713
fbshipit-source-id: 4ff06879f5a05e6fb4faeb1e9f330e251d3dbcb6
Summary: This is a temporary hack until we properly implement 0-rtt transport parameter updating. Now after 0-rtt we will use the packet size from the peer as the max packet size, if the can ignore setting is set.
Reviewed By: xttjsn
Differential Revision: D23690019
fbshipit-source-id: b4dbf5702e81e52ccd437e0fa68f4d156c7123be
Summary: This was in the right spirit, but doesn't work because we don't actually update the transport parameters if 0-rtt was accepted, so this ends up being the packet size in perpetuity.
Reviewed By: lnicco, xttjsn
Differential Revision: D23689185
fbshipit-source-id: c45eca1e388534f07eeafbb2c075e133bac071f8
Summary:
This is a bug, for 0rtt, even if the can ignore flag is set, we shouldn't trust the old max packet size. If it has changed then the peer will fail to decrypt anything.
There are open questions here around the PMTU we use for the handshake/0rtt, but let's just punt on those for now.
Reviewed By: udippant, xttjsn
Differential Revision: D23641082
fbshipit-source-id: aba93713091805e9498ab2c14b24bccf18192c02
Summary: This adds the Mocks for ClientHandshake and ClientHandshakeFactory. I added a simple test for `updateTransportParamsFromCachedEarlyParams`.
Reviewed By: mjoras
Differential Revision: D23308946
fbshipit-source-id: 6c22412efc6708ad13cd64ade3e9bccc7c80305d
