OpenSimulator:Introduction and Definitions - Revision history

Justincc at 17:17, 4 July 2011

2011-07-04T17:17:46Z

Makopoppo at 09:09, 4 June 2011

2011-06-04T09:09:10Z

Makopoppo at 11:10, 3 May 2011

2011-05-03T11:10:10Z

Mark.malewski: /* Technical Reference */ Removed improper spacing from "Turtle Track" navigation.

2009-05-21T20:49:11Z

‎Technical Reference: Removed improper spacing from "Turtle Track" navigation.

Ideia Boa at 20:40, 21 May 2009

2009-05-21T20:40:45Z

Mark.malewski: Added "See Also" heading with links.

2009-05-21T20:13:11Z

Added "See Also" heading with links.

Mark.malewski: /* UGAIM Services */ Updated hyperlinks to User, Grid, Asset, Inventory, and Messaging Server pages

2009-05-21T09:41:25Z

‎UGAIM Services: Updated hyperlinks to User, Grid, Asset, Inventory, and Messaging Server pages

Mark.malewski: /* UGAIM */ added the word "Services" after UGAIM

2009-05-21T09:36:13Z

‎UGAIM: added the word "Services" after UGAIM

Mark.malewski: /* Introduction to and Definitions of OpenSimulator */ removed the words "and Definitions" from heading.

2009-05-21T09:35:08Z

‎Introduction to and Definitions of OpenSimulator: removed the words "and Definitions" from heading.

Mark.malewski: /* Introduction to and Definitions of OpenSimulator */ Updated text, and removed references to LindenLabs

2009-05-21T09:33:25Z

‎Introduction to and Definitions of OpenSimulator: Updated text, and removed references to LindenLabs

← Older revision		Revision as of 17:17, 4 July 2011
Line 3:		Line 3:

	=Introduction to OpenSimulator=		=Introduction to OpenSimulator=
		+
		+	{{Warning\|This information is severely out of date. Most of the servers you see below are now services that run in a ROBUST shell. See [[Configuration]] for more details.}}

	The OpenSim project is an extensible platform which can simulate virtual 3-dimensional spaces. These virtual spaces can allow for the dynamic creation, modification, deletion, and scripting of primitive objects -- some of which, when properly linked, instruct the 3D viewer application to render them in new ways.		The OpenSim project is an extensible platform which can simulate virtual 3-dimensional spaces. These virtual spaces can allow for the dynamic creation, modification, deletion, and scripting of primitive objects -- some of which, when properly linked, instruct the 3D viewer application to render them in new ways.

@@ Line 1: / Line 1: @@
 __NOTOC__
-{{Template:Quicklinks}}
+{{Quicklinks}}
-<br />
-−
-== [[Technical Reference | Technical Reference]] ==
-−
-[[Technical Reference | Technical Reference]] -> [[Technical Reference/terms | Terms]] -> [[OpenSim:Introduction_and_Definitions | OpenSim: Introduction and Definitions]]
 =Introduction to OpenSimulator=

← Older revision		Revision as of 11:10, 3 May 2011
Line 71:		Line 71:
	[[Category:Development]]		[[Category:Development]]
	[[Category:Todo]]		[[Category:Todo]]
−	~~[[Category:Proposal]]~~

@@ Line 5: / Line 5: @@
 == [[Technical Reference | Technical Reference]] ==
-[[Technical Reference | Technical Reference]] -> [[Technical Reference/terms | Terms]] ->
+[[Technical Reference | Technical Reference]] -> [[Technical Reference/terms | Terms]] -> [[OpenSim:Introduction_and_Definitions | OpenSim: Introduction and Definitions]]
-−
 [[OpenSim:Introduction_and_Definitions | OpenSim: Introduction and Definitions]]
 =Introduction to OpenSimulator=

← Older revision		Revision as of 20:40, 21 May 2009
Line 1:		Line 1:
		+	__NOTOC__
		+	{{Template:Quicklinks}}
		+	<br />
		+
	== [[Technical Reference \| Technical Reference]] ==		== [[Technical Reference \| Technical Reference]] ==

@@ Line 38: / Line 38: @@
 In grid mode, the UGAIM servers are all run as centralized grid services.  All of the users have to be known by all regions, for example, and also have to interact with the Grid itself (which is defined, somewhat arbitrarily, as a 2-dimensional map akin to township and range specification for real property).  The region keeps a temporary cached copy of assets (currently set to 24 hours), but not a permanent local copy of its assets.  Other entities such as users, messages, or inventory aren't peristently cached.  In fact, region servers will opportunistically cache many things to reduce perceptual lag for the client.
 [[Category:Support]]
@@ Line 45: / Line 68: @@
 [[Category:Getting_Started]]
 [[Category:Development]]

@@ Line 17: / Line 17: @@
 Each of the servers plays a very specific -- and vital -- role in the OpenSim system.
-'''UserServer''': This is the server responsible for authenticating the user to the grid.  What this means is that it is responsible for a very important task: it creates a session identifier for the client which can be used to authenticate requests to the other servers in the same grid, and associates that session identifier with a UUID.  (This may involve a cryptographic authentication, OpenID authentication, or even the current Resident Name/Password authentication.)
+'''[[UserServer|UserServer]]''': This is the server responsible for authenticating the user to the grid.  What this means is that it is responsible for a very important task: it creates a session identifier for the client which can be used to authenticate requests to the other servers in the same grid, and associates that session identifier with a UUID.  (This may involve a cryptographic authentication, OpenID authentication, or even the current Resident Name/Password authentication.)
-'''GridServer''': This is responsible for authenticating something else to the grid: the regions.  Because the grid is 2-dimensional, and because there are X,Y coordinates that each region thus has, it is necessary to ensure that particular X,Y coordinates are assigned properly (whatever 'properly' means to the grid in question -- but OpenSim's current default is to do two-way authentication with the region servers, based on a dual shared-secret scheme (called "incoming password" and "outgoing password").  Each region is assigned a UUID.
+'''[[GridServer|GridServer]]''': This is responsible for authenticating something else to the grid: the regions.  Because the grid is 2-dimensional, and because there are X,Y coordinates that each region thus has, it is necessary to ensure that particular X,Y coordinates are assigned properly (whatever 'properly' means to the grid in question -- but OpenSim's current default is to do two-way authentication with the region servers, based on a dual shared-secret scheme (called "incoming password" and "outgoing password").  Each region is assigned a UUID.
-'''AssetServer''': This is essentially a WFRM database (write few, read many).  Once an asset goes in, there are two things that you can say about it: One, it's got a UUID as a label... and two, it's in for life (although in future OpenSim development, unused assets may be detected and reaped).  Sounds, textures, images, notecards, scripts, serialized inventory objects are added, and never modified again (they're "immutable").  If you decide that you need to change a graphic to be two pixels left of where it is for your virtual house's trim to look right, you have to upload a new asset, which gets a new UUID, and associate that new UUID with the texture.  The old one stays there forever.
+'''[[AssetServer|AssetServer]]''': This is essentially a WFRM database (write few, read many).  Once an asset goes in, there are two things that you can say about it: One, it's got a UUID as a label... and two, it's in for life (although in future OpenSim development, unused assets may be detected and reaped).  Sounds, textures, images, notecards, scripts, serialized inventory objects are added, and never modified again (they're "immutable").  If you decide that you need to change a graphic to be two pixels left of where it is for your virtual house's trim to look right, you have to upload a new asset, which gets a new UUID, and associate that new UUID with the texture.  The old one stays there forever.
-'''InventoryServer''': That's all well and good, of course, but if it's all jumbled up into a key-value database like that, then what's the point?  How could you keep anything straight?  The UUID may be great for a computer, but it doesn't have anything to do with a human-readable label -- and how does it keep track of where I put it?  That's the job of a much different database server -- one designed for a lot of little writes and a lot of little reads.  This is the Inventory server.  It works by -- you guessed it -- linking UUIDs together.  The User has a UUID, which is used to get his InventoryRoot folder's UUID, and the InventoryRoot has a list of UUIDs that it links to, and each of those that are folders have lists of UUIDs, and those that aren't contain a link to a UUID, a type, and a descriptive name for the asset.  The inventory server also retains permission information about items in inventory.
+'''[[InventoryServer|InventoryServer]]''': That's all well and good, of course, but if it's all jumbled up into a key-value database like that, then what's the point?  How could you keep anything straight?  The UUID may be great for a computer, but it doesn't have anything to do with a human-readable label -- and how does it keep track of where I put it?  That's the job of a much different database server -- one designed for a lot of little writes and a lot of little reads.  This is the Inventory server.  It works by -- you guessed it -- linking UUIDs together.  The User has a UUID, which is used to get his InventoryRoot folder's UUID, and the InventoryRoot has a list of UUIDs that it links to, and each of those that are folders have lists of UUIDs, and those that aren't contain a link to a UUID, a type, and a descriptive name for the asset.  The inventory server also retains permission information about items in inventory.
-'''MessagingServer''': This one came later, and it's not quite as essential as the first four.  However, if you want the people using your simulator to be able to communicate with each other via anything other than the creation of sky-writing primitive letters, you need this.  This keeps track of who's supposed to be able to listen to whoever else, keeps track of long-distance messages sent from one user to another (think 'SMS' for a real-world analogue), and keeps unread direct messages until they're read (also very much like SMS).
+'''[[MessagingServer|MessagingServer]]''': This one came later, and it's not quite as essential as the first four.  However, if you want the people using your simulator to be able to communicate with each other via anything other than the creation of sky-writing primitive letters, you need this.  This keeps track of who's supposed to be able to listen to whoever else, keeps track of long-distance messages sent from one user to another (think 'SMS' for a real-world analogue), and keeps unread direct messages until they're read (also very much like SMS).
 All of these servers are important, and because they're so important, they all share a specific property: There Can Be Only One (of each, known to any given region).

@@ Line 13: / Line 13: @@
 Based on the original design of the Linden Lab network, there are five major services which need to be provided to any region that wants to talk to the OpenSim viewer.  These services are known by the acronym UGAIM -- User, Grid, Asset, Inventory, Messaging.
-==UGAIM==
+==UGAIM Services==
 Each of the servers plays a very specific -- and vital -- role in the OpenSim system.

@@ Line 9: / Line 9: @@
 The OpenSim project is an extensible platform which can simulate virtual 3-dimensional spaces.  These virtual spaces can allow for the dynamic creation, modification, deletion, and scripting of primitive objects -- some of which, when properly linked, instruct the 3D viewer application to render them in new ways.
-As a demonstration of the power of this platform, it is coded in its default configuration to be compatible with the Second Life viewer application, released under GPL by Linden Lab.
+As a demonstration of the power of this platform, it is coded in its default configuration to be somewhat compatible with the Second Life viewer application, released under GPL by Linden Lab.
-Pretty consciously using the original design of the Linden Lab network, there were five major services which needed to be provided to any region that wanted to talk to the Linden viewer.  These are known by the acronym UGAIM -- User, Grid, Asset, Inventory, Messaging.
+Based on the original design of the Linden Lab network, there are five major services which need to be provided to any region that wants to talk to the OpenSim viewer.  These services are known by the acronym UGAIM -- User, Grid, Asset, Inventory, Messaging.
 ==UGAIM==