gr1ffon/quic-go
1
0
Fork 0
forked from quic-go/quic-go
Code Pull Requests Activity

rename Connection.{Send,Receive}Message to {Send,Receive}Datagram (#4116)

Browse Source 
This is more consistent with both the RFC and the rest of the API. For
example, the option in the Config is already name EnableDatagrams, and
the property in the ConnectionState is named SupportsDatagrams.
This commit is contained in:
Marten Seemann
2023-10-25 11:18:09 +07:00
committed by GitHub
parent 7884f87f82
commit 1c631cf9cb
8 changed files with 71 additions and 71 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
README.md
View File

@@ -159,18 +159,18 @@ On the receiver side, this is surfaced as a `quic.ApplicationError`.
Unreliable datagrams are a QUIC extension ([RFC 9221](https://datatracker.ietf.org/doc/html/rfc9221)) that is negotiated during the handshake. Support can be enabled by setting the `quic.Config.EnableDatagram` flag. Note that this doesn't guarantee that the peer also supports datagrams. Whether or not the feature negotiation succeeded can be learned from the `quic.ConnectionState.SupportsDatagrams` obtained from `quic.Connection.ConnectionState()`.
QUIC DATAGRAMs are a new QUIC frame type sent in QUIC 1-RTT packets (i.e. after completion of the handshake). Therefore, they're end-to-end encrypted and congestion-controlled. However, if a DATAGRAM frame is deemed lost by QUIC's loss detection mechanism, they are not automatically retransmitted.
QUIC DATAGRAMs are a new QUIC frame type sent in QUIC 1-RTT packets (i.e. after completion of the handshake). Therefore, they're end-to-end encrypted and congestion-controlled. However, if a DATAGRAM frame is deemed lost by QUIC's loss detection mechanism, they are not retransmitted.
Datagrams are sent using the `SendMessage` method on the `quic.Connection`:
Datagrams are sent using the `SendDatagram` method on the `quic.Connection`:
```go
conn.SendMessage([]byte("foobar"))
conn.SendDatagram([]byte("foobar"))
```
And received using `ReceiveMessage`:
And received using `ReceiveDatagram`:
```go
msg, err := conn.ReceiveMessage()
msg, err := conn.ReceiveDatagram()
```
Note that this code path is currently not optimized. It works for datagrams that are sent occasionally, but it doesn't achieve the same throughput as writing data on a stream. Please get in touch on issue #3766 if your use case relies on high datagram throughput, or if you'd like to help fix this issue. There are also some restrictions regarding the maximum message size (see #3599).