ping/!pong
The ping/!pong mechanism exists so that relays can check presence and responsiveness of a controller.
This was primarily meant to be used on relay wearer relog, in order to reactivate all restrictions so that sessions persist on relog if the controller still exists and is ready to continue the session.
!pong cannot require authentication and does not lock a session
We call ping message a message from the relay, having the following syntax:
ping,<controller_key>,ping,ping
We call !pong message a message from the controller, having the following syntax:
ping,<relay_key>,!pong
Relay side
A relay SHOULD NOT send an acknowledgement in response to !pong.
A ping message can be sent any time by the relay to a known controller.
On wearer relog, for each existing Locked session, the relay must send a ping message to the session controller.
When a !pong message is received from a controller, if it was a reply to a previous ping message:
if the session RLV restrictions contain unsit and the avatar was sitting on some object when the restriction was applied, then the relay MUST force the avatar to sit back on the same object (if still existing);
the relay MUST make sure all restrictions belonging to the session are made active again.
If a ping message is sent and is not answered by the controller, then the relay closes the session.
Note that the relay is responsible for storing restrictions and the key of the sit target across sessions, not the controller.
Controller side
Unless it does not matter that the relay could close the session (or for another reason, the controller knows the relay will not close it), a controller SHOULD listen to ping messages and answer any ping message with a !pong message.
A controller should ignore ping requests from relays it is not ready to handle.
Note controller don't have to poll for relay presence to resume a session but should just listen for ping messages instead. The relay should have stored all restrictions and handle sitting back to whatever furniture the relay wearer was tied up to.
Concerning the second bullet: for instance, if the controller is a furniture which is already in use by another relay wearer, it would be cause dysfunctions to let the pinging relay restore the restrictions without letting its wearer sit on the furniture. Or if the controller is not stateless and the state for the pinging relay has not been saved before, resuming the session from the initial state might be inconsistent.