LSL Protocol/Restrained Love Open Relay Group/handover

This is a discussion page for adding world object hand over support.

!x-handover

Implemented in Dahlia's multirelay

Justification

There should be a way to handover the victim from one world object to another without the having to ask for permission again

Requirements

The change must enable world objects to be easily compatible with both old and new relays. The relay must ensure that the target object is ready.

Syntax

!x-handover/(key)/(type)|!release

(key) is the id of the target object

(type) : 0 lift all restrictions of the source object, 1 keep them, it is the responsibility of the target object to keep them in mind

Compatibility

Immediately after the "!x-handover" a "!release" command must be sent by the world objects. Relays which support !x-handover must ignore the rest of the chat line, including that !release command.

Old Relays which do not support "!x-handover" will ignore it and execute the "!release" command instead. So they are available for the target object in the old way (e. g. may ask for permission again).

The relay must ignore further "/"-parameters for future extension of the command.

Note on ping/pong

The relay must ensure with the !ping meachnism that the target object is available. The target object, however, might not see the ping, for example because of a slow intersim teleport. The target object must respond to !pong on arrival anyway.

Alpha Code

TODO

Think about an additional "/"-paramter meaning "let that target object control the relay but keep me on the list, too" for relays that support multiple world objects. This needs a bit more of thinking because the policy of ignoring !release does not work this simple anymore. Since Dominatech's sample code is under a very restrictive license, i am unable to look at it, to see who much work this would be. --Maike Short 08:54, 15 February 2009 (UTC)

3 way handshake

This is a GREAT idea that perhaps should be expanded a little.. "Handover" (to me) implies "here, take this", "ok I got it, thanks". So perhaps this should be three commands? A !x-handover-r (request), !x-handover-s (send) and !x-handover-a (ack) something like -

sent to source object that has to do the handover - !x-handover-r/target-key/(type) (request you hand restrictions you have to target-key)

sent from source object to the target object - !x-handover-s/target-key/(type)/(list of restrictions in effect)

sent from the target object back to the source object !x-handover-a/target-key/(type)/0 (0 = handover accepted) -OR-

sent from the target object back to the source object !x-handover-a/target-key/(type)/-1 (-1 = handover failed)

the source takes whatever actions necessary depending on the success or failure of the handover. Just thinking out loud. --Ilana Debevec 02:22, 17 February 2009 (UTC)

Unfortunatally, there is a situation in which this won't work using normal chat: The first objects sends @tpto:././.=force|!x-handover/./.|!release. The tpto destination can be in another sim anywhere on the grid. There is such an object called "Kidnapper" in Stonehaven at <76, 202, 11>. --Maike Short 19:38, 17 February 2009 (UTC)

Comments

Implementations

I implemented this in my relay a few weeks ago, but honestly I could not really test it, as it is really new and in no piece of furniture I know of (do MSM devices already use this?). Moreover I am a bit dubious about the whole mechanism now. Depending on answers and future comments, I might propose a revised protocol for the next version.

Currently what my relay does is the following.

If restrictions should be kept:

• in my RLV sources list, it replaces the UUID of the handing over device by the taking over one,
• starts the ping process for that UUID, with a time out,
• if the device fails to answer in the delay, then the relay is released from restrictions coming from the handing over device.

If restrictions should be forgotten:

• it releases restrictions from the handing over source (and removes the device from the source list),
• it adds the taking over device to the temporary white list (in my relay, that means that any command coming from that UUID in the near future will be executed),
• it sends a !ping to this device (more for telling the taking over device that the relay is ready than for the usual meaning of !ping).

In both cases, the handover mechanism will fail if the taking over device fails to answer in a timely manner. The reason it is working like this, is the philosophy of my implementation, which considers that no device currently having no restriction should be kept in the list of active sources. Such devices can only have a "transient" nature (hence the temporary white list).

Anyway, those are internal implementation details no one but me should worry about. What I want to know is only whether my implementation is conform to the specification... and where I could actually test it!

Other question, Maike's and Felis' relays aside, are there other 1.040 compatible relays?

--Satomi Ahn 13:37, 18 May 2009 (UTC)