implement the datagram draft #2162
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2162 +/- ##
==========================================
- Coverage 86.22% 86.08% -0.14%
==========================================
Files 132 134 +2
Lines 9141 9265 +124
==========================================
+ Hits 7881 7975 +94
- Misses 910 934 +24
- Partials 350 356 +6
Continue to review full report at Codecov.
|
marten-seemann
force-pushed
the
datagram
branch
6 times, most recently
from
8ad535f to
ef169cf
Compare
marten-seemann
force-pushed
the
datagram
branch
from
ef169cf to
6da0432
Compare
|
Updated to the new draft version: https://tools.ietf.org/html/draft-pauly-quic-datagram-04. |
|
I hope this is merged to master. |
marten-seemann
force-pushed
the
datagram
branch
2 times, most recently
from
b70197d to
94dcee9
Compare
marten-seemann
force-pushed
the
datagram
branch
2 times, most recently
from
cfc78a6 to
a9d8d5c
Compare
marten-seemann
force-pushed
the
datagram
branch
from
a9d8d5c to
d243ac3
Compare
marten-seemann
force-pushed
the
datagram
branch
from
d243ac3 to
1728a6c
Compare
| @@ -44,11 +44,14 @@ const ( | |||
| ) | |||
|
|
|||
| // A ByteCount in QUIC | |||
| type ByteCount uint64 | |||
| type ByteCount int64 | |||
There was a problem hiding this comment.
This seems scary to me :S Are we sure this doesn't break any assumptions around non-negative numbers sprinkled throughout the codebase?
There was a problem hiding this comment.
It did uncover a uint underflow, fortunately it was just in test code (in the flow controller). I'm not sure why this is scary, as QUIC's varint encoding makes sure that all numbers that can practically be used are limited to MaxUint64 / 4.
| return f | ||
| default: | ||
| return nil | ||
| } | ||
| } | ||
|
|
||
| // HandleDatagramFrame handles a received DATAGRAM frame. | ||
| func (h *datagramQueue) HandleDatagramFrame(f *wire.DatagramFrame) { | ||
| data := make([]byte, len(f.Data)) |
There was a problem hiding this comment.
STREAM frames use frame-specific buffer pools, so maybe we need a DATAGRAM-pool here? Anyway, let's keep this for a future PR.
Implements draft-01 of https://datatracker.ietf.org/doc/draft-ietf-quic-datagram/.
Open questions:
Note that the maximum datagram size can change at any moment (in theory, not as it's implemented right now): The path MTU could change, or we could use a connection ID with a different length, leaving more / less space in the packet for the payload.
Idea: Return a
quic.ErrMessageTooLargeerror. Callers ofSendMessageare required to check for this error and should not propagate this error, but repackage the message into smaller pieces.