Response headers: HTTP/1.1 200 k Content-Length: 1163 content-encoding: deflate I guess the '200 k' instead of '200 OK' saves an extra byte! :) 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.
Ultrafast single TCP packet audio/visual experience
71–79 of 79 posts
Re: Ultrafast single TCP packet audio/visual experience
#72Response headers: HTTP/1.1 200 k Content-Length: 1163 content-encoding: deflate I guess the '200 k' instead of '200 OK' saves an extra byte! :) 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.
Not unless they switch to http/1.0. in 1.1 you need one of: content length, connection close, chunked encoding.
Edit: I wonder if you could go full retro and just return a HTTP/0.9 response (no HTTP headers at all, just the page contents). If they then put back the DEFLATE/GZIP header bits, perhaps a browser would spot that the contents are compressed and do the decompression...
Re: Ultrafast single TCP packet audio/visual experience
#73Pro-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.
also maybe the title could have [LOUD!!!] or something like that. I didn't realize my system could make a noise that loud with vol at 50%.
Re: Ultrafast single TCP packet audio/visual experience
#74For 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. You can visit the demonstration website here: http://packet.city/ You can see a screenshot of the demo here: http…
Re: Ultrafast single TCP packet audio/visual experience
#75Re: Ultrafast single TCP packet audio/visual experience
#76Earlier quoted context omitted.
This would be really great without the audio. Due to the sound of the audio my initial reaction is to be fascinated, followed immediately by discomfort.
Over the last 5 years I've learnt to set the default sound level on my computer to "mute"
Re: Ultrafast single TCP packet audio/visual experience
#77Earlier quoted context omitted.
Probably the two round trips. A semi-nearby server might be 50ms per round trip, and in that case any connection beating 1mbps can transfer 14KB in less than two round trips. A server could easily be 150-250ms away and make those round trips far worse.
It also depends on the buffer size. Some routers might only buffer 1 millisecond of line-rate data or less. If that's the case, that initial congestion window of 10 could overflow the buffer, causing loss and a much more costly double-round-trip to resend.
Re: Ultrafast single TCP packet audio/visual experience
#78All hail the rise of the Single Packet Web App.
Re: Ultrafast single TCP packet audio/visual experience
#79They 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!)