Wasmtime WASI 通过 HTTP/sockets 通信

Question

There is awesome webassembly compiler&vm named Wasmtime, which provide support for execution without any kind of embedding, which allows run WASM applications direcly from command line https://docs.wasmtime.dev/lang-bash.html

Unfortunately there is no official way to perform HTTP/network communication via WASI, since HTTP/sockets are not present in WASI preview snapshot, so developing any useful application via Wasmtime is problematic

Pure theoretically is't possible to run some proxy network server, which issuing real TCP connections from the host and communicate with Wasmtime application via filesystem over custom protocol, but it seem to be overcomplicated and maybe impact bad performance

There is solutions like https://github.com/deislabs/wasi-experimental-http , but it is not suitable since requires wrining custom entrypoint in Rust, installing Rust toolchain and compiling it for bunch of target platforms, instead of downloading standalone executalbe file from trusted web-site here https://wasmtime.dev/

Several weeks ago I opened issue https://github.com/bytecodealliance/wasmtime/issues/3483 , but unfortunately there is no progress or answer on it

So main questing addresses to Wasmtime team: how it meant to develop read-world applications with Wasmtime runtime, if any communication functionality is not avaiable? Same time exotic extensions like neural networks are actively developed, hovewer HTTP/raw sockets support are most MVP part

Thanks

Answer 1

The main answer to this is unfortunately that no, WASI is not yet ready for this kind of thing, but it is heading in that direction.

For context, I'm the founder/maintainer of Suborbital

We, for example, created our own custom set of 'cloud APIs' on top of the major Wasm runtimes (Wasmtime, WasmEdge, Wasmer), and expose them as a Go library . At the very least you don't need custom versions of anything, we bundle the runtime along with the library.

For now this is the best option, but the hope is that WASI will obviate the need for custom SDKs/APIs like ours in the future.

Happy to answer any questions you might have!