OpenSim Tech Basics: OpenSim is brought to you by the letters U, G, A, I and R

Hello there. This is the first in an irregular series of articles about some of the technological basics of OpenSim. Please feel free to suggest further topics in the comments, though as OpenSim is already large enough to make it difficult for a single person to understand, I might only be able to talk about a small proportion of them . This means I also take no responsibilty for the accuracy of these articles – even if they are correct right now, the rapid evolution of OpenSim might very quickly make them invalid.

I will be assuming a certain amount of OpenSim and general technical knowledge, though I hope to keep this to a minimum.

Anyway, today I want to talk about the letters U, G, A, I and R (also known as S). Apologies for the crappy graphics, by the way.

Don’t worry – I’m not going to launch into some extended Sesame Street metaphor. Rather. these letters represent the different ‘services’ in OpenSim. In order,

* U is the user service. This primarily handles user logins and logouts. This means that the user needs to be authenticated, and the region which is going to receive them needs to be told that they are coming.

* G is the grid service. When OpenSim is in a grid configuration (which we’ll talk about later on), it handles the registration of region servers with the grid, and is responsible for telling regions about their immediate neighbours. It also handles some of the main map functionality (which doesn’t work all that well at the moment).

* A is the asset service. This is a simple service which just retrieves and stores asset data (scripts, textures, sounds, etc).

* I is the inventory service. This is the service responsible for storing and updating your inventory folders and items.

* R is the region service (or Sim service). This is the big one – it contains orders of magnitude more code than all the other services. As you can probably guess, it’s responsible for actually providing an OpenSim region – so its major roles include handling the client sessions, managing the 3d environment and running scripts. It’s also responsible for telling a neighbouring region that an avatar is on its way when you cross a region border.

So why am I calling these things services rather than servers? This relates to the fact that OpenSim can be run in two configurations, standalone (or sandbox) and grid. In standalone mode, all these services are run as local code in the OpenSim executable. So when you open a script in a prim inventory, for instance, your client thread runs directly through the inventory code to find the asset UUID, then runs through the asset code to retrieve the script itself (ultimately from your local database). However, if you’re running on a region server in grid mode, the same action will

1. Query the local inventory information cache for the asset UUID. The cached information was itself retrieved from the grid inventory server when you entered the region.

2. Query the local asset cache for the asset. If the asset is there, it is returned directly. If the asset is a texture and it isn’t there, then we send ask the asset server for it and place the request on a queue. Once the asset server gives us the data, we take the queued request and use it to send the texture data back to the client. If the asset is not a texture, I have a suspicion we just wait a while to see if it comes in, rather than queueing the request (which is what we should be doing).

So as you can appreciate, what goes on in grid mode is rather more complicated than what goes on in standalone! And this is a major reason why grid mode can be rather unstable with our current alpha codebase. For instance, if when you cross into a region the inventory server fails to deliver your inventory and you then open a folder in your client’s inventory, the region server may tell you that there is nothing in that folder – it might seem that all your items have ‘disappeared’! If you then create new items on that region, there’s then a good chance that they won’t be properly stored in your inventory, and the next time you login, they will have disappeared. This problem is compounded by the fact that the Linden client caches the inventory, so unless you clear your cache – those items may seem to have disappeared permanently (even though they haven’t). We actually hope to address some of these problems soon (probably by popping up a big fat textbox telling you that your inventory has failed and that you need to relog .

Also, the current configuration of services, and perhaps the basics of the service architecture, will almost certainly change in the future. At the moment, we’re running with something called Open Grid Services 1 (OGS1). This is the first iteration of OpenSim’s grid and inter-region communications standard. However, Michael Wright (or MW), our dear founder, often talks about the need for an OGS2 (or possibly an OGS1.5). I don’t think there’s a firm idea yet of what this will contain, but among possible candidates are changes to make it easier to register custom services (not the U, G, A, I and R that OpenSim has pre-defined), and a move to abstract the standard away from the underlying communications transport.

As ever, watch this space!