-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: sockets example? #34
Comments
Great question! Go in v1.21 will support vanilla WASI preview 1, which has only limited networking capabilities. Specifically, you can only interact with a pre-opened socket file descriptors via This library provides a WasmEdge sockets extension, and may support other socket extensions in future (e.g. WASIX via #32). It sets up the WebAssembly runtime on the host side with the necessary system call implementations, but the guest (in this case, Go with There are two options:
This is still a rapidly evolving area so we'd appreciate any feedback you have 😄 I should add that these issues affect Go only. You should (in theory) be able to compile applications from other languages (e.g. C/C++/Rust/Zig) and get full networking support. |
Ah, makes sense. We’re using One tricky bit is that What do you think the odds are that stealthrocket/go#2 lands in 1.21? Is it possible to extract that into an alternative |
This is new: https://github.com/tetratelabs/wazero/releases/tag/v1.2.0 Looks like built-in support for pre-opened sockets: tetratelabs/wazero#1493 |
Hello @ydnar! We open-sourced https://github.com/stealthrocket/net which has a Let us know if this is useful and if you have any feedback! |
Nice! I'll check it out. What are your thoughts on WASIX? |
On WASIX, we love that important industry actors are trying to innovate and create experiments to enable more and more applications to run on WebAssembly. We've started a spike on adding ABI support for WASIX sockets in wasi-go #44 At first, it seems like the WASIX ABI footprint is all-or-nothing, programs compiled to WASIX easily take dependencies on threads and other extensions, which makes it a challenge to adopt incrementally. We're gonna keep investigating and help where we can, interoperability is an amazing feature of WASM so the more we can make systems compatible with one another the better! |
On the subject of threads, what's the current state of wasi-go with respect to non-blocking IO and goroutines? |
wasi-go has full non-blocking support, a Go program compiled with GOOS=wasip1 will be able to do cooperative scheduling and dispatch I/O to goroutines just like any other target gang Go compiled to. We still have a CL that needs to be merged in Go to enable non-blocking on stdio https://go-review.googlesource.com/c/go/+/498196, if you're interested in seeing this happen in 1.21 you could chime in there and voice your support for the change! |
Will do. Would love to nudge this along more: https://go-review.googlesource.com/c/go/+/500576 |
Ah yeah! This first attempt isn't going to make it but we have an alternative, stay tuned! |
I got this working with a proxy package that substitutes
(Note: this is to 127.0.0.1:6379, without having to resolve The commands I’m using to build and run: wasm: dist-dir go.sum tools $(go_source) $(resource_files)
GOOS=wasip1 GOARCH=wasm CGO_ENABLED=0 gotip build -ldflags "$(GO_LDFLAGS)" -o $(wasm_binary)
wasm-run: $(wasm_binary)
wasirun --non-blocking-stdio --sockets auto --listen 127.0.0.1:8080 $(wasm_binary) |
Would you happen to be able to share the code snippet for your application so we can reproduce the issue? |
We’re using github.com/gomodule/redigo/redis to create a connection pool. It has a config option to override pool := &redis.Pool{
MaxIdle: 64,
MaxActive: 128,
IdleTimeout: 5 * time.Minute,
DialContext: func(ctx context.Context) (redis.Conn, error) {
options := []redis.DialOption{
redis.DialContextFunc(wnet.DialContext),
redis.DialConnectTimeout(redisConnectTimeout),
redis.DialReadTimeout(redisReadTimeout),
redis.DialWriteTimeout(redisWriteTimeout),
redis.DialPassword(password),
}
return redis.DialContext(ctx, platform.TCP, addr, options...)
},
TestOnBorrow: func(conn redis.Conn, t time.Time) error {
if time.Since(t) < time.Minute {
return nil
}
_, err := conn.Do("PING")
return err
},
} wnet_wasip1.go: //go:build wasip1
package wnet
import "github.com/stealthrocket/net/wasip1"
// Dialer implements Dial and DialContext.
type Dialer = wasip1.Dialer
// DialContext opens a new net.Conn.
var DialContext = wasip1.DialContext
// Listen opens a net.Listener.
var Listen = wasip1.Listen wnet_unix.go: //go:build unix
package wnet
import "net"
// Dialer implements Dial and DialContext.
type Dialer = net.Dialer
// DialContext opens a new net.Conn.
var DialContext = (&net.Dialer{}).DialContext
// Listen opens a net.Listener.
var Listen = net.Listen |
I disabled if runtime.GOOS != "wasip1" {
signal.Notify(done, os.Interrupt, syscall.SIGTERM)
} |
@ydnar try running wasirun with |
This is working great. Closing, thanks for your help! |
Hi there, pardon if this isn’t the right place to ask a question…
Thanks for building this! Yesterday I was able to build and run a reasonable chunk of our stack with WASI after patching a few pieces (filesystem access, a few upstream dependencies without wasm/wasip1 compatibility), and immediately ran into the fake
net
package that’s currently shipping ingotip
.Would love to continue grinding on this so our stack can be—at least partially—deployed into a WASM/Wasi environment.
net
package semantics?Thanks!
The text was updated successfully, but these errors were encountered: