HTTP server embedded mode works with WasmEdge and not with WasmTime (and vice et versa)

[k33g]

Description

I have two use cases.

• WASM Rust HTTP server: it works with WasmEdge, not with WasmTime
• WASM ASP.Net HTTP server: it works with WasmTime, not with WasmEdge

Current State

First use case: Rust HTTP server

• My sample is inspired by https://github.com/WasmEdge/wasmedge_hyper_demo
• The source code is here: https://github.com/wasm-university/wasm-hosted-web-servers/tree/main/http-service

I start the WASM HTTP server with WasmEdge like this:

wasmedge target/wasm32-wasi/debug/http-service.wasm

🟢 everything is ok when I query the service with curl -d '👋 Hello World 🌍' -X POST http://127.0.0.1:8080/echo

btw, with macOS arm64, I get Error: Os { code: 52, kind: Unsupported, message: "Function not implemented" }

If I start the same wasm module with WasmTime:

wasmtime target/wasm32-wasi/debug/http-service.wasm --tcplisten localhost:8080

🔴 the server does not start:

Error: failed to run main module `target/wasm32-wasi/debug/http-service.wasm`

Caused by:
    0: failed to instantiate "target/wasm32-wasi/debug/http-service.wasm"
    1: unknown import: `wasi_snapshot_preview1::sock_setsockopt` has not been defined

Second use case: ASP.Net HTTP server

I created a WASM ASP.Net HTTP server with dotNet Core WASI support preview.

• The source code is here: https://github.com/wasm-university/wasm-hosted-web-servers/tree/main/dotnet-demo/hello

If I start the same wasm module with WasmTime:

wasmtime bin/Debug/net7.0/hello.wasm --tcplisten localhost:8080

🟢 the server starts, and I can "curl" the service: curl http://localhost:8080

If I start the same wasm module with WasmEdge:

wasmedge bin/Debug/net7.0/hello.wasm

🔴 the server does not start:

[2022-11-06 20:02:09.887] [error] instantiation failed: incompatible import type, Code: 0x61
[2022-11-06 20:02:09.887] [error]     Mismatched function type. Expected: FuncType {params{i32 , i32 , i32} returns{i32}} , Got: FuncType {params{i32 , i32} returns{i32}}
[2022-11-06 20:02:09.887] [error]     When linking module: "wasi_snapshot_preview1" , function name: "sock_accept"
[2022-11-06 20:02:09.888] [error]     At AST node: import description
[2022-11-06 20:02:09.888] [error]     At AST node: import section
[2022-11-06 20:02:09.888] [error]     At AST node: module

Expected

Theoretically, I should be able to launch the WASM HTTP servers either with WasmEdge or WasmTime.
https://twitter.com/juntao/status/1589323762901843971

Environment

• Hardware Architecture:
  • x86_64
  • aarch64
• Operating system:
  • Ubuntu 20.04 x86_64
  • Ubuntu 22.10 aarch64

Steps to Reproduce

It's possible to open my project samples (https://github.com/wasm-university/wasm-hosted-web-servers) with Gitpod like this https://gitpod.io/#https://github.com/wasm-university/wasm-hosted-web-servers.

First use case: Rust HTTP server

Build:

cd http-service
cargo build --target wasm32-wasi

Start with WasmEdge:

wasmedge target/wasm32-wasi/debug/http-service.wasm

Call the service: (🟢 it works)

curl -d '👋 Hello World 🌍' -X POST http://127.0.0.1:8080/echo

Start with WasmTime:

wasmtime target/wasm32-wasi/debug/http-service.wasm --tcplisten localhost:8080

Call the service: (🔴 it does not work)

curl -d '👋 Hello World 🌍' -X POST http://127.0.0.1:8080/echo

Second use case: ASP.Net HTTP server

Build:

export DOTNET_ROOT=$HOME/dotnet
export PATH=$PATH:$HOME/dotnet
cd dotnet-demo/hello
dotnet add package Wasi.Sdk --prerelease
dotnet add package Wasi.AspNetCore.Server.Native --prerelease
dotnet build

Start with WasmTime:

wasmtime bin/Debug/net7.0/hello.wasm --tcplisten localhost:8080

Call the service: (🟢 it works)

curl http://localhost:8080

Start with WasmEdge:

wasmedge bin/Debug/net7.0/hello.wasm

Call the service: (🔴 it does not work)

curl http://localhost:8080

[hydai]

Hi @k33g
Thanks for your detailed information, I am going to dig into this issue to check the root cause. Will get back to you ASAP.

[MediosZ]

I think I can help with the first issue.
hyper doesn't work for wasmtime, because hyper uses wasmedge_wasi_socket to provide socket support.
However, wasmedge_wasi_socket extends the official wasi spec. That's why you will see the error wasi_snapshot_preview1::sock_setsockopt has not been defined when using wasmtime.
This means that, if you want to use tokio_wasi based crates, you can only use WasmEdge for now.

[k33g]

@MediosZ do you mean that wasm_edge_socket is a dependency of https://hyper.rs ?

[MediosZ]

wasmedge_wasi_socket is a dependency of hyper_wasi.

[k33g]

Oh! @MediosZ thank you (I didn't read the _wasi part in Cargo.toml

[MediosZ]

If you have any other questions please let me know.

[hydai]

Hi @k33g

TLDR

The socket-related functions in the WasmEdge implementation are different from the WasmTime. Our socket-related functions will ask users to use wasmedge-wasi-socket crate in the application to leverage the socket extensions. Hence, it will not be compatible with the other runtimes.

Details

WasmEdge started working on the socket-related functions before the sock_accept got merged into the WASI spec. Due to the very slow process of the spec improvements, we decided to have our own version of socket extension that is extending as many as possible socket functions in libc including the following functions:

https://github.com/second-state/wasmedge_wasi_socket/blob/main/src/socket.rs#L271-L352

and also the epoll event-trigger support:

https://github.com/second-state/wasmedge_wasi_socket/blob/main/src/wasi_poll.rs#L101-L106

Since there are some projects starting using the WASI spec sock_accept, we are going to implement a compatible mode to handle both APIs, this will be added in the next release 0.12. Thanks.

[k33g]

@hydai, thank you for the detailed answer 🙏 (the release 0.12 will be ✨)

[fc7]

I tried the following two examples on a Macbook M1 with wasmedge version 0.11.2:

• https://github.com/WasmEdge/wasmedge_hyper_demo/server
• https://github.com/second-state/wasmedge_wasi_socket/tree/main/examples/http_server

and I likewise get the following runtime error:

Error: Os { code: 52, kind: Unsupported, message: "Function not implemented" }

The same issue was mentioned above in the description by @k33g. Any idea what might be causing this?

(Update: same thing happens on an Intel Mac, so it appears unrelated to the architecture on which WasmEdge is running.)

[juntao]

As the error message suggests, WasmEdge implements a super set of socket APIs thats available in standard WASI proposals. In order for these examples to work, we need non-blocking I/O, DNS etc, which are not currently supported in other runtimes.

We are working on getting this features into the WASI standard, however.

[fc7]

The issue is not occurring with some other runtime, but with wasmedge itself, hence my question.

[MediosZ]

I tried this example https://github.com/second-state/wasmedge_wasi_socket/tree/main/examples/http_server, and it worked on Intel MacBook, 12.6.3(Monterey), with wasmedge 0.12.1. I may need more investigation.

[MediosZ]

I believe the error occurs because the pr that adds networking functions on macOS is merged but not shipped with version 0.11.2.
And now this error should not occur anymore in version 0.12.1.
The test log can be found here.