Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ndp: consider exposing Conn constructor which accepts arbitrary PacketConn #10

Open
mdlayher opened this issue Sep 5, 2018 · 2 comments

Comments

@mdlayher
Copy link
Owner

mdlayher commented Sep 5, 2018

@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?

@stapelberg
Copy link

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)?

@mdlayher
Copy link
Owner Author

mdlayher commented Sep 5, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants