Second Life Forums Archive - O2O Nerfed Horribly *Groan*

Tateru Nino

Girl Genius

Join date: 13 Sep 2005

Posts: 312

10-25-2005 21:17

Makes perfect sense. I can even see a way to cheat limited persistent variable storage out of it with the cooperation of another object.

_____________________

Hiro Pendragon

bye bye f0rums!

Join date: 22 Jan 2004

Posts: 5,905

10-25-2005 21:34

From: Kelly Linden

Hiro, actually reading through the thread again I'm not sure which of the ideas you are trying to promote? The energy one from eggy or your tax?

Kelly, just dropped you an email.

I think ultimately the ideas in my thread would take a while to flush out details and borderline cases - like how to compensate for someone playing a FPS and rezzing thousands of bullets.

Anyway - I'll repost the other suggestions I emailed you, for the benefit of the forum readers:

Why not just cap # of rezzes per sim per second? How about allowing
temp on rez to be banned / autoreturned? (I know Cory spoke about
being able to ban a person's objects being in the works.) Why not add
more land options so that a person has more than simply an on/off
toggle checkbox for "rez objects"? Why not let land owners set a price
per rez for their land?

Ultimately - and I assume this would be the most difficult - why not
have objects ask permission before travelling over someone's land? Why
not check land create object permissions at the instance an object
crosses a parcel border / is rezzed, rather than at timed increments?

_____________________

Hiro Pendragon
------------------
http://www.involve3d.com - Involve - Metaverse / Emerging Media Studio

Visit my SL blog: http://secondtense.blogspot.com

Kelly Linden

Linden Developer

Join date: 29 Mar 2004

Posts: 896

10-25-2005 21:54

From: Tony Tigereye

Scripts within objects can modify the name and description of the object they are in by using llSetObjectName() and llSetObjectDesc() respectively. After they have put whatever data they want into these data storage areas, they can then call llGiveInventory() to send the object over to another object where a script in the receiving object can read the data stored in the object name by calling llGetInventoryName(), and/or it can rez the object it just received and use some kind of local communication method (llSay(), llWhisper()) to talk to the script inside the received object to get the description data.

Wow that's hard to read. Does it make sense?

I'm missing a step in this process.

Script1 in ObjectA can only change the name and desc of ObjectA if ObjectA is rezed in world.

Script2 in ObjectB can only transfer ObjectA to ObjectC via llGiveInventory if ObjectA is in the inventory of ObjectB.

How is this accomplished?

Unless you are saying Script2 can modify ObjectA?

_____________________

- Kelly Linden

Kelly Linden

Linden Developer

Join date: 29 Mar 2004

Posts: 896

10-25-2005 22:04

Thanks for the email Hiro. It is rather long, so I will reply tomorrow when I can do it justice.

_____________________

- Kelly Linden

Hiro Pendragon

bye bye f0rums!

Join date: 22 Jan 2004

Posts: 5,905

10-25-2005 22:11

From: Kelly Linden

Thanks for the email Hiro. It is rather long, so I will reply tomorrow when I can do it justice.

LOL no worries.

Can I get a straight answer on one thing, though - did LL today or yesterday feel it was in immediate threat of another DOS attack like the one we experienced?

_____________________

Hiro Pendragon
------------------
http://www.involve3d.com - Involve - Metaverse / Emerging Media Studio

Visit my SL blog: http://secondtense.blogspot.com

Jesrad Seraph

Nonsense

Join date: 11 Dec 2004

Posts: 1,463

10-25-2005 23:01

(I'm starting to feel like a parrot)

Why can't the number of physical objects be capped per sim in a similar way as the number of agents is (with an additional check on object rezzing) ? After all there already is a specific cap on the number of prims in a physical object enforced. It's not like it wouldn't make sense, and I think it would actually fix the problem at hand instead of making it just a bit more difficult to cause sim crashes.

_____________________

Either Man can enjoy universal freedom, or Man cannot. If it is possible then everyone can act freely if they don't stop anyone else from doing same. If it is not possible, then conflict will arise anyway so punch those that try to stop you. In conclusion the only strategy that wins in all cases is that of doing what you want against all adversity, as long as you respect that right in others.

Tateru Nino

Girl Genius

Join date: 13 Sep 2005

Posts: 312

10-25-2005 23:13

I'm not sure what the number for the cap should be. Maybe if it was based off the ips rate of the physics system? When the physics load gets too heavy don't allow an object to be set physical or rez as -- No, wait. I can figure a way to game that, too.

Hmm. No, capping the number of physical objects wouldn't work, unless the number was very very small indeed. Otherwise I can still think of ways to do to a sim what the griefsphere did. In fact the more I think about it, the more ways I can think of. I can certainly think of a way to totally mire a sim in a very hard to detect way (oh, it'd be insanely obvious to a Linden gridmonkey). Problem is, I can't think of a good way to prevent any of the things I can think of.

_____________________

Hiro Pendragon

bye bye f0rums!

Join date: 22 Jan 2004

Posts: 5,905

10-25-2005 23:20

From: Tateru Nino

Problem is, I can't think of a good way to prevent any of the things I can think of.

Yes ... ah .... please look into the light.

_____________________

Hiro Pendragon
------------------
http://www.involve3d.com - Involve - Metaverse / Emerging Media Studio

Visit my SL blog: http://secondtense.blogspot.com

Tateru Nino

Girl Genius

Join date: 13 Sep 2005

Posts: 312

10-25-2005 23:24

*giggle* I'm sorry. What was I saying again?

_____________________

Hiro Pendragon

bye bye f0rums!

Join date: 22 Jan 2004

Posts: 5,905

10-26-2005 00:03

From: Tateru Nino

*giggle* I'm sorry. What was I saying again?

I think you were just commenting how cool the new map is, how the capacity of each sim up to 100 people is a real great upgrade, and how you're anxious to see attachments utilizing the new movable attachment features.

_____________________

Hiro Pendragon
------------------
http://www.involve3d.com - Involve - Metaverse / Emerging Media Studio

Visit my SL blog: http://secondtense.blogspot.com

Jesrad Seraph

Nonsense

Join date: 11 Dec 2004

Posts: 1,463

10-26-2005 01:29

What about disabling physics if a sim is too laggy ? And/or throttling llRezObject performance with time dilation ? Then prim allotments / temponrez deletion could take care of it. It's all a matter of priorities, ensure the sim keeps running, then ensure it can handle that many people on it, then ensure it can serve all the network updates, then the physical simulation, then script execution, etc...

More cool stuff that was broken by this move here.

_____________________

Either Man can enjoy universal freedom, or Man cannot. If it is possible then everyone can act freely if they don't stop anyone else from doing same. If it is not possible, then conflict will arise anyway so punch those that try to stop you. In conclusion the only strategy that wins in all cases is that of doing what you want against all adversity, as long as you respect that right in others.

Kelly Linden

Linden Developer

Join date: 29 Mar 2004

Posts: 896

10-26-2005 08:35

Grey Goo attacks are different from other forms of attack:

* Other attacks have sources which makes them much, much easier to contain and stop. Long before they reach the sim wide scale.

* Grey Goo attacks turn every infected sim, even if only 1 stray object bounces there, into a source of attack.

* Other attacks can only grow exponentially for a limited number of generations.

* Grey Goo attacks grow exponentially for infinite generations, which means they can start smaller and simpler and grow bigger faster.

The ability to crash a sim is known, but crashing a sim is a far different situation than an attack that brings down the entire service and can be dealt with differently.

Thanks again for all the feedback.

_____________________

- Kelly Linden

blaze Spinnaker

1/2 Serious

Join date: 12 Aug 2004

Posts: 5,898

10-26-2005 08:42

From: Kelly Linden

That is an interesting idea blaze. What manner is this done in? I think only inventory names, type and notecard contents are accessible to scripts. Perhaps permissions, but using that for data storage would be ... interesting. None of the methods I can think of actually allow a script to modify this data, or require that objects be used in particular (as opposed to notecards for example).

Well, think of a card game.

If you had an object that sent a HUD an object called "QH", then your hud could detect the inventory change and then show it.

Kludgy, yeah, but that's what happens when you don't have secure communication available

blaze Spinnaker

1/2 Serious

Join date: 12 Aug 2004

Posts: 5,898

10-26-2005 08:45

From: Kelly Linden

Grey Goo attacks are different from other forms of attack:

* Other attacks have sources which makes them much, much easier to contain and stop. Long before they reach the sim wide scale.

* Grey Goo attacks turn every infected sim, even if only 1 stray object bounces there, into a source of attack.

* Other attacks can only grow exponentially for a limited number of generations.

* Grey Goo attacks grow exponentially for infinite generations, which means they can start smaller and simpler and grow bigger faster.

The ability to crash a sim is known, but crashing a sim is a far different situation than an attack that brings down the entire service and can be dealt with differently.

Thanks again for all the feedback.

I don't get it. Doesn't llGiveInventory not work after a number of generations? I thought it didn't

Eg: if object a gives inventory to object b which which gives inventory to object c, then object c can't give inventory to anyone.

Kelly Linden

Linden Developer

Join date: 29 Mar 2004

Posts: 896

10-26-2005 08:55

Nope blaze, that has never been the case.

_____________________

- Kelly Linden

Kelly Linden

Linden Developer

Join date: 29 Mar 2004

Posts: 896

10-26-2005 08:56

From: blaze Spinnaker

Well, think of a card game.

If you had an object that sent a HUD an object called "QH", then your hud could detect the inventory change and then show it.

Kludgy, yeah, but that's what happens when you don't have secure communication available

Very cool. I suppose with a suitably limited vocabulary (a deck of cards like your example) that would work. I believe this can be made to work with the ideas I have.

_____________________

- Kelly Linden

Surina Skallagrimson

Queen of Amazon Nations

Join date: 19 Jun 2003

Posts: 941

10-26-2005 09:11

From: Kelly Linden

Very cool. I suppose with a suitably limited vocabulary (a deck of cards like your example) that would work. I believe this can be made to work with the ideas I have.

Are you going to let us in on your ideas or will they just be sprung on us in a future "bug fix" update?

The only way my fish (and other similar ALife projects) will work as intended is by fully reinstating the orriginal functionality of llGiveInventry(). Limiting it to owners land, or group land, or limiting generations is just not good enough.

For example, my fish are designed to freely roam the SL waterways. They already have checks built into them to stay away from "protected" land where they may be auto-returned or fail to reproduce due to no-build. However, even this ability is limited due to none of the LSL functions working across a sim boundry, so boundry crossing is very much a leap of faith that they won't meet instant death on the other side.
All my fish have a built in limited lifespan after which they will die regardless, but they will only live that long if they continue to find food. The food could be on anyones land, not just mine or group land. The fish can go anywhere. Restricting O2O in any form totaly invalidates the ALife project.

You should be looking at the server code and finding a way to prevent it from crashing if someone tries this type of attack again rather than wasting time neutering the limited tools we already have.

_____________________

--------------------------------------------------------
Surina Skallagrimson
Queen of Amazon Nation
Rizal Sports Mentor

--------------------------------------------------------
Philip Linden: "we are not in the game business."
Adam Savage: "I reject your reality and substitue my own."

blaze Spinnaker

1/2 Serious

Join date: 12 Aug 2004

Posts: 5,898

10-26-2005 09:18

From: someone

You should be looking at the server code and finding a way to prevent it from crashing if someone tries this type of attack again rather than wasting time neutering the limited tools we already have

Well, there reasoning was sound for the change they did. They needed to put a stop to script kiddies who cut/pasted the virus.

Fact is, their change stopped nothing except the cut/paste attack.

Going forward, though, I agree with your sentiments. People will always be able to do global attacks, replication or not, so getting rid of replication isn't really a solution.

If you want, Kelly, give us access to a seperate grid and we can show you a number of many many different ways to do a global attack on single points of failure without replication.

Harris Hare

Second Life Resident

Join date: 5 Nov 2004

Posts: 301

10-26-2005 11:05

I also use llGiveInventory() to pass data. It's a great way to avoid using listen events between two nearby objects that cannot be linked.

In my particular case, I built a transporter system that uses Landmarks to pass destinations between each transport sphere. The avatar sits on the sphere and it uses the rarely used lRequestInventoryData() function to pull the coordinates from the current landmark and transport them there. Before it moves, it would rez a copy of itself in its place and give the current landmark to the new sphere it leaves behind.

I wouldn't have noticed but I have a friend who has the transporter on their property that they do not own but is allowed to use as part of a group (Luskwood Estates).

Welcome to the Second Life Forums Archive

O2O Nerfed Horribly Groan

O2O Nerfed Horribly Groan
Tateru Nino Girl Genius Join date: 13 Sep 2005 Posts: 312	10-25-2005 21:17 Makes perfect sense. I can even see a way to cheat limited persistent variable storage out of it with the cooperation of another object. _____________________
Hiro Pendragon bye bye f0rums! Join date: 22 Jan 2004 Posts: 5,905	10-25-2005 21:34 From: Kelly Linden Hiro, actually reading through the thread again I'm not sure which of the ideas you are trying to promote? The energy one from eggy or your tax? Kelly, just dropped you an email. I think ultimately the ideas in my thread would take a while to flush out details and borderline cases - like how to compensate for someone playing a FPS and rezzing thousands of bullets. Anyway - I'll repost the other suggestions I emailed you, for the benefit of the forum readers: Why not just cap # of rezzes per sim per second? How about allowing temp on rez to be banned / autoreturned? (I know Cory spoke about being able to ban a person's objects being in the works.) Why not add more land options so that a person has more than simply an on/off toggle checkbox for "rez objects"? Why not let land owners set a price per rez for their land? Ultimately - and I assume this would be the most difficult - why not have objects ask permission before travelling over someone's land? Why not check land create object permissions at the instance an object crosses a parcel border / is rezzed, rather than at timed increments? _____________________ Hiro Pendragon ------------------ http://www.involve3d.com - Involve - Metaverse / Emerging Media Studio Visit my SL blog: http://secondtense.blogspot.com
Kelly Linden Linden Developer Join date: 29 Mar 2004 Posts: 896	10-25-2005 21:54 From: Tony Tigereye Scripts within objects can modify the name and description of the object they are in by using llSetObjectName() and llSetObjectDesc() respectively. After they have put whatever data they want into these data storage areas, they can then call llGiveInventory() to send the object over to another object where a script in the receiving object can read the data stored in the object name by calling llGetInventoryName(), and/or it can rez the object it just received and use some kind of local communication method (llSay(), llWhisper()) to talk to the script inside the received object to get the description data. Wow that's hard to read. Does it make sense? I'm missing a step in this process. Script1 in ObjectA can only change the name and desc of ObjectA if ObjectA is rezed in world. Script2 in ObjectB can only transfer ObjectA to ObjectC via llGiveInventory if ObjectA is in the inventory of ObjectB. How is this accomplished? Unless you are saying Script2 can modify ObjectA? _____________________ - Kelly Linden
Kelly Linden Linden Developer Join date: 29 Mar 2004 Posts: 896	10-25-2005 22:04 Thanks for the email Hiro. It is rather long, so I will reply tomorrow when I can do it justice. _____________________ - Kelly Linden
Hiro Pendragon bye bye f0rums! Join date: 22 Jan 2004 Posts: 5,905	10-25-2005 22:11 From: Kelly Linden Thanks for the email Hiro. It is rather long, so I will reply tomorrow when I can do it justice. LOL no worries. Can I get a straight answer on one thing, though - did LL today or yesterday feel it was in immediate threat of another DOS attack like the one we experienced? _____________________ Hiro Pendragon ------------------ http://www.involve3d.com - Involve - Metaverse / Emerging Media Studio Visit my SL blog: http://secondtense.blogspot.com
Jesrad Seraph Nonsense Join date: 11 Dec 2004 Posts: 1,463	10-25-2005 23:01 (I'm starting to feel like a parrot) Why can't the number of physical objects be capped per sim in a similar way as the number of agents is (with an additional check on object rezzing) ? After all there already is a specific cap on the number of prims in a physical object enforced. It's not like it wouldn't make sense, and I think it would actually fix the problem at hand instead of making it just a bit more difficult to cause sim crashes. _____________________ Either Man can enjoy universal freedom, or Man cannot. If it is possible then everyone can act freely if they don't stop anyone else from doing same. If it is not possible, then conflict will arise anyway so punch those that try to stop you. In conclusion the only strategy that wins in all cases is that of doing what you want against all adversity, as long as you respect that right in others.
Tateru Nino Girl Genius Join date: 13 Sep 2005 Posts: 312	10-25-2005 23:13 I'm not sure what the number for the cap should be. Maybe if it was based off the ips rate of the physics system? When the physics load gets too heavy don't allow an object to be set physical or rez as -- No, wait. I can figure a way to game that, too. Hmm. No, capping the number of physical objects wouldn't work, unless the number was very very small indeed. Otherwise I can still think of ways to do to a sim what the griefsphere did. In fact the more I think about it, the more ways I can think of. I can certainly think of a way to totally mire a sim in a very hard to detect way (oh, it'd be insanely obvious to a Linden gridmonkey). Problem is, I can't think of a good way to prevent any of the things I can think of. _____________________
Hiro Pendragon bye bye f0rums! Join date: 22 Jan 2004 Posts: 5,905	10-25-2005 23:20 From: Tateru Nino Problem is, I can't think of a good way to prevent any of the things I can think of. Yes ... ah .... please look into the light. _____________________ Hiro Pendragon ------------------ http://www.involve3d.com - Involve - Metaverse / Emerging Media Studio Visit my SL blog: http://secondtense.blogspot.com
Tateru Nino Girl Genius Join date: 13 Sep 2005 Posts: 312	10-25-2005 23:24 giggle I'm sorry. What was I saying again? _____________________
Hiro Pendragon bye bye f0rums! Join date: 22 Jan 2004 Posts: 5,905	10-26-2005 00:03 From: Tateru Nino giggle I'm sorry. What was I saying again? I think you were just commenting how cool the new map is, how the capacity of each sim up to 100 people is a real great upgrade, and how you're anxious to see attachments utilizing the new movable attachment features. _____________________ Hiro Pendragon ------------------ http://www.involve3d.com - Involve - Metaverse / Emerging Media Studio Visit my SL blog: http://secondtense.blogspot.com
Jesrad Seraph Nonsense Join date: 11 Dec 2004 Posts: 1,463	10-26-2005 01:29 What about disabling physics if a sim is too laggy ? And/or throttling llRezObject performance with time dilation ? Then prim allotments / temponrez deletion could take care of it. It's all a matter of priorities, ensure the sim keeps running, then ensure it can handle that many people on it, then ensure it can serve all the network updates, then the physical simulation, then script execution, etc... More cool stuff that was broken by this move here. _____________________ Either Man can enjoy universal freedom, or Man cannot. If it is possible then everyone can act freely if they don't stop anyone else from doing same. If it is not possible, then conflict will arise anyway so punch those that try to stop you. In conclusion the only strategy that wins in all cases is that of doing what you want against all adversity, as long as you respect that right in others.
Kelly Linden Linden Developer Join date: 29 Mar 2004 Posts: 896	10-26-2005 08:35 Grey Goo attacks are different from other forms of attack: * Other attacks have sources which makes them much, much easier to contain and stop. Long before they reach the sim wide scale. * Grey Goo attacks turn every infected sim, even if only 1 stray object bounces there, into a source of attack. * Other attacks can only grow exponentially for a limited number of generations. * Grey Goo attacks grow exponentially for infinite generations, which means they can start smaller and simpler and grow bigger faster. The ability to crash a sim is known, but crashing a sim is a far different situation than an attack that brings down the entire service and can be dealt with differently. Thanks again for all the feedback. _____________________ - Kelly Linden
blaze Spinnaker 1/2 Serious Join date: 12 Aug 2004 Posts: 5,898	10-26-2005 08:42 From: Kelly Linden That is an interesting idea blaze. What manner is this done in? I think only inventory names, type and notecard contents are accessible to scripts. Perhaps permissions, but using that for data storage would be ... interesting. None of the methods I can think of actually allow a script to modify this data, or require that objects be used in particular (as opposed to notecards for example). Well, think of a card game. If you had an object that sent a HUD an object called "QH", then your hud could detect the inventory change and then show it. Kludgy, yeah, but that's what happens when you don't have secure communication available
blaze Spinnaker 1/2 Serious Join date: 12 Aug 2004 Posts: 5,898	10-26-2005 08:45 From: Kelly Linden Grey Goo attacks are different from other forms of attack: * Other attacks have sources which makes them much, much easier to contain and stop. Long before they reach the sim wide scale. * Grey Goo attacks turn every infected sim, even if only 1 stray object bounces there, into a source of attack. * Other attacks can only grow exponentially for a limited number of generations. * Grey Goo attacks grow exponentially for infinite generations, which means they can start smaller and simpler and grow bigger faster. The ability to crash a sim is known, but crashing a sim is a far different situation than an attack that brings down the entire service and can be dealt with differently. Thanks again for all the feedback. I don't get it. Doesn't llGiveInventory not work after a number of generations? I thought it didn't Eg: if object a gives inventory to object b which which gives inventory to object c, then object c can't give inventory to anyone.
Kelly Linden Linden Developer Join date: 29 Mar 2004 Posts: 896	10-26-2005 08:55 Nope blaze, that has never been the case. _____________________ - Kelly Linden
Kelly Linden Linden Developer Join date: 29 Mar 2004 Posts: 896	10-26-2005 08:56 From: blaze Spinnaker Well, think of a card game. If you had an object that sent a HUD an object called "QH", then your hud could detect the inventory change and then show it. Kludgy, yeah, but that's what happens when you don't have secure communication available Very cool. I suppose with a suitably limited vocabulary (a deck of cards like your example) that would work. I believe this can be made to work with the ideas I have. _____________________ - Kelly Linden
Surina Skallagrimson Queen of Amazon Nations Join date: 19 Jun 2003 Posts: 941	10-26-2005 09:11 From: Kelly Linden Very cool. I suppose with a suitably limited vocabulary (a deck of cards like your example) that would work. I believe this can be made to work with the ideas I have. Are you going to let us in on your ideas or will they just be sprung on us in a future "bug fix" update? The only way my fish (and other similar ALife projects) will work as intended is by fully reinstating the orriginal functionality of llGiveInventry(). Limiting it to owners land, or group land, or limiting generations is just not good enough. For example, my fish are designed to freely roam the SL waterways. They already have checks built into them to stay away from "protected" land where they may be auto-returned or fail to reproduce due to no-build. However, even this ability is limited due to none of the LSL functions working across a sim boundry, so boundry crossing is very much a leap of faith that they won't meet instant death on the other side. All my fish have a built in limited lifespan after which they will die regardless, but they will only live that long if they continue to find food. The food could be on anyones land, not just mine or group land. The fish can go anywhere. Restricting O2O in any form totaly invalidates the ALife project. You should be looking at the server code and finding a way to prevent it from crashing if someone tries this type of attack again rather than wasting time neutering the limited tools we already have. _____________________ -------------------------------------------------------- Surina Skallagrimson Queen of Amazon Nation Rizal Sports Mentor -------------------------------------------------------- Philip Linden: "we are not in the game business." Adam Savage: "I reject your reality and substitue my own."
blaze Spinnaker 1/2 Serious Join date: 12 Aug 2004 Posts: 5,898	10-26-2005 09:18 From: someone You should be looking at the server code and finding a way to prevent it from crashing if someone tries this type of attack again rather than wasting time neutering the limited tools we already have Well, there reasoning was sound for the change they did. They needed to put a stop to script kiddies who cut/pasted the virus. Fact is, their change stopped nothing except the cut/paste attack. Going forward, though, I agree with your sentiments. People will always be able to do global attacks, replication or not, so getting rid of replication isn't really a solution. If you want, Kelly, give us access to a seperate grid and we can show you a number of many many different ways to do a global attack on single points of failure without replication.
Harris Hare Second Life Resident Join date: 5 Nov 2004 Posts: 301	10-26-2005 11:05 I also use llGiveInventory() to pass data. It's a great way to avoid using listen events between two nearby objects that cannot be linked. In my particular case, I built a transporter system that uses Landmarks to pass destinations between each transport sphere. The avatar sits on the sphere and it uses the rarely used lRequestInventoryData() function to pull the coordinates from the current landmark and transport them there. Before it moves, it would rez a copy of itself in its place and give the current landmark to the new sphere it leaves behind. I wouldn't have noticed but I have a friend who has the transporter on their property that they do not own but is allowed to use as part of a group (Luskwood Estates).