There still no way for robot owner to limit inbound traffic. There should be some mechanism similar to annotation filtering that happens onDocumentChangedEvent in Google Wave, so robot can be in control of amount traffic it experiences.
On Nov 3, 10:53 pm, Soren Lassen <[email protected]> wrote: > Sounds good. Please file this feature request in the issue tracker > with your suggestions. > > Is anyone game for implementing this? > > > > > > > > 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]. > > 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.
