« Preparing Inventory... | Main | GDC 2006 »

February 09, 2006

Comments

Mike

Fascinating stuff Phoenix. One thing I've not seen anywhere is an exact breakdown of how the grid works. I understand this may be a trade secret, but you guys seem OK to discuss it, and curious minds want to know!

So far we have:

* Sims. Run the physics, scripts, store prims, cache assets, track agent positions and update them as to the state of the world.

* Asset server. Rack of file servers (apache?) that serve up textures, scripts and various other static things, keyed by UUID. Does it also store inventories? I've seen a lot of references to this being a bottleneck but am suspicious - static file serving scales pretty well normally. Maybe one day people will be able to host off-site asset servers just for their sims of the grid.

* Userserver. I'll take a wild guess and say this authenticates logins and routes IM messages to users. Maybe it serves up users inventories and profiles too. Potentially being replaced by jabber server[s] in future?

* Spaceserver. No clue. The release notes said until now sim communication was routed via a central server, perhaps this is it? This looks likely given that it's about to be abolished. Alternatively perhaps the spaceserver is what links the sims together, so if the client wants to resolve the sim name "Whatever" or some co-ordinates to an actual server it uses this to get to sim225.agni.lindenlab.com.

* Central database. Probably tracks everything else: in world transactions, event/place listings, data used to calculate dwell, any statistics you collect from the client.

Then I bet there are a bunch of smaller servers to collect submitted bug reports, crash dumps, etc

So - just how far off the mark am I? Can you give us more details?

PhoenixLinden

Thanks for the interest. I wasn't sure anyone would even notice my post. :)

* Asset Server: This is a small stack of isiolons with many terabytes of hard disk space which are front-ended by a web server, and further cached on each host through a squid proxy.
* Userserver: In 1.8 and before, this was responsible for login handshaking and routing all user bound instant messages. In this preview - which will probably become 1.9 - this process only manages IM sessions including group IM.
* Spaceserver: In 1.8 and before this process managed spatial location of the simulators and routed network traffic between them and to the userserver. In 1.9 it simply coordinates neighbor sim connectivity.

and the biggest omission:
* Inventory cluster: There are currently 4 inventory databases. Most residents are on the most recent one. In recent development, this has shifted to resident specific information with no relations to any centrally stored information other than the primary agent relationship.

Ferran Brodsky

Hi Phoenix,

I love the fact the preview grids are open to the resident developers to test out their content, which in turn helps you guys catch bugs. I want to address one thing you mentioned.

> "Most of the changes should be well
> below the radar of detectable changes"

Now I know theres a lot that doesn't end up in the build / release notes for each patch that ends up getting discovered by a resident after the fact. i.e. res limit changes etc. and that can cause quite a fuss.

I also know it's not terribly wise to release all the build changes being tested on a preview grid while the main grid is running along side with the old code that is being reworked.

What I want to know is if there is anyway residents can be added to a trusted tester list or some such, or even make a request to be privy to the 'below the radar changes' that are not mentioned in the build/patch notes.

Because sometimes these seemingly subtle changes have a much larger impact than anyone would imagine.

Keep the preview grid stress tests and VekSpam(tm) alive

The comments to this entry are closed.