Difference between revisions of "Region Domain"
Jump to navigation
Jump to search
Tao Takashi (talk | contribs) (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...) |
m (→See also) |
||
| (8 intermediate revisions by 4 users not shown) | |||
| 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 === | ||
| Line 9: | Line 9: | ||
[[Image:SLGArchWG1-10-Region Services.jpg]] | [[Image: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 Services handle stateless information about regions. This can be name, parcel information and so on. This can be cached and can (but isn't required to) be public. | ||
* Avatar Positions | |||
** Rough avatar locations (green dots on map) | |||
** Requests from other Agents | |||
*** Mapstalking | |||
*** God / Support level | |||
* Object Information | |||
** MetaData (Name / Desc / For Sale) | |||
*** Searching | |||
** Task Inventory | |||
** Location | |||
*** Building map images | |||
** Region Statistics (FPS/Frame Times/etc) | |||
*** I think that currently this is 'pushed' upstream | |||
* Parcel Information | |||
** Name / Desc | |||
** Only Public if search enabled (opt in vs opt out) | |||
=== Region Hosts === | === Region Hosts === | ||
| Line 15: | Line 32: | ||
[[Image:SLGArchWG1-11-Region Hosts.jpg]] | [[Image: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 | These are the things we know today as simulators. They handle all the in-world interaction between objects and avatars, however Region Stores to obtain their data (be it parcel information, objects in the region and so on). If a Region Host down, simulated region will be unavailable. | ||
* Physics | |||
* Script Execution (if not compiling) | |||
* Local avatar/script chat | |||
=== Region Stores === | === Region Stores === | ||
| Line 21: | Line 42: | ||
[[Image:SLGArchWG1-12-Region Stores.jpg]] | [[Image:SLGArchWG1-12-Region Stores.jpg]] | ||
Region Stores hold the actual data about a region. | Region Stores hold the actual data about a region. | ||
* Object Information | |||
** Location | |||
** Shape / Texture | |||
** Link/Group Relationship | |||
** Inventory | |||
** MetaData | |||
*** Name / Desc | |||
*** Permissions | |||
*** Version specific information. Isn't Qarl working on an extra object field ? | |||
* Region Info | |||
** Permissions | |||
** Textures | |||
** Logs | |||
** Metrics / Stats | |||
* Parcels | |||
** Metadata | |||
*** Name / Desc | |||
*** Permissions | |||
*** Metadata | |||
** Search Settings | |||
=== Other Region parts === | === Other Region parts === | ||
| Line 33: | Line 75: | ||
[[Image:SLGArchWG1-14-Region Login.jpg]] | [[Image: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. | After the [[Agent_Domain#How_login_works|login in the Agent Domain]] has taken place, the process goes on with the login in the Region Domain. | ||
# agent host contacts region service | # agent host contacts region service | ||
| Line 43: | Line 85: | ||
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. | 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. | ||
== See also == | |||
* [[Proposed Architecture]] | |||
* [[Agent Domain]] | |||
* [[Multiple Domains]] | |||
* [[Central Services]] | |||
* [[Running at Home and Offline]] | |||
[[Category:Architecture Working Group]] | |||
[[Category:Grid_Interoperability]] | |||
Latest revision as of 15:39, 14 July 2008
How the region domain looks like
A Region domains handles everything related to regions. The internal architecture is basically the same for Agent Domains.
Region Services
Region Services handle stateless information about regions. This can be name, parcel information and so on. This can be cached and can (but isn't required to) be public.
- Avatar Positions
- Rough avatar locations (green dots on map)
- Requests from other Agents
- Mapstalking
- God / Support level
- Object Information
- MetaData (Name / Desc / For Sale)
- Searching
- Task Inventory
- Location
- Building map images
- Region Statistics (FPS/Frame Times/etc)
- I think that currently this is 'pushed' upstream
- MetaData (Name / Desc / For Sale)
- Parcel Information
- Name / Desc
- Only Public if search enabled (opt in vs opt out)
Region Hosts
These are the things we know today as simulators. They handle all the in-world interaction between objects and avatars, however Region Stores to obtain their data (be it parcel information, objects in the region and so on). If a Region Host down, simulated region will be unavailable.
- Physics
- Script Execution (if not compiling)
- Local avatar/script chat
Region Stores
Region Stores hold the actual data about a region.
- Object Information
- Location
- Shape / Texture
- Link/Group Relationship
- Inventory
- MetaData
- Name / Desc
- Permissions
- Version specific information. Isn't Qarl working on an extra object field ?
- Region Info
- Permissions
- Textures
- Logs
- Metrics / Stats
- Parcels
- Metadata
- Name / Desc
- Permissions
- Metadata
- Search Settings
- Metadata
Other Region parts
There are some further services needed which e.g. map the IP address of an in-world object.
How login works (part 2)
After the login in the Agent Domain has taken place, the process goes on with the login in the Region Domain.
- agent host contacts region service
- region service queries region store to obtain information about the region
- region service contacts region host to ask it to establish a session for the new agent
- agent host put in direct contact with region host (e.g. for getting the avatar)
- agent host returns region host to viewer (for direct communication)
- 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.