[Opensim-dev] AssetServer Observations and Suggestions

Sun Feb 8 22:48:47 UTC 2009

Well, with all due respect to all, and I do respect you all, currently I am trying to focus on a couple of issues in the current C# logic and see if we can get a consensus on changing a couple of details that will help us move closer to a reasonable long-term strategy.

The things I am looking at right now are:

1) Some items which are currently stored on the assetServer at the gridlevel that could arguably be stored at the region level instead, such as a regions terrainImage.

2) Some items which when edited, create a new entry that is stored on the assetServer with a new random UUID and as a consequence, the previous item stored are orphaned and unavailable to the creator at all.

3) The issue that "access_time" may not be updated in all cases.

It seems to me that solving these three issues with our existing C# logic, or having "Cable Beach" make some progress by solving these issues helps us move along.

As a couple of examples:

Each terrain edit appears to create a new "terrainImage" entry in the assets table and each time that happens, all previous terrain images become unlinked, unusable and unnecessary. A similar thing happens with scripts, notecards, and clothes. Prims themselves are stored in the regions datastore, so they dont apply to this discussion.

A MySQL query of the form:     select count(*) from assets where access_time="0";    should be decreasing on an ongoing basis. Perhaps some could start checking this and looking for occurences where a fetch or an edit of an item from the assets table do not update the access_time. It is my hope that searching by access_time will be at least one method of identifying unusable entries that should be deleted.

Charles

________________________________
From: Tommi Laukkanen <tommi.s.e.laukkanen at gmail.com>
To: opensim-dev at lists.berlios.de
Sent: Sunday, February 8, 2009 1:55:02 PM
Subject: Re: [Opensim-dev] AssetServer Observations and Suggestions

I like the idea of grid independent storage providers (assets and inventories). It is in analogy with open id providers which are application independent identity providers. The challenge with both is that the UUID should always be accompanied by the provider url unless we have a way to resolve provider URL from asset UUID.  In other words if Frank will have texture asset on his avatar with given UUID it does not get me anywhere unless I have a way to find out from which URL I can actually download that asset. You can hide this from the viewer program and implement it in region services for example but ultimately you will still face the same problem. If we want simple engineering solution which works in all situations we should figure out how we will solve mapping from asset UUID to provider service URL. Possible solutions:

1) Use keys which consists of UUID and asset provider URL instead of just UUID's (not very practical when you store the key to database)
2) Have distributed registry with maps UUIDs and provider URLs. This might be even theoretically impossible as they amount of keys in the distributed registry would be same as all the assets in the internet. Could this be resolved by allocating UUIDs to different nodes based on somekind of UUID hash value?
3) Try to hard wire asset access to correct repository behind the scenes. In other words in HG region all avatars would notify the region which is their asset provider and region will broker the asset calls to correct asset provider. Client in turn assumes that each region may have separate asset server and queries assets separately from each region. This is not very clean solution and can result in quite complex overall system.

Number 2 would be good for enforcing uniqueness of UUID's so that it is not possible to manually copy an asset and steal the identity by using the same UUID. So this registry could be used to also store ownerhship rights for UUIDs.

Work name: Distributed Identity Ownerhship and Provider Registry

best regards,
Tommi Laukkanen

On Sun, Feb 8, 2009 at 11:21 PM, Paul Fishwick <fishwick at cise.ufl.edu> wrote:

On the observation that most multi-player games have asset stored
client-side,
thus allowing huge and feature-rich worlds, it would be nice to have an
option ("private assets", "fixed assets" perhaps indicated by land
parcel ?) that required people who wanted to take advantage of
interacting there to first download all assets prior to launching
the viewer. Having both ends of the spectrum (at one end, all
startup assets are private and non-dynamically shared and at the other
end, all assets are dynamically loaded to each connecting client)
would provide more flexibility and some detailed spaces.

-p

Frank Nichols wrote:
> I like the idea of shifting responsibility for user storage costs closer
> to the user. Region maybe a good place to do this.
>
> Frank
>
> Charles Krinke wrote:
>
>> We have been studying the assets table on OSGrid as it heads toward
>> the "disk full" stage and I have a couple of observations and am
>> heading towards a suggestion. Maybe this is already accounted for in
>> the "Cable Beach" project, at which point, this will only indicate
>> that I did not read all the exchanges carefully enough.
>>
>> It appears to me that we are storing on the MySQL data store at the
>> assetServer on a grid every edit of every script, terrainImage and
>> clothingItem amongst other things. So, my first observation is that we
>> appear to be storing all the older, obsolete items that can no longer
>> be accessed.
>>
>> Additionally, it appears to me that we are also storing things that
>> could arguably be stored on the regions datastore, such as the
>> terrainImage.
>>
>> Now, to the beginnings of a suggestion. It seems to me that each
>> avatar will have a "home" region. And that perhaps that is the place
>> to store the items in an avatars inventory. Things like scripts,
>> notecards, textures and the like.
>>
>> At that point, the assetServer on a grid could be used to store only
>> pointers (or URL's) to each avatars inventory on his or her home region.
>>
>> So, by doing that, we start shifting the ever increasing disk storage
>> requirements of a grid back to the regions distributed around the
>> internet.
>>
>> Again, perhaps Cable Beach is already doing this, and if so, this is
>> great. If not, I put out these ideas and duck as the tomatoes start
>> flying.
>>
>> Charles
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>

--
Paul Fishwick, PhD
Professor and Director, Digital Arts and Sciences Programs
University of Florida
Computer & Information Science and Eng. Dept.
Bldg. CSE, Room 301
P.O. Box 116120
Gainesville, FL 32611
Email: fishwick at cise.ufl.edu
Phone: (352) 392-1414
Fax: (352) 392-1220
Web: http://www.cise.ufl.edu/~fishwick

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090208/4b70047e/attachment-0001.html>