Provide a way to create sockets #20
Labels
feature-request
Requests for new WASI APIs
wasi-network-sockets
Issues targeted for a possible `wasi_unstable_sockets` module
Comments
|
This is a requirement for us. |
rylev
added
the
wasi-network-sockets
|
Is there a working spec somewhere for this feature? |
alexcrichton
added a commit
to alexcrichton/WASI
that referenced
this issue
Jan 19, 2022
* Procedurally generate the entire crate
This commit switches to using the `*.witx` file to procedurally generate
this entire crate. Both the raw low-level function bindings as well as
the higher level wrappers which use types like slices and `&str` are
procedurally generated.
Along the way a number of various other modifications and improvements
were made:
* Documentation is carried over from the `*.witx` file to bindings generated.
* The WASI bindings are updated to `wasi_snapshot_preview1`.
* The crate version is bumped, and now contains build metadata showing
what version of the WASI spec is implemented.
* A dedicated opaque `Error` type has been added which implements traits
like `Debug` and `Display` which are WASI-specific. It also
additionally implements the `Error` trait if enabled.
* The crate's module structure has been removed, with bindings now
appearing at the top level instead of in a `wasi_snapshot_preview1`
submodule.
* The `__wasi` and `__WASI` prefixes on names have all been removed.
* The names of enums values and flag values are now `{ENUM}_{FLAG}` to
disambiguate same-named flags between enum/flag types.
The entire crate is now procedurally generated but this means that a few
prior convenience wrappers no longer exist and/or are much more raw then
they were before:
* `args_get` - this simply takes raw buffers instead of a closure
* `environ_get` - takes raw buffers like above
* `fd_prestat_dir_name` - takes a raw pointer to write to instead of a
mutable buffer
* `fd_readdir` - same as above
* `path_readlink` - same as above
* `random_get` - same as above
* `poll_oneoff` - this seems like a bit of a weird API, but no longer
takes two arrays and only works in raw pointers
I think this means we'll probably want future wasi spec work to codify a
"mutable output buffer" as first class concept for most of the APIs
above, and I think that would make most of them nicer to use.
Closes WebAssembly#20
* Handle some review comments
|
The wasi-sockets API, which is now part of WASI, includes a way to create sockets. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is perhaps dependent on resolving #1 and #4, but a large gap in the wasi's capabilities is that there is currently no way to create sockets (i.e. no analogue to
acceptorconnect). There are currently ways to read and write to sockets (sock_sendandsock_recv), but without a good way to get a socket fd, these are not terribly useful.Given that a major early use case for wasi is in the FaaS and "edge computing" space where networking is pretty important, it makes sense for filling out the socket API to be high on the priority list.
The text was updated successfully, but these errors were encountered: