How to DDOS yourself (opens in new tab)

(devblog.bu.mp)

96 pointsjmintz14y ago18 comments

18 comments

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.

kevingadd14y 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.

azim14y 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.

jwcacces14y 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.

nddrylliog14y 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..

commanda14y 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.

pkandathil14y 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.

Pewpewarrows14y 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).

pkandathil14y 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.

1 more reply

ikhare14y 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.

bxr14y 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?

jamiequint14y 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.

bxr14y 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.

funkah14y 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.

samgro14y 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.

j / k navigate · click thread line to collapse

18 comments

johnrob14y 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.

kevingadd14y ago

azim14y ago

jwcacces14y ago

nddrylliog14y 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..

commanda14y ago

pkandathil14y ago

Pewpewarrows14y ago

pkandathil14y ago

1 more reply

ikhare14y 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.

bxr14y 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?

jamiequint14y ago

bxr14y 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.

funkah14y ago

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.

samgro14y 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.

j / k navigate · click thread line to collapse