Switch out direct usage of MIO for futures.rs (client) about trust-dns HOT 14 CLOSED

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!

from trust-dns.

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.

from trust-dns.

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

from trust-dns.

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

from trust-dns.

Ah yes, I believe you're correct! You'll probably want to call poll_write first or otherwise handle the case where "would block" is returned (e.g. cache the buffer to get written later)

from trust-dns.

Cool! Thanks for the validation.

from trust-dns.

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.

from trust-dns.

IPv6 tests failing in travis due to this:

travis-ci/travis-ci#6610

from trust-dns.

🎊

from trust-dns.

Current Future progress, for those following:

bluejekyll/trust-dns@294ffe1

The 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.

from trust-dns.

With the latest commit to bluejekyll/trust-dns@bb2ff3b

There is now full validation of RRSETs back to the trust_anchor (custom and public).

from trust-dns.

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.

from trust-dns.

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.

from trust-dns.

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.

from trust-dns.