Update: Fast Download
March 15, 2024
I've been working on the infrastructure for the Another Hour Another Planet endgame, and the various pieces are coming together.
There are now two AHAP servers running, which you can see here:
http://onehouronelife.com/ahapReflector/server.php?action=report
These are live and playable with bare-bones placeholder content, which is being managed here:
https://github.com/jasonrohrer/AnotherPlanetData
Eventually, the elected Content Leader will be able to edit and add to the content in this repository, and then make it live using this update trigger interface:
http://onehouronelife.com/ahapUpdateGate/
The general idea is that the community will make content (sprites, objects, sounds, and animations) and the submit it to the Content Leader as OXZ export bundles. The Leader will then choose which content to accept and integrate it into the master content tree, which is being maintained on Github. Once an "update full" of content is ready, the Leader will be able to push it out to the AHAP servers and players.
Off-Steam, One Hour One Life has always used its own custom-built update-downloading system. But elements of that system are going to be exercised heavily by all AHAP players in the future---even Steam players---since that's how user-generated content, selected by the Content Leader, will be delivered to players.
In testing this, I noticed that the first diff bundle for AHAP, the one that includes my place-holder content, was annoyingly slow to download. At around 48 MiB large, it was bigger than most individual OHOL diff bundles. At first, I thought the bandwidth on my download servers was lacking, but in doing some stress-testing, I found that downloading through the OHOL client was 2 to 4x slower than downloading the same diff bundle directly.
Long ago in my development career, I digested a bit of wisdom and took it to heart: threads are evil. Avoid using them whenever possible. A corollary is that when you're making networked systems, non-blocking IO is the performance king. In your main thread, you just check the socket to see if there's new data to read, and you read as much as you can, and then you continue on doing other things, and then you return to check the socket again later. While this is 100% true server-side, when you need to handle requests from hundreds or thousands of simultaneous clients, things end up working a bit differently in interactive GUI software when you're just trying to maximize download bandwidth.
In order to keep the GUI responsive, you have to keep returning to it and synchronizing with it---you need to wait for the graphic cards VSYNC interval. But waiting for VSYNC can take a while. On my test system, which was updating the screen at 60 Hz, you can end up waiting for 16.6 ms, worst case. But what's happening during that 16.6ms? Well, more data is arriving on the socket, and you're not reading it, because your main thread is stuck waiting for VSYNC. On a fast network, this is bad, because a lot of data can arrive in 16.6 ms. Let's say the OS receive buffer for your socket is 8192 bytes, which is the default size on many systems. And let's say you're on a pretty average DLS connection like mine, downloading at 40 Mbps. Well, during that 16.6ms, something like 83,000 bytes will arrive, which overflows the OS receive buffer ten times over. Even if you code things just right to do as much work as possible between VSYNC, if you wait for even 1/10 of the VSYNC interval, your receive buffer overflows. I haven't looked into the details of what happens when the buffer overflows, but my guess is that the socket has to send some kind of signal to tell the server to stop sending data (or maybe it's just through lack of packet ACKs coming back to the server). Regardless, the server is sending packets that aren't being received, and at the bare minimum, they will need to be re-sent later. Goodbye max throughput.
You can imagine all kinds of tricks to overcome this problem while still using threadless, non-blocking IO, but they all hit the hard reality of waiting on VSYNC eventually. Even if they don't wait on VSYNC as much, you can't have a responsive UI with a progress bar unless you're occasionally drawing to the screen.
The most straight-forward way to solve this problem is with a thread that runs in the background, receiving data from the socket as fast as possible, while your main thread continues updating the GUI and progress bar in a responsive way.
So yes, there's a thread in OHOL now! Actually, there was always one other thread in OHOL, because it turns out that on many platforms, resolving a DNS host name to an IP address cannot be done in a non-blocking fashion. But that LookupThread was pretty trivial. This new thread is doing a substantial amount of work.
And with all that in place, the OHOL client downloads stuff fast, maximizing the available bandwidth between the download server and you.
For the time being, this will mostly impact off-Steam players who are downloading all of their OHOL updates through this system.
|
|
|
