Re: [vwrap] [wvrap] Simulation consistency

[Morgaine <[e-mail]>]

I have no doubt that you *could* adapt SNOW-375 to hash-based addressing,
but that is not what SNOW-375 currently describes, so the point is moot.


Morgaine.




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

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

> Again, you assumed too much and narrowed it down too some straw-man
> argument of UUID only. There are many ways to cache.
>
> SNOW-375 has the functionality for hash-based, if you want to further the
> public/private implementation of URIs. The functionality for private-URI
> being based on public URIs (as documented) is just cache and redirect, not
> much different from hash-based as you describe. I just haven't implemented
> login option create a digest for private URIs (as noted in the documentation
> section about "feature freeze"). Purposely waited...   (and I'm in
> multi-point/multi-client/full-duplex/anti-exploit mindset )...
>
> ...and waited...
>
> Despite my reasons to wait and do other things, open virtual worlds vs
> legacy...
>
> I'll lean more towards organic and analog based types then identical
> assets, especially if virtual worlds include real world peripherals.
>
>
> Morgaine wrote:
>
>> 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] <mailto:
>> [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
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> vwrap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>
>
> --
> --- https://twitter.com/Dzonatas_Sol ---
> Web Development, Software Engineering, Virtual Reality, Consultant
>
>