[Mono-dev] Type.GUID patch

Sebastien Pouliot sebastien.pouliot at gmail.com
Sat Sep 3 17:57:48 EDT 2005


Hello Vladimir,

While "unique" isn't possible with a finite-length value [1] calling
Guid.NewGuid will, like the links says, get you 122 bits (out of 128) of
pseudo randomly generated bits [2] - which is quite a big number [3]. So
yeah they are "unique enough" wrt to your server lifetime ;-)

[1] that's the kind of answer you get from people doing crypto ;-)

[2] the source of randomness differs from platforms (/dev/[u]random on
Linux and other OS supporting it, CryptoAPI on Win32, EGD ...)

[3] which means a _very_ small collision probability.

On Sat, 2005-03-09 at 22:43 +0100, Vladimir Lushnikov wrote:
> 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"
-- 
Sebastien Pouliot
email: sebastien at ximian.com
blog: http://pages.infinit.net/ctech/




More information about the Mono-devel-list mailing list