A facelift for the networking documentation

[chschnell]

Recently I've put some work into the networking documentation at docs/networking.md, please see my draft over at docs/networking.md.

I'm not sure how to proceed with it, I feel it is too early for a PR, so I'd very much welcome criticism regarding the structure, content, choice of terms, etc. I don't even know whether this work is welcome.

There are only few todos left from my side, just the last section "Links" is entirely empty, maybe others who've been here longer can give some input there.

[SuperMaxusa]

There are only few todos left from my side, just the last section "Links" is entirely empty, maybe others who've been here longer can give some input there.

How about an idea to mention the issues/discussions about tcpip.js, go-netstack (used in env86), node-relay? And about experiment with Domain Controller between two instances, also would be interesing.

[gregnr]

Thanks for the kind words @chschnell. Happy to collab on docs for tcpip.js.

Just a heads up, lots of development happening right now to make the experience even better, like DHCP/DNS server to auto assign IPs/domains to VMs, a bridge interface so that you can use tcpip.js as a router/switch between multiple VMs, and an HTTP API that matches the same interface as fetch. Will give updates as these become ready 😄

[SuperMaxusa]

@chschnell Thanks too, good docs!

Will give updates as these become ready 😄

I'm looking forward to it! :)

[chschnell]

Thanks for the kind words @chschnell. Happy to collab on docs for tcpip.js.

Just a heads up, lots of development happening right now to make the experience even better, like DHCP/DNS server to auto assign IPs/domains to VMs, a bridge interface so that you can use tcpip.js as a router/switch between multiple VMs, and an HTTP API that matches the same interface as fetch. Will give updates as these become ready 😄

Can't wait for it!

Earlier I assumed that you're working on a replacement for fake_network.js, but I just realized, this sounds more like a complete, in-browser network backend with HTTP access to the Internet (please see my draft for what I mean by network backend)? As you can see, I'm a bit struggling with where your work fits in within the v86 networking architecture.

[gregnr]

I'm a bit struggling with where your work fits in within the v86 networking architecture.

The short answer is: it's an inbrowser backend, but designed to allow you to connect to other networks if you want, and also provides APIs to communicate directly with VMs from JS.

Long answer

tcpip.js decouples network logic by acting as the router/gateway. Its goal is to a emulate a physical LAN where each device simply sends ethernet frames to the router (tcpip.js stack), then the router decides what do to with them. You're taking the network responsibility away from the VM and placing it on tcpip.js. You could configure tcpip.js to:

1. forward the packet to another VM (aka. LAN networking)
2. proxy the packet over WebSocket/fetch (aka. WAN networking)
3. consume it directly in JS via TCP/UDP APIs

In a pure inbrowser mode, tcpip.js would simply route packets between VMs. Similar to the BroadcastChannel approach, but instead of broadcasting frames to all VMs, it behaves like a real network switch and only forwards it to the intended recipient. Though it will also respect true broadcast frames (ff:ff:ff:ff:ff:ff) and IP packets (255.255.255.255) too. It's running a real network stack (in WASM), so you get all of this standard networking logic for free.

You could extend it to be a proxy by adding, eg. a tun or tap interface, setting it as the default interface, then piping its packets over a WebSocket connection. This would behave exactly the same as a WAN port on a router where local IPs are routed internally, but external IPs are sent over the WAN (WebSocket).

Most devs will probably find point 3 most useful - the ability to actually talk to VMs from JS. It exposes TCP and UDP APIs directly to JS which means you can communicate directly from the JS runtime to a server running in the VM. Or the inverse - you could host a server on the JS runtime, and the VM could connect to it. When I mentioned the HTTP API above, this is what I was referring to - the ability to send a local fetch request into one of the VMs, assuming they are hosting an HTTP server.

Ultimately it's designed to give you 100% flexibility over the virtual networking piece of your app by providing a real network stack that you can hook in to in whichever way fits your needs.

[chschnell]

Thank you for the in-depth exaplanation. Yours is a highly sophisticated backend model!

Would you let this count as a fair summary for me to put in my draft:

A virtual switch based on lwIP that internally connects three different types of ports:

• any number of VM-ports for in-browser v86 guests,
• any number of TUN/TAP-ports for in-browser JavaScript clients and/or servers, and
• a WAN-port that acts as a gateway to external networks using one of the wsproxy proxy servers.