There is a new diva distribution available. It is packaged out of the bleeding edge OpenSim, revision 11056. If you have the previous release installed, you can simply run Update.exe.
In the past 2 weeks there has been a lot of plumbing in OpenSim, and things have improved considerably. First and foremost, we have identified and eliminated a memory leak that was causing OpenSim to use all memory over time, and eventually crash. Now OpenSim runs on much more reasonable memory footprint, and stays within that limit [for much longer].
Second, we have rewritten the grid service from scratch. The grid service is the part of OpenSim that manages region registration and lookup. All OpenSim installations have a grid service, even if they are standalones. In fact this distinction between standalone and “grid mode” is becoming fuzzier and fuzzier. So much so that it is now possible to have grids by stitching together standalone installations of OpenSim — without having to run any other servers!
Here are the instructions for how to do it with the diva distro. Instructions on how to do it with stock OpenSim can be found elsewhere.
Instructions for setting up a serverless grid with the Diva distro:
1 – If you want the second instance on the same machine, copy the entire folder of your diva distro into another folder on that machine. If you want the second instance on another machine, copy it to that other machine. Leave the original unchanged. In the copy (or copies), do the following steps.
2 – Edit Regions/RegionConfig.ini, and change the following fields for each region: (a) the name; (b) the RegionUUID; (c) the Location; and eventually (d) the InternalPort. For example, in my case my first region in my original instance is:
[Diva’s World 1]
RegionUUID = “9ca5b0b5-0b1e-47b7-ac30-7e0230152de0″
Location = “6178,3371”
InternalPort = 9000
In the copy on the same machine I have:
[Diva’s World 5]
RegionUUID = “854a1e57-95f2-42f9-b3c7-2488e0e0bd92″
Location = “6176,3371”
InternalPort = 9004
A couple of important notes:
* Please use truly random UUIDs. Here is a site that generates them for you: http://www.guidgenerator.com/.
* In my case I wanted to place the new 2×2 megaregion to the West of my original megaregion. Hence the coordinates 6176,3371 on the first region of the copy — the X coordinate is 2 to the left, the Y coordinate is the same.
* Megaregions need to be specified like what they are in that file: the first region is the SW corner, the second is the NW corner, the third is the SE corner and the fourth is the NE corner. Make sure you preserve this order when you make the changes in their coordinates.
* The InternalPorts must be unique for each region, on each machine. In my case, my second instance is on the same machine, so I had to change it. If your second instance in on another machine you can use the same InternalPort numbers of the original megaregion.
Do the necessary changes for the other three regions on that file.
3 – Edit config-include/MyWorld.ini. The only thing you need to change here, if at all, is in the [Network] section, the http_listener_port. If your second instance is on the same machine, you must change this port — for example 9001; this port needs to be unique per instance, per machine. If your second instance is on another machine, you can leave it as is. In any case, leave the server urls as they are for the original instance.
Et voila!
Login as usual. You will notice that the SW corner of your original instance now has neighbours to the left. In principle, you can cross back and forth, and teleport between regions as normal. In practice, crossing between instances with megaregions is still under heavy work and may produce surprising behaviour. For example, crossing from the original SW corner to the copy SE corner may end up being an auto-teleport, or you may get stuck in limbo, etc. Don’t be alarmed, this is “normal” behaviour for the time being, and these quirks will be fixed in future releases. For the time being,whenever you want to switch instances I recommend teleporting between SW corners of the different instances — that works pretty reliably.
[…] Metaverse Ink » Serverless grids http://www.metaverseink.com/blog/?p=22 – view page – cached There is a new diva distribution available. It is packaged out of the bleeding edge OpenSim, revision 11056. If you have the previous release installed, you can simply run Update.exe. — From the page […]
This new release is fantastic! Thanks Diva.
I do have one question though… When I go into the Region/Estate settings and change the land textures those changes only apply to the first region of the megaregion layout. I cannot seem to change the land textures for the other three regions even when I’m hovering over them and try to change the region textures.
Any suggestions?
Thanks!!!
A quick thank you note, the update worked really well
and was so easy and quick. I need more time for testing but it looks like
I still have the problem with phantom prims more on that on the mantis
again thank you.
@Len that is a bug in megaregions. I don’t think it’s been reported, so you may want to file a mantis in OpenSim.
Thanks Diva. I just submitted a bug report for this as you suggested:
http://opensimulator.org/mantis/view.php?id=4235
Diva… I just followed your instructions and set up two standalone on the same machine with the minimum modifications to configuration you proposed (0 modification). First standalone (diva1) is running on port 9000 with NO modifications (just changed the password of opensim user).
Second standalone (diva2) is running on port 6000 and regions have been modified subtracting 2 from X coordinates, and renaming ports from 900x to 600x, UUID accurately regenerated.
Apart from the “usual” could not teleport. Your home-region could not be found which is STILL bothering me (I’m using hippo), it seems it is working connecting to diva1 and moving dropping objects to diva2.
I then tried the same on diva2 and it worked almost as good as the first. Apparently after some “setting here as home” click on the viewer (or some crashes I don’t know) at the end something changed since now the home is on the bottom and a corner of a sim ((( definitely home location is apparently NOT handled ))).
BUT: there is still a lot that I’m missing and I need to have my mind very clear:
* Where are exactly the Inventory, Identity, Asset servers?
* How can you manage to have a real distributed architecture?
* How can 2 diva’s distro deployed in two different machines really share the same Identity server or even only the geographical grid connection?
All of this is still very confusing to me but I really am looking forward to seeing this working in our first Italian Anarchical distributed decentrated no-grid
Ah additional issue which is quite definitely important. If we were to build this as a real thing and not a lab test, we need to be sure that it is working with redux so that people is then able to register themselves.
This is why I asked for “where is the identity server” (maybe we can use the identity server already working in Cyberlandia, for instance?).
It is still very unclear how you can manage adding identities to this serverless grid without building a new standalone with a new Master Avatar, and create user in console appears at minimum “inconvenient”
Also, how this relates to voice and to group (and money) management?
I’m also going to write you an email, since this is really *too* importanto to find out a working thing
@salahazar: all the data is in the MySQL DB. All your standalone simulators point to that DB server & same DB, so they all share the same data.
This is the simplest, most standard way of sharing data between servers within an organization; this is how most large web sites work: several front-end web servers sharing the same DB server on the backend, possibly with a fault-tolerant and/or load balancing solution in between.
This works within the same organization, where the DB password can be shared. Obviously you can’t do that in a decentralized system involving multiple people/organizations — you can’t just publish your DB password. For that, you need other architectures.
Can grider help in dealing with inventory, identity servicing?
Also (and possibly even more importantly) what is exactly the role of grider? I’ve read a lot on proper pages and even installed it, but it is very difficult to understand (and explain) its utility.
When I tried to explain to Italian group that it wraps calls to remote inventory to enforce security they even objected that this might be an additional possibility for hackers to steal content
It’s me not understanding this…
My Diva distro grid updated flawlessly, and has been running since the initial release. Thanks so much Diva for your hard work! You are appreciated more than you can possibly know.