5 ms·
This only throttles the speed, it doesn't drop packets, AFAIK.
by Flimm 3y ago
This only throttles the speed, it doesn't drop packets, AFAIK.
- hunter2_ 3y agoIn a browser context, doesn't the HTTP stack sort out any issues in lower layers such as those stemming from packet loss (e.g., packets arriving out of order) such that what's presented to the client app (and debuggable by the developer thereof) is just an HTTP response or lack thereof? That lack thereof (or additional latency) could be due to packet loss, but it doesn't have to be, and it doesn't really matter because it's abstracted away.
- burntcaramel 3y agoThe problem is it throttles everything by a constant factor. So if at full speed response A arrived after response B, it still most likely will, they will all just arrive slower. It’s like the safety car in Formula 1: the cars will all slow down to crawl, but they won’t change order because they can’t overtake. Better to test a scenario like in F1 where one car hits another, and then takes a few more out with them. That will really scatter the order and timings of things. That’s more how the real world of Wi-Fi and cellular connections works, so being able to handle that level of unpredictability is going to lead to way more robust apps and a better UX. I have a dream of opening a co-working space for developers where you can connect to “Free Airport Wi-Fi” to really test your web application is going to survive in the real world.
- deleted 3y ago[deleted]