[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.
John
More information about the SLDev
mailing list