5 ms·
>Now we need app developers to log off their fiber-served wifi when writing messenger apps, and log into a high-latency, low-bandwidth, high-packet-loss network
by xoa 3y ago
>Now we need app developers to log off their fiber-served wifi when writing messenger apps, and log into a high-latency, low-bandwidth, high-packet-loss network instead so Messages will actually open instead of whatever it's trying to do to upload my location history and download contact pictures...
FWIW, it's perfectly possible to simulate arbitrary levels of bandwidth/latency with a variety of tools even while having a fiber connection. For example, Macs have long had the "Network Link Conditioner" tool as a free utility included with the Additional Tools for Xcode package, which then allows simulating configurable bandwidth, latency, and packet loss. There are similar tools for Linux as well, tc is powerful. Most firewalls with quality traffic shapers also allow at least the first two at the network level, I used that on OPNsense to simulate a VSAT connection with 750ms latency and 4/.5 to a specific VLAN so that we could just connect systems and then see how applications worked. It's been awhile but it was eye opening. A nice thing about that approach is that then you can just connect devices to a given VLAN, which makes testing back and forth super easy. Wired is trivial of course, have a switch where each port is a different test VLAN, but even for wireless if you have WAPs that support PPSK/MPSK, then hopping between test VLANs just means reconnecting with a different password. Simulating packet loss with a network device seems the be more niche and complicated and I don't know if any firewalls put a GUI on it. tc queue disciplines can be used though so any Linux device with two network ports can sit inline and modify the traffic to simulate loss/latency, an RPi would be fine for that.
I agree it'd be nice if more app developers would test under less than ideal conditions, particularly since it's so trivial to do so. I think most simply don't think about it though, same as many GUIs (web or local) not testing for stuff like various types of color blindness.
- cassepipe 3y agoFirefox's console in its Network tab also has a way to choose what tier of bandwidth you'd like: GPRS, 3G etc. Thought it was worth mentioning
- DaiPlusPlus 3y agoI find Firefox and Chrome's network-limiter feature to be "unrealistically unreliable" insofar as it limits data transfer bandwidth, and simulates some kinds of latency issues, but doesn't seem to implement things like DNS suddenly stopping working for 5 seconds, or sporadic network drop-outs, or how some things will arrive out-of-order, or an entire web-page blocked by a single synchronous <script> from one particular external host.
- londons_explore 3y agoI agree. It needs to simulate a phone right on the edge of connectivity, with the random 5 second dropouts, followed by 50 Mbps but downstream only, followed by another dropout, followed by 1kbps up and down, etc. That's the way real networks behave, and what real users have to manage with.
- lll-o-lll 3y ago> it's perfectly possible to simulate arbitrary levels of bandwidth/latency with a variety of tools even while having a fiber connection. Yes it is perfectly possible, but it’s very difficult. Having just gone through this process I can attest that this is not something the average “app developer” is going to be capable of doing, at least on Linux and Windows. The raw tools are there, but they are complicated, poorly documented, and require network engineering knowledge on top of software development knowledge. Probably there is some nice package to wrap up the whole “generate a virtual network and add latency + packet loss between these two end points”, I just never found it.
- DaiPlusPlus 3y ago> Probably there is some nice package to wrap up the whole “generate a virtual network and add latency + packet loss between these two end points”, I just never found it. Linux has a built-in command: trickle https://linux.die.net/man/1/trickle https://linux.die.net/man/1/trickle https://stackoverflow.com/questions/10328568/simulate-limited-bandwidth-from-within-chrome https://stackoverflow.com/questions/10328568/simulate-limite...
- eichin 3y agotrickle is clever, but when I've tried to use it for "use no more than this" bandwidth shaping (basically going for "rsync --bwlimit" but for a set of "related" rsync processes) the arguments given had very little to do with the amount of bandwidth actually consumed. (We found another way but definitely look at tc instead.)
- franga2000 3y agoIt's not that they won't be "capable of doing" it, it's that the effort required will be more than they care to put into solving a problem they can't sympathise with and/or isn't a requirement handed down from their boss. App developers have to jump through all sorts of technical hooks to get certain things done, but since their jobs depend on it, they power though. If "work reliably even in shit network conditions" was a baseline requirement that their jobs depended on, you bet they'd find a way. As for how hard it actually is: iOS has already been explained, the Android emulator has network latency and speed simulation right in the GUI, as do most web browsers. And there's alway the option to switch your phone to 2G only in the settings and/or go into the basement or elevator.
- lxgr 3y ago> For example, Macs have long had the "Network Link Conditioner" tool as a free utility included with the Additional Tools for Xcode package, which then allows simulating configurable bandwidth, latency, and packet loss. Well, I sure wish Apple would make use of that functionality themselves once in a while. It's frustratingly impossible to enqueue an iMessage message while out of signal and have it be automatically delivered once back in cell coverage. Bizarrely WhatsApp, a third-party application (with all the background execution restrictions that go with that), manages to do just that!