Plus you could use those hashes to distribute the assets to several backed databases in similar manner as hashmap works. If a database becomes too full you can always split it to sub databases and move assets there in analogy with hashmap internal datastructure. Basicly all hashmap performance math and algorithms should apply. Do you think this could be workable way of doing asset storage distribution?
regards, Tommi On Mon, Feb 16, 2009 at 3:21 PM, Frisby, Adam <a...@deepthink.com.au> wrote: > Hence me suggesting stronger hashes - there's no known attacks on anything > above or equal to 160bit, plus to calculate an attack you'd have to have the > hash of the original to begin with, which shouldn't be something revealed to > an end user. > > Adam > > > -----Original Message----- > > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- > > boun...@lists.berlios.de] On Behalf Of Melanie > > Sent: Monday, 16 February 2009 5:26 AM > > To: opensim-dev@lists.berlios.de > > Subject: Re: [Opensim-dev] Please do not revert fixes without careful > > comtemplation > > > > I see the potential of targeted MD5 collisions as a way to obtain > > script sources. > > A saves a script. > > B creates a targeted collision, which will result in creation of an > > inventory item refering to A. The data B saves is ignored because of > > hash equality > > B then reopens the object and receives A's script source. > > > > Melanie > > > > > > Frisby, Adam wrote: > > > You do realise you could just not update the asset. If the hash is > > the same, then you can just completely ignore the save/update request. > > > > > > That being said, even a targeted collision on MD5 is a 2^58 chance, > > on SHA256 it's well over 2^128 which makes it pretty much impossible. > > Frankly it's not something worth concerning oneself over. > > > > > > Adam > > > > > >> -----Original Message----- > > >> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- > > >> boun...@lists.berlios.de] On Behalf Of Melanie > > >> Sent: Monday, 16 February 2009 4:45 AM > > >> To: opensim-dev@lists.berlios.de > > >> Subject: Re: [Opensim-dev] Please do not revert fixes without > > careful > > >> comtemplation > > >> > > >> Again, I'd like to stress that I believe this is too dangerous to do > > >> for anything other than textures. > > >> It is also not really needed for things other than textures, since > > >> the other assets are comparatively small, textural data. > > >> > > >> I would not want to risk even the smallest chance of a hash > > >> collision on script source. > > >> > > >> Melanie > > >> > > >> Stefan Andersson wrote: > > >> > Coming in a bit from the side here, > > >> > > > >> > > > >> > > > >> > we have, for some time, discussed to separate out the binary blog > > out > > >> of the metadata for an entirely different reason, namely to be able > > to > > >> weed out binary duplicates. > > >> > > > >> > > > >> > If there was a way for us to separate out the binary parts, into > > >> something like 'binaryassetId, hashData[256], binarydata' and then > > just > > >> have the asset table referencing that row, I think it would help a > > lot. > > >> > > > >> > > > >> > I realize it's a separate discussion, just chipping in my two > > cents. > > >> > > > >> > > > >> > Best regards, > > >> > Stefan Andersson > > >> > Tribal Media AB > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > Date: Sat, 14 Feb 2009 17:49:22 +0200 > > >> > From: tommi.s.e.laukka...@gmail.com > > >> > To: mma...@gmail.com > > >> > CC: opensim-dev@lists.berlios.de > > >> > Subject: Re: [Opensim-dev] Please do not revert fixes without > > careful > > >> comtemplation > > >> > > > >> > > > >> > Hello, > > >> > > > >> > On second though we could keep the current structure and expose > > all > > >> fields also through AssetBase properties. Then we could save / load > > the > > >> AssetBase with nhibernate as a single object and leave out the > > Metadata > > >> property from NHibernate mapping. Does this sound good? > > >> > > > >> > regards, > > >> > Tommi > > >> > > > >> > > > >> > On Sat, Feb 14, 2009 at 5:06 PM, Mike Mazur <mma...@gmail.com> > > wrote: > > >> > > > >> > Hi, > > >> > > > >> > On Sat, Feb 14, 2009 at 4:05 PM, Tommi Laukkanen > > >> > > > >> > <tommi.s.e.laukka...@gmail.com> wrote: > > >> > > > >> >> I was talking with mikkopa and he suggested we should create two > > >> tables to > > >> >> cover AssetBase to solve this issue properly. Namely > > AssetMetadata > > >> for > > >> >> metadata information and AssetData for blobs to avoid situation > > >> where we end > > >> >> up accessing also the blob data just to read metadata. > > >> > > > >> > I was hoping not to have to do that. > > >> > > > >> > It should be straightforward to support the current > > >> > AssetBase/AssetMetadata composition in the existing OpenSim data > > >> > layers, but as sdague warned me earlier, by mapping multiple > > classes > > >> > to one table I was entering a world of pain. Seems that's exactly > > >> > what's happening with NHibernate. > > >> > > > >> > The reason I introduced the AssetMetadata class is to supply > > metadata > > >> > information only for some requests that Cable Beach, the new asset > > >> > server, supports. Now I realize that this was probably a premature > > >> > optimization. > > >> > > > >> > Instead of modifying the DB schema, we could have AssetBase > > inherit > > >> > from AssetMetadata, as I outlined before[1]. Alternatively, we > > could > > >> > get rid of AssetMetadata altogether and store everything in > > AssetBase > > >> > as before, splitting out the metadata sometime in the future when > > a > > >> > use case warrants it. > > >> > > > >> > What do you think? > > >> > > > >> > Thanks, > > >> > Mike > > >> > > > >> > > > >> > [1] https://lists.berlios.de/pipermail/opensim-dev/2009- > > >> February/004918.html > > >> > > > >> > > > >> > > > >> > > > >> > ------------------------------------------------------------------ > > --- > > >> --- > > >> > > > >> > _______________________________________________ > > >> > Opensim-dev mailing list > > >> > Opensim-dev@lists.berlios.de > > >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > > >> _______________________________________________ > > >> Opensim-dev mailing list > > >> Opensim-dev@lists.berlios.de > > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > > _______________________________________________ > > > Opensim-dev mailing list > > > Opensim-dev@lists.berlios.de > > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev@lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev >
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
