LSL Protocol/Restrained Life Relay/pong handling contradiction

From Second Life Wiki
Jump to navigation Jump to search

pong handling contradiction

Proposed Change
Change the point "When relogging, send a 'ping' message (see above) to check the in-world object is still available. If no message after a few seconds (not necessarily a '!pong', any message aimed at the relay can do), release the rules linked to this object." in section "Relay requirements" to: "When relogging, send a 'ping' message (see above) to check the in-world object is still available. If no !pong-message is received form this object, release the rules linked to this object."
Back in 1.014 there was a discussion on the wiki but mostly in world whether it is a good idea to only accept !pong as replay to ping. The reasons behind this proposed change was that it is easier and less error prone for world objects this way. They can easily send a !version when sat on or entered without having to check with @getstatus if the relay is remembering some old restrictions. This way makes it far less likely that people get stuck. So for 1.015 the spec was changed require a !pong reply.
Current state of the spec since 1.015
Unfortunately I messed up when I edited the wiki page. I change the sections "'ping' relay message and "!pong" object metacommand" and "In-world object requirements". But I overlooked the section "Relay requirements".
This will make the spec more consistent. It was the intended change back then and is still valid. I am not aware of any world object that depends on a non !pong message to keep the restrictions. Most relays only accept !pong nowadays, too.

--Maike Short 19:28, 16 April 2009 (UTC)


I agree that !pong should be a requirement in reply to !ping.

This said, I kept in my relay the principle following which any other reply is a proof that the device is still there and active: it is bad enough that many devices are not fully implementing the *requirements* and are not sending any reply to !ping (and thus relays checking for their presence either regularly or on user request think that the device is no more active or restraining the relay wearer) for neglecting other clues of the device presence. Henri Beauchamp 10:10, 17 April 2009 (UTC)