Realistically, there are ton of things that can go wrong with scripted systems in Second Life. Most of them can be worked around comparatively easily, if you're willing to pay a little attention to the details.
Skimping on those details can lead to runaway objects, or even executing a distributed denial-of-service attack against your own systems. A lot of people do skimp, however. Sometimes it's sloppiness, but more often it's just a matter of inexperience. Sometimes you need to be bitten before you think of these things. Some of us have been bitten more than once.
It's an unfortunate fact of life that scripts that were never intended to get loose in the wild often do, and scripts that are supposed to be cautious about resource-usage often aren't. Use as many kill-switches as you can reasonably get into the code.
Seriously. This doesn't apply to every kind of code, but if you've ever had a script go rogue on you, you'll realize just how important that is. A simple script that queries your HTTP server a few times per hour is fine. Having umpty-thousand copies of that script loose on the grid, and nothing you can do to stop them? That's thousands of HTTP requests to your server per-minute, and probably you getting kicked off by your hosting service. (Thanks a lot for distributing that script so widely, Linden Lab!)
One famous Second Life user, Lordfly Digeridoo, once set up a Halloween event on the Second Life grid, often called the "Zombie Cubes of Death". A simple little gimmick that was intended to bring a bit of fun and spooky excitement, the simplistic cubes backfired. Everything about them went horribly wrong, and Digeridoo spent ages hunting down and destroying them.
The zombie cubes were supposed to roam around, replicate a little and die when virtually anything hostile happened. Pretty much everything went wrong with that, with gigantic swarms of zombie cubes swarming on players, pushing them all over, and being stubbornly resistant to weapons, and... well, everything.
(These days, Linden Lab has a special tool that can do this, but heaven help you if you force them into a position where they actually have to use it)
Therefore, kill-switches:
- Have your server give out a custom HTTP response in the 460-490 range to signify that it is unwilling to communicate any more. If your script ever gets that response, have it switch to a state where it takes no action (or deletes itself, if you prefer). I prefer the no-action state for many things since the script can be reset and set running again, should you need to.
- Set the script to listen on a custom channel for a killphrase of your choosing. Out of control scripts can be quelled by teleporting into their sim with a scripted object that will blurt out the killphrase using llRegionSay().
- Use the changed() event and watch for CHANGED_REGION. If your scripted object moves but you don't want it to get away from you, have it disable itself if it actually does cross a sim-border.
- Check the owner. If a script shouldn't ever be running as someone other than you, make sure it doesn't.
- Check the time and date. If an object should not persist past a certain time and date, have it check periodically and clean itself up if it is overdue. Maybe it should have already stopped long before, but that part failed. This is often done with betas and preliminary release-candidates in major software.
- If a script communicates with in-world server objects, make sure they can send a kill-phrase to their clients, if the situation should warrant it.
- Have your scripts keep a track of failed communications, and have them back off. There's no sense in hammering away at a service or object that just isn't answering.
Scripts do get out of control from time to time, and when they do it can cause you severe problems, waste your time, and even cause damages and financial loss.
 |
Are you a part of the most widely-known collaborative virtual environment or keeping a close eye on it? Massively's Second Life coverage keeps you in the loop. |
