Summary:
Per
[d-24](https://tools.ietf.org/html/draft-ietf-quic-transport-24#section-19.15)
> An endpoint that is sending packets with a zero-length Destination
> Connection ID MUST treat receipt of a NEW_CONNECTION_ID frame as a
> connection error of type PROTOCOL_VIOLATION.
Reviewed By: JunqiWang
Differential Revision: D18619942
fbshipit-source-id: 9f453c8fb3ecdbc694813613006d1e88198cd4d2
Summary:
Client will set their active_connection_id_limit to the server as 7 (so it will
have 8 conn ids in total).
Reviewed By: JunqiWang
Differential Revision: D18532441
fbshipit-source-id: b0be65cec9f7c483469b0b4a2810bc370a6945c3
Summary:
It was hard to understand which names refer to which limits.
This diff makes it simple:
* conn.transportSettings.selfActiveConnectionIdLimit
represents how many of its peer's connection ids it will hold. It sends this to
the peer as the active_connection_id_limit
* conn.peerActiveConnectionIdLimit represents the value the peer sends as its
active_connection_id_limit. This should be defaulted to 0 and only changed
when we receive the transport parameters
Reviewed By: udippant
Differential Revision: D18531733
fbshipit-source-id: 53709ccaa58f835fd654ac28cdd740be46e65289
Summary: The state machine logic is quite abstruse, this modifies it to make it more readable.
Reviewed By: siyengar
Differential Revision: D18488301
fbshipit-source-id: c6fd52973880931e34904713e8b147f56d0c4629
Summary:
Use the Path rate limiter introduced in the previous diff.
When we initialize path validation of an unvalidated peer address,
enable pathValidationRateLimit.
When we receive a proper PATH_RESPONSE frame, disable this limit.
If this limit is enabled, we will check the pathValidationLimiter for
the amount of bytes we are allowed to write.
Change the migration tests in QuicServerTransportTest to use this new limiter
instead of writableByteLimits.
Update shouldWriteData to directly use the new congestionControlWritableBytes
function.
Reviewed By: yangchi
Differential Revision: D18145774
fbshipit-source-id: 1fe4fd5be7486077c58b0d1285dfb03f6c62831c
Summary: On Connection Migation use the time taken from pathchallenge frame to path response frame as initial rtt.
Reviewed By: JunqiWang
Differential Revision: D18388324
fbshipit-source-id: ede10484c240ca44a4eab544504461c052143bad
Summary:
QLogConnectionMigrationEvent:
Allow observing client-side ConnectionMigration attempts (replacing the
socket), and observing the server-side changing the peer address it
is writing to.
QLogPathValidationEvent:
Allow observing successful/failed path validation attempts.
Success is considered as a correct PathResponse being returned.
A Failure is only published on the timeout expiring, not an invalid
PathChallenge frame being returned (we do not cancel this).
There are already QlogEvents for PathChallenge/PathResponse that
can be observed.
Reviewed By: JunqiWang
Differential Revision: D18340999
fbshipit-source-id: 512108f82a6e082021c0bd3254f108c128b17ba3
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:
Implement sending stream limit updates in a windowed fashion, so that as a peer exhausts its streams we will grant it additional credit. This is implemented by having the stream manager check if an update is needed on removing streams, and the api layer potentially sending an update after it initiates the check for closed streams.
This also makes some driveby changes to use `std::lower_bound` instead of `std::find` for the sorted collections in the stream manager.
Reviewed By: yangchi
Differential Revision: D16808229
fbshipit-source-id: f6e3460d43e4d165e362164be00c0cec27cf1e79
Summary:
The plan is to not treat probing frame as simple frame, but that is not
going to happen soon.
Reviewed By: sharma95
Differential Revision: D15176635
fbshipit-source-id: 62ac13cdb82a09161e9148dfc437cf7377a01c96
Summary: This is step 1 for removing reset on reset, since the send side may need to transition to waiting for a reset ack while the read side is an any state.
Reviewed By: lnicco
Differential Revision: D15075849
fbshipit-source-id: 1e094942a8a1ca9a01d4161cd6309b4136a9cfbf
