Kitto Flora deserves some major kudos for recent developments with OpenSim vehicles. Not only do they work, but the revised car script I toyed with earlier today – was actually quite usable; and dare I say it? good. All of this is thanks to Kitto’s work refining and improving the vehicle functions and how they interrelate with the internal ODE physics engine.

I could speculate here, and say if you were a decent vehicle coder – you could probably do some amazing things with OpenSim these days. So what happens if you combine these new vehicles, with Teravus’s recent mega regions code, and my sculpty terrain code (with mods from nebadon)? This. (Recommend jumping to about 4:40)

(Edit: Added a new link to the video – 22/09/09)

I probably do not need to go into too much detail here – the above is a 3_x3 megaregion, using 576 physical sculpts, Kitto’s latest ODE mods & vehicle script – running on a home users cable connection; with several people driving around at once. Not only does it work – it suprisingly works well. I expect a more skilled texture artist could pull some amazing things off with the sculpty terrain code – the terrain is just a quick output from L3DT done by Nebadon.

The vehicle code isnt in trunk quite yet – but if you ask around in #osgrid, I’m sure someone can point you to the github account where you can get the ODE patches. I’m sure much like mega-regions, it will be in trunk soon enough.

Credits: Kitto Flora (vehicles), Teravus (megaregions), Nebadon (video, hosting, testing, sculpty terrain), Bri Hasp & Hiro Protagonist (hosting & testing), Myself (sculpty terrain generator).

We’ve just launched our brand-new OpenSim & realXtend hosting service – at what we think are pretty decent rates. $49.95/mo gets you 1024MB of dedicated memory plus a dedicated processor core, including fully managed OpenSim support. James Stallings (a veteran OpenSim sys-admin and grid operator for OSgrid) is managing the operations side and providing full-time dedicated support for SimHost.

So what’s that price get you?

• Fully Managed Support (we’ll deal with sim crashes, and keeping your simulator alive.)
• Regular Updates of the official OpenSim Software (we know you like the latest shinies – so we can provide them)
• Good Quality Hardware – 1GB of dedicated memory + 1 Processor Core is our ‘minimum’.
• Warm fuzzy feeling that money you pay is going to feeding OpenSim developers (our profits are being reinvested in the platform)
• Grid Agnostic Connections – Run your own grid (Standalone), Connect to OSGrid or any other public grid. It’s your choice. We wont force you into our own private grid.

For a little bit extra per month, we have a premium plan that includes 4 regions, the option to use modular realxtend (modrex — not compatible with some other features, just ask us.) and the option for us to run versions that aren’t quite properly tested yet (they require more support on our behalf, hence the higher rate.) – such as megaregions and other more experimental features (we’ll need to talk with you about risks first though.)

If you input the promocode “ADAMFRISBY” (no quotes) you will get a bonus $5.00/mo off the pricing too. (So you can get our standard package for only $44.95/mo).

Web: www.simhost.com
Live & Ticketed Support: www.simhost.com/support

If you have any questions – feel free to contact support and they will be happy to answer them.

So that post on Megaregions ended up being a bit more popular than I imagined – resulting in a veritable torrent of ‘How do I enable megaregions?‘ requests both to my personal inbox, the #opensim-dev chatroom and the opensim-dev mailing lists. You can stop now. Here’s instructions.

It’s actually really simple if you are running the latest experimental code, however I need to prefix these instructions with a dire warning: this is very new code. The first prototype was done on August 28th.  It’s been a week and a half since then. Yes MegaRegions are an exciting bit of technology, but no – they are not that well tested, and yes there are bugs. More than usual. It was added to OpenSim as a undocumented feature because Teravus (in his right mind) didnt want to inflict it on the masses until it had at least a modicum of testing among more experienced users.

There are known issues at this stage – do not attempt to convert an existing array of regions into a single Megaregion without taking a full backup first (apparently there are issues there too) – if you still want to go ahead and check this out; you need to be running a relatively recent Git release of OpenSim (warning: there be dragons here already), into your OpenSim.ini add the line “CombineContiguousRegions=true” under the [Startup] section, eg:

[Startup]
CombineContiguousRegions=true
...

The regions need to be contiguous (that is already bordering), and you need to order the regions in your Regions.ini in a Left-to-Right, Top-to-Bottom (Correction: South-to-North, West-to-East) order. Failing to order the regions will cause the combiner to fail (new code. known issues.); it is recommended to make new regions for the purpose of this exercise. Otherwise, this is a fairly simple process to those already aquainted with setting up OpenSim regions. Credit goes to Teravus for the original implementation.

Grid etiquette right now suggests it is best to not connect megaregions neighbouring to non-megaregions for the moment, as they may introduce instabilities into your neighbours. (eg, pick random numbers for your starting coordinates). While you can connect megaregions to grids such as OSgrid, please do so away from the main continents. For loading a terrain across all the regions, I recommend investigating the “terrain load-tile” command, which allows you to import multiple regions worth of terrain from a single image. The above terrain was generated off a 2048×2048 F32 RAW produced by World Machine.

One of the single most common requests for OpenSim has been “I want bigger regions” – coming originally from an ActiveWorlds background, I wholeheartedly agree.

Space is still a major constraint – and while OpenSim allows you to run multiple regions within a single simulator – it’s a poor comparison because crossing region borders, even within the same machine are a complicated and error-prone process; requiring the client to disconnect and reconnect at least once. This preventing any kind of “instant” handoff on a technical level. Megaregions are a new bit of code that solves this problem by side-stepping it (a.k.a cheating).

Regions within the same simulator process can be ‘combined’ via the new RegionCombinerModule; to the client all the regions that existed in the server previously become ‘neighbours’ rather than full regions in their own right; while the original region takes authority over the combined original space. Objects get coordinates that no longer resemble 0,0-255,255, they now can reach values such as “1077,2099″, and likewise your avatar and any positional coordinates you see reflect this new larger domain.

The result is you can use these combined regions to make ‘megaregions’ that exceed the original 256×256 bounds. I personally have tested both 512×512 and 2048×2048 regions (comprised of 4 and 64 original regions respectively) and it is awesome. For vehicles I can see this being a very impressive and useful new feature – eliminating border crossings makes for bigger racetracks and faster speeds. Sailors can build oceans that aren’t equivilent to a lake-in-the-backyard, and if my estimate of 5MB per empty region holds true at scales larger than 64 regions in size; then it’d be possible to build a 4km x 4km ocean on a server with less than 2GB of RAM (equivilent to about 256 sims normally).

Pictures are of course essential for this post – the first picture below has me selecting a 65,536sqm parcel for comparison — everything you can see in the picture is but a small fraction of a single region. (11 cells are visible, of a total of 64)

…and a slightly larger picture of the same sim showing a few more cells at once.

Finally, I recorded some video of vehicles playing around on one of these megaregions (from a slightly earlier version when the largest regions were a bit smaller). This is in OpenSim trunk now; however it does have some known issues – so I wouldnt do anything resembling production work on this code for a long while until it has been more properly tested. I’d like to do some more testing with this and vehicles at a later date however, as OpenSim/ODE’s support for vehicles has improved dramatically in the last few months.

Connecting a region to OSGrid is a rewarding experience – many users however run into the difficulty of instructions being out of date; and while this set too will eventually go stale – they should at least be current for the next few months. Before getting started – you need to decide on a few things; information about your region (what to call it, where to put it on the map), where you will host it (at home, or on a dedicated server)

OSGrid is a free OpenSimulator network – connecting a region and using the central services is done free without charge (however donations to keep the infrastructure running are appreciated.)

First – this guide assumes Windows, and also assumes you are hosting from home. Users running in more professional setups will need to adapt accordingly. You may be able to skip a large portion of this setup procedure, by using the automated ‘OSGrid Region Launcher’ utility, you can download a copy of this experimental tool from the OSGrid Website; however this has not been confirmed to work with all users (nonetheless, I recommend it as a first step).

Preparing your region

Before we undergo the region setup process, you need to know your internet facing IP address, have setup appropriate port forwards. OpenSimulator by default will use Port 9000 on TCP and UDP; if you are behind a router you need to forward these ports to the machine that will be running the simulator instance. If you don’t know how to do this – see experimental tool listed above; or consult instructions for your router. You will also need to configure your router to enable ‘NAT Loopback’ – some support this by default, some don’t. If yours doesn’t, you may be out of luck and will need to host somewhere else (see my article on that topic).

You will need to gather two bits of information about your hosting environment, first is your internet-facing IP address – if you do not know it, visit this page. The second is some spare coordinates on the OSGrid World Map. If you don’t know them (or dont care to work some out), you can use this page here. Record both of these bits of information, because you will need them in a moment.

Download a copy of the OSGrid Package. It’s usually about 40mb, and can be currently found at this address: http://www.osgrid.org/elgg/pg/utilities/software

Unzip this package; and look for ‘OpenSim.32BitLaunch.exe’ – ignore the other files within the directory (regardless of whether you have a 64bit or 32bit system) – right click on it, and hit ‘Run As Administrator’; text will scroll by for a little while, then you will be asked a series of questions, in the format “Question Name [default]: _” – the following is how to answer these questions.

Questions

• New Region Name []:
  This is the name of the region that you want, it should be less than 64 characters long – and cannot conflict with any existing registered region.
• Region UUID[random]:
  You can ignore this, just hit enter.
• Region Location [1000,1000]:
  Enter here the region coordinates you wrote down above – exactly as printed in the ‘autocoord’ web page – that is, two numbers with a comma between them and no spaces. (The first number is the X coordinate, second the Y)
• Internal IP address [0.0.0.0]:
  Hit enter here – 0.0.0.0 means use ‘any availible IP’; this should be your choice unless you know better.
• Internal Port [9000]:
  This should be 9000, hit enter to use the default.
• Allow alternate ports [False]:
  If you are using port forwarding, leave this setting as ‘False’ and just hit enter.
• External Host Name [SYSTEMIP]:
  For this setting you need to put in your internet-facing IP address (or DNS address); you can use the exact output of the page listed above.
• Master Avatar UUID
  Skip this setting – just press enter.
• Master Avatar First Name
  Enter the first name of your avatar name here – my Avatar Name is “Adam Frisby”, so here I would enter “Adam” (no quotes)
• Master Avatar Last Name
  Enter the lastname of your avatar – eg; “Frisby” (again, without quotes)

With a bit of luck, your region should have registered with the grid and is now accessible. Login to the grid, and try teleport to your region via the world map. If it connected successfully; then that is all you need to do – your region is now online.

Chances are however, something went wrong.

Troubleshooting

The following are the common sources of problems when hosting a region from home

• “Remote Destination Timed Out”, or “Remote Destination is not responding”
  This error means that your port forwarding was not done correctly; and that the grid services were not able to connect to your region on the TCP port. Double check your port forwarding, and that your external hostname is correct.
• “Could not connect to region“, or “(done)“, or “Despite our best efforts, something has gone wrong“.
  This is a more insidious error, it means the grid was able to contact your region server on the TCP port, however the client was unable to contact your region server – double check your port forwarding and check that you have NAT Loopback enabled. If it still gives you problems; your router is incompatible with OpenSim – you may want to read this article on the opensim wiki for additional pointers.

I wanted to take a few moments to publically reply to Linden Lab’s recent changes to content management policy. I think overall it is a step in the right direction; however one subsection of the policy leaves me with grave reservations – the suggested standards for backup utilities. To quote from the original posting on this subject:

To those developing copying tools, we urge the simultaneous development of standard industry practices that protect against intellectual property infringement. For example, consider the following standard practices for tools copying content from Second Life:

1. Check that the user of the tool is the Second Life “creator” of the content;
2. Do not facilitate the export of an entire Second Life inventory; and
3. Preserve the Second Life “creator” name and information that the content was originally created in the Second Life virtual world.

To summarise in other words, “You may only export content you created, and only if you label them as something you created in Second Life first, with your second life avatar name; and you cannot back up your whole inventory at once – you must do so piecemeal.” – every single one of these restrictions eliminates a large swathe of legitimate users and uses. Let’s go into them in detail.

Check that the user of the tool is the Second Life “creator” of the content

You have now eliminated all the content that is explicitly marked as compatible off-grid; everything licensed under creative commons or Open Source licenses, everything in the public domain. While I concur with ‘Full Permission != Permission to Export’; there is no way right now of programmatically indicating whether you want to allow content to be exported — however there are ways of legally indicating it, such as license files, README notecards, et al.

While Full Permissions are not an ideal situation – the overlap between content allowed off-grid, and full permission freebies is significant enough that a full permission check is a acceptable compromise. I personally would say ‘Full Permission OR Creator’; as both indicate a high level of permissiveness with the content itself (and the creator should always be able to export their own content). It is worth noting that Second Inventory (the popular backup tool) has been using ‘Full Permission’ as its own metric for over a year now; with I believe mostly acceptable results (it is not used as an infringement tool – the infringement part is always done by a illegitimate tool first).

Do not facilitate the export of an entire Second Life inventory

Hello.

The only possible reasoning for this I imagine is simply to prevent competition – by allowing full inventory export; you make it easy to translate content you developed from Second Life, to the numerous third party grids. If someone high profile wants to leave for one of these, these tools definetely help streamline the process. With 50,000+ downloads of the OpenSimulator software since December – I suspect there is an alterior motive for this ’standard’ that is not related at all to helping content creators; infact I cannot see a reason at all where this helps Content Creators.

The unintentional targets of this are now people who perform inventory backups – the Second Life Inventory server is about 99.99% reliable – which means 1 in 10,000 users can expect to lose their whole inventory, and 1 in 10,000 items will mysteriously vanish over the course of a year. There are reasons why Second Inventory market themselves as a backup tool for the unreliable asset & inventory services – and it is distinctly related to deficiencies in the platform itself.

As far as I can tell, this rule makes backups harder – which hurts content creators, because legitimate backup tools are now out of the question. It’s also saying something about the supposed ‘You own your IP’ line Linden Lab has been stating for the last 7 years. If we own our IP, how can you state what we can do with it?

which brings us to…

Preserve the Second Life “creator” name and information that the content was originally created in the Second Life virtual world.

Many probably want to be able to do this optionally; but it is not a mandatory feature. Mandating this indicates that you do not have control over your IP – because Linden Lab is going to demand attribution to Second Life. We at DeepThink developed a whole bunch of content over the last 2 years for use in both Second Life and OpenSim – I dont want that attributed to our content creation account, I want that attributed to:

DeepThink Pty Ltd. <www.deepthinklabs.com> – Copyright©2008, See attached license for licensing information

and not…

Adam Zaius – Second Life

Forcing the latter is stupid, and less effective than the former. The latter does not hold any form of copyright, it does not imply any license – and it does not imply any contact information for the creator or copyright holding entity [especially if they leave SL]. The tools should include the capability to add attribution metadata, and maybe they can default to showing a Second Life name (eg ‘Adam Zaius inSL’) – but ultimately, *I* want freeform legal attribution – which carries a lot more weight in the real world, where copyright matters.

This personally reeks of an disingenous alterior motive – particularly the last bit (Created in SL) – I’m very skeptical that Linden Lab would be able to legally enforce this; Textures and other assets have no ‘creative’ input by Linden Lab. The procedural primitive modelling may have some effect, but since a process is not legally creative – I dont believe the procedural algorithms themselves contribute creatively to the final work significantly enough to give Linden Lab joint copyright — although a legal experts opinion is definetely required here.

Ultimately, I think this is a counterproductive effort.

While I think this came from a earnest and honest discussion internally at Linden Lab – I dont believe it has any real world capacity to solve any real problems. Second Life needs a permission system that is capable of indicating an export permission. It should be clearly marked ‘Allow Export’; and be tied hand-in-hand with full permissions (so you can only check ‘Allow Export’ on existing full permission content — this way people are under no pretenses)

It’s not an ideal solution to the permission model’s deficiencies – but it would be a much better start than the three listed above. Since permissions are implemented as a 32-bit bitflags on the backend, and 28 bits are currently unused, implementing this would require no significant database or architectural modifications to Linden Lab’s backend (if anything it is just a viewer modification.) – it would be a very simple modification to make.

As a administrator on the most popular alternate grid – I dont want content on the grid that doesn’t belong. Infact we do spend a great deal of time making sure that our freebie locations and newbie content is all legitimately licensed (tell us if you find something that isn’t!), and the original creator intended the content to be there; anything that simplifies that process has my wholehearted approval.

Illegitimate content is not just irritating to deal with, it is also a legal minefield – we do have a DMCA process for OSGrid, and we’ve got some pretty sophisticated ways of removing every instance of an asset off the core servers, but it is a painful and annoying process. DMCA takedowns require certain legal procedures to be followed to the letter – which makes things a liability if they are done wrong; and there are significant extra considerations for non-US residents and servers.

Speaking with four hats on – that of a Grid Admin, Software Developer, Copyright Holder and Consumer – my firm response to this proposal is ‘go back, and try again.’ – because it’s not satisfying the requirements; and won’t do squat to solve the problem of content piracy; infact it will likely have the opposite effect where legitimate tools are handcuffed, and users favour of ones of illegitimate design.

There are good solutions to this problem, and I’ve got a proposal of my own in the works (one that I have been working on for a number of weeks already) – but these ‘Standards and Practices’ are complete hogwash; and degrate creator rights by imposing restrictions on what creators can do with their own content.

A non-OpenSim post for a change. This time on HTTP SSL certificates and the people who think self-signed certs are actually doing something.

I see this a lot on places like Slashdot, people’s blogs, mailing lists, etc. “SSL Certificates are worthless, self-signed certs are perfectly fine, Verisign are a rort charging money for nothing.” – and it’s completely false.

Simplified, SSL certificates consist of two main security properties – property #1, they facilitate public key encryption, which secures the transmission between you and a foreign entity from interception by a third party, and property #2 – they verify that the foreign entity on the other end is infact the server you want to be transmitting data to (ie, they are who they say they are.).

Both of these principles work in tandem – each server certificate is signed by a higher authority who vouches for the identity of the bearer; they are “signed” using cryptographic principles which prevent them from being tampered with. If a trustworthy third party cannot verify the certificate; then you do not know that the other party is really who you want to send data to.

While verification of identity has slipped with the price of certificates; you can be assured that the provider has at least verified the requestor is affiliated with the domain in question (ie; you cant just go out and get a certificate in paypal.com’s name). The stronger certificates, such as “EV” certificates (which get a green browser bar in modern browsers) – still require a full identity check.

This means, when you see that little padlock and dont get a self-signed warning; you know that the server you are speaking to is at least affiliated with the domain in question.

Which brings us to self-signed certificates. These are missing that little bit of verification – and the problem is, encryption’s purpose is to hide data from untrusted third parties; however with self-signed certificates, you dont know who you are communicating with in the first place – and hence the encryption is effectively worthless.

It’s quite possible for an attacker to generate a self-signed certificate in an identical name to the self-signed certificate you made, and then ‘proxy’ the connection; seeing the encrypted data, with you none-the-wiser. The only way of telling them apart would be to examine the certificate fingerprint; however there are no real effective ways of validating the fingerprint of a site easily.

You might ask where would an attacker be able to do this kind of intercept if they didnt work at say an ISP between you and the server, and a very common answer would be wireless hotspots and public networks. The same techniques which allowed an attacker to replace every image served on the DEFCON conference WiFi network with Goatse are the exact same techniques that would allow you to do a SSL-interception on a self-signed certificate.

So no – while the faux-SSL would raise the difficulty level slightly; it is not securing the connection; only a certificate signed by a trusted independent third party is secure. That does not have to be a subsidiary of verisign – but it does have to be a group who provide enough identity verification that they don’t hand out certificates to anyone who asks for one.

The default trusted authorities (CA’s) included in most major browsers consist of groups who provide some degree of identity verification. The browsers decisions on which CAs to include are based on this principle more than any other.

This also means, when Firefox shows you a big warning saying ‘This site has a screwed up security certificate’ – take heed. It’s saying it for a reason; the site isn’t secure.

Edit: for those who still dont believe self-signed certificates can be forged quickly or easily, read this.

The single most misunderstood bit of technology in both OpenSim and Second Life is the thing called the asset server; while my understanding of the backend of Second Life’s asset cluster is limited (Squid+Isilon AFAIK) – my understanding of OpenSim’s is fairly comprehensive.

Let’s start with the basics – the asset server is a gigantic document storage server. In our cases, documents are things such as primitives, textures, sounds, avatars – the works.

Each document is referred to by a specific unique filename called a UUID – which is a 128-bit number (think 3 with 38 zeros behind it – big number) – a UUID looks something like this “d61c1990-79b9-11de-8a39-0800200c9a66″ when represented in hexadecimal notation. You have probably seen them around a lot – just using OpenSim or Second Life.

A UUID is an excellent choice for a filename; because you can make them up randomly and statistically guaruntee it hasnt been used before (the chance of a UUID duplicate for a good random UUID is about 1 in a very very very very large number). This means you can have multiple asset servers on the one grid – each upload can be given an ID randomly, without the need for a central authority to give them out.

They also optimize extremely well – each “bit” is a single yes or no question; to find out exactly where an asset is located, you can play a game of 20 questions, but in this case, with 128 bits – you can ask 128 questions. For example; finding which server an asset is located on, in a server farm with 4 machines (labelled 1,2,3 & 4) could be found with the following question chain…

1. Is the asset on a server labelled closer to 4 than 1? (yes – servers 3,4 still possibilities)
2. Is the asset on an odd numbered server? (yes – located on server 3)

Asset found on server #3. It’s not very long is it? Even with say 300 servers; you can find the answer within 9 questions. Some further searching is needed to be done to locate the asset on the physical disk itself; but even then you will be asking a very small number of questions – far less than the maximum 128 allowed.

To put this into a diagram, fetching an asset directly by it’s indexed UUID is equivilent to something like this:

Fig 1. How asset UUIDs divide and conquer

Given that computers are capable of asking and answering questions very very quickly (several billion per second); and that none of the above questions require a central server; you can expand your asset server farm in a fairly linear fashion without scaling constraints; providing that you structure your data appropriately.

128 questions also means that you can define very very precise questions; so many that if you created 100 trillion assets every second; the sun would be lifeless before you ran out of address space that can be answered by that many questions. (Although a piece of statistical mathematics called the Birthday Paradox does make the address space significantly less usable the closer you get to that point – but for other reasons)

At this point, we know how assets are stored and retrieved – files are uploaded into the server farm, and given a UUID; that UUID can be used to find out where the asset is located precisely, and return the data later. However, when you access an item off the asset server; there’s only a modest chance you are accessing the asset by it’s UUID directly.

A lot of the time, you will be accessing the asset through a layer of redirection called the Inventory Server – if you have a texture within your inventory; there are actually two components; the first component is the data itself (the asset), and the second component is the inventory shell (uploader, time uploaded, permissions, reference to the asset, etc). When you lose an item of inventory (such as during a transaction); it is often not the asset servers fault, but instead the inventory server.

The inventory server exists so that if you give a copy of a texture to a friend; you and that friend do not make a duplicate copy of the heavier portion (the asset) – both inventory items, yours and your friends will have the same underlying asset ID. This also means that copying an item within your inventory will not prevent it from being saved during a asset glitch (as both point at the same data).

In Second Life®, the inventory server is using MySQL (and probably InnoDB), and the asset server uses IsilonFS (a custom hardware appliance based system.); in OpenSim this will vary a lot depending on the providers configuration – most grids use a SQL backend for storing both assets and inventory. By default, OpenSim will use a small embedded database for both Inventory and Assets – called SQLite. For grids, we recommend something more robust.

In grid mode, MySQL is still an appropriate solution for Inventory; however asset data will often exceed the normal operating tolerances of MySQL and lead to frequent table corruption, table locking issues (which in turn make performance suck) and other nasties. No large grid should be using MySQL for assets (small home and private grids are however fine.)

Grids such as ReactionGrid which use MS-SQL can get a bit further than MySQL when storing asset data (for inventory they are fundementally the same); MS-SQL like most sane database engines, store BLOB data seperately in a BSP-Tree indexed system; this means they can scale up pretty far (although at about the point of clustering, things degrade.); Postgres can do the same – however as best I am aware, Postgres is not yet properly supported in OpenSim.

For bigger grids like OSGrid (where we have hundreds of gigabytes of assets) a dedicated solution is ideal – unlike Second Life, we cant afford to purchase high end NAS-equipment for our storage solutions; so we have built a distributed system called Fragstore which has two big features.

1. A configurable backend – it can use distributed storage systems (such as Project Voldemort or Hadoop), or export to a filesystem (which can be a distributed filesystem via projects like KosmosFS.)
2. A duplicate detection system – so files uploaded twice only get stored once.

The duplicate detection is achieved via a secondary layer of indirection; when we allocate a UUID, we hash the incoming data (256-bit SHA1) and store the UUID and the Hash into a small database table (currently MySQL based); when we recieve future uploads; if the hash matches, the result is only stored once on disk.

The final point I would like to touch on is asset transmission and security – assets are transmitted in both SL and OpenSim over HTTP; the reason this works and is secure is because the UUIDs used in the requests are unguessable. Even by a computer making millions of guesses per second; the chance of hitting a valid address is very very small (same probability as generating a duplicate UUID).

From the asset server to the region server, the request is something in the form of http://assetserver.com/<uuid>/data – which will return the asset in a encoded container (usually packaging a little bit more information about the asset such as the content type, etc.) – using /metadata instead of /data will get you a JSON-encoded package with a bit more information about the asset (creation date, specific asset type, etc.)

From the region servers to the users – this transmission can vary a little. In both SL and OpenSim, the region servers act as proxy caches for the asset server; because assets cannot be updated (and instead are replaced) – this works fairly well. If twenty users in a region see a texture – it only needs to be fetched off the core asset service once; because the region will send it twenty times to the users; rather than twenty users hitting the core server.

In the case of OSGrid, this means we have 2,500+ reverse proxies sitting infront of the asset server (albeit in a somewhat suboptimal layout.); it reduces the bandwidth on the core asset server by approximately 90%+ (you can see our asset stats here); which means we can get away with much lower operating costs (since asset delivery costs are shared with region operators).

Yesterday, OSGrid officially turned 2, at the opening presentation hosted by yours truly. OpenSim interrupted my presentation just once – at about 40 minutes into it with 53 avatars, Mono finally kicked the bucket. (It crashed again just after I had finished. Serendipity at work!)

We’ve been experimenting with Vivox, so the entire presentation was streamed via the new VivoxVoiceModule; running on the latest trunk code for OpenSimulator; both for the most part performed pretty admirably. A lot of the improvements from IBM and Intel lately into OpenSim’s packeting have been paying dividends. Mono’s previous concurrency “record” was about 40 users (for comparison .NET’s current record is 65).

So, what’s in store in the future and near-future for OSGrid? I had a couple of announcements at the opening presentation.

First – Hello General Store

The general store is the first “webshop” based on OpenSim that integrates directly into the grid itself. Listing of items, setting of permissions, etc are all done from within the viewer – directly integrated with your inventory itself.

This has one major advantage outside of the improved convenience – it means you do not need a region to mediate the transaction. Every transaction can be done directly on the inventory server (infact this is exactly what we do.); but what does this exactly mean?

When you create your general store – a special undeletable folder is created in your inventory called ‘My General Store’, items placed into this folder that are marked ‘Allow anyone to copy’ are listed on our website automatically, providing you are the creator of the item in question (and have copy/trans permissions on it).

Purchasing of items will have them sent to your inventory directly via the inventory server (although you will need to relog after a shopping trip for the items to appear.); saves a bit of time and effort doing the transfers – and you dont lose a transfer because you were in busy mode.

User Achievements

Many of you spotted our new achievements system located on the OSGrid website – it’s mostly a bit of fun right now (and probably will always be), but we are going to be opening achievements up to region operators across the grid. If you have something open to the pubic (some form of competition, game or other activity that is ‘achievement-worthy’) you can offer achievements as rewards.

The exact process is yet to be exactly finalised – but you will recieve a bit of LSL at the end you can include which allows you to award your achievements to specified users. There will be some caps on who is eligable to be able to award achievements (particularly so that people do not just set them up for friends)

“More information soon”

Acknowledgement of Direction

OSGrid has traditionally been a test grid for OpenSimulator – that has been good and bad – in our case however, we’ve definetely moved on from those roots – OSGrid today is now more of a social space than a testing one. As a group, the admin team has decided to acknowledge this as part of OSGrid’s long term direction – and include those aspects in our mission statement (while preserving our current roles too).

While the testing aspects will always be present, we’re going to be focusing on making the social aspects more useful; such as improving our events calendars and website integration features. We would definetely like to see more live events – and will help promote any regular events to our wider communities.

Some of these changes will be more profound, which is actually tied to…

Continents

We are going to be introducing two new continents into the OSGrid ecosystem; so there will be three major continents in total. For lack of a name so far, they will be ‘Terra Alphus’, ‘Terra Betus’ and ‘Terra Gammus’ (subject to change). The current continent centered around 10,000×10,000 is ‘Betus’; and will not be changing.

Alphus will be the most structured of the continents – and subdivided into three zones based on the server geography – US, Europe and Asia. Regions connected to Alphus need to be approved by a small committee, and subject themselves to a few construction limits. Alphus will:

• Consist only of regions on dedicated server hosts (or good quality VPSs)
• Have a reasonable uptime (that is they are significantly likely to be online)
• Follow a master terraforming pattern.

Regions in Alphus will be organised so that servers located in the US are grouped with other US servers; EU with EU and Asia with Asia — meaning border crossing between Alphus regions is a lot more likely to be successful. The goals with the Alphus area is to ensure a more consistent user experience [especially for new users] and can be thought of as a ‘grid within a grid’ of sorts.

Betus is the current continent – it’s not going to be touched (other than perhaps by a few regions moving into Alphus); the current strategy of nearly-anything-goes is not changing here. You can place your own regions in this section without any considerations at all.

Gammus is the final section, and also a new continent – this will be tied to our new highly experimental region launcher. Regions hosted from home using our launcher will end up here. Because these regions are less likely to be online at any given moment, we are conglomerating them together away from other regions – so that the other regions on the grid are not affected by constant neighbour checks.

In summation:

• Your current regions arent changing or moving. If you want to setup a new region on any random coordinates, that’s fine too.
• The new continents will be fairly close to each other in coordinate terms (within 500 coordinates; or within reasonable scroll distance)
• The goals of the introduction of the two other continents are to improve user experience (especially with border crossing, etc.)
• This is not a grading system; Alphus regions are not better than Gammus – only that Alphus voluntarily comply with a tighter set of user experience restrictions.

New Orientation Sims

We’re going to be working on some new orientation island sims with OSGrid; particularly to aquaint people with what OSGrid is and isnt. These are going to be seperate from our welcome area (LBSA), but we are going to look at ways we can integrate them together (such as providing a chat bridge with a helpers group, etc.)

Again, more information coming soon.