Why isn't there something or someway to stop the grids from allowing self replicating

"We're having a problem with a slow down on the grid, which may be tied to a self-replicating object. We're going to shut the grid down and clean things up. It will be 1-2 hours before it reopens. Please watch here for an announcement regarding a re-opening."

~ R. Linden

-------------------------------------------------------------------------

This sucks. Period. I mean these 'self-replicating' objects need to be stopped and LL should put something in LSL of some sort to stop this, make a new freaking line of code for ppl to use so that land owners can stop this on the spot. This is not the first time and I don't usually complain, but this kind of repetitious behaviour is becoming the norm and not the exception to the rule. :/

-Wain

People suggest this and then other people point out their need for such objects in particular instances.

*shrugs*. Eventually I suspect eventually some solution will be settled on that makes the majority of users happy.

Self replicating is a combination of llRez and llListens! It's hard to stop. The only thing that 'could' stop it is 'rez only on your land' but that's just not something that LL should do.

could someone explain what these are? how do they occur? Is is a bug in the system, or just two things we need that join together badly?

I've come to grips with my inadequacies as a scripter (those inadequacies being: I have no idea what the hell I'm doing *grin*), so would someone be so kind as to 'splain how these are made and if there's a solution?

Im well aware of the coding involved...any basic lsl person could make this, and if this happened on my land I would eject it, what I am suggesting is that you can ban an avatar why can you not ban their items?

As you know return can be set to 1 minute minimum.

So...maybe therein lies the answer? Setting autoreturn to immediate.

It's simple to make. It's not a bug, it exactly the way everything is suppose to run. It's just 2 things that when put together in the right way, cause this. I'm not going to explain how to make it.

k.. thanks, nexus. I didn't think about that when I asked. *grin* trust me. I don't want to blow up SL.

Now, as the topic says, is there a solution? Is there a way to say to the language "These two things together=bad"?

to allow communication between two unlinked objects... so gating such an eventloop is hard to detect/filter.

data wants to be freeee....

Reaction time is too slow...if this string is identified it should or could be stopped, if LL chose, this wouldn't be the first time they hosed a series of scripts by changing the way lsl extracts and feeds data.

The functions used in self-replicating objects are very basic ones, and are not likely to go away. They are only malicious if combined with intent to cause problems, and there are plenty of other ways to grief sims without self-replication.

Now, I'm not too practiced yet with the Linden Language scripting. But I do have an idea regarding this problem.

Nature has a way to prevent runaway cell divison. It's a telomere at each end of each chromosone. With each cell division, the the telomeres shorten a bit. Eventually they run out.

LL should put into any routine that allows one object to spawn another, a counter that increases with each spawn. When a limit is reached, no more spawning allowed.

If this is too restrictive for some forms of creativity, the limit can be conditional on the overall system status. If the system is busy, the limit will take effect. If the system is running smooth, the limit need not be enforced.

This can be embellished further. It's the exponential spawns you most want to restrict. When an object spawns something else, something representing the root object remains somewhere on the system, even it has been deleted out of the active part of the world. It keeps a counter of all its children. As children spawn or are deleted, this counter is incremented or decremented. This root counter remains until all children have been cleaned up. If a child wants to spawn another, it check if the root counter is to exceed some limit. If so, no spawn allowed.

These counters and rules would be embedded in the LL functions. They would not be handled within the scripting language. Users would not be able code scripts to override.

If this idea has been thought of before, my apoligies. If not, then all of you bow low before me and ask "Please instruct us. How we may worship you?"

LOL!! hey, hold on; not quite yet

not dis-similar to past thoughts, but in computer-ese, there has to be some freedom to 'break the chain,' as it were. this is to allow the 'child' object some autonomy to take care of its own, without the 'parent' object being 'concerned' (which takes time... and if you consider the amount of programmatic 'parent/child' relationships in any given screenful, that can be the proverbial 'LOTS.'

and alllllllllll of it server-side concern too, which is a problem in this 'webish' setup that sl is - a lot of stuff has to 'check into' the main servers.

Those people need to do something to fix all the problems!

And why can't they they make all the cars run on salt water?

'cuz saltwater is not 'combustable' in a way that releases stored energy, short of a fission reaction.

even crazy environmentalists know this.

If I interpret correctly, you are be concerned there would be alot of overhead if each child points to its own parent and the management of it all would have to be up and down the chain.

I'm saying there would be only one root... and that root would just hold the counters. When an object spawns a child, the child inherits that objects pointer to its own root. The entire tree points back to that one root. Also, that root doesn't have to do any processing for each of its children. The children do their own processing to validate whether they can spawn. They look back at thr root just to look at and update counts.

Pointers up and down the chain would only be used in special cases to take care of garbage collection if some things don't take care of themselves naturally.

Instead of storing a child counter in a root object, why not have a local variable in each object that indicates its generation? This variable could be completely inaccessible to the scripting language, and the child object would be prohibited from replicating itself if its generation is higher than a certain threshold. That threshold could be dynamically set, as Marsluna suggested, or be permanently fixed at say 3 or 4 generations.

Would that work better? Would it be a tenable solution at all? Thoughts?

It's Big Oil's fault! And the Freemasons'.

There are academic papers on automatic resource allocation that have the potential to stop this sort of thing. But the telomeres concept sounds good too.

That would break a number of legitimate objects. For example, James Miller's lottery machines depend on rezzing tickets for sale. In your model, every ticket rezzed would count against the machine's rez limit and eventually it would run out.

You need to be very careful when devising limitations on the functions that are used for replication attacks. Most of the methods described here will break something like my PipeMaker tool. The only way the PipeMaker could possibly work is almost identical in behavior to the way a grid attack works. Breaking existing, useful content isn't acceptable when you're talking about ways to limit grid attacks.

Tickets don't rezz other tickets so there wouldn't be exponential growth. I don't know how many tickets a single machine would normally create on its own, but I guess its not that many. I haven't participated in the lottery know its details but I assume each ticket has a limitted life. No more than the time to the next lottery or until ticket is moved to a user's inventory. Because I'm new to this, I can't say whether having objects, such as tickets, in a user's inventory adds lag to the system.

Remember too, the limits wouldn't need to be enforced if the overall system is running smooth. Only when something starts to run away and begins to create unacceptable lag would the limits kick in.

Well your pipemaker tool is reason to impose limits on exponential growth rather than linear growth. This would be total number existing decendants maintained for a root. Since this limit would be to cover exponential growth, it would be a much higher number.

Another thing that could be done would be to track a growth/time factor. There would be a current total of existing decendants owned by a root and another number representing what the total was some number of seconds or minutes ago. If the difference between those two numbers exceeds a limit (growth rate limit) then spawning would be shut down.

Artificial Life requires the ability to self-replicate indefinitely. Preventing self-replication after the attack has already begun won't keep the set-up for the attack from happening. Preventing self-replication won't even prevent an attack from being set up using a "hive" scheme... and the one time LL nerfed self-replication after one of these attacks I came up with a script to support "hive" self-rep for Artificial Life without a great deal of trouble.

My car runs on recycled particles, and there's no Salt Water in SL anyway... all the water's made of prims or fog!

True, the pipemaker is only linear growth... but I can see some problems with trying to only limit exponential growth. First of all, I think it'd be nontrivial to keep track of all of those ancestors so that you can update every single ancester when a new object is rezzed. Also, what if an object has 10 children, and then dies immediately thereafter, before any of those have children? Then it's not there to keep number-of-descendants data on... so the attack can still go out of control so long as it's done carefully.

To counter that, you'd have to keep number-of-descendants data on objects that are dead... ho long do you store this data? This sounds like it suddenly takes up a non-trivial amount of memory space and computation time.

There's also the fact that it's probably not possible to keep track of this kind of data on a grid-wide basis. It'd take too much inter-sim communication. If it's only on a sim-by-sim basis, it probably won't be that effective.