Comments URL: https://news.ycombinator.com/item?id=45232758

Points: 2

# Comments: 0

With this kind of solution, the proxy only deals with the data in the underlying TCP socket. That data will be encrypted with TLS until it gets to the destination server. In this case, you don't need to fully trust the proxy sever to use it safely.

My first approach for networking was also to use SOCK5 through a Websocket. However, this turns out to be really slow. Each new connection created by emscripten requires waiting for: the TLS handshake from the browser to your proxy, the Websocket handshake which takes place over HTTP/1.1, the SOCK5 handshake on the Websocket, and the TLS handshake from libcurl to the destination server.

That's many many round trips required just for a single request! In practice, if the proxy server isn't physically close to you, the latency can be multiple seconds. This is partially mitigated by the fact that libcurl can use HTTP/2 to reuse that socket, but if you're placing requests to different hosts, or those that don't support HTTP/2, this is a huge problem.

The solution is to make it so that multiple TCP sockets can share the same Websocket, and then minimize round trips in the proxy protocol. I wrote a new protocol for this purpose here: https://github.com/MercuryWorkshop/wisp-protocol

It basically acts like multiplexed SOCKS5 over a Websocket. One trick that it uses to reduce latency further is for the client to simply assume creating a new socket succeeded, and to start immediately sending data, which eliminates another round trip. So apart from the very first connection which establishes the Websocket, there is zero added latency for new sockets.

Actually getting Emscripten to use this is slightly cursed and you need to patch the generated JavaScript using some Regex. I could probably get this upstreamed in emscripten someday through.

Also, it turns out that when writing this sort of network proxy, it doesn't really matter what language you use. The bottleneck ends up being the Linux TCP stack. You might think that a hyper optimized Rust or Go based Websocket proxy would be faster, but I found that the Wisp proxy server I wrote in Python was on par with the one written in Rust during synthetic tests. Even the slowest implementations get upwards of 2 gbit/s of throughput (on slow CPUs) which can saturate the NICs of almost all VPS providers.

It really just looks like you're just trying to take advantage of my work for clout/ad revenue.

However, I chose the shareware version since the file size is a lot smaller and it's more recognizable to people.

A disclaimer though - I don't have any experience with Doom modding. I don't know if the behavior of this feature is correct. All it does is it loads the PWAD by passing the "-file" argument to the game's main function.

I was inspired by the recent HN post about Tetris in a PDF (https://news.ycombinator.com/item?id=42645218) and I wondered if I could get Doom to run using a similar method.

It turns out that old versions of Emscripten can compile C to asm.js code that will happily run inside the limited JS runtime of the PDF engine. I used the doomgeneric (https://github.com/ozkl/doomgeneric) fork of the original Doom source, as that made writing the IO fairly easy. All I had to do was implement a framebuffer and keyboard inputs.

Unlike previous interactive PDF demos, the output for DoomPDF is achieved by creating a text field for each row of pixels in the screen, then setting their contents to various ASCII characters. This gives me a 6 color monochrome display, that can be updated reasonably quickly (80ms per frame).

The source code is available at: https://github.com/ading2210/doompdf

Note that this PDF can only run in Chromium-based browsers that use the PDFium engine.

Comments URL: https://news.ycombinator.com/item?id=42678754

Points: 369

# Comments: 74

Comments URL: https://news.ycombinator.com/item?id=41866802

Points: 407

# Comments: 77