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

Fix the failure to create UdpSocket asynchronously due to immediate polling #2157

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

mokeyish
Copy link
Contributor

@mokeyish mokeyish commented Feb 29, 2024

Fix the failure to create UdpSocket asynchronously due to immediate polling

@mokeyish mokeyish changed the title Fix the failure to create UdpSocket asynchronously due to immediate p… Fix the failure to create UdpSocket asynchronously due to immediate polling Feb 29, 2024
@djc
Copy link
Collaborator

djc commented Feb 29, 2024

I think this needs a little more context. What behavior did you see, and why do you think it is wrong?

@mokeyish
Copy link
Contributor Author

mokeyish commented Feb 29, 2024

@djc Hi,

I implement the trait RuntimeProvider to support for querying over socks5. But current code will never execute the code after await. This PR sovles the problem.

https://github.com/hickory-dns/hickory-dns/blob/main/crates/resolver/src/name_server/connection_provider.rs#L92

  fn bind_udp(
      &self,
      local_addr: SocketAddr,
      server_addr: SocketAddr,
  ) -> Pin<Box<dyn Send + Future<Output = io::Result<Self::Udp>>>> {
      let proxy = self.proxy.clone();
      Box::pin(async move {
            let backing_socket = TokioTcpStream::connect(proxy.server).await;
            /// 👉 The code below never executes
            let backing_socket = match backing_socket {
                Ok(s) => s,
                Err(err) => {
                    panic!("{:?}", err);
                },
            };
            ...
      })
  }

@bluejekyll
Copy link
Member

Sorry, I'm actually confused about how this change resolves the issue you're mentioning. I see that you're fixing the kind of ugly delay and awake code in here that exists today.

Is this comment what this is resolving?:

                // TODO: this immediate poll might be wrong in some cases...
                match (*self.closure)(bind_addr, self.name_server)
                    .as_mut()
                    .poll(cx)
                {

It looks like with this change we will always return on the poll of the socket, which is good, but it is removing the QOS that was in place with the for loop that was limited to the 10 iterations on finding a port. If that fails in 10 iterations, we'd return to allow other futures to make progress. This appears to not have a QOS limit on the number of attempts, and could mean that an application could get deadlocked on this trying to find an unused port. Am I missing 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