I think I figured out the issue. For every person, the blip submitted event is happening, and the Robot is receiving many more than 1 request per second. It's receiving however many people there are watching the wave requests. The problem is that there is no way for the gadget itself to update independently of the users, and thus, each user must submit an update request for themselves, rather than the gadget updating every second with a list of users who have the gadget running.
There is also no ability for the gadget to tell if a user stops looking at them, compounding the issues stated above. The only way for a gadget such as this to operate is to inundate the users (and Robots) with requests (2.6k requests with 2 people over the course of a few minutes). This is just unacceptable with the quotas for Robots set as they are. The massive amount of data being passed around used 2% of my "quota" in just 20 minutes. Assuming much larger scales, this sort of architecture would never hold up. Gadgets cannot be mini-applications unless they have the ability to reduce the load to something more in the order of 1 request per second maximum. This reduces the bot's load, but only by half, and it needs to be mitigated more. This can be done via creating a new event for gadgets, so that Robots can ignore them if there's serious issues with bandwidth usage. Oftentimes Robots will not care about gadgets anyways, so having an opt-in solution would be quite manageable. This is especially useful for Robots that are solely gadget-extenders, meant to increase the productivity and awesomeness of a gadget, in that they can ignore all users blip-submitting and just care about when the gadget updates the wave's state. There are probably better solutions too, but there is a preliminary one for consideration that hopefully gets the idea across. On Dec 1, 11:21 pm, Olreich <[email protected]> wrote: > It doesn't seem like that gadget should be causing an onblipsubmitted > every second... > > On Dec 1, 9:41 pm, Stephen George <[email protected]> wrote: > > > > > Daniel, I agree that it's difficult to remove a robot from a wave of > > over 200 participants. > > > I like to use [email protected] in that situation to avoid > > having to sift through the list. Glad that you were able to resolve > > it and save your exhausted bot. > > > On Dec 1, 5:44 am, Daniel Faust <[email protected]> wrote: > > > > I'm in a ugly situation. > > > > Due to a 3rd party gadget in a wave which has my robot as a > > > participant, the bot is depleting it's Incoming Bandwidth quota after > > > only 4 hours. > > > > That gadget -- judging from the bot's logs > > > it'shttp://www.razorcam.com/seconds_spent_by_everyone_reading.xml-- > > > causes an OnBlipSubmitted every second. > > > > This means that every second the entire context is being pushed into > > > the robot. > > > > I tried looking at the participant list in the wave through the normal > > > wave client, but the list is huge (1000+), and there is no way to > > > scroll through it, so that I can't find my bot to remove it from > > > there. (Ok, fixed that, got a computer with a bigger screen and used > > > the ctrl- to make the page smaller) > > > > I've seen a removeSelf or something similar in the API which allows a > > > bot to remove itself from a wave, but at that time, about a month ago, > > > it was not implemented. > > > > Maybe there should be a place where we can submit robots/gadgets that > > > should be blacklisted due to unfair behaviour, and maybe the docs > > > should mention the side effects of implementing a highly active > > > extension. > > > > Or maybe an extra element in the capabilities.xml file which defines > > > which waves, or submissions from certain robots or gadgets should be > > > excluded from being processed. > > > > I truely doubt that razorcam.com had bad intentions, so I'm not angry > > > at all. -- You received this message because you are subscribed to the Google Groups "Google Wave API" 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/google-wave-api?hl=en.
