Difference between revisions of "Region Domain"

From Second Life Wiki
Jump to navigation Jump to search
(New page: ==How the region domain looks like== Image:SLGArchWG1-09-Region Domain.jpg A Region domains handles everything related to regions. The internal architecture is basically the same for...)
 
Line 3: Line 3:
[[Image:SLGArchWG1-09-Region Domain.jpg]]
[[Image:SLGArchWG1-09-Region Domain.jpg]]


A Region domains handles everything related to regions. The internal architecture is basically the same for [[Agent Domains]].
A Region domains handles everything related to regions. The internal architecture is basically the same for [[Agent Domain|Agent Domains]].


=== Region Services ===
=== Region Services ===

Revision as of 10:11, 15 September 2007

How the region domain looks like

SLGArchWG1-09-Region Domain.jpg

A Region domains handles everything related to regions. The internal architecture is basically the same for Agent Domains.

Region Services

SLGArchWG1-10-Region Services.jpg

Region Services handle stateless information about regions. This can be name, parcel information and so on. This can be cached and can be public.

Region Hosts

SLGArchWG1-11-Region Hosts.jpg

These are the things we know today as simulators. They handle all the in-world interaction between objects and avatars. They rely on Region Stores to obtain their data (be it parcel information, objects in the region and so on). Is a Region Host down, the region it simulated is not available.

Region Stores

SLGArchWG1-12-Region Stores.jpg

Region Stores hold the actual data about a region. This can be objects and their position, parcel information and so on.

Other Region parts

SLGArchWG1-13-Region Other.jpg

There are some further services needed which e.g. map the IP address of an in-world object.

How login works (part 2)

SLGArchWG1-14-Region Login.jpg

After the login in the Agent Domain has taken place, the process goes on with the login in the Region Domain.

  1. agent host contacts region service
  2. region service queries region store to obtain information about the region
  3. region service contacts region host to ask it to establish a session for the new agent
  4. agent host put in direct contact with region host (e.g. for getting the avatar)
  5. agent host returns region host to viewer (for direct communication)
  6. viewer now can talk to correct region host

Now this actually means that the Viewer itself does not decide to which region to connect. Or it might be part of the information send to the Agent Service in step 1 of the agent domain login process.