AgentPresenceTests

Agent Presence Tests

Bugs that were fixed

Most of you are probably familiar with this login error:

The system is logging you out right now. Your account will not be available until $DATE Pacific Time.

http://jira.secondlife.com/browse/SVC-583

Turns out that this happens a lot more frequently than it should, due to a few low level bugs in the simulator. The most common case is really frequent, resulting in around 50 to 100 failed login requests per minute on our login cluster.

There is also a nasty bug where one of your attachments fails to upload during logoff, which leaves your avatar in a limbo state until the region is restarted. This is pretty rare, but is also fixed.

The agent presence cache in the simulator has been overhauled to deal with these issues.

Test Region Layout

There is a channel called "Agent Presence" on Aditi where these changes are being tested. There are 3 regions, Miramare Bay, Darkwood and Bay City - Morton. Miramare Bay and Darkwood are just north of Miramare and Dore, while Bay City - Morton is off by itself.

    __________
   |          |
   | Bay City |
   | Morton   |
   |__________|

               ___________  __________
              |           ||          |
              | Miramare  || Darkwood |
              | Bay       ||          |
              |___________||__________| _________
              |           ||          ||         |
              | Miramare  || Dore     || Ahern   |
              |           ||          ||         |
              |___________||__________||_________|

Testing surface area

The agent presence cache in the simulator was completely overhauled, so many parts of the simulator were changed. The following is a list of expected behaviors that should not have changed:

• Login: During login, the simulator publishes your current presence info to an internal service called the agent-presence service. Other simulators will use this service to find you if they need to route a message to you, see if you are online, or plot your location on a map.

• Online/Offline notifications: During login and logoff, the simulator will attempt to notify all of your friends that have permission to see your online status. Once it finds your friends, it routes the appropriate message (OnlineNotification or OfflineNotification) to your friends viewer through the simulator that they are connected to.
  • When the viewer receives these messages, they will update their respective entries in your friends list, so offline friends will appear inactive.
  • Region crossing / Teleport: When you cross regions or teleport, the destination simulator updates your presence with new coordinates.
  • You can verify that your friend's presence has changed by waiting for the cache to expire (around 10 minutes) and finding them on the map, or moving to another region and looking them up again.
    1. Your friend is in Miramare Bay, and you are in Darkwood.
    2. You find your friends position on the map, and verify that you see them in Miramare Bay.
    3. Your friend teleports to Bay City - Morton
    4. You cross over to Miramare Bay, and find your friend on the map.
    5. Verify that the map now shows them in Bay City - Morton.

• Logoff: This was the inspiration for this work. During logoff, the simulator will perform some session cleanup, and serialize your attachments for storage in the asset system. This should always result in a clean logout with your presence deleted from the agent-presence service, and your attachments properly stored for your next login.
  • You should only see the pending logoff message if you have a complicated set of attachments, which may or may not be scripted, which takes a little longer to serialize and upload. But even then, the wait should be less than one minute.
  • In 1.42 I've found that with several scripted attachments, where at least one script implements the attach() callback, the timing will be just right during logoff that you will end up with stuck presence for 5 minutes. This should no longer happen. http://lslwiki.net/lslwiki/wakka.php?wakka=attach

• The Mini Map: The same code that periodically records your presence presence also sends your viewer CoarseLocationUpdate messages, which contain a collection of objects and their coordinates at a 10 meter resolution. The viewer uses these rough coordinates to populate the mini map.

• llRequestAgentData(): Any LSL script that uses llRequestAgentData() with the DATA_ONLINE flag will use the presence cache on the simulator to find out if the target agent is online. This data can be stale. The simulator can cache it for up to 10 minutes.
  • Example script:

key owner_key;
key owner_online_query;
update()
{
    owner_key = llGetOwner();
    owner_online_query = llRequestAgentData(owner_key, DATA_ONLINE);
}

default
{
    state_entry()
    {
        llSetTimerEvent(60 * 10); // every 10 minutes
        update();
    }

    timer() { update(); }

    dataserver(key query_id, string data)
    {
        if (query_id != owner_online_query)
        {
            return;
        }

        integer online = (integer) data;
        string msg = llKey2Name(owner_key);
        if (online == 1)
        {
            msg += " is ONLINE!";
        }
        else
        {
            msg += " is OFFLINE!";
        }

        llSetText(msg, color, alpha);
    }
}

• Instant messages: When you send an IM to another user, the simulator looks up their presence information in the presence cache. If they are not found the IM is persisted in a data store, and optionally sent to their email account, and will be delivered to them on login.
  • If they are online, the IM is routed through the simulator that they are connected to.
  • This includes normal instant messages, instant messages from LSL scripts, busy auto responses (the response you receive if you IM someone who has set themselves to busy), and group notices.
• Inventory delivery: When you offer your friend an inventory item, the simulator uses the presence cache to find them. If they are offline, the offer is persisted in a data store, and they will receive the offer when they log in.
  • This is very similar to instant messages above.

• Group membership updates: If there are role changes made to a group, the viewers of all online members are notified so that they always have the latest state of the group.
  • If a user is offline, they don't need to receive these updates, because the viewer will get a complete snapshot of the state of the group on login.
  • Notification of rights grant: When viewing the profile of a friend, you can give them permission to:
    • See your online status
    • See you on the map
    • Edit, delete or take your objects
  • If you toggle any of these, the simulator will notify the simulator that your friend is connected to so that it is aware of the permissions change. Example:
    1. Your friend tries to find you on the map, but the "map" button is inactive.
    2. You grant your friend the right to find you on the map.
    3. Your friend tries again to find you on the map, but this time the button is active.