On Sun, Sep 19, 2010 at 12:53 PM, Tateru Nino <tat...@taterunino.net> wrote:
> > > On 20/09/2010 3:49 AM, Oz Linden (Scott Lawrence) wrote: > > On 2010-09-19 10:21, Tateru Nino wrote: > >> I believe he was referring to the fact that a UUID does not always refer > >> to the same inworld object. There are instances where an object UUID > >> will be used more than once. > > > > Those would be bugs, by definition. > Well, it pretty much happens when a sim is down. When that happens, > objects being instantiated in other sims may be given the same UUIDs as > objects that are in another sim that is not presently online on the > grid. When the sim comes back up, the clash in UUIDs is noted, and new > UUIDs are chosen for any conflicts in that sim. It's been around for > quite some time, and is a particular pest for someone who wants to refer > to a server-object by UUID in - for example - an inworld or outworld > script. Common workarounds involve using an external server for the > object to register its current UUID to. > > That's been the case since 2005, but being a server-side issue is > probably out-of-scope here. > > As far as textures go, I believe the way they are handled as assets is > different to instantiated objects, and that they do not suffer from the > same issue. Of course, if log in to more than one grid, there's no > guarantees that a texture with a given UUID in your cache is the same > texture that you're supposed to be getting. While the space for texture > UUIDs is very large, they're only unique to a specific grid and clashes > will inevitably occur over time. > > -- > Tateru Nino > http://dwellonit.taterunino.net/ > > I'm not sure how what you describe could happen. There is no system in place to detect UUID clashes, especially between different regions/sims, and nothing that notes them and then replaces them. The way you describe it makes it sound like there is a central service that hands out UUIDs as needed and when a region that has been down comes back up it may have UUIDs that have been given out that need to be corrected. That isn't how UUIDs work - each process generates its own UUIDs as needed from an algorithm that attempts to minimize the already slim chance of a collision. * Rezed objects are given a new UUID (though they will still reference the 'original asset id' for some internal tracking server side) * An object that is out in the world could be modified and will retain its same UUID (and local ID) even though the object changes. So it is true that an object cache based purely on UUID could show stale data - this is a unique case for inworld objects only. Not inventory, textures, sounds, gestures, notecards, scripts or even landmarks. All of those will have a unique ID that never changes. * The only way I can think of right now to force a UUID 'collision' is to bring up a duplicate of a region so that the same region is brought up in two places at the same time, including copying all the content. This is something that shouldn't happen, and even if we have to we do have a system to generate new IDs for parcels and content. * If you have more details about UUID collisions happening, let us know. It would definitely be a bug and we would want to look into it. - Kelly
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
