Re: [vwrap] [wvrap] Simulation consistency

[Morgaine <[e-mail]>]

Hash-based addressing is very different to UUID-based addressing as used in
SNOW-375, so I expect there is some misunderstanding of how hash digests are
applied in this scheme,

The universal address of the item is the hash digest over the data of the
item using a specified digest algorithm, and is not a UUID.  It is invariant
regardless of who computes it, although it would normally be computed only
once by the asset service at the time that the item is being stored in the
service.  All asset services everywhere will use the same digest as an
address for this item, because the digest algorithm is specified.

Data that is addressed and indexed in this way can of course be used in a
REST architecture with appropriate design, but because hash digests are not
UUIDs, there is quite a different semantic to it.  A UUID cannot be used as
a shared cache index in a multi-world architecture, because identical
content in N different worlds will have different UUIDs associated with it
in each world.  In contrast, identical content in N different worlds will
have an identical hash in every world, and therefore only a single storage
entry is needed in a multi-world cache.

The effect of this is dramatic.  Every time that an Object ARchive is loaded
to populate a new region, this can generate another several hundred thousand
(and soon, millions) of new assets which in a UUID-addressed scheme will
typically just grow the asset storage without bound.  In a hash-addressed
scheme, that OAR can be loaded a million times and the asset data storage
doesn't increase by 1 byte, neither in the asset server, the region, nor in
client caches.  Only metadata storage need grow for repeated assets in asset
services, but it's not even needed in client-side caches, so the benefits
are huge.

A nice mental image that really brings this home is that of grass patches
and trees and other common environmental objects reused in countless worlds
across the metaverse, yet requiring no downloads at all as you tour around
the worlds because visiting just one world has populated your persistent
cache with those common items already.

This can represents storage savings of thousands or even millions to 1, and
corresponding time savings too because the remote fetches from asset
services are avoided entirely.  The impact of this scheme on user experience
can be expected to be outstanding even in today's humble beginnings, and
much more so as the metaverse blooms.  It's the scheme with the best
performance and scalability of any we have examined so far.

UUID-based asset storage does not have these excellent properties, nor the
other advantages that I have described previously.


Morgaine.





=====================

On Sat, Apr 2, 2011 at 4:36 PM, Dzonatas Sol <[e-mail]> wrote:

> Your hash/digest method is similar to basic REST and what I already
> implemented. Icesphere already has implementations and methods and even
> furthers them with burst modes so where there is no worry to have a URI for
> each asset. The URI can specify a list of assets or single asset (content
> varies as such), which can be returned immediately or when each is ready for
> transfer, individually. Uses LLIDL with proposed changes:
>
> Everything is documented here:
> http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources/Inventory
> (Last edited that doc in August 2010 & Icesphere's implementation has been
> used for awhile since then)
>
>
>
> Morgaine wrote:
>
>> Back in September 2010, I wrote this post which proposes that we use in
>> VWRAP a form of asset addressing that provides massive scalability at the
>> same time as a very high degree of resilience --
>> http://www.ietf.org/mail-archive/web/vwrap/current/msg00463.html .� It is
>> based on the concept of the URI containing a host part and a hash part,
>> where the hash is generated (once, at the time of storage to the asset
>> service) using a specified digest algorithm over the content of the asset
>> being referenced.� You may wish to note that if this design were used, the
>> failure of an asset service to deliver a requested item would result in a
>> failover request for the item to one or more backup services, using the same
>> hash part but with a different host address.
>>
>>
>
> --
> --- https://twitter.com/Dzonatas_Sol ---
> Web Development, Software Engineering, Virtual Reality, Consultant
>
>