Hacker News Reader

Comment by jlgaddis | Hacker News Reader

It's irrelevant, I suppose, but I'm sorta curious how big this database was (or, more specifically, how much traffic he was generating to Dropbox).

There was also no mention in this article (except in one of the screenshots) about whatever -- "[a] UDP flood or so" "at the beginning of this month".

It would certainly suck to have your account locked out when you're serving production sites but it sounds like we haven't heard all of the story (we obviously haven't heard DO's, of course).

View on HN

The DB is pretty small actually just 10 MBish. Is this really a traffic flood for DO ?

What about the crawling? How much traffic does that generate? I'm just wondering if you are hitting one or more of the sites very hard and they complained to DO about it.

10MB once no, but lets say hypothetically, if the dropbox api returned an error or wasn't available which denied your request but your script didn't account for it and it constantly kept making the request over and over and over. The 10mb would soon add up.

Also, are you sure it wasn't something else, not the dropbox db script which could have caused problems?

I'm pretty sure that it's nothing else and i've never used the Dropbox script after i got the first ticket.

I seriously doubt it, there is almost certainly something else going on. Does the dropbox api even use udp at all? A udp flood has little to do with the size of a file transfer, and everything to do with the rate of udp packets per second. Generally to be identified as a "flood" your server would have to be doing something very poorly coded (best case) or downright malicious. Did you check where this udp traffic was being sent to (destination ip addresses/ports)? Did you compare the dates/times of the "flood" to when your scripts/jobs were running? Did you check your server for any suspicious activity or indications of compromise? A little bit of critical thinking can go a long way here.

Reply on news.ycombinator.com