Update QuakeJS or replace with other browser client about quake-kube HOT 4 OPEN

"relies on SOCKS" isn't quite accurate. It will make websocket requests directly to quakejs servers if you want it to. I only use the SOCKS stuff to get the "Multiplayer" menu working with traditional native Q3 servers. It actually works as a SOCKS proxy for your whole computer, OR it also adds a websocket connection on top of the normal TCP way of controlling the proxy to support the web client.

Aside from the Q3 specific network logging the SOCKS proxy is a fully working SOCKS 5 proxy server.
https://github.com/briancullinan/planet_quake/blob/master/code/xquakejs/lib/socks.server.js

I've also considered adding the websocket protocol directly to the engine and not relying on the proxy or the dedicated JS build. This would probably be more similar to how the quakejs server works now. I just found it cringy to compile a "native" server to a non-native architecture like Nodejs. Seemed kind of counter productive since these 2 other (imho better) options became clear.
https://github.com/rohanrhu/cebsocket

from quake-kube.

Thanks for replying, this is good to know!

I agree completely wrt to the NodeJS version of ioq3ded, it ran so poorly (by like a factor of 20 times or more) which is why I ended up making a websocket -> udp proxy that runs in the backend:

https://github.com/criticalstack/quake-kube/blob/master/internal/quake/client/proxy.go

It ends up allowing using any vanilla implementation of the Quake 3 dedicated server, which is why we are using standard ioquake3 atm for dedicated servers. The only thing left from QuakeJS being used is the browser client, so do you think it would be as easy as building the planet_quake js target and then passing similar args in this fashion?

Interested to know your thoughts, if we could use planet_quake without much fuss that would be awesome!

from quake-kube.

Yes, of course. Those arguments are a feature of emscripten. My build still uses emscripten, but someday I hope to move away from it and only implement the OS features Quake 3 refers to in libraries. This is where I am making exceptions for specific configurations, it would be trivial to clean this up and add something for kubernetes use case:

https://github.com/briancullinan/planet_quake/blob/master/code/xquakejs/sys_main.js#L162

I think the easiest thing to do would be to add kubernetes configuration to planet_quake, then combine the features we like. Q3e is being maintained. They have a lot of bug fixes from other engines plus tons of performance enhancements. UrT engine, defrag engine, happy Diesel, and probably a handful more I don't know are all built from Q3e.

I actually started with a plain old UDP proxy, that is hanging around here, suggested by another member:

https://github.com/briancullinan/planet_quake/blob/master/code/xquakejs/bin/proxy-simple.js

But the problem became clear, that proxy would only access 1 or a specific number of endpoints based on some sort of control code. But a general proxy like SOCKS is controllable by the client. But with websockets in-between it's not quite so vulnerable as an open proxy. I could support passwords, and I'm using it over https/wss with Google Cloud load balancer.

I needed an excuse to learn to use kubernetes and it might be nice to run these as separate processes.

from quake-kube.

It would be amazing if there was like a 1 click run button for a few cloud providers that basically does all of this, scaling as needed for each service. If I was to properly split up the Dockerfile in to separate processes based on demand and resources. This is the stack we need for the entire project thus far:

from quake-kube.