Revision as of 09:42, 13 October 2014

Hyperlinks and Agent Transfers

When you establish a link between your opensim and another, a message is sent out to that other opensim requesting information about it; the required information includes the network information of that opensim host, and the coordinates of its first region on its local grid in the form of a region handle. For example, suppose you are linking node X.com:9000, placing it in your local map at 900, 900. That opensim runs one or more regions that likely are not in 900, 900 on their own map; suppose the first region of that opensim is at 1100, 1100. From your point of view, it doesn't matter what those other coordinates are, and you don't need to know -- that's the key to being able to decentralize the "world" as given by a 2D map; you want to place it in your map at 900, 900. The "true" position of that simulator only matters for the LL viewer, when there are teleports between your world and that other opensim. This mapping between coordinate systems is the essence of hyperlinks for opensim; it's one simple but critical thing that the hypergrid implementation does. The mapping happens on the TeleportFinish event; instead of sending the local coordinates to the viewer, the hypergrid teleport wrapper sends the remote coordinates.

When an agent teleports through that hyperlink the following happens. First, before InformRegionOfChildAgent, the local opensim notifies the remote opensim of this foreign user via the "expect_hg_user" method. That message sends along the addresses of all the servers that this user uses, i.e. user, inventory and asset servers. The remote opensim places an entry for that user in its local user profile cache but not in its user database; the foreign user information is non-persistent. After that, the teleport process is exactly the same as the normal teleport process; the only difference is that the region handles are switched between the remote region's hyperlink position on the local grid and its actual position on its grid.

In summary, the two new concepts introduced by the hypergrid are the concept of an hyperlink and the concept of a "local user" vs. "foreign user".

Inventory Access

Inventory access from a foreign grid is done by wrapping the existing scene-inventory interactions with additional code that gets or posts inventory assets from/to the user's asset server. When inventory is accessed, the hypergrid wrapper checks if the user is foreign and, if she is, the wrapper requests the necessary assets from the user's asset server. As with any fetched asset, these may be cached by the foreign simulator. From then on, the wrapper passes the control to the existing inventory access functions.

When something is added to inventory, the hypergrid wrapper is notified via an event, and posts the assets to the user's asset server. A cache of the exchanged item identifiers is maintained so that they aren't continually refetched.

The result is that hypergrided opensim instances end up interacting with several asset servers, instead of just one. That interaction is implemented in a by instantiating a GridAssetClient object for each foreign grid, instead of just the one used in non-Hypergrid OpenSimulator installations.

Asset Access

In a normal non-Hypergrid OpenSimulator installation, either

• the LocalAssetServiceConnector (for standalone) by specification in the [Modules] section of bin/config-include/Standalone.ini
• or the RemoteAssetServiceConnector (for grid) by specification in the [Modules] section of bin/config-include/Grid.ini

get registered to the scene (via Scene.RegisterModuleInterface()). Both these interfaces implement IAssetService. Other modules then retrieve this via the Scene.RequestModuleInterface<IAssetService>() call.

Under a Hypergrid configuration, HGAssetBroker is registered to the scene instead. This IAssetService implementation contains logic to work out if a requested asset can be served from cache, is a locally hosted asset or needs to be fetched from a remote grid, etc. Similar logic is present for other IAssetService methods (e.g. store).

HGAssetBroker also contains code to work out if any security configuration should prevent certain assets from being imported or exported.