[Mono-dev] Type.GUID patch

[Vladimir Lushnikov]

Hi,

Can I ask a slightly unrelated question - does Mono actually generate unique 
GUID's at the moment? I use them for a generic collection of "worker" 
sockets in a server, so wondering if they are unique enough to be used there 
in Mono (I know it works in .NET).

Sorry if it's a tad off-topic but thanks for replying

On 03/09/05, Sebastien Pouliot <sebastien.pouliot at gmail.com> wrote:
> 
> Hello Robert,
> 
> On Sat, 2005-03-09 at 23:18 +0200, Robert Jordan wrote:
> > Hi Sebastien,
> >
> > >>The hash appears to change with the assembly name and type name.
> > >>Renaming gt.cs will return another GUID as well as renaming
> > >>"App". Renaming gt.exe doesn't change the GUID.
> > >>Applying an AssemblyVersionAttribute will change the GUID,
> > >>so I'm pretty sure, that Type.AssemblyQualifiedName is taken
> > >>into account while generating the hash.
> > >>
> > >>The following algorithm computes the GUID from
> > >>Type.AssemblyQualifiedName using a MD5 hash:
> > >>
> > >>Guid ComputeGuid (Type t)
> > >>{
> > >> byte[] bytes = System.Text.Encoding.UTF8.
> > >> GetBytes (t.AssemblyQualifiedName);
> > >> using (System.Security.Cryptography.MD5 md5 =
> > >> System.Security.Cryptography.MD5.Create ()) {
> > >> return new Guid (md5.ComputeHash (bytes));
> > >> }
> > >>}
> > >>
> > >>Is it a patch worth?
> > >
> > >
> > > I guess it depends on how it's gonna be used. This isn't the first 
> time
> > > people talks about Type.Guid but I never seen any talk about _using_
> > > it ;-) at least not with Mono.
> > >
> > > MD5 will give you a 128 bits digest value, which match the required 
> Guid
> > > length, and recent problems related to MD5 are pretty much irrelevant 
> to
> > > such usage. So it's probably (if everything is included in the 
> qualified
> > > name) a correct implementation - functionality-wise.
> > >
> > > But creating a using MD5 is kind of heavyweight - even more if a new
> > > instance is created each time. So anyone using this heavily will 
> notice
> > > a big performance problem.
> >
> > MSFT's implementation (actually an InternalCall) is 3 times slower
> > then the computation of an MD5 hash using an *unmanaged* implementation
> > of the MD5 algorithm.
> 
> Oh, that's interesting. How does this compare to your managed
> implementation (using Mono's managed MD5 implementation) ?
> 
> > It's probably slower because it has to generate
> > properly formatted UUIDs which consists of only 122 random bits.
> 
> I doubt that. Fixing the remaining bits is a very fast process (compared
> to MD5). Anyway it's still interesting informations ;-).
> 
> > (see the 2nd link of Kornél's post).
> 
> I know about that, I changed Mono implementation based on this more than
> a year ago :-)
> 
> 2004-05-18 Sebastien Pouliot <sebastien at ximian.com>
> 
> * Guid.cs: Fixed thread-safety issue. Simplified implementation to use
> pseudo-random numbers to generate GUIDs (as per section 3.4 of the
> spec). This removes the TODO to get the computer MAC address and
> the chances to get a duplicate GUID (across different machines).
> 
> > Ok, I don't think it's worthwhile to provide an unmanaged InternalCall
> > for a property that obviously nobody uses.
> 
> I _totally_ agree with you on that :-)
> 
> 
> Anyway my main point (beside the performance ;-) was that Mono's
> Type.Guid won't be used for COM (at least not anytime soon) and since we
> don't know how, or even if, this feature is gonna be used in Mono it's
> difficult to know if your MD5 approach is correct or not.
> 
> Like Kornel said someone could depend, even for non-COM purpose, on the
> specific value of a (generated) Guid. Yes that would be bad (on many
> aspects) from any application but it would be easier to find this out
> with an exception.
> --
> Sebastien Pouliot
> email: sebastien at ximian.com
> blog: http://pages.infinit.net/ctech/
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 



-- 
Vladimir Lushnikov
C.E.O and Software Developer
EverythingX Limited (http://www.everythingx.net)

http://mireno.blogspot.com - "Of Life and Programming"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20050903/7628018f/attachment.html