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.

[sunfishcode]

#74 has landed, and we recently published our first API update using the new mechanism and process.

We recently had an in-person meeting about HTTP APIs; see the notes there, especially the slides linked there, for more info.

With that said, two things to keep in mind: One is that the next big step in WASI happening soon is that the API will be made modular, so that it's straitghtforward for implementations to chose not to implement features which don't make sense for them. Many implementations won't chose to implement HTTP proxying APIs, for example. The other is that WASI can address multiple levels of abstraction with different APIs. The fact that we're considering an HTTP API now doesn't preclude doing a plain sockets style API as well. And ideally, it should be possible to implement HTTP APIs on top of sockets APIs, so that an implementation could chose to support just sockets, and support the HTTP APIs via a pure wasm module loaded on top.

[ghost]

HTTP features in a low-level POSIX-like API seems highly out of place - let third-parties implement that stuff on top of the, low-level BSD-like socket syscalls from WASI instead (assuming they are added at some point).

An HTTP server or client is really high-level and can be implemented in a million different ways with tons of different goals and opinions - BSD sockets on the other hand are quite standardized and efficient and a much more logical fit for a low level base WASM API like WASI.

There are about a million web servers and clients ready to compile for WASI as soon as networking syscalls are added - let them figure out how to bring HTTP to WASM.

If you need an HTTP client, wouldn't it makes sense to let the market self-organize and let things like curl or wget come out the victor? I sure would prefer curl-on-WASI, rather than some new HTTP-client from WASI itself.

[svsintel]

Once low level sockets are implemented, then any upper level protocol can work. I can use "fetch" to access external data, but I want sockets to be able to listen.

[pchickey]

We agree that low level BSD-like socket functionality should be part of WASI. The HTTP interfaces we are working on are motivated by two environments (Fastly's Compute@Edge product, and Istio/ATS's proxy-wasm environment https://github.com/WebAssembly/wasi-http-proxy) where low-level socket access is inappropriate or impossible. These interfaces are not intended to replace socket interfaces or displace use of curl/wget in those environments.

[ghost]

Alright I misunderstood what WASI was about. Apparently it's not just low level.

But we still want BSD sockets :)

[tschneidereit]

But we still want BSD sockets :)

As @pchickey said, low level sockets do make sense. I'm not aware of anyone currently driving the process of working out a proposal for a WASI module. If that's something you'd be interested in helping drive, opening an issue in the WASI spec repository might make sense. See the recent issue on WASI-nn as an example. (Though of course something not as fully fleshed out definitely works as a starting point!)

We'd be happy to provide help with implementations in Wasmtime, be they experimental to support the standards process, or production-quality to already serve use cases!

[MikeCamel]

Suggest adding labels "wasi-network-sockets" and "feature-requests".

[tschneidereit]

Suggest adding labels "wasi-network-sockets" and "feature-requests".

@MikeCamel we don't have those, and should be careful about adding too many labels. I added the enhancement label and hope at least for now the combination of that and wasi:api should be enough. If and when the wasi labels become too crowded, we can look into adding a more fine-grained taxonomy.

[MikeCamel]

Sounds good, thanks.

[ShadowJonathan]

Is there any progress on this front? I was surveying krustlet for usage, but i quickly realized that quite core functionality like networking wasn't implemented all the way back here in wasmtime, and by extension, WASI.

Are there any proposals/issues/requests/PRs that I can follow on WASI's side to see progress regarding this?

[3miliano]

We at Kong we are working on full socket implementation for WASI. We included connect, bind, listen, accept, etc. We also added some security features so the host does have some sort of control about what the WASM code can connect to, listen to, and so forth.

I think it aligns with everything I am reading on this thread.

You can find the proposal here:
https://github.com/Kong/WASI/tree/feat/wasi-sockets
and a potential implementation here:
https://github.com/Kong/wasmtime/tree/feat/wasi-sockets

I would love to hear some feedback on it.

[ueno]

@3miliano that looks great! A couple of random comments below:

• IMO it would be nice if TLS and proxies are handled transparently by the host, rather than the Wasm guest, because those involve host dependent network configuration (such as TLS certificates handling and address translation) and may affect portability of Wasm application. If TLS is supported by the host, address resolution would also need to be done by the host, because the original host name is embedded and checked in the handshake (as SNI).
• Support for multiplexing might also be desirable, for protocols like QUIC.

I was sketching a draft proposal mostly focusing on those aspects, though the other POSIX related stuff is similar to yours.

[ShadowJonathan]

@3miliano can we maybe see the link to the pull request into WASI proper once it's up? Interesting proposal, I'll be looking out for it

[3miliano]

@ueno On the topic of TLS. Yes, that would be interesting. One thing to consider is that TLS doesn't exactly require system calls, and therefore you can of course compile a TLS library such as WoflSSL, OpenSSL, etc in WASM itself. Having said that, I hear you about the TLS. That might be something to look out for in the future.

I'll take a look at your proposal, maybe we can collaborate on a single solution.

[bjorn3]

Should this #71 and #73 be moved to https://github.com/webassembly/wasi?

[NobodyFAH]

Pardon me, but are there any updates concerning this topic?

[cardil]

The draft of the proposal is here: https://github.com/badeend/WASI-Networking

[hurae]

For who concerns, the draft of the proposal now moved to here: https://github.com/WebAssembly/wasi-sockets

[ondrejtomcik]

For who concerns, the draft of the proposal now moved to here: https://github.com/WebAssembly/wasi-sockets

Thanks for keeping us up to date!

[badeend]

WASI now has low-level sockets and higher-level HTTP support. So I think this can be closed now.