[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GEU-algorithms (was Ozone object identity)
Using a hash value to annote a global object does satisfy the GEU
(globall and eternall uniquess) properties of an identity. We also agree
that a URL scheme satisfy that as well.
However, there is a problem with hash value is how to recover enough
information from it to reconstruct the object.
Take the discountinuous mobile database example. I get objects from
several sources, keep the locally, disconnect from the server, modify
the data, and later on sync to the server.
In this implementation (as well as the ClinetCacheDatabase already
proposed for Ozone), the implementation must be able to retrive the
object later on from the identity.
Using a hash value as identity will likely to result the following
implementation:
1. A hostname, port, database name, time, and a random value are hashed
to generated the id.
2. The id is sent down to the client side
3. The client side cache must associate at least hostname, port and
database name with an object identity in order to recover the objects
later on while connecting back to the real database.
Why we destroy the perfect information in the beginning just to have
client side having to do more work. Won't encoding the necesary
information in the identity be better?
CORBA (www.omg.org) has a similar scheme in producing the ID for a
distributed object. Full information about the object (host, port, and
id) are encoded in an object id. A client side app can retrive the
object using just the id.
I think we are looking for the following properties in a identity.
1. Globally and Eternally Uniqueness
2. Locatablility (be able to locate a where about and access the object
from the identity)
I think we have agree on the first one. Now, let's see if the second is
an important property in our search for perfect object identity
representation.
David
Ola Berg wrote:
>
> There are a couple of algorithms that almost ensures
> global and eternal uniqueness. By "almost" I mean that
> the chances for collisions are sooooooo minimal.
>
> They all built on secure hashing. You feed the algorithm with
> whatever uniqueness information you have (millis since the epoch,
> hostname, data from the object, object counter in the VM blablabla.
> The hash it produces will probably be unique.
>
> How? The hashing algorithm shuffles the input totally (converts
> the bits into noise in an orderly fashion). Since the input is
> an ordered data combination, and there are billions of noisy
> combinations for each ordered combination, the hash will probably
> be unique.
>
> The Secure Hashing Algorithm (SHA) has this property, and it produces
> 20 bytes. A byte[] of size 20 will for all practical purposes be
> globally and eternally unique.
>
> The idea (and I am sure that Falko didn't have this in mind from the
> beginning) would be that each and every instantiated Ozone object will
> have a GEUID. Exactly how this is implemented should be hidden, but
> identity should definitely be both in time and space.
>
> I am thinking about the ability to move ozone objects between
> several ozone servers (for load balancing maybe, or for distributed
> computing, peer-to-peer capability of ozone where the objects float
> around the network until it finds computing space, or...). The point
> is that object identity is a good thing, and to not mess up things
> in the future, let's do it GEU.
>
> Furthermore, a standard URL scheme is also a good idea. But let's not
> confuse this with GEU. URL's are bad candidates for GEUness. But if
> you have a GEUID, it is easy to implement a URL scheme on top of it.
>
> My third quarter...
>
> /O