I’m still planning on creating networked browser-based VMs based on v86, by the way…
I desperately want a feature where a ServiceWorker can run a HTTP request to a browser VM(Part of plan is to enable hosting the entire project as a static website, by shipping a tiny Linux image with the scripts etc. installed, and booting that in the browser, to have a publicly hosted version, without allowing random users access to my server).
I’ve considered just writing an application that listens on the serial port, and responds to HTTP requests from the browser. But that seems slow and error-prone, and implementing full multiplexing with multiple event-streams and all seems unreasonable for such a hack.
The other option is adding a network stack to the Browser, and sending requests via actual IP/TCP/HTTP.
This sounds even more unreasonable, but there are some nice embedded TCP/IP stacks that can be ported easily to the browser using emscripten(I’ve read the porting guides, nobody has done that yet AFAIK).
There are currently two TCP/IP implementations I’m considering to port to the browser: uIP and lwIP(both written by the same guy Adam Dunkels)
Using uIP would mean that I only implement a minimal HTTP for getting/sending content from/to the VM, but no routing etc.
But that would probably be easier to implement and port. uIP in it’s “raw” form should basically just work if sending/receiving packets from the v86 network events when compiled via emscripten(I’d still need to write a dead-simple C program/wrapper).
You could still do possibly do routing in the VM network by using a VM as router and configuring the switch accordingly(might require a switch with MAC VLANs, but that’s easy to implement)
Using lwIP would mean that every VM gets a properly routed port, and packets will be forwarded only to the right place, instead of “broadcast” to all VMs and interfaces.
lwIP also supports some protocols directly, like HTTP, DHCP, DNS, etc. and this would expose that to the browser which is very cool.
lwIP is more difficult to port, all though I believe still very possible for a hobbyist like me.
Part of the plan is to connect multiple browser VMs, and connect external browser VMs via WebRTC, and connect external servers etc. via TAP device exposed via CGI.
This way you can effortlessly network between browser VMs, actual servers running a CGI script, and WebRTC peers, all from the comfort of your browser.
The browser VMs could also be live-migrated over such a network, and could stay up(even after a browser close) as long as a single browser tab is open somewhere within the network.