Skip to content

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

Open
Open
HTTP server embedded mode works with WasmEdge and not with WasmTime (and vice et versa)#2056
Assignees
hydai
Labels
bugSomething isn't working

Description

@k33g
k33g
opened on Nov 6, 2022

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

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.

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

Activity

  1. hydai commented on Nov 6, 2022

    @hydai
    hydai
    on Nov 6, 2022
    Member

    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.

  2. hydai
    self-assigned this
    on Nov 6, 2022
  3. hydai
    added
    bugSomething isn't working
    on Nov 6, 2022

  4. MediosZ commented on Nov 8, 2022

    @MediosZ
    MediosZ
    on Nov 8, 2022
    Collaborator

    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.

  5. k33g commented on Nov 8, 2022

    @k33g
    k33g
    on Nov 8, 2022
    Author

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

  6. MediosZ commented on Nov 9, 2022

    @MediosZ
    MediosZ
    on Nov 9, 2022
    Collaborator

    wasmedge_wasi_socket is a dependency of hyper_wasi.

  7. k33g commented on Nov 9, 2022

    @k33g
    k33g
    on Nov 9, 2022
    Author

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

  8. MediosZ commented on Nov 9, 2022

    @MediosZ
    MediosZ
    on Nov 9, 2022
    Collaborator

    If you have any other questions please let me know.

  9. hydai commented on Nov 9, 2022

    @hydai
    hydai
    on Nov 9, 2022
    Member

    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.

  10. k33g commented on Nov 9, 2022

    @k33g
    k33g
    on Nov 9, 2022
    Author

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

  11. k33g
    changed the title [-] HTTP server embedded mode works with WasmEdge and not with WasmTime (and vice et vers)[/-] [+] HTTP server embedded mode works with WasmEdge and not with WasmTime (and vice et versa)[/+] on Nov 11, 2022

  12. fc7 commented on Apr 23, 2023

    @fc7
    fc7
    on Apr 23, 2023

    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.)

  13. juntao commented on Apr 24, 2023

    @juntao
    juntao
    on Apr 24, 2023
    Member

    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.

  14. fc7 commented on Apr 26, 2023

    @fc7
    fc7
    on Apr 26, 2023

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

  15. MediosZ commented on May 18, 2023

    @MediosZ
    MediosZ
    on May 18, 2023
    Collaborator

    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.

  16. MediosZ commented on May 19, 2023

    @MediosZ
    MediosZ
    on May 19, 2023
    Collaborator

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions