How to DDOS yourself

96 points by jmintz 14 years ago | 18 comments

johnrob 14 years ago |

Great example of why client side software is more exacting (and frightening) than building for the web. I wish I had more of these tales as ammo for future "native vs mobile web" debates.

kevingadd 14 years ago | |

What exactly protects web developers from this problem? Badly written AJAX-based code could do this just as easily as client software. Web development isn't a magic cure-all and it certainly doesn't protect you from the problem described in this post.

azim 14 years ago | | |

Part of the issue, a bit tangent to your point, is that when dealing with thick client software, once a version is released you can typically expect it to be in the field for quite some time. Many customers are upgrade-averse and simply won't upgrade a piece of software that is working suitably for them. Software developers have a bad habbit of fixing one bug and introducing another. With a web-based application you essentially control the release platform and can change things behind the scenes.

jwcacces 14 years ago |

How about this revolutionary idea: don't connect if you've got nothing to send. That way, the first power event sends the logs, and the next several hundred do nothing! Timeouts work great too. Don't send a log if you've just sent one in the last hour. Yeah, the android is acting weird here, but the problem is defiantly the application logic.

nddrylliog 14 years ago |

One might wonder why they simply didn't limit the number of log sends per day. Then they would've had no zombies at all..

commanda 14 years ago |

This is why it's often a good idea to outsource tasks that aren't your business's core competency. I've used Flurry for mobile stats tracking because they've devoted a lot of time figuring out solutions to problems like this. Time I don't have, and DDOSs I don't have to diagnose.

pkandathil 14 years ago |

I guess just setting the phone to state to sending file while uploading the logs to the server was the solution. Is there a better way to solve this issue? The user did not put it as part of the article.

Pewpewarrows 14 years ago | |

Meh, to me that's just band-aiding the problem. The core issue here is that they anticipate getting the log from each user approximately once every day or two (that's on average when people plug in their phones to charge). I would just keep track of the timestamp of the previous log upload, and simply ignore the Intent if it's within a certain threshold (say, less than 12 hours ago).

pkandathil 14 years ago | | |

Do you think it makes sense with the mobile architecture to have an application store its current state? This is obviously a more general question regarding mobile application architecture. This would specifically to be handle broadcast listeners performing conflicting actions.

ikhare 14 years ago | |

We decided to upload when only when we had logs right when the user backgrounded the app. This way we don't fire a new connection just for logs.

bxr 14 years ago |

Testing software before shipping found to help reduce undesired behavior in the field, film at 11.

Also, unconditionally opening a connection before finding out if they even have data to shoot across?

jamiequint 14 years ago | |

Buying every existing phone that is sold in reasonable volume across all major networks in all major countries and testing them individually on each release is probably not the testing plan I would go with.

bxr 14 years ago | | |

I didn't say that they should have tested it on every target, just that they didn't. They accepted the risks and were bitten by it.

funkah 14 years ago | |

The problem wasn't really lack of testing, unless you expect these devs to test their app on every extant Android device and all future devices as well. The problem is that they assumed they could rely on the behavior of the Android system on one device to apply to another, and that turned out not to be the case.

Even worse, the device in question ("Fascinate") was apparently just a Verizon-branded version of the Galaxy S, which probably gave them a false sense of security if they tested their app on the Galaxy S.

But, as you touch on, there do seem to be some things they could have done differently here. Checking the last time the logs were sent, not connecting unless there is data to send, etc.

samgro 14 years ago |

Great illustration of one of the many reasons why developing for iOS is easier than Android...no need to deal with buggy hardware driver edge cases.