pion
net.PacketConn
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.
@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 :sweat_smile:
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.
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.
