Self Replication & "The Grid"

Others have suggested a limit to the number of generations an object can self-replicate. What types of things are builders doing that require an indeterminate number of generations? What would limiting the number of generations hurt that presently exists in SL? What would be a reasonable limit in such a scenario?

Might it be possible to add some high velocity leaping and flying about to the self replicators to get across the nobuild areas well enough to render them not too effective?

Yes, I would think so. All you'd have to do would be to use llScriptDanger to check whether where you were travelling to was "dangerous" or not, and if so apply a big impulse to get you through it. Nobuild counts as "dangerous".

Might it be possible to add some high velocity leaping and flying about to the self replicators to get across the nobuild areas well enough to render them not too effective?

Well, option a) isnt really doable since it means a lookup to the DB server on every rezobject() call. Option B is closer to what I'm suggesting, but isnt something that can be phased into the existing grid area.

Well.. how do you calculate ho many generation old an item is? There's currently no way to figre that out.

Of course, if there was a limit on the number of times a prim could be copied it would add a whole new aspect to making items for sale... just not a very good one.

The ideas presented may be totally naive. If this is the case, please enlighten me!

1. Throttling object creation. Many functions of LSL that could be abused or are resource intensive, are "throttled". Why not throttle the scripted creation of objects (which seems to be the core of all of the last gridwide attacks)? If this would be done on a per user base it should not affect legitimate usage much. If the scripts of one resident could create only X identical new objects per hour, and X would be a reasonable large number (500 or 1,000 or more) a griefer still could attack one sim but rarely the whole grid.
   
2. Disabling all scripts owned by a resident. If LL admins could do that, a grid attack might still be possible but would be easily stopped once the resident(s) responsible for it is/are identified. Self replicating would stop.
   
3. Deleting all objects owned by a resident. If LL admins could do that, cleanup after a grid attack would be fast and easy.

Seems like better tools would stop a lot of the damage.

I still believe that throttling the object creation process (on a per user basis) would be much more effective.

Problem is -- you cant do that on a grid-wide scale, it means centralised requests for RezObject. The server incharge of recieving those requests would be crushed under normal load, let alone the load in 6 months time.

I am no expert for the current systems architecture of SL, but doesn't the asset server already experience a much higher load?

And the asset server has to actually "deliver objects" to another server. The throttling would only need a kind of ping towards a central authority waiting for an ACK or NACK. In my endless naivity I would assume that it should be possible to build a service like this which can handle a few thousand pings per second (in a local network setting). Last time I checked, there were many DB servers on the market with performance well above that threshold.

But, as I said before, I am certainly no expert for SL systems architecture.

The asset server is a filesystem - it doesnt have any details about the files it's storing, just their names (in this case, UUIDs). Information about the objects are stored on the DB server, and the two are not nessecarily congruent (for scalability reasons).

Basically, when your doing that kind of lookup, you end up with table scanning huge log tables. Plus, if that server dies, nothing will rez.

Basically, if there is a good solution for this, it's going to be distrobuted or heavily scalable, so that when SL has 10,000 sims - nothing will choke.

Oh, and what ever happened to the FBI reporting?

One of the problems with self replicating objects is - occasionally they are required for some tasks, removing the functionality removes a tool from the SL content creator's toolbox.

The problem comes, when someone creates (deliberately or not) a self replicator that then consumes the whole grid. There are a multitude of solutions to this problem - but most of them require features to be disabled and removed from SL.

There is however, a simpler option - default permissions. One of the reasons these grid attacks are so successfully is twofold.

1) Autoreturn is usually set high enough that the objects can replicate a few generations before the parents being returned.
2) Most land in SL is set 'others can build here'.

When both of those things are combined - it creates a form of Agar Jelly, perfect nutrients for the spread of replicating prims.

If LL were to consider changing the default land parcel permissions from 'other can build', to 'others cant build' - and then allowed users to toggle it (as it can be done now), then vaste swathes of the mainland would be unbuildable - this would significantly impede the progress of any out of control replicator, since each unbuildable parcel acts like a barrier wall against the oncoming flood.

If enough parcels were unbuildable, then most outbreaks would be contained to just a localised area. The problems with this are also self evident - if you want to build on someone elses plot, they need to either have on in a group the land is set to, or alternatively, enable the 'anyone can build' option on the land menu.

The biggest downside to this is, anyone who's using anothers parcel as a free sandbox wont be able to anymore - but the advantage is that it's a scalable solution to a common form of attack; that wont cripple functionality.

I am no expert for the current systems architecture of SL, but doesn't the asset server already experience a much higher load?