update documentation for the new quic-go v0.53.0 API

Author: marten-seemann

content/docs/http3/datagrams.md

@@ -78,7 +78,7 @@ The `http3.ClientConn` manages a single QUIC connection to a remote server.
 The client is required to check that the server enabled HTTP datagrams support by checking the SETTINGS:
 
 ```go
-// ... dial a quic.Connection to the target server
+// ... dial a quic.Conn to the target server
 // make sure to set the "h3" ALPN
 tr := &http3.Transport{
 	EnableDatagrams: true,

content/docs/quic/client.md

@@ -134,7 +134,7 @@ As mentioned above, the client applies the flow control limits used on the initi
 
 Upon rejecting 0-RTT, the server discards all 0-RTT packets sent by the client. This results in the invalidation of all opened streams and any data sent. quic-go does not automatically retransmit data sent in 0-RTT after completion of the handshake. It's the application's responsibility to detect this error and respond appropriately.
 
-The `quic.Connection` returned by `DialEarly` behaves as if it had been [closed]({{< relref "connection.md#closing" >}}): all calls to `OpenStream`, `AcceptStream`, as well as `Read` and `Write` calls on streams return a `quic.Err0RTTRejected`. **However, the underlying QUIC connection remains open**, it is only used as a signal to the application that all data sent so far was not processed by the server. To continue communication, the application can transition to using `NextConnection`:
+The `quic.Conn` returned by `DialEarly` behaves as if it had been [closed]({{< relref "connection.md#closing" >}}): all calls to `OpenStream`, `AcceptStream`, as well as `Read` and `Write` calls on streams return a `quic.Err0RTTRejected`. **However, the underlying QUIC connection remains open**, it is only used as a signal to the application that all data sent so far was not processed by the server. To continue communication, the application can transition to using `NextConnection`:
 
 ```go
 conn, err := tr.DialEarly(ctx, <server address>, <tls.Config>, <quic.Config>)

content/docs/quic/connection-migration.md

@@ -39,7 +39,7 @@ tr1 := &quic.Transport{
 tr2 := &quic.Transport{
   Conn: conn2, // for example: a connection bound to the cellular interface
 }
-var conn quic.Connection // connection established on tr1
+var conn *quic.Conn // connection established on tr1
 
 path, err := conn.AddPath(tr2)
 // ... error handling

content/docs/quic/connection.md

@@ -4,7 +4,7 @@ toc: true
 weight: 4
 ---
 
-The `quic.Connection` is the central object to send and receive application data. Data is not sent directly on the connection, but either on [streams]({{< relref "streams.md" >}}), or (optionally) in so-called [datagrams]({{< relref "datagrams.md" >}}).
+The `quic.Conn` is the central object to send and receive application data. Data is not sent directly on the connection, but either on [streams]({{< relref "streams.md" >}}), or (optionally) in so-called [datagrams]({{< relref "datagrams.md" >}}).
 
 
 ## Using the Connection Context {#conn-context}
@@ -50,7 +50,7 @@ This allows applications to clean up state that might they might have created in
 
 ## Closing a Connection {#closing}
 
-At any point during the connection, a `quic.Connection` can be closed by calling `CloseWithError`:
+At any point during the connection, a `quic.Conn` can be closed by calling `CloseWithError`:
 
 ```go
 conn.CloseWithError(0x42, "I don't want to talk to you anymore 🙉")

content/docs/quic/datagrams.md

@@ -6,13 +6,13 @@ weight: 10
 
 ## The Unreliable Datagram Extension
 
-Unreliable datagrams are not part of QUIC (RFC 9000) itself, but a feature that is added by a QUIC extension ([RFC 9221](https://datatracker.ietf.org/doc/html/rfc9221)). As other extensions, it can be 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 `ConnectionState.SupportsDatagrams` obtained from `Connection.ConnectionState()`.
+Unreliable datagrams are not part of QUIC (RFC 9000) itself, but a feature that is added by a QUIC extension ([RFC 9221](https://datatracker.ietf.org/doc/html/rfc9221)). As other extensions, it can be 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 `ConnectionState.SupportsDatagrams` obtained from `Conn.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 retransmitted.
 
 ## Sending and Receiving Datagrams
 
-Datagrams are sent using the `SendDatagram` method on the `quic.Connection`:
+Datagrams are sent using the `SendDatagram` method on the `quic.Conn`:
 
 ```go
 conn.SendDatagram([]byte("foobar"))

content/docs/quic/server.md

@@ -23,7 +23,7 @@ for {
 }
 ```
 
-The listener `ln` can now be used to accept incoming QUIC connections by (repeatedly) calling the `Accept` method (see below for more information on the `quic.Connection`).
+The listener `ln` can now be used to accept incoming QUIC connections by (repeatedly) calling the `Accept` method (see below for more information on the `quic.Conn`).
 
 This listener can be closed independently from the underlying transport. Connections that are already established and accepted won't be affected, but clients won't be able to establish new connections.
 
@@ -103,7 +103,7 @@ go func() {
 
 As soon as the connection is accepted, it can open streams and send application data. If [datagram support]({{< relref "datagrams.md" >}}) is negotiated, datagrams can be sent as well.
 
-At any point, the application can wait for completion of the handshake by blocking on the channel returned by `Connection.HandshakeComplete()`.
+At any point, the application can wait for completion of the handshake by blocking on the channel returned by `Conn.HandshakeComplete()`.
 
 
 ## 0-RTT

content/docs/quic/streams.md

@@ -4,11 +4,11 @@ toc: true
 weight: 6
 ---
 
-QUIC is a stream-multiplexed transport. A `quic.Connection` fundamentally differs from the `net.Conn` and the `net.PacketConn` interface defined in the standard library.
+QUIC is a stream-multiplexed transport. A QUIC connection fundamentally differs from the `net.Conn` and the `net.PacketConn` interface defined in the standard library.
 
-Data is sent and received on (unidirectional and bidirectional) streams, not on the connection itself. The stream state machine is described in detail in [Section 3 of RFC 9000](https://datatracker.ietf.org/doc/html/rfc9000#section-3).
+Application data is sent and received on (unidirectional and bidirectional) streams, not on the connection itself. The stream state machine is described in detail in [Section 3 of RFC 9000](https://datatracker.ietf.org/doc/html/rfc9000#section-3).
 
-In addition to QUIC streams, application data can also sent in so-called QUIC datagram frames (see [datagrams]({{< relref path="datagrams.md" >}})), if implementations can negotiate support for it.
+In addition to QUIC streams, application data can also sent in so-called QUIC datagram frames (see [datagrams]({{< relref path="datagrams.md" >}})), if endpoints negotiate support for it.
 
 
 ## Stream Types
@@ -46,7 +46,7 @@ These functions return an error when the underlying QUIC connection is closed.
 
 As described in [Flow Control for Streams]({{< relref "flowcontrol.md#stream-num" >}}), endpoints impose limits on how many streams a peer may open. The receiver may grant additional streams at any point in the connection (typically when existing streams are closed), but it means that at the time we want to open a new stream, we might not be able to do so.
 
-`OpenStream` attempts to open a new bidirectional stream  (`quic.Stream`), and it never blocks. If it's currently not possible to open a new stream, it returns a `net.Error` timeout error:
+`OpenStream` attempts to open a new bidirectional stream (`quic.Stream`), and it never blocks. If it's currently not possible to open a new stream, it returns a `net.Error` timeout error:
 
 ```go
 str, err := conn.OpenStream()

content/docs/webtransport/session.md

@@ -6,7 +6,7 @@ weight: 3
 
 A WebTransport Session functions similarly to a [QUIC Connection]({{< relref "../quic/connection.md" >}}), enabling the opening and accepting of streams, as well as the sending and receiving of datagrams. 
 
-The API of `webtransport.Session` is _almost_ identical to that of `quic.Connection`, with a few minor differences: For example, QUIC allows streams to be reset using a 62-bit error code, whereas WebTransport limits the error code range to 32 bits.
+The API of `webtransport.Session` is _almost_ identical to that of `quic.Conn`, with a few minor differences: For example, QUIC allows streams to be reset using a 62-bit error code, whereas WebTransport limits the error code range to 32 bits.
 
 ## Closing a WebTransport Session
 
@@ -15,7 +15,7 @@ The WebTransport session can be closed by calling the `CloseWithError` method:
 sess.CloseWithError(1234, "please stop talking to me 🤐")
 ```
 
-Similar to closing a `quic.Connection`, this action causes all calls to `AcceptStream` and `OpenStream`, as well as stream `Read` and `Write` calls, to return immediately.
+Similar to closing a `quic.Conn`, this action causes all calls to `AcceptStream` and `OpenStream`, as well as stream `Read` and `Write` calls, to return immediately.
 
 {{< callout type="warning" >}}
   `CloseWithError` only closes the WebTransport session, but not the underlying QUIC connection.