Pretty OpenSim 0.7 diagrams and updated grid setup instructions July 30, 2010Posted by justincc in hypergrid, opensim, opensim-dev, opensim-grid, opensim-tech-basics, opinion, secondlife, virtual-environments, virtual-worlds.
Hi folks. Just thought I’d let you know that I’ve once again undertaken the sisyphean task of updating the OpenSimulator configuration instructions 🙂 This time, I’ve updated the grid setup instructions to reflect the current situation in OpenSimulator 0.7. In fact, I wrote a whole new set of steps based on my experiences in setting up a very small multi-machine grid from scratch, so hopefully they should be reasonably accurate! Of course, any improvements are very, very welcome – feel free to just edit the wiki page!
I also included some diagrams to illustrate the basic differences between standalone and grid configurations. Here’s the standalone diagram.
As you can see, in standalone mode both grid services (login, assets, inventory, etc.) and the region simulator itself are contained within the same process (OpenSim.exe). Viewers simply connect to this one instance.
On the other hand, even a very simple grid setup is considerably more complicated.
In OpenSimulator 0.7 a process called Robust.exe runs all the grid services. Instead of using their own local services, each simulator (OpenSim.exe) connects to this common set of services, usually across a network. And once a network gets involved there’s considerably more to go wrong – simulators may encounter both network congestion and a delayed response from the central services if they’re overloaded with requests.
In grid mode, simulators also need to communicate with each other. For instance, since all regions are on a common grid, an avatar may teleport to a region running on another machine, or cross an in-world border between regions hosted on different computers. Both teleports and border crossings involve an intricate data handoff between the origin simulator and the destination simulator. The less reliable the network between the simulators, the worse the teleport or crossing experience will be. Naturallly, this is often worst in the case where these simulators are communicating over the Internet.
Another interesting thing to note about this diagram is that all communication between the viewer and the virtual environment (apart from initial login, which isn’t shown here) occurs through the region simulator that the avatar is currently in. This applies not only to things such as walking about and creating objects (both of which naturally belong there anyway), but also to operations such as inventory retrieval and texture fetch.
This is one reason why the current grid model is a centralized one, even though OpenSim instances themselves are distributed across different machines. Anyone wanting to add a new region simulator to a grid is forced to store their assets and inventory in the single set of services provided by that grid operator – they can’t choose some independent third party or provide their own data store. Equally, anyone adding a simulator has to be trusted by the grid operator since the guy (or gal) running the simulator potentially gains access to the assets and inventory of that grid.
That’s what makes efforts like the hypergrid, http texture fetching and VWRAP so interesting – I think that they’re all trying to lever open the door to a genuinely distributed, more web-like network of virtual environments. A network where anybody can set up their own simulator without requiring the trust of every other operator, yet receive visitors with the same ease that one can click on a web hyperlink today. A network where visitors retain their own appearance and are safe in the knowledge that the items in their inventory are not exposed to the simulator that they happen to be visiting (unless they rez them there). It’s a massive challenge but one that could really transform the landscape.
Anyway, enough architectural rambling :-). The OpenOffice draw source files for the diagrams above are linked from the configuration wiki page if anybody wants to use them further.