On Wed, Oct 28, 2009 at 11:39 AM, Tim Steele <t...@chromium.org> wrote:
> The update{foo} update{blech} case is most likely a different kind of
> failure, though, and I was thinking we could limit that with a generic cap
> on just the "number of updates in a period of time". From the data we have
> seen so far, most common is 'update{foo}' in a loop type behavior. But if
> the generic cap gets us far enough along, then I agree simpler is better.
Cool. I hope and suspect we can get far enough with the simple approach.
> We have this. The problem is that the user doesn't even realize the
> extension is spamming the server. Our server knows the client is producing a
> lot of traffic, that's all. So what happens is we limit the client and the
> user is left bewildered and helpless because a rogue extension is eating
> away his quota. What I just landed was a way to correlate how many of our
> sync commits originate from extensions, but we need to find a way to solve
> the problem once we learn from the data. The reason I suggested this, is
> because it dawned on me that this problem affects any extension author
> trying to send updates from Chrome to their servers. If extension Bob and
> Eve are installed, Eve can bring down Bob's service because of a silly bug.
> I was proposing we just add some layer of protection in here, because we
> can, to help our extensions developers out (and Chrome Sync in the process).
Thanks for explaining. Makes sense to me.
- a
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
