Live data from Hacker News

Google Doorman: Global Distributed Client Side Rate Limiting

github.com

11–20 of 27 posts

Re: Google Doorman: Global Distributed Client Side Rate Limiting

#11
post #9

Earlier quoted context omitted.

That is because Google claims copyright on everything you create while you work there, even if you create it in your garage in your free time. You baked some cookies for your daughters birthday party? Sorry, can't distribute them for free, consumers of those must sign a CLA (Consumer License Agreement) and Google retains copyright on your recipe.

Question: Does this also apply to Google employees at Google Hamburg, and, if yes, how far? Because, as far as I know, German law directly prohibits such contracts.

I can't answer your question, because I don't know the answer.

However, I would recommend against relying on wereHamster's apparent mis-information... unless Google's policies are different in the jurisdiction that wereHamster is familiar with, in which case I apologize.

Re: Google Doorman: Global Distributed Client Side Rate Limiting

#12
post #9

Earlier quoted context omitted.

Question: Does this also apply to Google employees at Google Hamburg, and, if yes, how far? Because, as far as I know, German law directly prohibits such contracts.

I can't answer your question, because I don't know the answer. However, I would recommend against relying on wereHamster's apparent mis-information... unless Google's policies are different in the jurisdiction that wereHamster is familiar with, in which case I apologize.

I think wereHamster’s text was satire, but the idea was repeated by many others: Anything related to your job you do is owned by Google.

You can’t contribute to ejabberd when you work on Hangouts.

Re: Google Doorman: Global Distributed Client Side Rate Limiting

#13
So do I understand this right: Doorman could be used to rate-limit access to a website by integrating it with the sites proxy server, the result being individual clients would only get a certain number of requests per minute based on available server side resources?

Re: Google Doorman: Global Distributed Client Side Rate Limiting

#14
post #13

So do I understand this right: Doorman could be used to rate-limit access to a website by integrating it with the sites proxy server, the result being individual clients would only get a certain number of requests per minute based on available server side resources?

I think it's more meant for internal RPC within a cluster, to e.g. avoid overloading a service.

Re: Google Doorman: Global Distributed Client Side Rate Limiting

#15
post #14
post #13

So do I understand this right: Doorman could be used to rate-limit access to a website by integrating it with the sites proxy server, the result being individual clients would only get a certain number of requests per minute based on available server side resources?

I think it's more meant for internal RPC within a cluster, to e.g. avoid overloading a service.

This is the correct answer, since this exact problem is a major issue when dealing with distributed system failovers. Here are a few examples of AWS service disruptions due to exactly this problem, where they were unable to recover the system because nodes kept failing over under load:

https://aws.amazon.com/message/5467D2/ https://aws.amazon.com/message/2329B7/ http://aws.amazon.com/message/65648/

An example quote:

"When this network connectivity issue occurred, a large number of EBS nodes in a single EBS cluster lost connection to their replicas. When the incorrect traffic shift was rolled back and network connectivity was restored, these nodes rapidly began searching the EBS cluster for available server space where they could re-mirror data. Once again, in a normally functioning cluster, this occurs in milliseconds. In this case, because the issue affected such a large number of volumes concurrently, the free capacity of the EBS cluster was quickly exhausted, leaving many of the nodes “stuck” in a loop, continuously searching the cluster for free space. This quickly led to a “re-mirroring storm,” where a large number of volumes were effectively “stuck” while the nodes searched the cluster for the storage space it needed for its new replica. At this point, about 13% of the volumes in the affected Availability Zone were in this “stuck” state."

So these things are very hard, can occur in totally unexpected situations, and I'm not at all surprised that a company like Google comes out with something like this.

Re: Google Doorman: Global Distributed Client Side Rate Limiting

#17
post #16
post #2

It should have been called "Velvet Rope" :-)

Care to you explain the joke for the culturally unaware?

When waiting to get into a club or party, you wait behind such a rope until the bouncer allows you to enter (or doesn't).

Re: Google Doorman: Global Distributed Client Side Rate Limiting

#18
post #5
post #3

Hopefully there is a Googler reading who can answer this: I'm curious why the README.md says > Note: This is not an official Google product. However the copyright is Google, and you must sign their CLA. That seems pretty official to me? Or is there some other implication to "official" beyond ownership?

This is a project whose author is a Googler thus Google has the copyright and all the CLA stuff. However Google is not directly involved in the project, in the sense of having employees solely work on the project and have an OKR on this project, or roadmap whatsoever. Think about this: someone work for Google wrote a software and Google is kind enough to open source it. Disclaimer: I work for Google but my interpreta…

Does Google also own code that you write in your spare time at home?

Re: Google Doorman: Global Distributed Client Side Rate Limiting

#19
I know it expects cooperative behavior. However, I wonder if the protocol design could be used in a setup where an embedded firewall did the rate limiting and mediated traffic from the possibly-malicious host. Boeing already has rate-limiting in their embedded firewall but cheap or OSS project could use a OSS rate limiter prebuilt to save time.

As in, is this protocol inherently cooperative or could an implementation have checks/controls added?

Post reply on HN