Getting Tokio TCP working with WASM #6526
Replies: 5 comments 2 replies
-
I'm not familiar with wasm, but that error means that 3 is not a file descriptor. You are using |
Beta Was this translation helpful? Give feedback.
-
The way to make that work with wasmtime run -S preview2=n -S tcplisten=127.0.0.1:8080 ./wasi-server.wasm The |
Beta Was this translation helpful? Give feedback.
-
@FrankReh I decided to build out macros that directly manipulate the linear memory in WASM to transfer complex data structures over the WASM boundary. Then it just routes to different functions. You define your kernel for both client and WASM binary like so: use nanoservices_utils::create_contract_handler;
use nanoservices_utils::errors::{NanoServiceError, NanoServiceErrorStatus};
use serde::{Deserialize, Serialize};
#[derive(Debug, PartialEq, Serialize, Deserialize)]
pub struct ContractOne {
pub name: String,
pub age: u32,
}
#[derive(Debug, PartialEq, Serialize, Deserialize)]
pub struct ContractTwo {
pub account_name: String,
pub amount: u32,
}
create_contract_handler!(
ContractHandler,
ContractOne,
ContractTwo
); You then define the routes in the WASM build with code like the following: use nanoservices_utils::errors::{NanoServiceError, NanoServiceErrorStatus};
use kernel::{
ContractHandler,
ContractOne,
ContractTwo,
};
use nanoservices_utils::register_wasm_contract_routes;
use paste::paste;
fn handle_contract_one(mut contract: ContractOne) -> Result<ContractOne, NanoServiceError> {
contract.name = "Bob".to_string();
Ok(contract)
}
fn handle_contract_two(contract: ContractTwo) -> Result<ContractTwo, NanoServiceError> {
Ok(contract)
}
register_wasm_contract_routes!(
ContractHandler,
handle_contract_routes,
ContractOne => handle_contract_one,
ContractTwo => handle_contract_two
); When you build it the macro will generate a load of entry points for the WASM binary and also generates the @Darksonn I have been building an open source package manager on top of Docker so you can declare your docker images in your |
Beta Was this translation helpful? Give feedback.
-
I don't want to be a wet blanket but you might be on your own if you are trying to build something sophisticated using the Wasm core module approach. Wasm work over the past year or more that I'm aware of is focusing on using the new Wasm Component Model. Although the new Wasm C-M is currently released as WASI Preview 2, which does not support async APIs well, there are many in the ByteCode Alliance that are working towards a WASI Preview 3 that will allow things like first class async calls into a Wasm Component image and then it will be possible to run an async runtime like Tokio in a Wasm embedder with one or more Wasm Components, running in separate threads, and composed running in a single thread. It might still take a year, from what I've read about their efforts, but it is pretty clear (to me) that Wasm Components are going to be the future. (If you want to drink the cool-aid too, search for WebAssembly Component Model on YouTube and see the discussions that have come out over the last year and half, especially the latest ones from early this year.) Going down the Wasm Component Model route means no longer having to hand craft the glue between the Wasm host and the Wasm guest. The interfaces will now be defined by the Wasm C-M IDL (they call it WIT), and the ABI that the host and guest then must follow is specifically defined and the binding code (the code that used to be called the glue code) is now generated by the build tools. Admittedly many companies already ship product with the old Wasm Core module idea, successfully, and they will not drop what they have already built, and perhaps some will continue to try and innovate using the old APIs. But I think you find a smaller and smaller audience for that over time. The strongest reason to continue using the Wasm Core module APIs seem to be when targeting browsers or embedded devices that are already in the field and can take Wasm module updates but not Wasm embedder updates. |
Beta Was this translation helpful? Give feedback.
-
Not sure what you mean by "kernel". WIT is the name they have given to the interface definition language. If a host process, aka an "embedder", can support what the guest Wasm Component module calls out as its interface which is defined by the WIT that comes with the guest, then the host was probably built to support what the guest needs as it makes calls into the guest. |
Beta Was this translation helpful? Give feedback.
-
Hey I'm the author of Rust and Web Programming for Packt and the O'Reilly book Async Rust. I am trying to map a knowledgebase of WASM in rust to see if I can have a comprehensive guide to networking in WASM. I've managed to get TCP working with
wasmedge
with their own forked libraries. However, now that Tokio unstable supportswasmtime
, directly running wasm compiled Rust programs is a lot cleaner. So far the following code compiles:With the following dependencies:
If we use the following commands for the compilation:
We then have the
wasi-server.wasm
file in the root of the project. We can then try and run the file with the following command:However, I get the following error:
This happens on the
std_listener.set_nonblocking(true).unwrap();
which suggests that the TCP connection didn't really work and anything happening on the TCP connection causes an error. Does anyone have any references on how to get a TCP connection working withwasmtime
? I have been burning days looking at repo examples and searching issues in github repos and only found some light references to code that is essentially what we have in this post.Beta Was this translation helpful? Give feedback.
All reactions