• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
MAINTENANCE ANNOUNCEMENT - JIRA will undergo maintenance starting 1:00am PDT through 3:00am on Saturday 2010.03.20. Please do not enter issues during this time as the system maybe restarted.
Issue Details (XML | Word | Printable)

Key: VWR-9222
Type: New Feature New Feature
Status: Reopened Reopened
Priority: Normal Normal
Assignee: Soft Linden
Reporter: Darien Caldwell
Votes: 5
Watchers: 4
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

Change Permission Throttling to a 'per object' model versus the current 'per owner' model.

Created: 16/Sep/08 12:59 PM   Updated: 14/Jul/09 09:12 AM
Component/s: Permissions
Affects Version/s: None
Fix Version/s: 1.23 Release Candidate, 1.23

Time Tracking:
Not Specified

File Attachments: 1. Text File VWR-9222-llviewermessage.cpp.patch (0.5 kB)

Issue Links:
Relates
 

Linden Lab Issue ID: DEV-20608
Linden Lab Internal Branch: maint-viewer-12


 Description  « Hide
As discussed on the SL Scripting list, The current permission throttling was implemented with the mind to protect residents from maliciously scripted objects which would flood the target with bogus permission requests.

The current solution is to limit the number of incoming permission requests to a certain threshold per time period and discard any further requests silently.

However, there can be legitimate instances when a large number of permission requests can occur, such as when rezzing a grouping of scripted vendor objects. The difference being, the multiple requests are coming from a number of individual objects, not from a single object.

The proposal as outlined by Soft Linden is as follows:

"I could see a good argument for throttling the request per object instead of per owner when an agent owns the object making the request."

This is the proposal as it stands now, It seems to be a good middle ground enhancement to the existing throttle.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Soft Linden added a comment - 16/Sep/08 01:18 PM
As I plan to do this:

agent's own objects: throttled per root prim
others' objects: throttled per agent


Darien Caldwell added a comment - 16/Sep/08 07:27 PM
That sounds very reasonable.

Darien Caldwell added a comment - 21/Oct/08 05:22 PM
You know I was thinking about this one the other day as I was setting up another spot with another 40 vendors I had to reset one by one. Looking forward to this.

Nutron Foton added a comment - 09/Feb/09 09:12 AM
It looks like the throttle on llRequestPermissions was added in VWR-3214. I'm having a problem with the throttle, as an object I own is spawning child objects which each need to request permission to change links. Failing silently makes the situation worse, as the object doesn't know if it should wait and try again.

If I own an object, shouldn't it be able to ask for as many permissions as needed without being throttled?


Soft Linden added a comment - 09/Feb/09 09:54 AM
@Nutron - this JIRA fixes the case you're talking about. With this, objects you own are independently throttled. Each individual object will be able to request permissions 5 times in a 10 second period, rather than having the single overall limit.

Chalice Yao added a comment - 09/Feb/09 11:41 PM
Now this is very shiny. I approve!

Now the messages caused by llDialog and llLoadUrl just need to supply the object owner's key as well (instead of just the name), so those can be throttled the same way :| But I guess that'd be kind of a protocol change, mh?

Does llRequestPermissions/script_question even serve that itself, or are you going to do this by the supplied owner name?


Chalice Yao added a comment - 09/Feb/09 11:43 PM
I should mention that the lack of owner key in the received llMessageSystem is currently why llDialog etc. aren't currently muted at all with the default viewer, even if the object owner is on the mute list..

Darien Caldwell added a comment - 09/May/09 10:05 PM
I see this was listed as included in the 1.23 Viewer, however in testing it doesn't seem to be working. I selected 8 scripted vendors, and reset them from the Tools menu, and I consistently only get 5 Debit Permission windows. if I try again too soon, I don't get any, so this appears to indicate the per owner model is still in effect.

Soft Linden added a comment - 10/May/09 05:35 AM
@Chalice, it' susing the supplied owner name. Adding the key to dialogs across the board would be a good idea.

Soft Linden added a comment - 10/May/09 05:35 AM
@Darien - Are the vendors deeded to a group, or is there anything otherwise special about these?

I just put this script into ten objects:
default { state_entry() { llRequestPermissions( llGetOwner(), PERMISSION_TAKE_CONTROLS ); } }

I then reset them all simultaneously and I got ten dialogs.


Darien Caldwell added a comment - 10/May/09 07:19 AM
No they aren't deeded to group. Your example did work when I tried it in another region, and the vendors in question do too in that region. So it seems related to the sim I tried it in. I'll assume for now a restart will clear it up. If not I'll look into it further and be back.

Dessie Linden added a comment - 15/Jun/09 04:42 PM
Fixed in 1.23.4, released on 06/15/2009.

Latif Khalifa added a comment - 13/Jul/09 08:06 AM
Still experiencing problem with max 5 vendors giving me debit dialog, since I am moving the store to a new region, this is major problem.

Second Life 1.23.4 (123908) Jun 11 2009 15:16:56 (Second Life Release)
region Baern


Latif Khalifa added a comment - 13/Jul/09 09:12 AM
Turns out, under some circumstances sim sends us owner_name with an additional whitespace at the end. This patch fixes it in the viewer.

Soft Linden added a comment - 14/Jul/09 09:12 AM
Thanks again, Latif! Awesome catch.

Given that it's causing other bugs as well, we'll probably do this on the simulator end.