Hacker Newsnew | comments | show | ask | jobs | submit login

For starters, average podcast download is 40Mb or so. More than 50Kb in any case. Next maintaining state per client isn't anything new - it might not be ideal for CDNs but many LBs keep state for things such as maintaining session persistence etc.

If there is a potential for clients intentionally or unintentionally jacking up your CDN bill - I am sure somebody has a solution to prevent it - especially since money is at stake.

You laughed at iRules - I got that part, but what about iRules doing HTTP Request throttling? Far as I know it can do that based on source ip and port, uri etc. which should work for this kind of scenario with some modifications.

Your average podcast source material may be 40mb. Clients will most assuredly not be fetching that all in single request. Your state transfer overhead is per request. The 50kb estimate is an educated guess at the average size of an http response from a CDN. You have to keep state on every request, otherwise how can you detect your "bad request" patterns. Now, you could only stick your state on to Range'd requests. But a lot (most?) of the customers affected by this are doing a significant portion of requests as ranges already.

IRules, specifically, don't work for any reasonable packet rate. Every request must now come off the nic, across the bus, hit CPU, hit a few times memory, and back. Tracking state, in general, kills packet rates. There's no guarantee that your flow is going to be hitting the same interface, interrupt, processor, or even host. At every one of those levels shared state dramatically increases complexity and reduces your max possible packet rate. Silicon really can't flip bits that quickly.

Which gets us back to the business question. So you've found a "bad" client. What aceptable action can you take? Throttle all iOS 6 users? Throw 400s?

To be honest here this excess cost is going to be absorbed in three places. 1) end users will suck it up in data charges because they have no alternative 2) sites will eat the bandwidth charges. They can't passit on if they have no directly associated revenue. Or they don't want to lose customers. 3) CDN/providers will take a relatively small hit issuing credits to keep their customers happy.

Notice who won't lose a cent here? Apple and other broken client providers.


Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact