Summary:
Sometimes evb delays, e.g. from packet writing, can cause our timestamps to be very inaccurate relative to the RTT. Adjust for this by using the time from the packet.
This also tracks the largest received timestamp per-thread so that the packet receive times reported to the transport layer don't move backwards.
Reviewed By: yangchi
Differential Revision: D24628778
fbshipit-source-id: 5fa26091f9a0020cdfa456eaa88bb35fae836e30
Summary:
We shouldn't send a VN on receiving a VN, as this can cause VN ping pong.
Also, we need to check earlier whether a packet meets the minimum Initial size.
Reviewed By: yangchi
Differential Revision: D24196884
fbshipit-source-id: 222f38b6f341702e7d2dbaa9030557cef6438ee6
Summary:
Adding setter for QuicServer to pass down connection ID version.
Also updating hostId setter to uint32 from uint16, I've udpated ServerConnectionIdParams to uint32 earlier, but not server setters.
Reviewed By: udippant
Differential Revision: D23917110
fbshipit-source-id: e3bef08c91b52fccc3ef4b2f3cc6aa67e24c089d
Summary: Adding new version of CID, increasing L4 part from 16 to 24 bits. Also aligning at byte boundaries for easier parsing. See comment in DefaultConnectionIdAlgo.h.
Reviewed By: udippant
Differential Revision: D23177448
fbshipit-source-id: 706a8ed2b71a27bfc96eaf3a8822a3880730c0c6
Summary:
This is the second half of the actual support for CCP in mvfst.
As described in the previous diff, the CCPReader's job is to simply wait for messages from CCP, and then apply the changes (update cwnd or rate) to the correct connection.
Each server worker creates their own instance of CCPReader and thus each maintains their own separate connection to CCP (to avoid the use of a shared queue/lock between the workers).
This diff also adds the `ccpConfig` field to `QuicServer`, which is just a string that contains arguments to start CCP. If it is empty, ccp is disabled, and thus no instances of `CCPReader` are created.
Reviewed By: udippant
Differential Revision: D21854344
fbshipit-source-id: f1dd1e1bad00563db5f55f1514278e52ad11bb8b
Summary:
Adds `quic::AcceptObserver`, an observer that is notified when a connection is accepted.
- Can be used by instrumentation that ties its lifetime to that of the transport; the observer can be used to initialize instrumentation and install additional observers on accept.
- `wangle::Acceptor` has a matching interface being added (D21652470), so instrumentation can follow the same paradigm for both QUIC and TCP.
- In the future, will extend to also be triggered when a transport becomes ready (e.g., TLS handshake complete), similar to what we have for `wangle::Acceptor`.
Reviewed By: mjoras
Differential Revision: D21656740
fbshipit-source-id: 46f30379551087e4f22b06d4493cf0263530639f
Summary: It is useful to know at what frequency we are receiving each version.
Reviewed By: yangchi
Differential Revision: D22071299
fbshipit-source-id: 1e6f909d2b3a65cf54decc35f7e2e321d0ff8f24
Summary:
We should randomize the size of the reset and the data in the first byte.
This also implements the latest recommendatioons from the spec around reset packet sizing.
Reviewed By: yangchi
Differential Revision: D21885631
fbshipit-source-id: ad82f3356203b6809eed746e3948ba47fbc31cf5
Summary: QUIC server support for async recvmsg
Reviewed By: mjoras
Differential Revision: D21235170
fbshipit-source-id: df18fa2bf7e6b58a4c2b3a302dd3c1949204c563
Summary:
This introduces a rate limit to new connections created by a worker.
Right now it will simply send a VN, but eventually this will only issue a RETRY for unverified initials.
Reviewed By: udippant
Differential Revision: D21614905
fbshipit-source-id: 1832fbdad525c53fb1cb810aa9d7bae868c267d6
Summary: safety check, in case someone passes in a bad config
Reviewed By: mjoras
Differential Revision: D21383830
fbshipit-source-id: 60ab9e9e350855d6013c39590fb5c0d4a8e4f1ef
Summary:
There were some TODOs left in the QuicServerWorker where we silently drop
packets.
Reviewed By: mjoras, yangchi
Differential Revision: D21235150
fbshipit-source-id: eb546ea6d792915cf3155370758e837318530a38
Summary:
for initial or zero-rtt packets, or in the case of short-header packets, if the
worker-id already matches, we do not need to do any userspace routing of
packets.
Reviewed By: mjoras
Differential Revision: D21219335
fbshipit-source-id: 988614530960a621a02c0375f4a507b333f66e69
Summary: Extract out logging of all relavent routing info into a separate method
Reviewed By: sharmafb
Differential Revision: D21217339
fbshipit-source-id: 7982a4d9a3f3549a470e543e0a14aac1c6dec5f0
Summary: This can happen more often than we'd like, and there's no reason to force throwing the exception when we can instead validate the length first.
Reviewed By: udippant
Differential Revision: D20770869
fbshipit-source-id: 93e2349b02d6d2067f345b5fa9decee800c84ea6
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:
The CID Algo can possibly generate a CID that's already in the map.
This diff adds a mechanism to reject such CID and try another one.
ServerStateMachine will loop encoding CIDs until either QuicServerWorker no
longer rejects, or encode fails
Reviewed By: udippant, vchynarov
Differential Revision: D20251043
fbshipit-source-id: a38e4e8b33007779a9710c32057d47f32f7d1774
Summary:
The `QuicServerWorker` routing layer only retains mapping of a
single cid -> transport pair. However, in the case of two different
connections eventually having the same CID, both of those connections
will each believe they have that CID, while the routing layer
will only route to one of them.
When one connection is closed and the mappings are removed for all of its CIDs,
this MAY close the other connection inadvertently.
Reviewed By: yangchi
Differential Revision: D20046389
fbshipit-source-id: 2ab225725a4410d6665ee0a0536dc1f48c0c49ba
Summary: generic API for setting socket Options on both client and server
Reviewed By: yangchi
Differential Revision: D19763928
fbshipit-source-id: 7078eb8738aebc192bbace2498aaf9489526efff
Summary: deref a folly::Expected can throw if it's an error
Reviewed By: mjoras
Differential Revision: D19977541
fbshipit-source-id: d8f841c1c685c91c4ebd7d3a2ceb4aa1110de06b
Summary: no more surprises in upper layer
Reviewed By: mjoras
Differential Revision: D19976510
fbshipit-source-id: 3487e9aa2cb28d7bc748f13bc2bbc393216b4a8a
Summary:
The current shedding APIs in the transport would accept a new
connection and then immediately close it. This will fail the request and waste server resources.
This diff
removes all the Shedding functions from transport and let upper layer handle
it.
Reviewed By: udippant
Differential Revision: D19729902
fbshipit-source-id: 6daab5902235b6daa8d059b51cc1229d1042f892
Summary:
New QUIC draft no longer has this limitation for connection-id, and allows
connid of len 0 -> 20.
This diff removes the constraints. I still kept the requirement for
*server-chosen* conn-id
Reviewed By: mjoras, lnicco
Differential Revision: D19507366
fbshipit-source-id: 4c73f45617f40b29d47d2d86b7598f6c95588d0a
Summary:
All instancesi of LIKELY and UNLIKELY probably should be removed. We will
add them back in if we see pathologies in performance profiles.
Reviewed By: mjoras
Differential Revision: D19163441
fbshipit-source-id: c4c2494d18ecfd28f00af1e68ecaf1e85c1a2e10
Summary:
Currently, before server generate the destination CID, we route packets with client's address, port and client's source connection ID. But now that client can use 0-len source connection ID, the different connections from the same client address and port will be routed to the same server connections.
This diff changes it to use client's initial destination connection ID as part of the routing key.
Reviewed By: udippant
Differential Revision: D19268354
fbshipit-source-id: 837f5bd2f1e3a74957afacf7aabad922b1719219
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:
This adds checks for forwarded data on all the possible branches that lead to
forwarding of packets to another process
Reviewed By: mjoras
Differential Revision: D18416971
fbshipit-source-id: 22dc3fd63de615904a411f90164a138bf0ef56e0
Summary:
Before any CID is available, the source address routing
table might be the only owner of the transport. Removing the transport from
there deletes the transport. connectionIdData param is a const ref to a member
of the connection state owned by the transport. So deleting transport also
deletes this vector, which makes the const ref invalidated.
Reviewed By: vchynarov
Differential Revision: D18253200
fbshipit-source-id: 728b15d0872164ba6549a32e10a5a3611e808f27
Summary:
This diff is the one that introduces+passes the test of multiple server conn
ids routing to a single transport.
Currently, there is still only one time in non-test code that more than one
server connection id is added. This diff ensures when we call connectionUnbound
we remove all associated connection ids.
Reviewed By: udippant
Differential Revision: D17479563
fbshipit-source-id: 8d0ebbf26251f7bef44cdea53dfd4ff93ab465ae
