Mapping the OpenSimulator Architecture - Computer Science and ...

flashypumpkincenterΛογισμικό & κατασκευή λογ/κού

14 Δεκ 2013 (πριν από 3 χρόνια και 9 μήνες)

143 εμφανίσεις

Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


1


Mapping
the

OpenSimulator Architecture

Chris Dempewolf, Gregory Stafford, Seth Williams


A
bstract

The absence of collaboration and standardization among the diverse collection of virtual worlds
presents an interesting problem when exploring how they are related and how these worlds can
be integrated with one another.

Outdated documentation and a lack
of access to the architecture
of these worlds contributes to this obstacle and leave a large amount of information regarding the
structure to be discovered.

We target this problem by studying the intricacies of the
OpenSimulator software and proposing a g
eneralized
architecture for future virtual w
orlds.

Once this task is accomplished, we are then able to update the current documentation and
suggest a standard architecture that would enable various virtual worlds to become integrated as
a single environme
nt.

1.

Problem

Virtual worlds, being a nascent technology, have few standards and many are still in a heavy
development process.

In order to discover which standards, protocols, services, etc. are most
profitable for use in virtual world systems, one mus
t have a clear understanding of how they are
implemented and how this might be modified or how functionality could be added/removed to
meet certain requirements.

A mapping of the architecture of a popular virtual world system would be a good place to start
.

The source code to Second Life, being proprietary, is not available, thus we will be working
with OpenSimulator (OpenSim).

OpenSim is an open source virtual world platform that
“supports the core of SL’s messaging protocol” [1] and is, next to Second L
ife, probably the
second most popular virtual world platform.

2.

Objective

The objective of this project is to map the architecture of OpenSim, specifically starting with the
DBMS.

Our short term goals were to make a UML
-
like diagram of the DBMS (i.e.,
learn the
attributes of different tables and note their relations to one another) and discover where certain
tables are stored (i.e., client
-
side, server
-
side, are there multiple server
-
side DBMS?).

Then we
looked at the data structures to get an idea of
the functionality and programming modularity of
OpenSim.


3.

Related Work

Tom Censullo’s paper, “Tutorial:

Architecture for OpenSimulator,” [3] gave us a good idea of
the layout of OpenSim and the end goals of the OpenSim project.

In his paper, Tom des
cribes
the architecture of OpenSim as a layered
-
component architecture consisting of region, grid, and
application layers that separate simulator
-
level and interoperability
-
level functionalities. He goes
Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


2


on to describe the integral role that modularity pla
ys in OpenSim (i.e., each layer consists of
various modules implementing a certain functionality that can be added or removed).

These
modules interact with each other via common interfaces.

After that he explicates on the scene,
which augments the SceneB
ase (an abstract class) with methods and various services and which
he refers to as “the core of the region server.”

The OpenSim grid layer contains the “UGAIM”
servers (User, Grid, Asset, Inventory, and Messaging respectively) that provide inter
-
region
f
unctionality and include a basic HTTP server each.

These grid layers can be linked in a new
extension called the HyperGrid.


Josh Eno's dissertation, “An Intelligent Crawler for a Virtual World”, is closely aligned with our
research this semester.

The m
ain goal of Eno's dissertation is to learn how data in virtual worlds
is represented and how to make it publicly accessible on the “flat web.”

In it, he includes a
rough mapping of his OpenSim indexing crawler through his own speculative database schema.

We have reviewed this to get an idea of the scope of the OpenSim DBMS schema.

Ours,
however, will be based on empirical results based on the OpenSim DBMS schema and will
accurately reflect the current schema.

4.

Architecture
/Design

We began by research
ing related works and the OpenSim documentation to learn what other
people have discovered about OpenSim’s architecture and database.

While these works may be
outdated due to the fact that OpenSim is ever
-
changing, we wanted to be well researched so that
we may have some guidance in the proper discovery of the current implementation’s various
components and connectors.

The next step we took was to dive into the source code packaged with the current distribution.
Dividing the various modules amongst the var
ious project team members, we were able to
quickly piece together the various components of OpenSim’s architecture and obtain a high level
perspective of their interactions.


Some of this source code was not entirely applicable to the scope of this projec
t.

The Test and
TestSuite folders contain files which only test the different modules available.

The Tools folder
contains the configuration manager and the compiler for the system, as well as the code that
launches the SecondLife viewer.

The other fold
ers contain the files necessary for the operation
of the system after it has been launched.


The Client folder contains all protocols that the client can use in communication with the server.

Sirikata

is included in this folder as a library for virtual world communication protocols, while
VWoHTTP allows for the use of SLuRLs.

MXP (Multi
-
User Dungeon eXtension Protocol) is
also included as a potentially available communication protocol, one specificall
y designed for
worlds which include multiple users to ensure that all users in a given region will be receiving
updates on the state of the region or the avatars within that region simultaneously.

The Server folder contained files which initialized the ser
ver and handled requests from the
client side using the aforementioned protocols.

The Framework folder contains everything that will be visualized on the client side whenever
they are running the OpenSim viewer.

It specifies two different ways that the c
lient receives
information from the database: REST (Representational State Transfer) and SOAP (Simple
Object Access Protocol).

The RESTful architecture depends on the resources being passed back
Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


3


and forth, namely the states that these resources are in.

S
o, REST is used whenever the client
wants to update something in the system, like the elevation of the region’s landmass or the
clothing on an avatar (which actually exists as states for 14 distinct points on the avatar’s body).

SOAP is used whenever the
client wants to use the SLuRLs as a request to load a new region.

This is because RPC (Remote Procedure Calls) allow the user to send data back to the server
under specialized system calls that the developers needed to add.

REST, on the other hand uses
t
he existing methods of the HTTP to update and send information to the client or server.

From
there, we see the assets available for transfer between these two entities also present in this
folder.

The AssetBase file initializes new assets in the system,
given whatever properties that the
one developing the asset wants to give it.

This can manifest itself in a multitude of forms:
regions, objects, clothing, notecards, among others.

The Framework folder contains the
necessary information for each of these

types of assets.


The Region folder contains files necessary for visualization of the world in the OpenSim
console.

The files include all of the instructions used by the physics engine to simulate gravity,
wind, and movement of objects.

It also include
s the physical restrictions of a region like the land
height, depth, and regional boundaries.

Additionally, it holds the files necessary for the access of
regions via permissions, or of sections of regions via estate permissions.

It includes the World
Ma
p, complete with SLuRLs for other regions that the user may want to visit.

The Region folder
also contains files for the visualization of avatars.

All of the actions of an avatar are stored here,
including modules for dialog boxes, combat, and social ges
turing, along with all of the physical
attributes of avatars.

The AvatarFactory module allows the user to customize their avatar’s
appearance when they register with the OpenSim service.

The Attachments module allows the
user to add clothing and accessor
ies to their avatar’s appearance.

The service folder is in charge of setting up access to various services (asset, grid, inventory,
hypergrid, avatar, etc.) by means of URLs with REST as described above to the UGAIM servers
described by Tom Censullo [3].

It should be noted that all of this data is resources (i.e., data
about the current state) and that they are all stored persistently, so that different entities can have
access to them.

The Data folder contained files which were able to hook the server up

to a database and specify
how the server is meant to handle client requests.


While the source code contained within the Data folders gave us a general understanding of how
the database tables were related, we still did not have a complete listing of eac
h table’s columns
and the corresponding datatypes, default values, and attributes.

To obtain this information a
schema dump of our OpenSim server’s MySQL database was required.

This gave us a
comprehensive description of how objects are represented and s
tored on the server side.

The
foreign keys that relate the data objects to one another within the database were not explicitly
stated within the schema, which suggests that the developers of OpenSim were trying to save the
overhead of these restrictions w
hen performing a SQL statement.

Unfortunately this was a
setback in the analysis of the database architecture, but combining the past documentation, the
statements located within the source code, and common SQL practices we were able to create an
accurate

reconstruction of the database schema.

Figure 1
below
shows the extracted OpenSim database ER diagram, with only the columns
showing
direct relations to save space.

See Appendix I for all tables and attributes circa April
2011.
Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


4



Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


5



5.

Results

Related to Figure 1, t
he information we were able to extract from the OpenSim software gave us
a good insight to the general compo
nents used to store the data needed to represent objects
within the virtual world.

We conjectured that by breaking down the data store of a virtual world
into basic components we could then find similarities with other virtual worlds, and discover
differe
nces that are unlikely to be shared between them.

The OpenSim DBMS was broken down
into 8 different components:



Physical Space
-

the three
-
dimensional environments in which the users can navigate.



o

OpenSim physical space was structured to have a region
made of parcels, and
estate made of regions, and a grid that contained estates.

The estates were
generally physically different servers, but we felt that a virtual world should be
scaled depending on it’s application and could be implemented accordingly w
ithin
this component.



Physical Objects
-

graphical information used to represent physical objects within the
three
-
dimensional environment.

o

Avatar display was included in this component because it is an object in its most
basic form.

Although it is animat
ed and represents a user, it still contains
appearance and texture information as any other object displayed in a virtual
world would.

When discussing objects that are present but have no physical
appearance (e.g. wind, sound) there may be a ‘visible’ att
ribute that could define
these instances.



Identification
-

authorization information to uniquely identify a user and the verification
information.

o

While it is important to authorize a user securely for the virtual environment, it is
still important for a
user to be able to easily represent themselves in alternative
forms through the use of various avatars.

This functionality could be
implemented in a sub
-
component as it is the ‘virtual identification’ of the user,
while some applications of a virtual envi
ronment

may not wish to support this
functionality.



Assets
-

the objects held or owned by a single user, avatar, physical space, or social group
-

different forms of media.

o

A complication occurs when trying to link physical objects and assets.

There is
o
verlap between these two components that needs to be clearly defined.

We
suggest that the objects are passed completely from one component to the other
when the ability to do so is required.

For example. if a user wants to set a soccer
ball on the ground

for a quick game, he wants to pull it out of his inventory and
into the physical space as a physical object.

The item makes a transfer from the
Assets component to the Physical Objects while only retaining the information
describing the object owner.

Fu
rther exploration into proper solutions will be
required when trying to implement these components for standardization.



Social
-

social relations between various users.

o

This component tracks the data required to manage friends lists, group
information, or
any other social organization that may be required by the
Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


6


application.

This is undoubtedly an optional component by the fact that there may
be no social exchanges in the application.

A good example is a virtual world that
perhaps allows an avatar
-
less us
er, or viewer, to navigate the virtual solar system.

No social reactions are implemented or needed to achieve the purpose of this
system.

Another noteworthy fact is that the current OpenSim implementation
maintains the group lists through an external dat
abase via the floatsam group
module.

This is done to track the groups outside of each individual server so that
more users on various servers could be a part of these organizations.



Expansion
-

table to handle the synchronizing of the hardware components
required to
support the virtual world.

o

For OpenSim, the ‘griduser’ table was the only table to be contained within this
component.

This table synchronized the user authentication of the grid with the
authorization information of the individual servers.

A

service such as this will be
required if a virtual world wishes to expand and support a single virtual world
across multiple hardware components or to become part of another virtual world.



Mapping
-

the mapping tables required to handle ‘many
-
to
-
many’ rel
ationships.

o

In MySQL (the database we chose to implement and research with our OpenSim
server) a separate table is required to map a ‘many
-
to
-
many’ relationships.

This
component will be responsible for those mappings between components and
integrity check
s of the information being tracked.



Server Handling
-

tables required for server processing and network transmission.

o

The migrations and tokens table were included in this component as fine
examples of exactly what this component does.

It handles any data

storage that is
required to manage the functioning of the virtual world, but is not necessarily
represented within the world itself.

The migrations table is used to handle data
transfers between various version of OpenSim while the tokens table stores
cr
eation information of tokens that are used for network connections which are
possibly behind firewalls as a sort of ‘session’ token.

Both of these examples
shows that extra data storage may be required by a server even though it may not
respond to an obje
ct relative to a virtual world.

6.

Relation to Software Architecture Course Themes

Our project is related to the course at large because we essentially analyzed the whole of
OpenSim’s architecture from start to finish.

There are applications of everythin
g covered in the
course evident in the source code and in the overall architecture of OpenSim, starting with the
design process.

In multiple locations in the source code, there are empty functions or functions
filled with comments like “We need to do [som
e function] here, somehow.”

They went through
the feasibility stage, and worked their way through the preliminary design stage, where they
chose the most useful functions to work on first.

Then they went into greater detail on how they
were going to impl
ement those functions. Finally they worked through the planning stage, where
they realized that some of the functions that they wanted to implement were either unnecessary
or far overreached the scope of their abilities.

The OpenSim system operates through

several different kinds of connectors.

As evidenced
previously, the SOAP architecture uses procedure call connectors (in specifically remote
procedure calls) whenever they are invoked by the client so that only the necessary information
Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


7


can be passed fro
m client to server, and vice
-
versa.

Linkage connectors are used by the RESTful
architecture to insure that the information transferred does not lose its state in transit between the
server and the client.

The chat client that was implemented in the syste
m for users used stream
connectors to allow all users in a region to chat, or for “friends” to chat with one another
privately.

Separation of concerns is a major issue that OpenSim addresses.

The system allows several
different entities to be displayed in

a single screen, but changes in the state or data of each of
these entities are handled separately from one another.

Of course, the changes to one part of a
system must be reflected in another (like the exact coordinates of an avatar in the region that t
hey
are in) in order to update all necessary parties with the correct information.

So, here we see a
loci of communication which separates the different needs of the system:

the RESTful
architecture for server
-
to
-
client communication, the SOAP architectu
re for process calls, and the
MXP for communication from the server to all clients connected to the same region.

We also see
a loci of computation which separates the needs of different components, and combines them
when necessary.

The viewer, for instan
ce, takes all visual data from the region and the avatar
and combines them with the inventory data and chat data to form the GUI.

But, these individual
parts do not necessarily need to know anything about each other to ful
fill their original functions.

Th
e avatar needs a region to exist in, but beyond that, all of its animations or properties exist
outside of the realm of the region.

A region can exist with or without avatars, but it is only
viewed when an avatar is present (something that could potential
ly be abstracted away for the
purpose of strictly modeling a region).

These functionalities show that OpenSim was built with
an eye towards making sure that only that data which is absolutely necessary for an asset to
function are shown to that asset.

OpenSim employs a layered
-
component, client/server architecture where the layers are region,
grid, and application.

The clients (application instances) communicate with the servers which
receive information from the databases.


Modularity and transparenc
y are integral to the OpenSim architecture.

Functionality can be
easily added or removed via modules without the other modules being wholly affected.

The
modularity also helps with separation of concerns and makes the system easier to upgrade or
scale.

O
penSim also makes ample use of abstraction.

For example, it defines “base” classes for all of
its services.

These “base” classes are simply abstract classes that other classes inherit from.

Using the knowledge we gained from the course (e.g., fundamental
s of software architecture,
styles, patterns, non
-
functional and functional requirements, connectors, components, etc.)
,

we
were better able to determine what we were looking for and identify instances of things we
learned in the course such the ones menti
oned above.

7.

Conclusions

7.1

Summary

We discovered the methods used to connect the clients and servers in the OpenSim universe.
Through the use of REST, the server/database handles client requests to allow the server to
update the client when they first log in, or whenever they decide to chan
ge regions.

Clients can
also use specific remote calls (via SOAP) to change the information on the server side, which are
Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


8


then reflected on the client side.

Simultaneously, through the use of MXP, the updates from one
user are manifested on all machines
also connected to the region.

This is an effective use of
multiple protocols because each implementation is used for its intended purpose, and in an
efficient manner.

Even with the lack of updated documentation, we were able to obtain a lot of information

of the
architecture behind OpenSimulator and how it operates between its components.

By observing
this noteworthy virtual world and mapping out the numerous components and connectors within
the architecture and database, we are able to make knowledgeable

suggestions on how a standard
framework for virtual worlds could help tie them together and over time evolve into a single,
seamless environment.

7.2

Impact

OpenSim is still in an alpha stage (i.e., it is continually evolving and changing) [1].

Due to t
his,
OpenSim's documentation on their wiki needs to be continually updated to keep up with
development, and some of it (particularly the database documentation) has become out of date.

Using the knowledge we have obtained, we plan to update the database a
nd architecture
documentation found on the OpenSim wikipedia, where the updated information about the
OpenSim software should be maintained.

7.3

Future Work

While we were able to provide detail of the OpenSim architecture and suggest a generalized
schema
that may open doors for the various virtual worlds to communicate, the actual
exploration of these component layouts is left for future researchers to pursue.

Unfortunately,
like the problem we faced with outdated documentation, our research presented her
e will need to
be verified and updated before others may build upon our discoveries.

8.

Team

Chris Dempewolf

-

Dempewolf is a junior in the Computer Science and Computer Engineering
Department expecting to graduate with a BS degree in May 2012.

He is wor
king on a SURF
grant with Dr. Thompson to explore possibilities for a virtual worlds reference architecture.

Seth Williams


Williams is a junior majoring in Computer Science at the University of
Arkansas, and is expecting to graduate in a May 2012 with a
BS degree.

He is currently
researching methods to create a plug
-
in for automatic terrain generation for the Unity Game
Engine.

Gregory Stafford

-

Stafford is a first year graduate student at the University of Arkansas.

He
obtained his B.S. in Computer Sc
ience at the University of Arkansas and is continuing his
masters in the same discipline.

His expected graduation date is May 2012 and is currently
researching search engines in virtual worlds under the guidance of Dr. Susan Gauch.

9.

References

[1]

Open
Simulator,
http://opensimulator.org/wiki/Main_Page

[2]

Josh Eno, "An Intelligent Crawler for a Virtual World," PhD Dissertation, Computer
Science and Computer Engineering Department, University of Ark
ansas, Fayette
ville,
Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


9


AR, December 2010,
http://vw.ddns.uark.edu/content/2010
-
12
--
Dissertation
--
Josh
-
Eno
--
Final
-
Draft.pdf

[3]

T. Censullo,
Semantic World:
Ontologies for the Real and Virtual World
,
X10 Workshop
on Extensible Virtual World Architectures,
http://vw.ddns.uark.edu
/X10/content/CAPABILITIES
--
Ontologies
-
for
-
the
-
Real
-
and
-
Virtual
-
World
--
Censullo
-
Thompson.pdf



Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


10


Appendix I
-

OpenSim DBMS Schema circa April 2011

TableName

Column

DataType

Primary
Key

NotNU
LL

Default

Ind
ex

AutoIncrem
ent

Uniq
ue

Description

assets











name

varchar(64)

X

X







description

varchar(64)


X







assetType

tinyint(4)


X







local

tinyint(1)


X







temporary

tinyint(1)


X







data

longblob


X







id

char(36)


X

00000000
-
0000
-
0000
-
0000
-
000000000000






create_time

int
(11)



0






access_time

int(11)



0






asset_flags

int(11)


X

0






CreatorID

varchar(128)


X

(emptry string '')















auth











UUID

char(36)

X

X

(empty string '')






passwordHash

char(32)


X

(empty string '')






passwordSalt

char(32)


X

(empty string '')






webLoginKey

varchar(255)


X

(empty string '')






accountType

varchar(32)


X

UserAccount















avatars

PrincipalID

char(36)

X

X


X





Name

varchar(32)

X

X







Value

varchar(255)


X

(emptry string '')















estate_group
s










Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


11



EstateID

int(10)
unsigned




X





uuid

char(36)


X
















estate_mana
gers











EstateID

int(10)
unisgned


X


X





uuid

char(36)


X
















estate_map











RegionID

char(36)

X

X

00000000
-
0000
-
0000
-
0000
-
000000000000






EstateID

int(11)


X


X














estate_settin
gs











EstateID

int(10)
unisgned

X

X



X




EstateName

varchar(64)



NULL






AbuseEmailToEstateOw
ner

tinyint(4)


X







DenyAnonymous

tinyint(4)


X







ResetHomeOnTeleport

tinyint(4)


X







FixedSun

tinyint(4)


X







DenyTransacted

tinyint(4)


X







BlockDwell

tiny(4)


X







DenyIdentified

tinyint(4)


X







AllowVoice

tinyint(4)


X







UseGlobalTime

tinyint(4)


X







PricePerMeter

int(11)


X







TaxFree

tinyint(4)


X







AllowDirectTeleport

tinyint(4)


X







RedirectGridX

int(11)


X






Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


12



RedirectGridY

int(11)


X







ParentEstateID

int(10)
unsigned


X







SunPosition

double


X







EstateSkipScripts

tinyint(4)


X







BillableFactor

float


X







PublicAccess

tinyint(4)


X







AbuseEmail

varchar(255)


X







EstateOwner

varchar(36)


X







DenyMinors

tinyint(4)


X
















estate_users











EstateID

int(10)
unsigned


X


X





uuid

char(36)


X
















estateban











EstateID

int(10)
unsigned


X


X





bannedUUID

varchar(36)


X







bannedIp

varchar(16)


X







bannedIpHostMask

varchar(16)


X







bannedNameMask

varchar(64)



NULL















friends











PrincipalID

char(36)

X

X


X





Friend

varchar(255)

X

X







Flags

varchar(16)


X

0






Offered

varchar(32)


X

0















griduser










Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


13



UserID

varchar(255)

X

X







HomeRegionID

char(36)


X

00000000
-
0000
-
0000
-
0000
-
000000000000






HomePosition

char(64)


X

<0,0,0>






HomeLookAt

char(64)


X

<0,0,0>






LastRegionID

char(36)


X

00000000
-
0000
-
0000
-
0000
-
000000000000






LastPosition

char(64)


X

<0,0,0>






LastLookAt

char(64)


X

<0,0,0>






Online

char(5)


X

FALSE






Login

char(16)


X

0






Logout

char(16)


X

0















inventoryfold
ers











folderName

varchar(64)



NULL






type

smallint(6)


X

0






version

int(11)


X

0






folderID

char(36)

X

X

00000000
-
0000
-
0000
-
0000
-
000000000000






agentID

char(36)



NULL

X





parentFolderID

char(36)



NULL

X














inventoryite
ms











assetID

varchar(36)



NULL






assetType

int(11)



NULL






inventoryName

varchar(64)



NULL






inventoryDescription

varchar(128)



NULL






inventoryNextPermissio
ns

int(10)
unsigned



NULL






inventoryCurrentPermis
sions

int(10)
unsigned



NULL






invType

int(11)



NULL





Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


14



creatorID

varchar(128)


X

00000000
-
0000
-
0000
-
0000
-
000000000000






inventoryBasePermissio
ns

int(10)
unsigned


X

0






inventoryEveryOnePer
missions

int(10)
unsigned


X

0






salePrice

int(11)


X

0






saleType

tinyint(4)


X

0






creationDate

int(11)


X

0






groupID

varchar(36)


X

00000000
-
0000
-
0000
-
0000
-
000000000000






groupOwned

tinyint(4)


X

0






flags

int(11)


X

0






inventoryID

char(36)

X

X

00000000
-
0000
-
0000
-
0000
-
000000000000






avatarID

char(36)



NULL

X





parentFolderID

char(36)



NULL

X





inventoryGroupPermissi
ons

int(10)
unsigned


X

0















land











UUID

varchar
(255)

X

X







RegionUUID

varchar(255)



NULL






LocalLandID

int(11)



NULL






Bitmap

longblob









Name

varchar(255)



NULL






Description

varchar(255)



NULL






OwnerUUID

varchar(255)



NULL






IsGroupOwned

int(11)



NULL






Area

int(11)



NULL






AuctionID

int(11)



NULL






Category

int(11)



NULL






ClaimDate

int(11)



NULL





Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


15



ClaimPrice

int(11)



NULL






GroupUUID

varchar(255)



NULL






SalePrice

int(11)



NULL






LandStatus

int(11)



NULL






LandFlags

int(11)



NULL






LandingType

int(11)



NULL






MediaAutoScale

int(11)



NULL






MediaTextureUUID

varchar(255)



NULL






MediaURL

varchar(255)



NULL






MusicURL

varchar(255)



NULL






PassHours

float



NULL






PassPrice

int(11)



NULL






SnapshotUUID

varchar(255)



NULL






UserLocationX

float



NULL






UserLocationY

float



NULL






UserLocationZ

float



NULL






UserLookAtX

float



NULL






UserLookAtY

float



NULL






UserLookAtZ

float



NULL






AuthbuyerID

varchar(36)


X

00000000
-
0000
-
0000
-
0000
-
000000000000






OtherCleanTime

int(11)


X

0






Dwell

int(11)


X

0















landaccesslis
t











LandUUID

varchar(255)



NULL






AccessUUID

varchar(255)



NULL






Flags

int(11)



NULL















Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


16


migrations











name

varchar(100)



NULL






version

int(11)



NULL















primitems











invType

int(11)



NULL






assetType

int(11)



NULL






name

varchar(255)



NULL






description

varchar(255)



NULL






creationDate

bigint(20)



NULL






nextPermissions

int(11)



NULL






currentPermissions

int(11)



NULL






basePermissions

int(11)



NULL






everyonePermissions

int(11)



NULL






groupPermissions

int(11)



NULL






flags

int(11)


X

0






itemID

char(36)

X

X

(emptry string '')






primID

char(36)



NULL

X





assetID

char(36)



NULL






parentFolderID

char(36)



NULL






creatorID

char(36)



NULL






ownerID

char(36)



NULL






groupID

char(36)



NULL






lastOwnerID

char(36)



NULL















prims











CreationDate

int(11)



NULL






Name

varchar(255)



NULL





Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


17



Text

varchar(255)



NULL






Description

varchar(255)



NULL






SitName

varchar(255)



NULL






TouchName

varchar(255)



NULL






ObjectFlags

int(11)



NULL






OwnerMask

int(11)



NULL






NextOwnerMask

int(11)



NULL






GroupMask

int(11)



NULL






EveryoneMask

int(11)



NULL






BaseMask

int(11)



NULL






PositionX

double



NULL






PositionY

double



NULL






PositionZ

double



NULL






GroupPositionX

double



NULL






GroupPositionY

double



NULL






GroupPositionZ

double



NULL






VelocityX

double



NULL






VelocityY

double



NULL






VelocityZ

double



NULL






AngularVelocityX

double



NULL






AngularVelocityY

double



NULL






AngularVelocityZ

double



NULL






AccelerationX

double



NULL






AccelerationY

double



NULL






AccelerationZ

double



NULL






RotationX

double



NULL






RotationY

double



NULL






RotationZ

double



NULL





Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


18



RotationW

double



NULL






SitTargetOffsetX

double



NULL






SitTargetOffsetY

double



NULL






SitTargetOffsetZ

double



NULL






SitTargetOrientW

double



NULL






SitTargetOrientX

double



NULL






SitTargetOrientY

double



NULL






SitTargetOrientZ

double



NULL






UUID

char(36)

X

X

(empty string '')






RegionUUID

char(36)



NULL

X





CreatorID

char(36)



NULL






OwnerID

char(36)



NULL






GroupID

char(36)



NULL






LastOwnerID

char(36)



NULL






SceneGroupID

char(36)



NULL

X





PayPrice

int(11)


X

0






PayButton1

int(11)


X

0






PayButton2

int(11)


X

0






PayButton3

int(11)


X

0






PayButton4

int(11)


X

0






LoopedSound

char(36)


X

00000000
-
0000
-
0000
-
0000
-
000000000000






LoopedSoundGain

double


X

0






TextureAnimation

blob









OmegaX

double


X

0






OmegaY

double


X

0






OmegaZ

double


X

0






CameraEyeOffsetX

double


X

0






CameraEyeOffsetY

double


X

0





Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


19



CameraEyeOffsetZ

double


X

0






CameraAtOffsetX

double


X

0






CameraAtOffsetY

double


X

0






CameraAtOffsetZ

double


X

0






ForceMouseLook

tinyint(4)


X

0






ScriptAccessPin

int(11)


X

0






AllowedDrop

tinyint(4)


X

0






DieAtEdge

tinyint(4)


X

0






SalePrice

int
(11)


X

10






SaleType

tinyint(4)


X

0






ColorR

int(11)


X

0






ColorG

int(11)


X

0






ColorB

int(11)


X

0






ColorA

int(11)


X

0






ParticleSystem

blob









ClickAction

tinyint(4)


X

0






Material

tinyint(4)


X

3






CollisionSound

char(36)


X

00000000
-
0000
-
0000
-
0000
-
000000000000






CollisionSoundVolume

double


X

0






LinkNumber

int(11)


X

0






PassTouches

tinyint(4)


X

0















primshapes











Shape

int(11)



NULL






ScaleX

double


X

0






ScaleY

double


X

0






ScaleZ

double


X

0






Pcode

int(11)



NULL





Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


20



PathBegin

int(11)



NULL






PathEnd

int(11)



NULL






PathScaleX

int(11)



NULL






PathScaleY

int(11)



NULL






PathShearX

int(11)



NULL






PathShearY

int(11)



NULL






PathSkew

int(11)



NULL






PathCurve

int(11)



NULL






PathRadiusOffset

int(11)



NULL






PathRevolutions

int(11)



NULL






PathTaperX

int(11)



NULL






PathTaperY

int(11)



NULL






PathTwist

int(11)



NULL






PathTwistBegin

int(11)



NULL






ProfileBegin

int(11)



NULL






ProfileEnd

int(11)



NULL






ProfileCurve

int(11)



NULL






ProfileHollow

int(11)



NULL






State

int(11)



NULL






Texture

longblob









ExtraParams

longblob









UUID

char(36)

X

X

(empty string '')















regionban











regionUUID

varchar(36)


X







bannedUUID

varchar(36)


X







bannedIp

varchar(16)


X







bannedIpHostMask

varchar(16)


X






Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


21












regionsetting
s











regionUUID

char(36)

X

X







block_terraform

int(11)


X







block_fly

int(11)


X







allow_damage

int(11)


X







restrict_pushing

int(11)


X







allow_land_resell

int(11)


X







allow_land_join_divide

int(11)


X







block_show_in_search

int(11)


X







agent_limit

int(11)


X







object_bonus

double


X







maturity

int(11)


X







disable_scripts

int(11)


X







disable_collisions

int(11)


X







disable_physics

int(11)


X







terrain_texture_1

char(36)


X







terrain_texture_2

char(36)


X







terrain_texture_3

char(36)


X







terrain_texture_4

char(36)


X







elevation_1_nw

double


X







elevation_2_nw

double


X







elevation_1_ne

double


X







elevation_2_ne

double


X







elevation_1_se

double


X







elevation_2_se

double


X







elevation_1_sw

double


X







elevation_2_sw

double


X






Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


22



water_height

double


X







terrain_raise_limit

double


X







terrain_lower_limit

double


X







use_estate_sun

int(11)


X







fixed_sun

int(11)


X







sun_position

double


X







covenant

char(36)



NULL






Sandbox

tinyint(4)


X







sunvectorx

double


X

0






sunvectory

double


X

0






sunvectorz

double


X

0






loaded_creation_id

varchar(64)



NULL






loaded_creation_dateti
me

int
(10)
unsigned


X

0






map_tile_ID

char(36)


X

00000000
-
0000
-
0000
-
0000
-
000000000000















regionwindli
ght











region_id

varchar(36)

X

X

00000000
-
0000
-
0000
-
0000
-
000000000000






water_color_r

float(9,6)
unsigned


X

"4.000000"






water_color_g

float(9,6)
unsigned


X

"38.000000"






water_color_b

float(9,6)
unsigned


X

"64.000000"






water_fog_density_exp
onent

float(3,1)
unsigned


X

"4.0"






underwater_fog_modifi
er

float(3,2)
unsigned


X

"0.25"






reflection_wavelet_scal
e_1

float(3,1)
unsigned


X

"2.0"






reflection_wavelet_scal
e_2

float(3,1)
unsigned


X

"2.0"






reflection_wavelet_scal
e_3

float(3,1)
unsigned


X

"2.0"





Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


23



fresnel_scale

float(3,2)
unsigned


X

"0.40"






fresnel_offset

float(3,2)
unsigned


X

"0.50"






fresnel_scale_above

float(3,2)
unsigned


X

"0.03"






fresnel_scale_below

float(3,2)
unsigned


X

"0.20"






blur_multiplier

flaot(4,3)
unsigned


X

"0.040"






big_wave_direction_x

float(3,2)


X

"1.05"






big_wave_direction_y

float(3,2)


X

"
-
0.42"






little_wave_direction_x

float(3,2)


X

"1.11"






little_wave_direction_y

float(3,2)


X

"
-
1.16"






normal_map_texture

varchar(36)


X

822ded49
-
9a6c
-
f61c
-
cb89
-
6df54f42cdf4






horizon_r

float(3,2)
unsigned


X

"0.25"






horizon_g

float(3,2)
unsigned


X

"0.25"






horizon_b

float(3,2)
unsigned


X

"0.32"






horizon_i

float(3,2)
unsigned


X

"0.32"






haze_horizon

float(3,2)
unsigned


X

"0.19"






blue_density_r

float(3,2)
unsigned


X

"0.12"






blue_density_g

float(3,2)
unsigned


X

"0.22"






blue_density_b

float(3,2)
unsigned


X

"0.38"






blue_density_i

float(3,2)
unsigned


X

"0.38"






haze_density

float(3,2)
unsigned


X

"0.70"






density_multiplier

float(3,2)
unsigned


X

"0.18"






distance_multiplier

float(4,1)
unsigned


X

"0.8"






max_altitude

int(4)
unsigned


X

1605






sun_moon_color_r

float(3,2)
unsigned


X

"0.24"





Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


24



sun_moon_color_g

float(3,2)
unsigned


X

"0.26"






sun_moon_color_b

float(3,2)
unsigned


X

"0.30"






sun_moon_color_i

float(4,3)
unsigned


X

"0.30"






sun_moon_position

float(4,3)
unsigned


X

"0.317"






ambient_r

float(3,2)
unsigned


X

"0.35"






ambient_g

float(3,2)
unsigned


X

"0.35"






ambient_b

float(3,2)
unsigned


X

"0.35"






ambient_i

float(3,2)
unsigned


X

"0.35"






east_angle

flaot(3,2)
unsigned


X

"0.00"






sun_glow_focus

float(3,2)
unsigned


X

"0.10"






sun_glow_size

float(3,2)
unsigned


X

"1.75"






scene_gamma

float(4,2)
unsigned


X

"1.00"






star_brightness

float(3,2)
unsigned


X

"0.00"






cloud_color_r

float(3,2)
unsigned


X

"0.41"






cloud_color_g

float(3,2)
unsigned


X

"0.41"






cloud_color_b

float(3,2)
unsigned


X

"0.41"






cloud_color_i

float(3,2)
unsigned


X

"0.41"






cloud_x

float(3,2)
unsigned


X

"1.00"






cloud_y

float(3,2)
unsigned


X

"0.53"






cloud_density

float(3,2)
unsigned


X

"1.00"






cloud_coverage

float(3,2)
unsigned


X

"0.27"






cloud_scale

float(3,2)
unsigned


X

"0.42"






cloud_detail_x

flaot(3,2)
unsigned


X

"1.00"





Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


25



cloud_detail_y

float(3,2)
unsigned


X

"0.53"






cloud_detail_density

float(3,2)
unsigned


X

"0.12"






cloud_scroll_x

float(4,2)


X

"0.20"






cloud_scroll_x_lock

tinyint(1)
unsigned


X

0






cloud_scroll_y

float(4,2)


X

"0.01"






cloud_scroll_y_lock

tinyint(1)
unsigned


X

0






draw_classic_clouds

tinyint(1)
unsigned


X

1















terrain











RegionUUID

varchar(255)



NULL






Revision

int(11)



NULL






Heightfield

longblob


















tokens









uuid_token is one single unique key


UUID

char(36)


X


X


X



token

varchar(255)


X


X


X



validity

datetime


X


X














useraccounts









KEY 'Name' ('FirstName', 'LastName') is an
additional key


PrincipalID

char(36)


X




X



ScopeID

char(36)


X







FirstName

varchar(64)


X


X





LastName

varchar(64)


X


X





Email

varchar(64)



NULL

X





ServiceURLs

text









Created

int(11)



NULL






UserLevel

int(11)


X

0





Mapping the OpenSim Architecture

CSCE 5013


Software Architecture


Spring 2011


26



UserFlags

int(11)


X

0






UserTitle

varchar(64)


X

(empty string '')