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

Correct TODO in udp_windows.go #1433

Merged
merged 1 commit into from
Mar 12, 2023
Merged

Conversation

tmthrgd
Copy link
Collaborator

@tmthrgd tmthrgd commented Mar 7, 2023

These TODOs were not correct as x/net/ipv4 and x/net/ipv6 still don't have Windows support.

Updates #738
Updates #765
Updates coredns/coredns#2138
See golang/go#7175
See golang/go#7174

These TODOs were not correct as x/net/ipv4 and x/net/ipv6 still don't
have Windows support.
@tmthrgd tmthrgd requested a review from miekg as a code owner March 7, 2023 02:14
@miekg miekg merged commit e88948e into miekg:master Mar 12, 2023
@tmthrgd tmthrgd deleted the udp_windows_todo branch March 12, 2023 10:59
@francislavoie
Copy link

Hopefully you don't mind me asking here, but it's the most recent issue/PR about Windows.

Would this be an explanation for why failures to connect to a DNS server takes significantly longer on Windows?

We're investigating the tests in caddyserver/certmagic#228 (comment) and the ones that use intentionally incorrect resolver addresses (localhost with a non-standard port) takes until the configured timeout to return, whereas on other platforms it fails fast. We're using udp.Exchange().

@tmthrgd
Copy link
Collaborator Author

tmthrgd commented Apr 16, 2023

@francislavoie I don't believe so as this should only really impact sending packets and making sure they go out the right interface. I'd be surprised if it could cause that.

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

Successfully merging this pull request may close these issues.

None yet

3 participants