Live data from Hacker News

Ultrafast single TCP packet audio/visual experience

github.com

71–79 of 79 posts

Re: Ultrafast single TCP packet audio/visual experience

#71

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.

Not unless they switch to http/1.0. in 1.1 you need one of: content length, connection close, chunked encoding.

Re: Ultrafast single TCP packet audio/visual experience

#72
post #71

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.

Not unless they switch to http/1.0. in 1.1 you need one of: content length, connection close, chunked encoding.

True, their server should be returning HTTP/1.0. It's a shame that you can't get away with replacing the initial HTTP/1.0 with HTTP/1 and shave off another couple of bytes :)

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

#73
post #29
post #27

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.

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%.

I set my system's volume to the lowest possible value before mute (1/64) and it was still extremely loud and unpleasant. I'm actually impressed.

Re: Ultrafast single TCP packet audio/visual experience

#74

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. You can visit the demonstration website here: http://packet.city/ You can see a screenshot of the demo here: http…

That audio demo is CRAZY loud. I had my headphones on my desk since I'm on the phone and thought it was playing music through my laptop speakers.

Re: Ultrafast single TCP packet audio/visual experience

#76

Earlier 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"

You can also set your browser windows to automatically mute on chrome. I think in high sierra macOS will do it by default.

Re: Ultrafast single TCP packet audio/visual experience

#77

Earlier 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.

1 millisecond of buffering is geat on a high speed core link. But if you apply that to a 5 megabit connection you've basically decided you'll only buffer one packet. A slow-speed bottleneck link needs to have more capacity. The charts in http://www.nctatechnicalpapers.com/Paper/2011/2011-right-siz... suggest that 64KB is often a good buffer size for end links, and that can absorb 10 packets fine.
Post reply on HN