Tracking: Implement sock_accept and basic networking

[haraldh]

With the addition of sock_accept() in wasi-0.11.0, wasmtime can now implement basic networking for pre-opened sockets.

Todo

• [x] https://github.com/bytecodealliance/wasmtime/pull/3711
• [x] https://github.com/bytecodealliance/wasmtime/pull/3729
• [x] Rust: https://github.com/rust-lang/rust/pull/93158
• [ ] Wasi definition of Preopentype for sockets (listener and stream, tcp and unix) to make fd_prestat_get() work for sockets
• [ ] Non-busy polling on Windows
• [ ] Fix get_fdflags() for sockets on Windows
• [ ] More networking test cases
• [x] Discussion of SocketAddr return value for ::accept() in the rustsrc PR

        Ok((
            TcpStream::from_inner(unsafe { Socket::from_raw_fd(fd as _) }),
            // WASI has no concept of SocketAddr yet
            // return an unspecified IPv4Addr
            SocketAddr::new(Ipv4Addr::UNSPECIFIED.into(), 0),
        ))

[huangjj27]

How is this going on? I try to use just std::net::TcpListener to handle TcpStream and it raises errors that wasi is not supported yet.

[hlubek]

Is there a way to use sock_accept (and reading / writing) without having a busy wait loop? With wasmtime I couldn't see that poll_oneoff could be used to wait on the preopened fd to wait for a new connection.

[Kerosin3]

How is this going on? I try to use just std::net::TcpListener to handle TcpStream and it raises errors that wasi is not supported yet. passing --tcplisten=127.0.0.1:10000 to wasmtime and then

let mut server = { 
let s = unsafe { std::net::TcpStream::from_raw_fd(3) };
  s.set_nonblocking(true).context("failed to set non-blocking flag on socket")?;
  TcpListener::from_std(stdlistener)
}

makes the passed socket available to use in server app.

btw I dont know how to perform connect when writing a client app. passing --tcplisten=127.0.0.1:10000 to client wasm app in case server is running is not possible. (socket already in use) but enarx example seems to achieve this functionality https://github.com/enarx/codex/blob/main/demos/chat-client/rust/src/main.rs#L32 I still haven't figured out whether this functionality implemented in wasi .. If anyone can provide any info about how pass a socket to wasm client via wasmtime to perform a connection.. would be great

[maxwellflitton]

@Kerosin3 did you have any luck with this? I just want the TCP to be listening from the wasmtime runtime

[alexcrichton]

I'm actually going to go ahead and close this as more-or-less not planned at this time. The wasip1 proposal's implementation of sockets was never fully completed, however the wasip2 implementation does have a full suite of socket-based APIs for use. If it works I'd recommend using the wasip2-based APIs.

[FrankReh]

I've actually seen the mio Wasm tcp listener just work with the latest wasmtime, once I used the -S preview2=n -S tcplisten=... options to run. I had to modify some lines within the mio src too since it is now treating warnings as errors and the wasi build target of mio was causing all sorts of warnings (well at least two, my memory of what all the failures were two days ago is fuzzy).

So the mio Wasm example is able to listen to a socket opened up by wasmtime and interact with nc processes I opened from other terminals. It's cool and I actually didn't expect it to work, so I may dig a little deeper to understand how it works with a Wasm module (a preview1 image).

[alexcrichton]

I commented in another issue as well but if it aligns with your goals one thing that might be good is to implement mio's support for WASI in terms of the wasip2 target with wasi-sockets. Otherwise though I'm glad you were able to find the -Spreview2=n flag for local testing for now (sorry again for the bad name...)