For those you are wondering, this is a webserver that serves an HTML page in a single TCP packet. I guess ≤ 1500 bytes to avoid fragmentation - shows as 1.1KB in Chrome's network view. The HTML contains embedded JavaScript that runs a simple demo with animated ASCII and playing a LOUD changing audio tone.<p>You can visit the demonstration website here: <a href="http://packet.city/" rel="nofollow">http://packet.city/</a><p>You can see a screenshot of the demo here: <a href="http://www.p01.org/128b_raytraced_checkboard/" rel="nofollow">http://www.p01.org/128b_raytraced_checkboard/</a>
Pro-tip: If you are doing additive synthesis and want to stack sine-waves in a harmonic series, please scale each successive n harmonic to an amplitude of 1/n. It creates a much more tolerable experience.
Interesting to see DEFLATE over GZIP here, as it is something I used to recommend maybe 7 or so years ago. I collected results for several years and began seeing more browsers dropping support for raw deflate (or switching to zlib deflate).<p>I accidentally let my hosting account expire years ago and lost the server code and db for it, but managed to pull the HTML from the way back machine. I've backed up the results here: <a href="https://davidmurdoch.com/compression-tests-results/" rel="nofollow">https://davidmurdoch.com/compression-tests-results/</a>. It's all pretty outdated now, but rather fun to look at.<p>Anyone know if this is using raw DEFLATE or ZLIB (HTTP 1.1 DEFLATE)?
Response headers:<p><pre><code> HTTP/1.1 200 k
Content-Length: 1163
content-encoding: deflate
</code></pre>
I guess the '200 k' instead of '200 OK' saves an extra byte! :)<p>However, since they don't do any HTTP keep-alives (the connection sends a HTTP response and closes before you even send it anything), couldn't they save some space by dropping the Content-Length? It's an optional header.
<a href="http://packet.city/" rel="nofollow">http://packet.city/</a><p>summary: A demo scene page that is smaller than a single IP frame and uses some flags to avoid other round trips.<p>view-source:<a href="http://packet.city/" rel="nofollow">http://packet.city/</a><p>The page itself and view-source only work on some browsers. Use wireshark etc to see what it actually does.
They spend nearly 75% of the page weight on that party parrot image - if they dropped that, the rest of the page could probably be a lot more impressive (and less screechy!)
Nice work. I guess it'd just as quick if it sent up to ~4kB - that's the normal TCP initial window? <a href="https://tools.ietf.org/html/rfc3390" rel="nofollow">https://tools.ietf.org/html/rfc3390</a>
Nice. I was just reviewing some TCP fundamentals with my friend for his class, specifically sliding windows and window control, etc.<p>It's as if they took what we were just reading in a compsci textbook for class and directly monetized it.
It might be fast but does it handle load? Did you try to benchmark it with a service like <a href="https://ddostest.me" rel="nofollow">https://ddostest.me</a>