mirror of
https://github.com/hickory-dns/hickory-dns.git
synced 2026-04-25 19:25:56 +03:00
[GH-ISSUE #32] Switch out direct usage of MIO for futures.rs (client) #22
Labels
No labels
blocked
breaking-change
bug
bug:critical
bug:tests
cleanup
compliance
compliance
compliance
crate:all
crate:client
crate:native-tls
crate:proto
crate:recursor
crate:resolver
crate:resolver
crate:rustls
crate:server
crate:util
dependencies
docs
duplicate
easy
easy
enhance
enhance
enhance
feature:dns-over-https
feature:dns-over-quic
feature:dns-over-tls
feature:dnsssec
feature:global_lb
feature:mdns
feature:tsig
features:edns
has workaround
ops
perf
platform:WASM
platform:android
platform:fuchsia
platform:linux
platform:macos
platform:windows
pull-request
question
test
tools
tools
trust
unclear
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hickory-dns#22
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @bluejekyll on GitHub (Aug 11, 2016).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/32
http://aturon.github.io/blog/2016/08/11/futures/
and
https://crates.io/crates/futures
@alexcrichton commented on GitHub (Aug 22, 2016):
Hey @bluejekyll! I'd love to help out with this if I can. If you have any questions about futures/etc feel free to ask me any time :)
We've already got an issue about asynchronous DNS resolution, although I'm not entirely sure where we're going to end up on that. In any case just wanted to say hi and offer help if needed!
@bluejekyll commented on GitHub (Aug 22, 2016):
Thanks @alexcrichton ! I'll definitely be pinging you when I get started on this. I'm still groking the futures library and trying to think through converting from MIO to futures. From what I can tell it will probably reduce my async io code by a few hundred lines of at least.
When you announced this, I actually stopped working on DNSCrypt support (and now might actually just implement TLSDNS), because I starting thinking about how I could be chaining the futures together to create layered abstractions around the IO code.
Shiny new things distract me too much sometimes ;)
@bluejekyll commented on GitHub (Sep 2, 2016):
@alexcrichton I've got the initial UdpClient stream impl done (I think, I haven't written any tests yet, need the server side for that first).
I had a QQ that maybe you can answer, I noticed in your impl you had a dequeue you were using to cache queries, I didn't do that but am realizing that the message once popped off the Receiver, it may not be available on the next iteration (probably the only way it can work).
If you have a minute can you look at:
https://github.com/bluejekyll/trust-dns/blob/bfry/futures/src/udp/udp_client_stream.rs#L89
and confirm this? basically I'm guessing that if this line blocks:
https://github.com/bluejekyll/trust-dns/blob/bfry/futures/src/udp/udp_client_stream.rs#L95
then I will lose the message off L89 for the next time the
poll()is run.@alexcrichton commented on GitHub (Sep 2, 2016):
Ah yes, I believe you're correct! You'll probably want to call
poll_writefirst or otherwise handle the case where "would block" is returned (e.g. cache the buffer to get written later)@bluejekyll commented on GitHub (Sep 2, 2016):
Cool! Thanks for the validation.
@bluejekyll commented on GitHub (Sep 16, 2016):
FYI: latest commit has what I consider to be the final version of the future impl.
@alexcrichton, this includes your suggestions for the return from the client_future::poll()
thanks for you input on that. I'll be moving on to TCP next.
@bluejekyll commented on GitHub (Sep 16, 2016):
IPv6 tests failing in travis due to this:
https://github.com/travis-ci/travis-ci/issues/6610
@alexcrichton commented on GitHub (Sep 26, 2016):
🎊
@bluejekyll commented on GitHub (Sep 26, 2016):
Current Future progress, for those following:
github.com/bluejekyll/trust-dns@294ffe184dThe bfry/futures-state-machine branch has the current HEAD which will eventually be merged in. The other futures branches were some various other attempts and directions. The current HEAD has generic support for UDP and TCP clients, but only for querying at the moment. I'm working on what I hope to be a better abstraction for ClientFuture than what I had with Client.
@bluejekyll commented on GitHub (Oct 17, 2016):
With the latest commit to
github.com/bluejekyll/trust-dns@bb2ff3b4f3There is now full validation of RRSETs back to the trust_anchor (custom and public).
@bluejekyll commented on GitHub (Oct 20, 2016):
FYI, the current bfry/future_dnssec branch is very close to complete. I need to add a select_all and remove invalid rrsets from the response.
Also, need to upgrade to the current futures version.
@bluejekyll commented on GitHub (Oct 25, 2016):
This client side validator is nearly complete. There is currently a race condition in the evaluation logic, where it seems to enter a recursive lookup chain. It's not 100% reproducible. I would like to track this down before landing the secure_client_future impl in master.
@bluejekyll commented on GitHub (Nov 2, 2016):
I'm splitting this issue between server and client impls. I'm going to push the client in a release soon, the server will come one after I think.
@bluejekyll commented on GitHub (Nov 3, 2016):
It was a lot of work, but ClientFuture (with associated SecureClientHandle for DNSSec) just landed as 0.8.0 Published on crates.io as well.