Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

WASI: asynchronous name resolution APIs #73

Closed
npmccallum opened this issue Mar 27, 2019 · 3 comments
Closed

WASI: asynchronous name resolution APIs #73

npmccallum opened this issue Mar 27, 2019 · 3 comments
Labels
wasi:api Issues pertaining to the WASI API, not necessarily specific to Wasmtime.

Comments

@npmccallum
Copy link
Member

One of the greatest flaws of current *nix APIs is its complete lack of async DNS. We also need native support for encrypted DNS. This should be one of the highest priorities on the "things to fix" list.

@sunfishcode sunfishcode added the wasi:api Issues pertaining to the WASI API, not necessarily specific to Wasmtime. label Mar 27, 2019
@sunfishcode
Copy link
Member

Following up on my coment in #69, my impression is that the best way to go here might be to start thinking in terms of creating a Network module, separate from the Core module. Core can just focus on relatively generic stream/datagram operations, and Network can be the place where we do DNS, create sockets, and so on.

If that makes sense, it'd be good to start making a rough list of features that the Network module should aim to include.

@npmccallum
Copy link
Member Author

I think that's sane.

Regarding DNS, we can also choose not to offer APIs. We can just depend on libraries to do this lifting for us. But if we do provide name resolution, it need to be async.

Honestly, I'd love to see a SOCK_DNS socket type for name resolution. You push a struct into the socket and poll() to wait for the reply.

However, and I'm afraid I might be harping on this, I'd really like to keep the core module very small. With versioning (#74), we can always expand it and even break the ABI. But, IMHO, core should only be a set of ABIs that all other modules depend on. I don't think there is any requirement for core to be functional by itself.

pchickey pushed a commit to pchickey/wasmtime that referenced this issue May 12, 2023
…odealliance#73)

* Split wasi-stream into separate input and output stream types.

This syncs the prototype's streams with the upstream wasi-io repo.

Streams are unidirectional, so this allows us to statically describe
whether something is an input stream or an output stream in an
interface.

This differs a little from the component model async streams, which
don't have separate input and output streams, but it does partially
reflect how the component model async design differentiates between
input streams in type signatures, which are passed in as arguments,
and output streams, which are returned as return values.

* Fix compilation on Windows.
pchickey pushed a commit to pchickey/wasmtime that referenced this issue May 16, 2023
…odealliance#73)

* Split wasi-stream into separate input and output stream types.

This syncs the prototype's streams with the upstream wasi-io repo.

Streams are unidirectional, so this allows us to statically describe
whether something is an input stream or an output stream in an
interface.

This differs a little from the component model async streams, which
don't have separate input and output streams, but it does partially
reflect how the component model async design differentiates between
input streams in type signatures, which are passed in as arguments,
and output streams, which are returned as return values.

* Fix compilation on Windows.
@badeend
Copy link
Contributor

badeend commented Nov 11, 2023

wasi-sockets has an asynchronous resolver .

The interface itself is pretty simple and leaves it up to the implementation to pick the most appropriate resolver strategy. (Hostfile, DNS, DNS-over-HTTPS, ...)

Anyway, I think this issue can be closed now. Any further discussion (if any) can take place at https://github.com/WebAssembly/wasi-sockets

mooori pushed a commit to mooori/wasmtime that referenced this issue Dec 20, 2023
dhil added a commit to dhil/wasmtime that referenced this issue Jan 8, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
wasi:api Issues pertaining to the WASI API, not necessarily specific to Wasmtime.
Projects
None yet
Development

No branches or pull requests

4 participants