467,116 Members | 1,165 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,116 developers. It's quick & easy.

GUID

Hi,

The following is from MSDN.

"A GUID is a 128-bit integer (16 bytes) that can be used across all
computers and networks wherever a unique identifier is required. Such
an identifier has a very low probability of being duplicated."

My application will crush if I have two or more number that are
identical, so I need to know do I need to worry about this"
very low probability " of having two identical numbers generated from
Guid structure.

Thanks.

Nov 17 '05 #1
  • viewed: 3091
Share:
10 Replies
I don't think you will have an issue with using a GUID.

Are you using this in a database table as the primary key?
<ww*****@gmail.com> wrote in message
news:11**********************@l41g2000cwc.googlegr oups.com...
Hi,

The following is from MSDN.

"A GUID is a 128-bit integer (16 bytes) that can be used across all
computers and networks wherever a unique identifier is required. Such
an identifier has a very low probability of being duplicated."

My application will crush if I have two or more number that are
identical, so I need to know do I need to worry about this"
very low probability " of having two identical numbers generated from
Guid structure.

Thanks.

Nov 17 '05 #2
> "A GUID is a 128-bit integer (16 bytes) that can be used across all
computers and networks wherever a unique identifier is required. Such
an identifier has a very low probability of being duplicated."

My application will crush if I have two or more number that are
identical, so I need to know do I need to worry about this"
very low probability " of having two identical numbers generated from
Guid structure.

It is based on a nework card MAC, and these should be unique on all network
cards.
Also take into account the date and time and some random generator and the
chance that you get a duplicate is almost none existing. It happens maybe
once if a milennium? ;-)
Nov 17 '05 #3
Well, you know.

a 128 number is a 128 bit number. Chances are much higher to win a 6 in a
lottery than you having two double GUIDs.

Risk the crash. I do the same for about 5 years, and never ever got a
double. Not once.

Just translate 2^128 to decmial to see what you talk about.

This translates to 340.200.000.000.000.000.000.000.000.000.000.000.00 0.
Roughly.

--
Regards

Thomas Tomiczek
THONA Software & Consulting Ltd.
(Microsoft MVP C#/.NET)
(CTO PowerNodes Ltd.)
---

Still waiting for ObjectSpaces? Try the EntityBroker today - more versatile,
more powerfull.
And something in use NOW. for the projects you have to deliver - NOW.
<ww*****@gmail.com> wrote in message
news:11**********************@l41g2000cwc.googlegr oups.com...
Hi,

The following is from MSDN.

"A GUID is a 128-bit integer (16 bytes) that can be used across all
computers and networks wherever a unique identifier is required. Such
an identifier has a very low probability of being duplicated."

My application will crush if I have two or more number that are
identical, so I need to know do I need to worry about this"
very low probability " of having two identical numbers generated from
Guid structure.

Thanks.

Nov 17 '05 #4

<ww*****@gmail.com> wrote in message
news:11**********************@l41g2000cwc.googlegr oups.com...
Hi,

The following is from MSDN.

"A GUID is a 128-bit integer (16 bytes) that can be used across all
computers and networks wherever a unique identifier is required. Such
an identifier has a very low probability of being duplicated."

My application will crush if I have two or more number that are
identical, so I need to know do I need to worry about this"
very low probability " of having two identical numbers generated from
Guid structure.

Thanks.


Again, if you don't have a network card, the GUID will be semi-unique.
With a network card your GUID will be guranteed to be unique for many
millenia to come.

So you should not worry.

Happy Coding
- Michael S
- Michael S
Nov 17 '05 #5
Actually it is not longer using the Mac address.
But if it was using it would be disaster, becouse every 16 years old
teenager who has a computer in his father garage is can changing the
Mac address of his computer. Now it is really comon becouse some
Internet Providers are identifing the computer by their Mac address and
people do cange their Mac address to steal someone else Internet. So if
I was depending on the Mac address and I can crush my application.

In someones blog I was reading that GUID is no longer using the Mac
address.
But any way my question is - could I really depend on GUID.
And If I am writing something that I do not want to take any chances.

Do you find it reasonable to check every time whether I have
duplicates.

Thanks

Nov 17 '05 #6
Yes. You can depend on GUID's. We have several applications that use a GUID
as a primary key and have not had any issues of duplicates.

If you are that uncomfortable with using GUID's in fear of duplicates, then
do what you suggested and check to see if the GUID exists before using it.

Good luck!

Yosh

<ww*****@gmail.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...
Actually it is not longer using the Mac address.
But if it was using it would be disaster, becouse every 16 years old
teenager who has a computer in his father garage is can changing the
Mac address of his computer. Now it is really comon becouse some
Internet Providers are identifing the computer by their Mac address and
people do cange their Mac address to steal someone else Internet. So if
I was depending on the Mac address and I can crush my application.

In someones blog I was reading that GUID is no longer using the Mac
address.
But any way my question is - could I really depend on GUID.
And If I am writing something that I do not want to take any chances.

Do you find it reasonable to check every time whether I have
duplicates.

Thanks

Nov 17 '05 #7
> Actually it is not longer using the Mac address.
But if it was using it would be disaster, becouse every 16 years old
teenager who has a computer in his father garage is can changing the
Mac address of his computer. Now it is really comon becouse some
Internet Providers are identifing the computer by their Mac address and
people do cange their Mac address to steal someone else Internet. So if
I was depending on the Mac address and I can crush my application.

I doubt that very much that the MAC address is not used anymore.
But it is not only the Mac address, but also the processor ID, harddisk
ID,... anything that has a unique ID in it is beeing used as far as I heard.
So even if the MAC address is beeing duplicated, the GUID will still be
unique.
Nov 17 '05 #8

"Olaf Baeyens" <ol**********@skyscan.be> wrote in message
news:42**********************@news.skynet.be...
Actually it is not longer using the Mac address.
But if it was using it would be disaster, becouse every 16 years old
teenager who has a computer in his father garage is can changing the
Mac address of his computer. Now it is really comon becouse some
Internet Providers are identifing the computer by their Mac address and
people do cange their Mac address to steal someone else Internet. So if
I was depending on the Mac address and I can crush my application.

I doubt that very much that the MAC address is not used anymore.
But it is not only the Mac address, but also the processor ID, harddisk
ID,... anything that has a unique ID in it is beeing used as far as I
heard.
So even if the MAC address is beeing duplicated, the GUID will still be
unique.


The MAC address might still be used on downlevel windows W95 and 98 when
generating UUID's (DCE algorithm), but the UUID generation algorithm has
been changed to a random number on NT based systems years ago.
Other stuff like CPU Id and HW disk numbers have never been part of the
UUID.
Just run uuidgen a couple of times from the commandline and watch the
result, if anything like MAC address would be part of it you would notice
it, right?

Willy.

Nov 17 '05 #9
> The MAC address might still be used on downlevel windows W95 and 98 when
generating UUID's (DCE algorithm), but the UUID generation algorithm has
been changed to a random number on NT based systems years ago.
Other stuff like CPU Id and HW disk numbers have never been part of the
UUID.
Just run uuidgen a couple of times from the commandline and watch the
result, if anything like MAC address would be part of it you would notice
it, right?

This strikes me very odd, since you had a almost guaranteed unique systesm
because the MAC address and CPU ID were completely unique. And this in
combination with a time could generate a really unique GUID. Ok CPU ID can
be deactivated, and the MAC addres could be duplicated, but still most users
would probably have a unique MAC address, so in my opinion this could
improve the uniqueness of the GUID even more.

I always thought that generating perfect random numbers were alsmost
impossible in software. You could come close to it (hence the seed) but it
was not really random. So by not using the MAC address you have an increased
risk that a random number happen to occur 2 times.

So I am wondering why they did this?

Anyway, unique GUID or not, anyone relying on unique numbers should at least
built a protection in his software in case a duplicate GUID is used. Not
because GUID is bad, but because people might generate a fixed GUID on
purpose to crash that software in order to some bad things with it. Hackers
are very good in this.
Nov 17 '05 #10

"Olaf Baeyens" <ol**********@skyscan.be> wrote in message
news:42**********************@news.skynet.be...
The MAC address might still be used on downlevel windows W95 and 98 when
generating UUID's (DCE algorithm), but the UUID generation algorithm has
been changed to a random number on NT based systems years ago.
Other stuff like CPU Id and HW disk numbers have never been part of the
UUID.
Just run uuidgen a couple of times from the commandline and watch the
result, if anything like MAC address would be part of it you would notice
it, right?

This strikes me very odd, since you had a almost guaranteed unique systesm
because the MAC address and CPU ID were completely unique. And this in
combination with a time could generate a really unique GUID. Ok CPU ID can
be deactivated, and the MAC addres could be duplicated, but still most
users
would probably have a unique MAC address, so in my opinion this could
improve the uniqueness of the GUID even more.

I always thought that generating perfect random numbers were alsmost
impossible in software. You could come close to it (hence the seed) but it
was not really random. So by not using the MAC address you have an
increased
risk that a random number happen to occur 2 times.

So I am wondering why they did this?

Anyway, unique GUID or not, anyone relying on unique numbers should at
least
built a protection in his software in case a duplicate GUID is used. Not
because GUID is bad, but because people might generate a fixed GUID on
purpose to crash that software in order to some bad things with it.
Hackers
are very good in this.


Guid.NewGuid() winds up in calling Win32's CryptGenRandom on W2K and higher
boxes.
Chances that you get two 16 byte sequences that are equal from this random
number generator is 1/(2^128).
Note that unlike rand(), CryptGenRandom isn't a repeatable random number
generator, so you can give it the same seed twice in a row, you'll get
totaly different numbers back.

Why the change?
1. Privacy and security concerns, people didn't like to give away their MAC
address.
2. Setting the clock back is obviously the weak point of the OSF DCE
algorithm.

Willy.

Nov 17 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

4 posts views Thread by Louis Frolio | last post: by
6 posts views Thread by Jim Heavey | last post: by
9 posts views Thread by Rene | last post: by
14 posts views Thread by Nak | last post: by
5 posts views Thread by George | last post: by
1 post views Thread by Wolf | last post: by
5 posts views Thread by Michael Primeaux | last post: by
4 posts views Thread by Marc | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.