2 ms·

> I believe most browsers do it like that, these days Nope. Browsers send a byte range request for the whole file (`0-`), and the correspoding time range grows

> I believe most browsers do it like that, these days Nope. Browsers send a byte range request for the whole file (`0-`), and the correspoding time range grows as the file is being downloaded. If the user decided to seek to a different part of the file, say at byte offset 10_000, the browser would send a second byte range request, this time `10000-` and a second time range would be created (if this part of the file has not already been downloaded). So there is no evidence there that any browser would stream files in small chunks, request by request. > in terms of server memory usage It's not less efficient in terms of memory usage because the server wouldn't read more data from the filesystem than it can send with respect to the flow control. > concurrent open connections Maybe if you're on HTTP/1, but we live in the age of HTTP/2-3. > Many wireless protocols also prefer large, infrequent bursts of transmissions over a constant trickle. AFAIK browsers don't throttle download speed, if that's what you mean.

lxgr 2y ago
Ah, interesting, I must have mixed it up/looked at range request based HLS playlists in the past. Thank you! > AFAIK browsers don't throttle download speed, if that's what you mean. Yeah, I suppose by implementing a relatively large client-application-side buffer and reading from that in larger chunks rather than as small as the media codec allows, the same outcome can be achieved. Reading e.g. one MP3 frame at a time from the TCP buffer would effectively throttle the download, limited only by Nagle's Algorithm, but that's probably still much too small to be efficient for radios that prefer to sleep most of the time and then receive large bursts of data.
- koakuma-chan 2y ago
  Realistically you wouldn’t be reading anything from the TCP buffer because you would have TLS between your app and TCP, and it’s pretty much guaranteed that whatever TLS you’re using already does buffering.
  - lxgr 2y ago
    That's effectively just another small application layer buffer though, isn't it? It might shift what would otherwise be in the TCP receive buffer to the application layer on the receiving end, but that should be about all the impact.
    - koakuma-chan 2y ago
      Oh you’re right, I’m just so used to making the TLS argument because there is also the cost of syscalls if you make small reads without buffering, sorry xD

lxgr 2y ago

Ah, interesting, I must have mixed it up/looked at range request based HLS playlists in the past. Thank you! > AFAIK browsers don't throttle download speed, if that's what you mean. Yeah, I suppose by implementing a relatively large client-application-side buffer and reading from that in larger chunks rather than as small as the media codec allows, the same outcome can be achieved. Reading e.g. one MP3 frame at a time from the TCP buffer would effectively throttle the download, limited only by Nagle's Algorithm, but that's probably still much too small to be efficient for radios that prefer to sleep most of the time and then receive large bursts of data.

koakuma-chan 2y ago
Realistically you wouldn’t be reading anything from the TCP buffer because you would have TLS between your app and TCP, and it’s pretty much guaranteed that whatever TLS you’re using already does buffering.
- lxgr 2y ago
  That's effectively just another small application layer buffer though, isn't it? It might shift what would otherwise be in the TCP receive buffer to the application layer on the receiving end, but that should be about all the impact.
  - koakuma-chan 2y ago
    Oh you’re right, I’m just so used to making the TLS argument because there is also the cost of syscalls if you make small reads without buffering, sorry xD