You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@stapelberg and I had spoken at GopherCon and I believe he mentioned the need to specify an arbitrary net.PacketConn in this package.
The problem right now is that we effectively force an *ipv6.PacketConn because of multicast groups and control messages. Is this a problem for you, Michael?
The text was updated successfully, but these errors were encountered:
I can’t see a way to easily test an *ipv6.PacketConn, which is a struct type, not an interface.
Would it be possible to define an interface which includes the methods you need from the PacketConn, so that tests can use a different implementation (to inject/capture packets)?
Certainly. Now that I'm thinking about it more, I am also curious if there is real value in giving the caller access to IPv6 control messages as well. I could likely wrap that internally and remove them from the interface as well.
@stapelberg and I had spoken at GopherCon and I believe he mentioned the need to specify an arbitrary net.PacketConn in this package.
The problem right now is that we effectively force an
*ipv6.PacketConn
because of multicast groups and control messages. Is this a problem for you, Michael?The text was updated successfully, but these errors were encountered: