TcpListener::bind, etc. may block

[ExoticMatter]

TCP/UDP listeners and streams take A: std::net::ToSocketAddrs. Some ToSocketAddrs impls will resolve domain names. However, ToSocketAddrs is not futures-aware, so DNS lookups are synchronous.

Possible solutions:

• Spawn a blocking task a la filesystem operations (simpler)
• Replace ToSocketAddrs with an async version (probably more efficient)

[skade]

@ExoticMatter, this is actually an API oversight. Thanks for the notice!

An async ToSocketAddr is definitely on the way.

[DCjanus]

I'd like to handle this, but I'm not sure what should I do.

In std code, resolve socket addr via OS API, for example: gethostbyname on Linux, which is blocking call.

I found two way for this issue:

1. Implement an async resolver by hand, might not do same work with OS API.
2. Wrap the blocking call with backend thread, pretend this is an asynchronous call.

[sdroege]

Wrap the blocking call with backend thread, pretend this is an asynchronous call.

This wouldn't be very different from how the filesystem API works right now, and some code can probably be shared with that thread infrastructure there. IMHO would make more sense for now and is simpler to implement (and more consistent: OS resolvers!), but maybe others disagree :)

[DCjanus]

There is a solution, sounds good to me: provide wrapped version default, and provide a async host resolver in pure Rust.

The code in my mind(for now):

pub trait ToSocketAddrs {
    type Iter: Stream<Item = SocketAddr>;
    type Resolver: HostResolver = SystemResolver;
    fn to_socket_addrs(&self) -> Future<Result<Self::Iter>>; // I'm not sure what should be here, the return type.
}

pub trait HostResolver {
    fn resolve_host(xxx: SomeThingNotSure) -> OtherThingNotSure;
}

[ExoticMatter]

@DCjanus to_socket_addrs should probably just return Result<Self::Iter> since Iter: Stream.

Iter should probably be renamed to Stream to clarify that it is asynchronous.

I don't think the associated type Resolver is needed. In std, the DNS resolution method is an implementation detail and some implementations such as for SocketAddr will never resolve domains at all.

Edit: Also, DNS resolution can fail asynchronously, e.g. if the internet connection is unreliable. TryStream would be handy here.

[DCjanus]

Sorry for that, but I don't think TryStream correspond with Result<Iterator, for TryStream, each item could be Err, but for Result<Iterator>, one Err or all Ok. May be the code should be like this:

pub trait ToSocketAddrs {
    type Iter: Iterator<Item = SocketAddr>;
    type Output: Future<Output = io::Result<Self::Iter>>;
    fn to_socket_addrs(&self) -> Self::Output;
}

[andrewtj]

An async ToSocketAddr is definitely on the way.

Can you expand on that? Are you working on a wrapper for the various platform-specific APIs? (getaddrinfo_a, DnsQueryEx, DNSServiceGetAddrInfo, others?)

[DCjanus]

@andrewtj For now, I've just implemented a simple wrapper for std::net::ToSocketAddrs, based on thread pool.

In the future, we could implement 'real async' via platform-specific APIs.