This is great. I would love mobile support.
Comcast: Simulating shitty network connections so you can build better systems
71–80 of 87 posts
Re: Comcast: Simulating shitty network connections so you can build better systems
#72Earlier quoted context omitted.
I don't think Dumb Starbucks was saved. They just didn't ride it out long enough to find out. Who knows what would have really happened though
The problem is that fair use and satire are defenses that must be argued. They don't automatically stop you from being sued. It can results in a lot of upfront costs and hoops to jump through before you are actually granted your fair use exception. You have to be pretty committed to your joke to actually fight something like this to the end. Although if I were Comcast, I would ignore this entirely. I wouldn't want to…
You can't ignore a trademark violation and keep your trademark. Trademarks can become "generic" (think Kleenex or Band-Aid) if not enforced, which makes them unenforceable. So no, they won't ignore it.
Re: Comcast: Simulating shitty network connections so you can build better systems
#73On linux, tc can do similar things, such as dropping a percentage of packets or adding random delays. http://linux.die.net/man/8/tc
From TFA :) > On Linux, we use iptables and tc. Comcast is merely a thin wrapper around these controls.
Re: Comcast: Simulating shitty network connections so you can build better systems
#74Earlier quoted context omitted.
I keep hearing a categorical "you can't do P2P on mobile." I intend to fling myself at this problem like a drunk seagull soon, so I'll blog on it. I think it's possible, but with a number of special considerations around wakeup-quantization and general power management, some protocol augmentation, and a high tolerance for nodes appearing and disappearing. Primer concept: http://en.wikipedia.org/wiki/Interrupt_coalesc…
The problem isn't power (well it is; but that can be overcome), it's spectrum and pricing. Pricing: Most people in the US are charged for the data they use on their mobile devices, and thus would not want P2P used on their phone because it costs them money. Spectrum: P2P is not a very efficient distribution model in a world where most clients are on asynchronous connections. Asynchronous connections exist because tra…
Good point on spectrum.
Verizon and AT&T monitor for super-chatty apps and in some cases can rate-limit or otherwise impair them.
Re: Comcast: Simulating shitty network connections so you can build better systems
#75Nice. It'd be neat to include options to simulate other pathological conditions often encountered in the field like: - Multiple layers of NAT - overlapping un-synchronized timeouts are one thing ... but the REAL fun comes in when intermediate layers have the same IP ranges as IPs you are trying to reach on the "outside" of the NAT sandwich. All kinds of "interesting" things can happen, like the "software laser": http…
I take it you've seen core switches on fire off the Jupiter gate?
Tannhauser gate
Re: Comcast: Simulating shitty network connections so you can build better systems
#76Very nice.
How's this better/different than Crapify?
Re: Comcast: Simulating shitty network connections so you can build better systems
#77Did this with dummynet on FreeBSD around 1999. Made it a bridge though, so everyone on the test network could "enjoy" 28.8kbaud dialup experience! Great fun.
Called it "the molasses network", which is what they should change the name to before Comcast smokes them.
Re: Comcast: Simulating shitty network connections so you can build better systems
#78Prediction: name of this project will be different within 12 months due to trademark infringement.
Re: Comcast: Simulating shitty network connections so you can build better systems
#79The project name is pure gold!
Re: Comcast: Simulating shitty network connections so you can build better systems
#80Earlier quoted context omitted.
I keep hearing a categorical "you can't do P2P on mobile." I intend to fling myself at this problem like a drunk seagull soon, so I'll blog on it. I think it's possible, but with a number of special considerations around wakeup-quantization and general power management, some protocol augmentation, and a high tolerance for nodes appearing and disappearing. Primer concept: http://en.wikipedia.org/wiki/Interrupt_coalesc…
The problem isn't power (well it is; but that can be overcome), it's spectrum and pricing. Pricing: Most people in the US are charged for the data they use on their mobile devices, and thus would not want P2P used on their phone because it costs them money. Spectrum: P2P is not a very efficient distribution model in a world where most clients are on asynchronous connections. Asynchronous connections exist because tra…
P2P doesn't necessarily mean cooperative relaying or swarm distribution like BitTorrent. I agree that those applications are mobile-unfriendly with current batteries and cell networks. It just means you are talking directly to your peers instead of back-hauling to the cloud. You can have P2P where the only traffic you handle is your own. In that scenario total aggregate bandwidth shouldn't be that different from a cloud-backhauled app -- the only difference you'd see is in how many endpoints you're talking to. So instead of seeing 25mb transferred to/from one IP, you'd see it sprayed across a few dozen IPs.
The big hurdles I see are (in no particular order):
- Connection maintenance and keep alive. Basically this is bad, so you want to be more aggressive about shutting down unnecessary P2P links on mobile than you need to on desktop/server. Keep alive requirements generally suck anyway, and are one way NAT murders kittens.
- Restrictions around background tasks on mobile OSes (iOS is particularly onerous).
- Squelching inbound traffic from badly behaved or broken peers to avoid inbound flooding.
- Battery life and related concerns.
I understand it this way: cellular networks currently have their own "netiquette." It includes things like don't be too chatty, try to coalesce instead of spewing packets at excessively random times, etc. These things are less important on wired networks since they don't have the same resource constraints or bandwidth issues.
I guess a related question is why you would do P2P and not backhaul to the cloud? I can think of many:
- Reduced latency for things like AR and VR where latency matters a lot.
- Reduced bandwidth cost due to lack of back-haul, and back-hauling a pic being sent between two people in the same city 2000 miles to a cloud server is just offensively stupid anyway.
- Privacy and security.
- With P2P you could have a more open app model where apps aren't wedded to proprietary cloud infrastructure. They still work even without someone's cloud, etc.