Summary: Decide if knob frames are supported based upon a transport parameter instead of relying on the QUIC version. This is a cleaner approach, at the cost of an additional transport parameter.
Reviewed By: mjoras
Differential Revision: D42465442
fbshipit-source-id: bfd1d177bdbe198e5eb47e63113410b5738dcede
Summary: This is a cosmetic change to make the naming consistent for all the advertised* variables in the transport settings.
Reviewed By: sharmafb
Differential Revision: D42465443
fbshipit-source-id: d570cbb1a2ca017105ac335b8efc404cb73f3c57
Summary: Use TransportParameterId enum as the source of truth for all the parameter ids. This basically moved the stream groups enabled parameter to the enum.
Reviewed By: kvtsoy
Differential Revision: D42465425
fbshipit-source-id: 94f9968326ac61f92587ef380a7288dd8ab38eef
Summary:
Pass max stream group parameter on handshake
The parameter conveys max number of stream groups a peer wishes to support. Note that the number/param is exchanged during handshake and currently there is now way to bump it later in connection. We can add something like MAX_STREAM_GROUP frame later.
Reviewed By: mjoras
Differential Revision: D36415454
fbshipit-source-id: 9d1c8fca7efa4adfb67fdeef859c47a3f50a67ef
Summary:
make getDatagramSizeLimit return the maximum datagram payload size that the
peer can accept.
This is currently the most conservative length, considering the maximum length
of a QUIC short header packet and a datagram frame header
Reviewed By: mjoras
Differential Revision: D28784866
fbshipit-source-id: cce8944a77f6f7b2d3535758c3c29ad88382710f
Summary:
This should be a noop in our current set up. I added some comments to clarify
the logic. Put it in another way,
- `udpSendPacketLen = f(max_packet_size, kDefaultMaxUDPPayload, canIgnorePathMTU)`
- `d6d.maxPMTU = g(max_packet_size, kDefaultMaxUDPPayload, d6dConfig.enabled)`
`f` and `g` are what the code does.
Reviewed By: mjoras
Differential Revision: D23745844
fbshipit-source-id: bc8c38a8a9086fe31e5f367d01737f360c403353
Summary:
This is following a similar pattern than what was done for the client side.
Pull Request resolved: https://github.com/facebookincubator/mvfst/pull/160
Reviewed By: yangchi
Differential Revision: D23560951
Pulled By: xttjsn
fbshipit-source-id: 351417cbfa3230112fff4c4de59b307f88389cf6
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: no more surprises in upper layer
Reviewed By: mjoras
Differential Revision: D19976510
fbshipit-source-id: 3487e9aa2cb28d7bc748f13bc2bbc393216b4a8a
Summary:
My goal in this stack is to properly support the functionality of issuing new
connection ids.
There are at least three cases in which this is done (server-side):
* generate initial server connection id based on host id parameters
* provide several NewConnectionId frames to the client (for use with
migration) after handshake
* responding to RetireConnectionIdFrame and issuing more NewConnectionId frames
as needed
**Changes**:
* move connIdAlgo away from parent ConnectionStateBase to just
QuicServerConnectionState
* create virtual function in ConnectionStateBase to generate
folly::none ConnectionIdData by default,
and server subclass will generate a new server id
* add unit tests to test this behaviour.
Intended for Junqi's diff of server issuing 7 new connection ids
to be rebased on this (D15178642)
Reviewed By: yangchi
Differential Revision: D17840780
fbshipit-source-id: 1a01077742d01d058eb0a726c4c9c44e39eafb24
