net.PacketConn

[neilalexander]

I'm a little surprised to find that a DTLS implementation, which is specifically datagram-oriented, seems to expect a stream-oriented net.Conn rather than a datagram-oriented net.PacketConn as an input to Client() and Server().

Curious if there is a reason for this? It means that anything net.PacketConn-based has to be wrapped.

[daenney]

@Sean-Der Do you know why this is? Looking at our code, the only thing we use from Conn that PacketConn doesn't have is the RemoteAddr, but since using ReadFrom on a PacketConn returns the info it doesn't seem necessary. Somewhat similarly we'd need to use WriteTo on a PacketConn, which in turn needs the address. But it feels like this is something we should just plop onto the ConnCtx.

I'm honestly a little confused myself now 😅

[igolaizola]

The other day I was listening to Adam Woodbeck, author of Network Programming with Go, during a gotime podcast (https://changelog.com/gotime/176) and he recommends to use net.PacketConn on UDP implementations.

[Sean-Der]

Just a design mistake! I am up for fixing this in the next major release. Maybe we could provide a nice helper to make net.Conn users migration easy.

This also would be a great chance to fix this as well. We shouldn't provide a Handshake function that is implicitly called on Read/Write. Right now we do it on conn creation which diverges from crypto/tls and causes issues.

[hasheddan]

Assigned myself as this is being addressed as part of #558.