Summary:
This ensures they are available to the whole stack rather than the transport only. The validator needs it in the server case, and will soon need it in the client case, so that seems appropriate to make it available.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/117
Reviewed By: yangchi
Differential Revision: D20536366
Pulled By: mjoras
fbshipit-source-id: a76d369c0a82b9be1f985aed1f33f7a6b338a2ae
Summary:
Currnetly there isn't a way for apps to unregister a pending
WriteCallbacks for a stream. resetStream() does that if the transport isn't in
Closed state. This diff adds such support even if transport is already in
Closed state. This solves the problem where app has a class that's both stream
ReadCallback and stream WriteCallback and readError would kill the callback
object itself. The new API gives such class a chance to remove itself from the
transport.
Reviewed By: mjoras
Differential Revision: D20545067
fbshipit-source-id: 81d9f025310769aadef062711a49adc47a0639d0
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 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:
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:
F14 should be faster and have lower memory urilization for near-empty sets and maps. For most H3 connections these are mosotly going to be near-empty, so CPU wins will likely be minimal.
For usecases that have extremely high numbers of streams, there are likely going to be CPU wins.
Reviewed By: yangchi
Differential Revision: D18484047
fbshipit-source-id: 7f5616d6d6c8651ca5b03468d7d8895d1f51cb53
Summary:
We currently pause all producers if the sum of the egress buffers of all transactions exceeds the write buffer limit. This turns out to be deterimental to prioritization.
Now, we pass the underlying transport pause state or connection flow control state back to the handlers. The previous diff in this stack introduces a per-stream buffer limit (64kb default). To limit total session buffer size, limit the number of concurrent streams or lower the per-stream limit.
Reviewed By: lnicco
Differential Revision: D17097138
fbshipit-source-id: 9025c5be8b318963311c3aaad9ee9a03c0e2265e
Summary:
I think not doing this, and throw an error at the point of output to
files is kinda surprising to users
Reviewed By: sharma95
Differential Revision: D18016183
fbshipit-source-id: b16881b365ea82b75842f89dc364054804808116
Summary:
Mainly based on Junqi's changes in D15230415
Added the start of several error checking. Section 19.15
of d-23
(https://tools.ietf.org/html/draft-ietf-quic-transport-23#section-19.15)
specifies 2 cases where PROTOCOL_VIOLATION should be thrown during processing:
* retire_prior_to is larger than sequence number
* new_connection_id is sent by peer using 0-len conn id (will handle later)
I don't think it was specified what happens if we get a NEW_CONN_ID frame
after the the endpoint already has enough of the peer's conn ids - just ignore
the frame.
Reviewed By: sharma95
Differential Revision: D17578167
fbshipit-source-id: 6e410b6110970a6e52970576ac3ff2b1c7d5c06a
Summary:
Prior to this we had an incorrect check for something being a stream frame. It technically should have worked for minimally encoded frame types, but would not work for a spec-incompliant frame type.
Instead of using a mask this makes it so each stream frame type is explicitly enumerated. This isn't as clean looking but is easier to validate as correct.
This also revealed some places where we were not correctly plumbing through the version for unit tests, so fixing those as a driveby.
Reviewed By: yangchi
Differential Revision: D16676631
fbshipit-source-id: 835dcc6e1f431bbe3fa4a5c6b8e616863c126155
Summary:
Previously we tried to put this API in connectionCallback, but that has
some lifecycle problem. So we decided to make this API independent of mvfst's
state. Application (e.g. HTTP/3, QPACK) will have to either make the 2 functions
stateless or maintain the lifecycle of any captured objects.
Reviewed By: afrind, lnicco
Differential Revision: D16074471
fbshipit-source-id: b0a3baa6870bee56372797754972ab5c2c1f2232
Summary:
This diff adds a DebugState in the QuicConnectionState to track the
reason we schedule transport WriteLooper to run, the reason we end up not
writing and the number of times such write happens consecutively. And when it
reaches a predefined limit, we trigger a callback on a loop detector interface.
Reviewed By: kvtsoy
Differential Revision: D15433881
fbshipit-source-id: d903342c00bc4dccf8d7320726368d23295bec66
Summary:
Previously updateAppLimited was not accounting for peer created streams.
This moves app limited accounting into the stream manager
This also makes a subtle change to the applimited callback. We assume that
we start off as not app limited now, so if we create a stream we will not call
the congestion controller app limited callback.
Reviewed By: mjoras
Differential Revision: D15166114
fbshipit-source-id: 1a8d573533861f53bb1bd9fdc605dfefe68902dc
Summary: The previous diff removed automatically sending a rst stream when receiving a reset stream. This adds a helper to do that from the application layer.
Reviewed By: mjoras, pkir
Differential Revision: D15208997
fbshipit-source-id: b8d3898e85537e97df61cc66854299698a48c825
Summary:
For the sender, upon egress or ingress skip we must check registered
delivery callbacks and invoke `onCancel()` for each offset below the skipped
offset.
Reviewed By: mjoras
Differential Revision: D15113113
fbshipit-source-id: 221badce8e92abde48e8ab2c8f3c1da9e506f54e
