wasi: net implement sockets

[james-lawrence]

Proposal Details

there is a sockets proposal for wasi in phase 3 (implementation). I'd like to start laying the ground work for that in golang as an experiment initially. the scope is mainly to wire up socket (tcp/udp, possibly unix if thats easier since filesystem already is supported) support within golang behind a flag for the wasi arch and help move the standardization process along.

What I'm not sure on is the golang teams willingness to support/enable such work. looking for clarity on where the boundaries would be and the process we'd want to follow for it.

[johanbrandhorst]

The sockets WASI proposal referenced builds on top of WASI 0.2 (AKA wasip2) and the WASI Component Model. Go today supports WASI preview 1 through the wasip1 GOOS value. There are rough plans for implementing wasip2 support, but it will depend on other ongoing work (go:wasmexport, wasm32, WASI FFI type constraint relaxation).

We can't make progress on implementing the sockets proposal until we have a wasip2 proposal in place. I expect the sockets proposal will be implemented as part of implementing a wasip2 GOOS target, so I don't know that this proposal makes sense independently of a well thought out proposal for implementing a wasip2 GOOS target.

If you'd like to help contribute to this effort, please have a look at one of the existing proposals, and join the #webassembly channel on Gophers Slack where we coordinate any ongoing work to implement them.

[johanbrandhorst]

In the meantime, if you want to use WASI and networking sockets, the official Go WASI blog post references https://github.com/stealthrocket/net, which can be used to get networking on GOOS=wasip1 on runtimes that support the unofficial wasip1 networking extension (wasmedge, wazero).

[james-lawrence]

we're aware of the library its not sufficient for our use case. which requires transparent interopt with stdlib. stealthrockets implementation doesn't provide that. it mutates the default dialers, requires using stealthnet's custom net package, and doesn't (last I checked a couple months ago so this may have changed) support remapping filesystem paths in the guest runtime. technically we could get part of the way there if stealthnet supported fs path remapping potentially and could defer the golang upstream support for networks. but that'll just delay getting wasi implementing sockets as a standard due to lack of implementations. We'd rather just move the ball forward.

unfortunately we need upstream support in golang stdlib to support sockets as a result of all the above. we're happy to implement the missing calls within stdlib and put it behind compile experiment flags.

[johanbrandhorst]

In case it wasn't clear in my first reply, you cannot just "implement the missing calls within stdlib". You need to add all the surrounding infrastructure to support wasip2, which will include a proposal for how to handle everything that comes along with that (WIT client generation, function import/export, ABI, WASI component compilation). It sounds to me like your best path forward for now is to either contribute to the efforts I outlined above, or contribute the necessary changes to the stealthrocket/net library for your use case.

[james-lawrence]

I know what needs to be done for it to work. yes, you can 'just' implement the system calls long as host runtimes support them (which is exactly what stealthrocket has done). the issue is golang stdlib has implemented nothing because there are no implementations that exist for it to hook into. this issue is about getting that implementation going. its a boring chicken/egg problem, and I'll happily join that dev golang channel to kick start it since we need to get that ball rolling =)

[johanbrandhorst]

It sounds like you want to help implement runtime support for wasi-sockets? If so, I'd raise an issue against a Wasm/WASI runtime wazero or wasmtime. The Go project doesn't have a Wasm/WASI runtime so this wouldn't be the right place for it. That said, it seems wasmtime implements it if this issue is to be believed: bytecodealliance/wasmtime#4276.

Regardless of runtime support, we still need to answer the questions I outlined before the Go standard library can consider supporting wasi-sockets. Unless you want to turn this issue into a general-purpose wasip2 proposal, I think we should close it.

[james-lawrence]

I'm fairly indifferent to what the golang team decides here since wasip2 includes sockets I'm fine with that. my goal is to get the ball rolling on having some socket support moving forward in some manner as its been an annoying thorn in my side for a few months now (im just finally getting the bandwidth to address it). If golang team needs help getting the implementation done, im here for that in whatever form the golang team wants the process to take.

[seankhliao]

I believe this can be closed in favour of a future complete wasip2 proposal.