Following the update to quic-go with Go 1.20 support ( #2478), we want to update our QUIC code in netxlite to use the new quic-go API, as introduced in release v0.35.0.
Plan:
Substitute calls to quic.DialEarlyContext with calls to quic.DialEarly → netxlite/quic.go
Replace all instances of Listener with *Listener (same for EarlyListener) → simplequicping_test.go.
Use new quic.Transport in (*quicDialerQUICGo).DialContext.
Edit: I believe we should not use the quic.Transport after all, due to the following reasons:
We do not have the intended use case of the quic.Transport, i.e. multiplexing multiple QUIC connections on a single net.PacketConn. Instead, we establish a 1:1 relationship between net.PacketConn and QUIC connection and take care of closing every UDP socket after using it. The design of quicDialerQUICGo conveniently fits to the new API as it makes sure that we do not use the same net.PacketConn for multiple subsequent Dials.
We use quic.DialEarly which uses a single-use Transport under the hood. There is probably no need to handle this extra complexity ourselves.
However, if in the future we decide to use the same UDP socket for multiple (concurrent) QUIC connections, we should use quic.Transport. In this case, we should have a singleton quic.Transport in quicDialerQUICGo which creates a single net.PacketConn used by all Dials. This quic.Transport needs to be closed as soon as we are not using the Dialer anymore.
Possibly identify other cases where we pass the same net.PacketConn to Listen and Dial subsequently. → This is not the case.
Related naming issues:
Even though quic-go abolished all "Context" Dial functions, we should probably continue using the naming scheme of (model.QUICDialer).DialContext, to be analogous to the TCP case.
QUICListener should be renamed to UDPListener. This is more precise. Also, we avoid confusion with the concept of a QUIC Listener (e.g. quic-go's quic.Listener) which is a server listening for incoming QUIC connections and which operates on the QUIC layer rather than the UDP layer. The new quic-go quic.Transport API makes this distinction of UDP socket creation vs. QUIC listening more explicit by multiplexing Dial and (QUIC-) Listen calls over the same net.PacketConn.
Update (07.08.2023):
We want to update to quic-go 0.37.3 which should solve issues we had with the 0.35 version.
Following the update to quic-go with Go 1.20 support ( #2478), we want to update our QUIC code in netxlite to use the new quic-go API, as introduced in release v0.35.0.
Plan:
Substitute calls to
quic.DialEarlyContext
with calls toquic.DialEarly
→ netxlite/quic.goReplace all instances of Listener with
*Listener
(same forEarlyListener
) → simplequicping_test.go.Use new quic.Transport in (*quicDialerQUICGo).DialContext.Edit: I believe we should not use thequic.Transport
after all, due to the following reasons:quic.Transport
, i.e. multiplexing multiple QUIC connections on a singlenet.PacketConn
. Instead, we establish a 1:1 relationship betweennet.PacketConn
and QUIC connection and take care of closing every UDP socket after using it. The design ofquicDialerQUICGo
conveniently fits to the new API as it makes sure that we do not use the samenet.PacketConn
for multiple subsequent Dials.quic.DialEarly
which uses a single-useTransport
under the hood. There is probably no need to handle this extra complexity ourselves.quic.Transport
. In this case, we should have a singletonquic.Transport
inquicDialerQUICGo
which creates a singlenet.PacketConn
used by all Dials. Thisquic.Transport
needs to be closed as soon as we are not using the Dialer anymore.Possibly identify other cases where we pass the same net.PacketConn to Listen and Dial subsequently. → This is not the case.
Related naming issues:
(model.QUICDialer).DialContext
, to be analogous to the TCP case.QUICListener
should be renamed toUDPListener
. This is more precise. Also, we avoid confusion with the concept of a QUIC Listener (e.g. quic-go'squic.Listener
) which is a server listening for incoming QUIC connections and which operates on the QUIC layer rather than the UDP layer. The new quic-goquic.Transport
API makes this distinction of UDP socket creation vs. QUIC listening more explicit by multiplexing Dial and (QUIC-) Listen calls over the samenet.PacketConn
.Update (07.08.2023): We want to update to quic-go 0.37.3 which should solve issues we had with the 0.35 version.