GUID

  • Thread starter Thread starter www.dir
  • Start date Start date
W

www.dir

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.
 
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?
 
"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.
Click to expand...
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? ;-)
 
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.000.
Roughly.

--
Regards

Thomas Tomiczek
THONA Software & Consulting Ltd.
(Microsoft MVP C#/.NET)
(CTO PowerNodes Ltd.)
 
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.
Click to expand...

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
 
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
 
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
 
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.
Click to expand...
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.
 
Olaf Baeyens said:
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.
Click to expand...

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.
 
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?
Click to expand...
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.
 
Olaf Baeyens said:
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.
Click to expand...

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.
 
Back
Top