4 ms·
How does that work in the browser context? Just one long-living HTTP request that the server streams messages too? How does the browser reply? It's hard to unde
by capableweb 5y ago
How does that work in the browser context? Just one long-living HTTP request that the server streams messages too? How does the browser reply? It's hard to understand how it's duplex and real-time over just HTTP without making more than one HTTP request.
- bullen 5y agoYou have two sockets, one eternal response with transfer-encoding: chunked, which is basically <hex_length>\r\n<data>\r\n\r\n over and over again, so very compact. On the browser to server it gets a bit heavier because you need GET /path?data=<message> HTTP/1.1\r\nHost: kinda.verbose.com\r\n\r\n and then each request gets a response that can be either zero so 200 OK\r\nContent-Length: 0\r\n\r\n or contain a sync. response. It looks bad but trust me that verbosity is a rounding error when it comes to the real bottleneck which is CPU concurrent atomic parallelism, and for that you basically need to use Java: https://github.com/tinspin/rupy/wiki https://github.com/tinspin/rupy/wiki (Most people disagree but the VM + GC and Javas memory model allows for atomic shared memory like none other, not even C/C++ can compete because you need a VM with GC to make that memory model work, they tried to copy it into C++11 and that was a faceplant of epic proportions that is still C++ memory model).