[sldev] Unexpected objects return in group land

[Tigro Spottystripes]

I think a simple solution would be to have rez requests include the prim
count, if the rez request is accepted, the prim count is increased
before the object event starts to actually be rezzed.

Doing it like this, it would be somthing like this.

1. Sim receives rez request for an coalesced object with 9000 prims
2. It confirms the parcel where the object will be rezzed has 10000
prims avaiable
3. The sim adds 9000 prims to the count of prims used by the parcel
assigned to the object that is being loaded
4. The asset server is slow to serve the actual prims
5. The sim gets a rez request for a object with 500 prims
6. The sim confirms that the parcel has 1000 prims still avaiable
7. The sim adds 500 prims to the coutn of prims used by the parcel
8. The asset server is still crawling
9. The sim gets a rez request for an object with 1000 prims
10. The sim verifies that the parcel only got 500 prims avaiable
11. The rez request is denied and fails
12. The asset server finally delivers the whole 9000 prim object
13. Some misterious condition results in the delivery of the 500 prims
object being interrupted and not finishing.
14. The rez request for the 500 prims object fails.
15. The sim remvoes 500 prims from the count of the parcel since the
object isn't there anymore.

Basicly the rez request is only accepted if there are enough prims
avaiable, and once a rez request is accepted the prim count for the
object is already reserved regardless of how many prims of the object
have actually been rezzzed already.

A scripted object that repeatedly rezzes an object with enough prims to
clog a parcel, DOSing by filling the queue after a few repeats would
probably trigger the grey goo fence anyway, so there shouldn't be much
concern, and since the prims are already being counted a parcel manager
should be able to see who is cloging their parcel.




On a slightly unrelated topic. You've probably noted that I mentioned an
object with a huge number of prims, way beyond what is currently
allowed, here is somthing from a pjira entry on the topic of the
supposed problems with rezzing big number of prims:

Dante Linden
<http://jira.secondlife.com/secure/ViewProfile.jspa?name=Dante+Linden>
added a comment - 22/Jun/09 05:52 PM
Here's the KB article I mentioned:

https://support.secondlife.com/ics/support/default.asp?deptID=4417&task=knowledge&questionID=6425^
<https://support.secondlife.com/ics/support/default.asp?deptID=4417&task=knowledge&questionID=6425>

Tigro, addressing the root cause of the issue would require changing old
and fundamental pieces of the simulator: the pieces that manage object
rezzing. The only somewhat-recent related changes I'm aware of have been
a rez limit and now the prim limit, both of which are mentioned in that
KB article.

[ Show »
<http://jira.secondlife.com/browse/SVC-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=120995#action_120995>
]
Dante Linden
<http://jira.secondlife.com/secure/ViewProfile.jspa?name=Dante+Linden>
added a comment - 22/Jun/09 05:52 PM Here's the KB article I mentioned:
https://support.secondlife.com/ics/support/default.asp?deptID=4417&task=knowledge&questionID=6425^
<https://support.secondlife.com/ics/support/default.asp?deptID=4417&task=knowledge&questionID=6425>
Tigro, addressing the root cause of the issue would require changing old
and fundamental pieces of the simulator: the pieces that manage object
rezzing. The only somewhat-recent related changes I'm aware of have been
a rez limit and now the prim limit, both of which are mentioned in that
KB article.

[ Permlink
<http://jira.secondlife.com/browse/SVC-4207?focusedCommentId=119881&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_119881>
| « Hide
<http://jira.secondlife.com/browse/SVC-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=120995#action_120995>
]
TigroSpottystripes Katsu
<http://jira.secondlife.com/secure/ViewProfile.jspa?name=TigroSpottystripes+Katsu>
added a comment - 22/Jun/09 06:50 PM - edited
so if it is just due to concern of physical objects breaking apart while
rezzing, only apply the limit to coalesced objects that contain at least
one physical object, or even better, simply don't simulate any physics
for a coalesced object until it is all rezzed
[ Show »
<http://jira.secondlife.com/browse/SVC-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=120995#action_120995>
]
TigroSpottystripes Katsu
<http://jira.secondlife.com/secure/ViewProfile.jspa?name=TigroSpottystripes+Katsu>
added a comment - 22/Jun/09 06:50 PM - edited so if it is just due to
concern of physical objects breaking apart while rezzing, only apply the
limit to coalesced objects that contain at least one physical object, or
even better, simply don't simulate any physics for a coalesced object
until it is all rezzed

[ Permlink
<http://jira.secondlife.com/browse/SVC-4207?focusedCommentId=119890&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_119890>
| « Hide
<http://jira.secondlife.com/browse/SVC-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=120995#action_120995>
]
TigroSpottystripes Katsu
<http://jira.secondlife.com/secure/ViewProfile.jspa?name=TigroSpottystripes+Katsu>
added a comment - 22/Jun/09 08:26 PM - edited
also, with so many issues, people are already used to have to do
workarounds and avoid certain things, taking a field together with a
physical ball would be avoided, either turn the ball non-phys, or have
the field rez a new ball if no ball is around

edit:also, what happened to being in build mode to rez physical objects
you don't wanna get loose? Isn't that common sense?

And sim crossing, if your chair isn't linked to the rest of the boat,
you're asking to have it move separatedly, usually even when the avatar
is sitting in an object there is already the risk the avatar itself will
be separated from the rest of the object during sim crossing. And anyone
that has walked across a sim border over prims, unless only with builds
that are made with the workaround to avoid the issue, knows that when
crossing sim borders physics and collisions don't work well

[ Show »
<http://jira.secondlife.com/browse/SVC-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=120995#action_120995>
]
TigroSpottystripes Katsu
<http://jira.secondlife.com/secure/ViewProfile.jspa?name=TigroSpottystripes+Katsu>
added a comment - 22/Jun/09 08:26 PM - edited also, with so many issues,
people are already used to have to do workarounds and avoid certain
things, taking a field together with a physical ball would be avoided,
either turn the ball non-phys, or have the field rez a new ball if no
ball is around edit:also, what happened to being in build mode to rez
physical objects you don't wanna get loose? Isn't that common sense? And
sim crossing, if your chair isn't linked to the rest of the boat, you're
asking to have it move separatedly, usually even when the avatar is
sitting in an object there is already the risk the avatar itself will be
separated from the rest of the object during sim crossing. And anyone
that has walked across a sim border over prims, unless only with builds
that are made with the workaround to avoid the issue, knows that when
crossing sim borders physics and collisions don't work well

[ Permlink
<http://jira.secondlife.com/browse/SVC-4207?focusedCommentId=119893&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_119893>
| « Hide
<http://jira.secondlife.com/browse/SVC-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=120995#action_120995>
]
TigroSpottystripes Katsu
<http://jira.secondlife.com/secure/ViewProfile.jspa?name=TigroSpottystripes+Katsu>
added a comment - 22/Jun/09 08:46 PM - edited
the explanations on that knowledge base entry seems to suggest this is
just a bunch of solutions to problems that didn't exist causing real
problems

get rid of the freezing sim, and get rid of the prim count limit, that
should result in having less problems than what we have now, if you add
up all problems that will be created by removing those non-features,
subtract all problems that are caused by having them present, and
combine with the problems that exist with or without them being present,
the result is less problems than what we have now, I believe you won't
even have to weight each individual problem solved by not having those
two non-features to notice a clear benefit in not having them

[ Show »
<http://jira.secondlife.com/browse/SVC-4207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=120995#action_120995>
]
TigroSpottystripes Katsu
<http://jira.secondlife.com/secure/ViewProfile.jspa?name=TigroSpottystripes+Katsu>
added a comment - 22/Jun/09 08:46 PM - edited the explanations on that
knowledge base entry seems to suggest this is just a bunch of solutions
to problems that didn't exist causing real problems get rid of the
freezing sim, and get rid of the prim count limit, that should result in
having less problems than what we have now, if you add up all problems
that will be created by removing those non-features, subtract all
problems that are caused by having them present, and combine with the
problems that exist with or without them being present, the result is
less problems than what we have now, I believe you won't even have to
weight each individual problem solved by not having those two
non-features to notice a clear benefit in not having them

----

if you wanna read the rest of the comments go to
http://jira.secondlife.com/browse/SVC-4207

ps:sorry if the links get kinda messy, I just pasted  straight fromt he
page, I'm not sure if the links will get mangled with formating
conversions and stuff





Dale Mahalko escreveu:
> On Wed, Jul 8, 2009 at 8:37 PM, Argent
> Stonecutter<secret.argent at gmail.com> wrote:
>   
>> The correct solution (don't rez the object, leave it
>> in inventory) seems too obvious.
>>     
>
>
> This sounds like a potential race condition, since rez requests are
> not instant and load-in takes time. Assume two people want to rez
> objects on a parcel with limited space. Both attempt to rez a high
> prim object from inventory at the same time (or within milliseconds).
>
> 1. The sim does a precheck for space availability for #1, finds enough
> room, starts the load-in
> 2. Asset system is being slow again
> 3. The sim does a precheck for space availability for #2, finds enough
> room, starts the load-in
> 4. Object #`1 rezzes
> 5. Object # 2 attempts to rez but fails due to insufficient capacity,
> same old problem occurs..
>
> ======
>
> The alternate solution to this is:
>
> 1. The sim does a precheck for space availability for #1, finds enough
> room, starts the load-in
> 2. Asset system is being slow again
> 3. The sim does a precheck for space availability for #2, finds that
> another load-in is pending and not completed yet, and so aborts the
> rez attempt.
> 4. Object #`1 rezzes
>
> Though this may lead to a possible "denial-of-rez" exploit by
> continously streaming rez requests of objects that quickly delete
> themselves, to keep the "rez queue" busy and prevent other people from
> rezzing objects since the sim always says "sorry, someone else is
> rezzing right now, cannot complete request", even in a fairly empty
> parcel or sim.
>
> ======
>
> It appears that the real problem is, if a parcel is overflowed, the
> sim tries to bring the number of objects back down to within limits by
> any means necessary, and it apparently is not aware of the order in
> which objects are added into a parcel so instead it randomly returns
> objects.
>
> Perhaps what is really needed is the capacity for a load-in of prims
> to be backed-out via a form of disk-partition journaling /
> transaction-tracking. If the parcel is found to be full when the
> load-in is asynchronously completed by the asset system, it can be
> safely backed out from the journal data.
>
> But next you run into problems of deciding how big this journal should
> be, since it adds more processing burden to the sim, to track the
> rezzing of everything in the sim in order to permit rez back-out.
>
> If a sim allows 15,000 objects then the journal should probably be a
> few multiples as large, since it is apparently theoretically possible
> to attempt to rez a 15,000 prim coalesced object in an empty sim. If
> two people try this at the same time the journal would need room to
> buffer the insane amount of rez overflow, and not wreck the rest of
> the existing sim.. so a 45,000 prim journal should be unreasonably
> large enough. :-)
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090709/ee3ea144/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkext7.gif
Type: image/gif
Size: 166 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090709/ee3ea144/attachment-0001.gif