Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to DDOS yourself

devblog.bu.mp

Post reply on HN
Print view View original

11–20 of 22 posts

Re: How to DDOS yourself

#11

Post by etherealG »

pkandathil wrote: post #8
Pewpewarrows wrote: post #5

Earlier quoted context omitted.

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

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.

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.

Re: How to DDOS yourself

#13

Post by 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.

Re: How to DDOS yourself

#14

Post by ikhare »

pkandathil wrote: post #2

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.

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.

Re: How to DDOS yourself

#15

Post by funkah »

bxr wrote: post #9

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?

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.

Re: How to DDOS yourself

#16

Post by kevingadd »

johnrob wrote: post #13

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.

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.

Re: How to DDOS yourself

#17

Post by 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.

Re: How to DDOS yourself

#20

Post by azim »

kevingadd wrote: post #16
johnrob wrote: post #13

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.

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.

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.
Post reply on HN