* make it possible to pack path probes with multiple frames
* simplify function signature of pathManager.HandlePacket
* simplify connection short header packet handling logic
No functional change expected.
* make server send PATH_RESPONSEs on the same path
This makes sure that we’re actually testing for return routability.
* remove unused bool return value from sentPacketHandler.getPTOTimeAndSpace
* ackhandler: implement timer logic for path probing packets
Path probe packets are treated differently from regular packets: The new
path might have a vastly different RTT than the original path.
Path probe packets are declared lost 1s after they are sent. This value
can be reduced, once implement proper retransmission logic for lost path
probes.
* ackhandler: declare path probes lost on OnLossDetectionTimeout
* refactor the framer to pack both control and STREAM frames
* refactor framer STREAM frame packing logic
* pack STREAM_DATA_BLOCKED in the same packet as the STREAM frame
This makes debugging easier (and is slightly more efficient). In the
pathological case where there is not enough space remaning in the packet
to pack the STREAM_DATA_BLOCKED frame, it is queued for the next packet.
* add an integration test
* clear receivedPackets buffer on connection close
If packets were queued up in our receivedPackets queue when we closed
the connection we would fail reuse them. Eventually the GC would have to
clean this as trash.
* move drain logic to defer in run
The keep-alive period can be set using Config.KeepAlivePeriod. While
very large values will likely make keep-alives ineffective (depending on
the NATs in the path), there's no good reason to hardcode a maximum
value.
* pass a context to Transport.ConnContext
This context is cancelled when the QUIC connection is closed, or when
the QUIC handshake fails. This allows the application to easily build
and garbage collect a map of active connections.
* correctly handle fresh contexts returned from ConnContext
On the client side, we always use the configured packet size. This comes
with the risk of failing the handshake if the path doesn't support this
MTU. If the server sends a max_udp_payload_size that's smaller than this
size, we can safely ignore this: Obviously, the server still processed
the (fully padded) Initial packet, despite claiming that it wouldn't do
so.
On the server side, there's no downside to using 1200 bytes until we
received the client's transport parameters:
* If the first packet didn't contain the entire ClientHello, all we can
do is ACK that packet. We don't need a lot of bytes for that.
* If it did, we will have processed the transport parameters and
initialized the MTU discoverer.
This is more useful than the maximum frame size. The user of the library
shouldn't have to care about the QUIC framing layer.
---------
Co-authored-by: 世界 <i@sekai.icu>
