

How to DDOS yourself - jmintz
http://devblog.bu.mp/how-to-ddos-yourself

======
johnrob
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
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
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
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
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
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
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
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
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.

~~~
etherealG
application state storage is part of the package with android isn't it? that's
how apps always start up where you left off, even if the OS killed them to
free up memory.

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

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

