Summary: This will limit us to standard Ethernet MTU (1500) for now, but I think that is fine. This will allow us to experiment with packet size from the client more easily.
Reviewed By: yangchi
Differential Revision: D20709146
fbshipit-source-id: 608463de53d4520a257052491683263e14fc9682
Summary: The error code is actually expected to be transport here.
Reviewed By: yangchi
Differential Revision: D20553042
fbshipit-source-id: 82eb5dd51b5b0ccddebe6a5eb9c5c723f2caa95a
Summary:
This somewhat contrains what applications using mvfst can do with their errors, as it makes the semantics of onConnectionEnd vs onConnectionError tied to the value of GenericApplicationError::NO_ERROR.
For now, we believe this is fine, and fixes a case of connection close mis classification by HQSession.
Reviewed By: yangchi
Differential Revision: D20550139
fbshipit-source-id: eec7d90c33141bfa7f1280bf5b569818890d1130
Summary: Previously we would end up writing a non-application close when the application calls close(folly::none). This isn't correct, as those cases should be an application error with no error.
Reviewed By: afrind
Differential Revision: D20518529
fbshipit-source-id: fe069cccc32bd550fb3ec599694110955816993f
Summary:
The cache is obviously dependent on the crypto that is used. It's management needs to be moved down to part of the code that are specific to the crypto used. As a first step, we remove the cache from the transport, and use the one from the fizz context - if available - through the handshake.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/111
Reviewed By: mjoras
Differential Revision: D20463307
Pulled By: yangchi
fbshipit-source-id: c14908a10c80a977096f1ec145359f60899f8777
Summary: Unqualify nearly all uses of `folly::AsyncUDPSocket::ReadCallback::OnDataAvailableParams` since nearly all uses already have `OnDataAvailableParams` in scope.
Differential Revision: D20450063
fbshipit-source-id: c0fd49a7eace44a6edc8086762c44753224788dd
Summary:
All the state already moved there anyways, and this is closely related to the Psk cache management, which is also moving away from QuicClientTransport.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/109
Reviewed By: mjoras
Differential Revision: D20463300
Pulled By: yangchi
fbshipit-source-id: e9f0dc6285ccc6fd8cdc98d0e3579e6af8b00306
Summary:
This ensures we have a place to plug things into the connect method that do not depend on the actual handshake implementation.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/110
Reviewed By: mjoras
Differential Revision: D20463305
Pulled By: yangchi
fbshipit-source-id: a46c23871ec1021712641fbef98399cd5036001a
Summary:
Some of these parameters are already there. The other need to be move so that the can be accessed when caching new public keys.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/104
Differential Revision: D20250783
Pulled By: mjoras
fbshipit-source-id: 3e8b6c9e8945fb5ae1ea71a8af1512bfe0616736
Summary: In the constructor of FileQlogger adds a bool that sets streaming mode. If it's set it creates a thread that reads events from the log and immediatly outputs them to an output file.
Reviewed By: mjoras
Differential Revision: D20250881
fbshipit-source-id: 2af3ff0aeaa5b62f90b0c01570c96c92fdab4412
Summary:
This iterates the mvfst version to be semantically equivalent to draft-27, and leaves support for the old mvfst version.
The client will not yet be moved to draft-27 by default.
Reviewed By: lnicco
Differential Revision: D20182452
fbshipit-source-id: 1e11ad7296a6cd8d15ca5ed359d9ed82af79bb17
Summary:
Similar to the exiting empty write loop callback. The new API will
trigger when we read from socket but back with empty hands.
Reviewed By: lnicco
Differential Revision: D20130432
fbshipit-source-id: 9b61310b4ea4c5c7999742c5a8761a831f20f7b7
Summary:
This eliminatees some tech debt by completely removing the notion of version from the core transport parameters structure and the app token for zero rtt.
Note that for the draft-27 changes we will need to temporarily re-introduce it, but to a different layer (the extension encoding itself).
Reviewed By: JunqiWang
Differential Revision: D20073578
fbshipit-source-id: 2b55af621566bf1c20e21dd17251116de1788fa0
Summary: This implements the handshake done signal and also cipher dropping.
Reviewed By: yangchi
Differential Revision: D19584922
fbshipit-source-id: a98bec8f1076393b051ff65a2d8aae7d572b42f5
Summary: generic API for setting socket Options on both client and server
Reviewed By: yangchi
Differential Revision: D19763928
fbshipit-source-id: 7078eb8738aebc192bbace2498aaf9489526efff
Summary: When we don't use NiceMock we end up with a ton of spam in failing tests for every callback that we didn't EXPECT. This makes failed test output extremely noisy.
Reviewed By: sharmafb
Differential Revision: D19977113
fbshipit-source-id: 1a083fba13308cd3f2859da364c8106e349775bb
Summary: no more surprises in upper layer
Reviewed By: mjoras
Differential Revision: D19976510
fbshipit-source-id: 3487e9aa2cb28d7bc748f13bc2bbc393216b4a8a
Summary:
The fizz `encrypt` API will opportunistically use inplace encryption if the `IOBuf` you pass it is correctly sized. If it is not it will manually create the output buffer.
It turns out doing inplace versus encrypting with a given target output is a bit faster in microbenchmarks, and it will also allow experimenting with caching `IOBuf`s on the send path.
Reviewed By: knekritz
Differential Revision: D19506291
fbshipit-source-id: 3ef41290538ceac34a344114badbd167e2c25a50
Summary:
Previously we stored an `IntervalSet` in each `WriteAckFrame`. We don't need to do this, as by the time we are writing an `ACK` the `IntervalSet` is complete. Instead of bothering with the `IntervalSet` operations, we can simply serialize it to a reverse-sorted `vector.`
Additionally this has some micro-optimizations for filling the ACK frame, with a new function for getting varint size.
Reviewed By: yangchi
Differential Revision: D19397728
fbshipit-source-id: ba6958fb36a4681edaa8394b1bcbbec3472e177d
Summary:
Retry the original multiple recvmsg diff.
This has a few changes from the original:
1. Fixes happy eyeballs behavior by using the socket directly from the callback.
2. Fixes an error condition to make sure we unregister the callback on error
3. Makes the default to use the basic 1 message recv.
Reviewed By: yangchi
Differential Revision: D19192548
fbshipit-source-id: cd441a8bd448d2ae7d4b1add61aae0eeb7d0e840
Summary:
This diff adds an new setting to allow the client callbacks
onTransportReady slightly earlier during handshake: first ack instead of cipher
ready.
Reviewed By: mjoras
Differential Revision: D19414177
fbshipit-source-id: 6714630c5a49b3ed8e81b79da2af81b50ad828a1
Summary:
This moves the fizz specific part of the handshake into its own folder and library.
There is a bit of smurf naming going on as a result, not sure it is worth fixing or not at this stage. Maybe this code should be a in namespace named quic::fizz .
This should be doable with the client as well as soon as the key cache situation is figured out.
---
## Proxygen Canary
Reviewed By: yangchi
Differential Revision: D19290919
fbshipit-source-id: 48d7f7c70db42c65f7dffe3256805c268a481198
Summary:
This test tries to construct a bad packet by using server CID as the
dest CID in a server to client packet. It hopes to verify client will fail
parsing and throw. It used to work fine.
Then a couple month ago, our client code switched to use 0-len client CID. Now
client always read 0 bytes out as Dest CID on received packet. But in this test
case server writes a >0 len CID into the packet as Dest CID since the test case
tries to construct a bad packet. Then client treats these bytes as frame bytes
since it assumes 0 len DestCID. Then it parse frames from there. Now sometimes
parsing fails and we throw from parsing. Sometimes parsing accidentally goes
through, then we may or may not throwing when we process the parsed frames.
For example, if we parse out a stream frame successfully with a local stream ID
that's not open, we throw from there. But sometimes, nothing gets throw, since
we can potentially, for example, parse out a stream frame with a remote stream
ID and just simply create it. Sometime the test just hangs, since the stream ID
is huge and we create thousands of streams.
It's hard to fix this test case and keep it unflaky. For example, I figured by
using (0, 5, 3) instead of (0, 0, 0) as the CID encoding params, the test always
passes. That's because the server generates a CID that will definitely fail
parsing on client side. But if some day draft changes the frame type ID values
again, the test will fail again. And someone else will have to go through this
debugging process all over again.
I think we can just remove this test case altogether.
Reviewed By: mjoras
Differential Revision: D19268239
fbshipit-source-id: 66930d6e9044c863a26e29be1dbad683abc6c96c
Summary:
In QuicExceptions, in the case where the toString method was able to statically determine the response strings, we simply return the string literals in a folly::StringPiece instead of unnecessarily copying them into std::string.
Some toString methods had some dynamically generated responses and thus could not be updated. Added a TODO explaining the fact.
Reviewed By: mjoras
Differential Revision: D19192117
fbshipit-source-id: d9e5f202f9bf240009e8b8fd16f337b0506fbeb0
Summary:
Revert back to using getReadBUffer for reading from the udp socket.
There are a few issues we found while testing, so reverting for now, we can fix them later.
Reviewed By: yangchi
Differential Revision: D19055438
fbshipit-source-id: 2288e94e0aeab95a5cc6ade39f744b5d98062281
Summary:
That ensure the connect API from ClientHandshake doesn't depend on fizz specific things anymore.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/76
Reviewed By: yangchi
Differential Revision: D18888115
Pulled By: mjoras
fbshipit-source-id: 00103d629708796b73787b3dabb6f8d3815ff976
Summary:
Previously we track them since we thought we can get some additional
RTT samples. But these are bad RTT samples since peer can delays the acking of
pure acks. Now we no longer trust such RTT samples, there is no reason to keep
tracking pure ack packets.
Reviewed By: mjoras
Differential Revision: D18946081
fbshipit-source-id: 0a92d88e709edf8475d67791ba064c3e8b7f627a
Summary: By modifying `IntervalSet` a bit we can make it so it takes a `folly::small_vector` as the container. We expect that for real traffic there will not generally be a lot of ACK blocks per frame, so optimize for that.
Reviewed By: siyengar
Differential Revision: D18919975
fbshipit-source-id: 199a2ea9ba5003382e2d7d99fc7a6de7e8aafdca
Summary:
Don't use IOBufQueue for most operations in mvfst and use BufQueue instead. Since BufQueue did not support a splitAtMost, added it in instead.
The only place that we still use IOBufQueue is in crypto because fizz still requires it
Reviewed By: mjoras
Differential Revision: D18846960
fbshipit-source-id: 4320b7f8614f8d2c75f6de0e6b786d33650e9656
Summary:
In the current client code we read one packet, go back to epoll, and then read
another packet. This is not very efficient.
This changes it so that we can read multiple packets in one go from an epoll
callback.
This only performs changes on the client
Reviewed By: mjoras
Differential Revision: D18797962
fbshipit-source-id: 81be82111064ade4fe3a07b1d9d3d01e180f29f5
Summary:
Use the new recvmsg api on the client to receive a packet
from AsyncUDPSocket
Reviewed By: mjoras
Differential Revision: D18797963
fbshipit-source-id: 319d5c41f3a868e7b78947fdbcf2c411b6d7fbf0
Summary: As a part of Draft 17, application close frame has been removed, we use connection close frame to represent both application close and connection close.
Reviewed By: mjoras
Differential Revision: D18580856
fbshipit-source-id: d274fa2d3dbc59b926bca5a2b8a20328ae582703
