Closed rog77 closed 3 years ago
The network connection works by transmitting raw ethernet frames via a websocket back to a server that behaves more or less identically to a home router.
To achieve what you're asking on the client side, we'd need to build low-level stateful packet inspection into jor1k that detects in-transit HTTP requests, then transforms them into XHR or fetch requests, then transforms the results back into raw ethernet frames. This would only work for HTTP, as HTTPS requests are encrypted, and therefore can't be inspected in this way without jumping through additional hoops that would degrade the security of TLS on jor1k.
A better approach to mount a Google drive would be to write a 9P storage adapter for Google drive. I personally don't have the time to work on this, but if @s-macke agrees that this approach would work and that the end result would be beneficial to the project, someone could definitely submit a pull request.
Thanks for the response. I am not sure that this is where I should be asking such questions, and I don't mean to be a pain. I hope to use OR1K in a project soon, and as part of that would just love to be able to use Jor1k along side other implementations.
Can I ask what would the feasibility be of having a second interface in the browser that handled http\httsp direct to the web, such that is was presented within the OS along side the one that uses websockets, and leave policy routing to the user?
what would the feasibility be of having a second interface in the browser that handled http\httsp direct to the web, such that is was presented within the OS along side the one that uses websockets, and leave policy routing to the user?
See my previous comment. The answer to this question is exactly the same, I'm afraid.
FWIW, when I implemented network support I really wanted it to be a 100% client-side solution, but for fairly obvious security reasons browsers don't allow for websites to initiate socket connections of any type to anything but the request origin, and even then you're restricted to websockets. Pedants will point out that this isn't strictly true because of CORS, but that doesn't change things functionally here.
There are new emerging decentralized web technologies however that may change this in the future, but for now those protocols are not supported in the browser, and the ones I've experimented with (various flavors of libp2p) are rather high-latency, potentially high message-loss, and generally not well suited to this sort of purpose because of their need to rely on redundant transmission of data throughout the network.
Something that I haven't had a chance to look into is WebRTC. This would likely still require a centralized server for network participant coordination, but I believe it allows for direct p2p connections to be made from browser-to-browser.
If someone does the legwork to come up with a decent scheme for using that in place of websockets, I'll be happy to write an alternative virtualized ethernet controller implementation based on their findings. I don't really have the time to do the research on it now, however.
@benjamincburns All I tried was to setup Apache webserver inside the VM and hosted a website to serve outside the VM. The websockproxy DHCP assigned VM IP is not reachable from the host machine. Any suggestion to web-host inside VM and server outside?
@DawnofMan that's likely one for another issue, but I'll answer here anyway. What you're trying to do is the same as running a web server in your home network and trying to access it via the public internet. To do so you'd need to set up a port mapping (port forwarding rule) on your home router.
Websockproxy is analagous to your home router in this case. That is, it behaves as a DHCP service to assign IP addresses to a private subnet (10.X.X.X), and behaves as a NAT gateway to route packets to subnets outside of the private subnet. Unfortunately it doesn't have any features that allow for port mappings.
Websockproxy is a stateless demo service at the moment. Keeping it stateless allows me to run it very cheaply so that I can provide it for free for jor1k users. If I were to add stateful features like port forwarding rules, I'd likely need to charge people to use it, as the operating costs would go beyond what I'd prefer to spend to offer it up as a free service.
I'm going to close this issue as I don't believe it's technically feasible to address the initial problem raised, and I'd rather new discussion topics be directed to new issues.
Is there any setting to separate out http traffic, such that it goes directly to the target rather than to a/your websockets server?
With the addition of Google sign-in, couldn't one then mount a Google drive within the in browser linux? One could also download user/system settings/profiles from drive?
With the addition of a bluetooth keyboard, Jor1k runs nicely on a Fire TV stick from the standard browser, I think it would make for a really handy addition to the app store.
Thanks!