Previously rustc would fail with
error: reached the type-length limit while instantiating
`<std::vec::IntoIter<Peer> as std...rs:216:58: 220:6 keylog:&bool]]>`
(cherry picked from commit 817a57d281)
Quoth the spec: a server MUST expand the payload of all UDP datagrams
carrying ack-eliciting Initial packets to at least the smallest
allowed maximum datagram size of 1200 bytes.
(cherry picked from commit b7e95fdba7)
A stream's size is only known after we've issued at least that much
flow control credit, so the peer necessarily won't need any more. Our
logic to schedule credit issuing already uses similar judgement, so
this brings the last-minute sanity check into alignment.
Use zero-copy APIs when sending data in perf application.
Performance difference:
1. First line is before
2. Second line is after (but with only the download write change)
```
│ Duration │ FBL | Upload Throughput | Download Throughput
──────┼───────────┼───────────┼───────────────────┼────────────────────
AVG │ 5.00ms │ 1.00ms │ 332.82 MiB/s │ 334.20 MiB/s
AVG │ 5.00ms │ 0.00ns │ 332.64 MiB/s │ 335.96 MiB/s
```
=> Makes less than 1%. Still neat to have
This extends the public quinn API to offer support for writing owned buffers.
Besides the universal `write_chunks` API which supports a variable amount
of buffers the API also offers convenience methods for writing either a
single buffer completely or an arbitrary amount of buffers completely.
When a frame contained data for an offset of 0, the transmit logic did not
fully fill a packet. The reason for this is that the logic reserved 1 byte for
writing an offset. However storing offset 0 doesn't require 1 byte,
because it will be encoded with a special flag in the message header.
Without GSO, this isn't a huge issue. It mostly means we are wasting
1 byte per datagram.
However with GSO, this actually leads to data corruption:
When using GSO, and packet isn't fully filled, it later gets padded
to MTU size. Padding a packet ending with a STREAM frame that
doesn't contain a length information is however invalid, and will let
the receiver assume the padding is part of part of the data. This means
the receiver will receive an extra `0` at the end of a stream - and
depending on the duplicate detection at the receiver either the 0
or the correct byte in the next packet will win.
Dirkjan Ochtman