I'm all for rate limits. I have no quibbles with this plan. -- Nathanael Abbotts
Email: [email protected] Wave: [email protected] Twitter: @natabbotts (http://twitter.com/natabbotts) On Wed, Nov 3, 2010 at 13:59, Joseph Gentle <[email protected]> wrote: > Yep; that sounds good to me. > > Even leaving aside the robot case, it makes sense to implement that > for spammy humans. > > I'd like this to be the default WIAB behaviour, but not required by > the protocol. > > -J > > > On Thu, Nov 4, 2010 at 12:45 AM, Tad Glines <[email protected]> wrote: > > This conversation seems to have wandered a bit from the original topic. > The > > core problem raised is what to do about the possibility of two robots > stuck > > in a endless loop of programed replies (e.g. two echoy's). The simplest > > solution is to rate limit deltas generated by robots and to automatically > > drop them as a participant if they generate too many deltas in a fixed > time > > window. So for example, limit the burst rate to 2 deltas per second, if > the > > robot generates more than 110 deltas in 50 seconds, remove it as a > > participant, and include a message to the wavelet author that the robot > was > > removed. > > > > As the creator/owner of a wave, I and no one else, should have control of > > what happens in my wave. If someone doesn't like what they see, or isn't > > interested in a particular category of changes, then can remove > themselves > > as a participant. I as a wave provider need to prevent a DOS attack on my > > server, without being overly restrictive of what people can do with their > > waves. If someone wants to see what happens when they put two separate > chat > > bots in a wave, that's their business. Providing a way for the robots to > > know the server's rate limits allows the robots to self limit/self sensor > > when needed. And the server can drop poorly behaving robots. > > > > The same rate limiting can also be applied to deltas generated by remote > > wave servers. A sane limit might be 200 deltas per second (20 chars per > > second * 10 participants). The federation protocol already has an error > code > > (RESOURCE_CONSTRAINT(5)) indicating that the sender needs to back-off. A > > server can simply drop deltas on the floor and send a RESOURCE_CONSTRAINT > > error to the sender if they arrive too fast. > > > > -Tad > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Wave Protocol" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<wave-protocol%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/wave-protocol?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
