WASI: expand networking functions

[npmccallum]

We need a full fledged networking API. This includes functions like socket(), connect(), bind(), listen(), accept(), getsockopt(), setsockopt(), etc.

[maxmcd]

I think this one is pretty well documented: https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-capabilities.md#berkeley-socket-rules

And more from cloudabi on the issue with just providing socket(): https://github.com/NuxiNL/cloudabi#capability-based-security

As an example cloudabi uses flower to solve this issue: https://github.com/NuxiNL/flower

[npmccallum]

@maxmcd When Red Hat initially evaluated CloudABI, that was one of the primary reasons we rejected it.

[maxmcd]

Ah, interesting. Would love to hear more thoughts on why the approach is problematic. Naively it seems elegant enough to hand a program a connection to a db and worry about nothing else.

[npmccallum]

@maxmcd It can never work for a self-healing, distributed cluster. It can never work for any kind of proxy except for the most limited one with predefined connections. The list of things it can't do is pretty endless.

CloudABI was an ABI defined for a narrow use case. I'm really hoping WASI isn't.

It is perfectly legitimate for a particular implementation of WASI to return ENOSYS on functions like socket(). But it is another thing to prevent the working group from standardizing such methods.

[maxmcd]

Ah. I asked the proxy question to @EdSchouten recently:

I have a quick question. Let's say I have a web server that receives requests and makes arbitrary external network requests, like a web proxy. How would that work with cloudabi? Is it easy to configure flower to allow any external network connections?

That should be relatively easy. Below is an example of how you can achieve this with the standard Flower command line tools:

1. Run a switchboard to route requests.
   $ flower_switchboard ~/flower

2. Run an egress process that makes outgoing connections. We could let that hijack the entire address space of the switchboard by using {} as the listen address. Instead, let's only route requests to it that have a 'process' label set to a given value.
   $ flower_egress_connect ~/flower '{"process": "flower_egress_connect"}'

[example of simple network address redacted]

Fair enough though that with access to socket() and filtering done by the runtime could provide the same security guarantees.

[npmccallum]

@maxmcd Your runtime assumes communication between the host and the WASM code. Ours doesn't. The flower model can work in your use case, but it can't in ours.

[sunfishcode]

Yes, networking is a part of the API that we've not done much work on yet. I agree that it's desirable to support more than just preopened sockets from the runtime. I'm optimistic that it'll be feasible to create capabilities that represent address/port/protocol/etc. sets that an application is permitted to create sockets with, however it's obviously going to take work to flesh out all the details.

[npmccallum]

@sunfishcode While the BSD socket API isn't great, there are a lot of applications and libraries written to it. Whatever we do, we should make sure applications can be trivially compiled for the new APIs.

[jtenner]

Yeah this is definitely a huge bottleneck for the https://github.com/assemblyscript/node project which aims to use wasi for HTTP, TCP, and UDP stuff. What was the latest news on this standard? I'm dying to create a socket from wasi and get a wapm installable mud server going.

[sunfishcode]

At the moment, we're still working on putting together a template for making new API proposals, with WebAssembly/WASI#74 as one of the key pieces. Once that's in place, it will be possible for people to start making proposals, and I know some folks are already prototyping network APIs that could be proposed.

[svsintel]

WASM would make a great Agent based system where messages are passed between agents. Networking is required for this concept. I can think of different ugly ways to do the networking. One way I would like to see an "insecure" versions on sockets, just for concept development. There are two parts to the system, one is the wasm code that would contain network functions. and the vm/engine that would allow/deny socket sysCalls. Only on a system that has both parts could do networking.
A network interface is very important for WASM and WASI

[jtenner]

Yeah it's been a couple months since I posted here. What's the status on the working group? I would love to voice my opinion on the current set of suggested ideas.