Talk:LSL Protocol/Restrained Living Relay/Other Implementations/Dominatech RLV Relay

Issues with multi-device relays

There's a couple of issues that people need to consider now that multi-device relays are becoming available.

First, it used to be you could assume that if someone's relay would talk to you and take commands, they were not otherwise restricted. This is obviously no longer the case. Don't assume someone has no restrictions just because their relay responds to you.

Second, any relay that supports an arbitrary number of devices using a finite number of prims ought to have some way to report the status back to a device of only the restrictions coming from that device. The usual @getstatus is insufficient for this task, since that will tell you every restriction from the relay, not from the device, since the reply will come from the client rather than the relay. And a relay can't simply intercept and reply to @getstatus itself since will be listening for the response to come from the avatar. Hence, my proposed !getstatus command. Using multiple prims on the relay works only to a point. No matter what N you choose, sooner or later someone's going to want N+1, and having all those scripts running at once to handle a task that could just as well be handled by one doesn't strike me as Grid-friendly.

Thoughts?

--Julia Banshee 08:37, 14 February 2009 (UTC)

I think that this is not hard on the sim if coded properly (e. g. one main script with does all almost all of the work and which sends llMessageLinked to the correct prim. And a script in each prim that simply forwards anything it gets on that llMessageLinked channel to llOwnerSay). But I agree that this approach has some issues. As far as I know @getstatus is not used by many world objects. And I think that on a normal use case having more restrictions in there should not cause trouble. Please make a proposal for !getstatus at https://wiki.secondlife.com/wiki/LSL_Protocol/Restrained_Life_Relay/Bugs_and_Pendings_Features And while you are at it, I would like to ask you to comment on !handover. --Maike Short 10:15, 14 February 2009 (UTC)

Well Julia I'm glad to see we're not the only ones that have been fighting this task over the past coupla months. We will be putting up the full details of our implementation in a few days (soon as we clean up a few things and squash a bug that one person has found (it's always one case you never thought of in testing) but I wanted to respond to the 'arbitrary prims' point you made.

We did things a little differently in this, the relay is broken into two parts. The SUPERVISOR (SU) and the PROCESSING UNIT (PU). The SUPERVISOR does all the 'global relay' work. The listeners, handling ASK/AUTO/OFF, Object Trustworthyness, dialogs (Allow/Deny for ASK), SAFEWORD, HARDCORE (a special mode that we had requests for.. remember old Chinese Proverb there). Everything that only needs to be handled 'once' and applies to all the objects being handled. The PROCESSING UNIT does all the dirty work, deconstruction of the commands, sending them to the viewer, ect.

This (we believe) actually puts LESS work on sim resources. The PU only works when a given object is active. But the major reason we took this approach was to not have to juggle so many lists. Even if MONO was great in list handling, just handling lists, adding/deleting/changing them gets cumbersome to say the least. The SU only has a couple of small lists to deal with that get built once and then don't change. This also means that with the small PU's, the number of objects that can be handled is.. well, I did one up with 20 PU's (objects) and the SU scaled to it nicely.

As for the 'arbitrary prims'. Well we didn't start out that way. Originally the SU and PU's were all in the root prim, we had the PU's do some fancy footwork to get their 'PU Number' from the script name, communicated to them with a link message that told which PU it was for and it was going fine. But, our Relay is HUD based, no chat commands. So, since the HUD was already "visual" with the graphic changing as it's state (AUTO/ASK/OFF/HARDCORE), we added the 'pips' in the padlock to show how many devices 'had hold' of you and if it was active or pending (waiting an ASK). Then we had to put the status indicator scripts in the pips. Suddenly, the EUREKA moment hit. We moved the PU's to the 'pips', put the status texturing code in the PU when they changed states, and got rid of a BUNCH of lists, link messages in the SU and extra scripts in the pips.

We know the link number of each pip, so we can send link messages directly to the PU that needs to handle a command.

We keep the UUID of the object controlling a PU in the description of the pip, so we can reach over with a llGetObjectDetails(llGetLinkKey(pip#link), [OBJECT_DESC]) and a) find out if a PU is being used (!=NULL_KEY) and b) what object is using it. The pips (prims) becomes the list, that we can query, manipulate, blank, etc.. lot easier and faster than the LSL list commands.

As far as only 5 devices. Well that was an arbitrary decision. Could have been 4, could have been 6. Our logic was based on our customers requests.

- One 'area effect' device (a dungeon with a no TP, no location, no outgoing IM's) - One 'device' restraining them (no stand) or confining them (a cell or cage that might shut off chat, or whisper only, or block IM's totallY) - One 'remote control' from their owner that may do other things (strip, deafen, totally mute)

that was 3. With the exception of additional remotes to control you, we couldn't stack the boxes inside each other any further. Add 2 more for good measure and, well that's how we got there. Perhaps someone will want one with 6, then 7, then 8. We'll see.

But, just wanted to respond, the code will be up on the wiki in a few days. Let's keep on keeping on, see where we can go with this.

--Ilana Debevec 10:39, 14 February 2009 (UTC)

Maike.. I got long winded and you must have been reading my mind :) --Ilana Debevec 10:41, 14 February 2009 (UTC)