Difference between revisions of "LSL Protocol/Restrained Love Open Relay Group/listen"

From Second Life Wiki
Jump to navigation Jump to search
Line 1: Line 1:
=!x-listen=
{{ ORG Restrained Life Relay Specs TOC }}
!x-listen/xxxx: changes the communication beween relay and controlling device to channel xxxx instead of RLVR, assuming xxxx is a high negative integer.


Motivation: the relay and the device thus stop spamming the RLVR channel with messages that only concerns those two objects.
==!x-listen==


Scenario:
; Description : Command to open up a second communication channel to undocumented features of the object containing the relay.
(session on channel RLVR between R and C)
-RLVR> blah,k(R),!x-listen/-12345
<RLVR- blah,k(C),!x-listen/-12345,ok
(session continues on channel -12345)


Neither R and C are required to listen on channel RLVR after this. It is even recommended that R and C close every useless listener.
; Implementation : Simply opens up a new listener on the given channel for the specified period of time (indefinitely if no time is specified)


Both R and C are required to listen to each other on channel -12345 after this dialog.
; Syntax : '''!x-listen/(channel)/(time)'''
::(channel) = the channel to be opened up by the relay
:: (time) = the length of time to keep the channel open


C should only propose high negative channels (<1000). The relay is not required to accept any other channel than high negative ones. If the proposed channel is wrong, the relay can "ko" the message.
; Examples
: Opens up a listener on channel 1234 for one minute '!x-listen/1234/60'
: opens up a listener on channel -56789 indefinitely '!x-listen/-56789'


Recommendation: this command should preferably be used after the session is locked, as the relay is not required to retain any data concerning a non-locking device.
; Discussion
There are many instances where a relay is embedded in a bigger device (e.g., the Think Kink PBA, collars, and the Cool HUD). These devices often need additional listeners, and might even need listeners for short periods of time to listen to some external object. Of course, it would be simple for the devices to always listen on the specified channel, but that would add to lag which is a big enough problem as it is. The goal here is to allow the device to use the relay channel (to which the person should ''always'' be listening) to open up the additional listener as needed, cutting down on overall lag as the second listener is only open as needed.


Good practice scenario:
It should be the responsibility of the bigger device and not the relay to shut the channel down.
(session on channel RLVR between R and C)
-RLVR> blah,k(R),@randomlockingcommand=n|!x-listen/-12345
<RLVR- blah,k(C),@randomlockingcommand=n,ok
<RLVR- blah,k(C),!x-listen/-12345,ok
(session continues on channel -12345)
 
It is not recommended to place other commands after the !x-listen, as it is not clear on which channel they should be acknowledged (depending on whether or not the relay ok's the !x-listen, and even when ok'd it is might make relay implementation harder in some cases if the acknowledgement channel changes within a batch of commands).

Revision as of 09:04, 11 June 2009

Restrained Love
Open Relay Group
x-tensions
Restrained Love Relay

!x-listen

Description
Command to open up a second communication channel to undocumented features of the object containing the relay.
Implementation
Simply opens up a new listener on the given channel for the specified period of time (indefinitely if no time is specified)
Syntax
!x-listen/(channel)/(time)
(channel) = the channel to be opened up by the relay
(time) = the length of time to keep the channel open
Examples
Opens up a listener on channel 1234 for one minute '!x-listen/1234/60'
opens up a listener on channel -56789 indefinitely '!x-listen/-56789'
Discussion

There are many instances where a relay is embedded in a bigger device (e.g., the Think Kink PBA, collars, and the Cool HUD). These devices often need additional listeners, and might even need listeners for short periods of time to listen to some external object. Of course, it would be simple for the devices to always listen on the specified channel, but that would add to lag which is a big enough problem as it is. The goal here is to allow the device to use the relay channel (to which the person should always be listening) to open up the additional listener as needed, cutting down on overall lag as the second listener is only open as needed.

It should be the responsibility of the bigger device and not the relay to shut the channel down.

Retrieved from "https://wiki.secondlife.com/w/index.php?title=LSL_Protocol/Restrained_Love_Open_Relay_Group/listen&oldid=390343"