[sldev] Re: Plugin architecture

John Hurliman jhurliman at wsu.edu
Thu Feb 22 08:12:59 PST 2007

dirk husemann wrote:
> John Hurliman wrote:
>> The original post on plugin invalidation was talking about runtime
>> loading/unloading of plugins and had nothing to do with throttling or
>> server-side code, I think you might have got sub-threads crossed. The
>> mention of a server-side throttle was made by the same person you are
>> responding to.
> yes and no. as far as i understood the "plugin invalidation" idea, it's
> purpose was to protect against broken plugin/rogue plugins that would
> cause pain on the grid --- for that it's better not to rely on properly
> functioning clients but instead have proper protections on the servers
> (i.e., protect by throttling the client link and signalling that to the
> user).

I agree, but I'm not sure what server throttling has to do with plugin 
invalidation. If a client is flooding data it doesn't matter if it's 
coming from a plugin, a modified opensl, a libsecondlife client, etc, 
the idea is to throttle against the flood. The example that was given 
earlier was an IM flood which is fitting because two weeks ago or so I 
was working on a libsecondlife bot that would auto-respond to IMs. There 
was a race condition with people logging off before the reply IM got to 
them, and the grid would reply back with an IM that says that person is 
offline (shows up as a normal IM but from UUID NULL_KEY if I recall). 
The bot would blindly auto-respond to NULL_KEY which triggered another 
message from NULL_KEY, and things got caught in an infinite loop which 
managed to send tens, maybe hundreds of thousands of IMs to no one in a 
very short amount of time. This brought the sim dilation down to 0.05 
and would eventually crash the sim. Even after bringing a Linden in no 
one could figure out what was going on other than a lot of traffic was 
coming from the client. Randomly one day we decided to turn IM 
forwarding to e-mail on for the bot and as soon as e-mail flood started 
coming in it was easy to figure out what was happening and fix it.

I guess the moral of the story is that intelligent server throttling is 
good, proper logging mechanisms are better, and writing code that 
doesn't crash simulators is a good idea too.


More information about the SLDev mailing list