This question already has answers here:
Is a GUID unique 100% of the time?
(24 answers)
Are GUID collisions possible?
(19 answers)
Closed 9 years ago.
I generate keys for my software as:
Guid.NewGuid().ToString();
that returns something like: 15c6bd70-8d3c-42d0-bb24-40da6e08ed9d
anyways everytime someone purchases a new software I generate a new key. can it be possible that I generate the same key twice? Everytime someone purchase the software I call the method: Guid.NewGuid().ToString() Should I append a counter at the end of each guid to be 100% sure that there cannot be duplicates?
Edit
A constructor of the Guid class takes a byte array of 16 bytes as a parameter. If you serialize the current date (8 bytes) then append another 8 random bytes to the constructor of the GUID will that be 100% secure? I am just asking for learning based on your answers I will probably just have Guid.NewGuid()
An excerpt from one of the best blog series ever written about the Guid:
There are a number of possible strategies for making a unique GUID, and in fact information about the strategy used is encoded in the first four bits of the third "group"; almost every GUID you see will be of the form {xxxxxxxx-xxxx-1xxx-xxxx-xxxxxxxxxxxx} or {xxxxxxxx-xxxx-4xxx-xxxx-xxxxxxxxxxxx}.
If there is a one in that place then the algorithm used to guarantee uniqueness is essentially a variation on the ISBN strategy. The GUID is guaranteed to be unique "in space" by choosing some of the bits as the MAC address of the network card in the machine. (The tricky problem of ensuring that no two network cards in the world have the same MAC address is solved somehow by someone else; how that problem is solved, we don't particularly care. The cost of solving that problem is passed on to you, the consumer, in the purchase cost of the network card.)
In short, it's very unlikely that they would ever collide.
Yes, it's possible, but extremely unlikely. The probability for a GUID collision is about as likely as a bit in the GUID changing spontaneously in memory, and that kind of thing is not something that you normally worry about.
You can already be 100% sure, that is of course if you dont mean that you need to be 100.000000000000000000000000000000000000% sure.
Just use the Guid.. no need to append anything. Unless you expect to sell more copies than there are atoms in the universe (unlikely).
Related
This question already has answers here:
YouTube-like GUID
(9 answers)
Closed 7 years ago.
Is it possible to the Hash or digest of a GUID so it is shorter in length while maintaining it's uniqueness?
No. A GUID needs all 128 bits to be globally unique. The bits describe the time, location, and uniqueness identifier (an incrementing key used to prevent the same GUID from being generated if the clock hasn't moved or has been artificially manipulated).
If you have some requirement short of global uniqueness, then yes, you can create locally unique identifiers that are less than 128 bits. There are likely better ways to do this than generating a 128 bit GUID and then coming up with some kind of awesome hashing algorithm that maintains pretty good uniqueness at less than 128 bits.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
class System.Random .. why not static?
Following on from "Generated random numbers are always equal", I was wondering;
Why doesn't the Random class expose a static method for Next with an optional minimum and maximum? This might sound like a silly question, but from experience, 9 times out of 10 I want to generate a random number, without having to explicitly specify a seed? Am I missing something obvious, is there a reason for this? Or is there in fact a method that I'm explaining that I'm yet to discover?
This might sound like a silly question, but from experience, 9 times out of 10 I want to generate a random number, without having to explicitly specify a seed?
You shouldn't be using a static method for that though. You should be using an instance method on something which does maintain state. If you create a new instance of Random every time you call Next, you'll end up with repeated numbers if you call it several times in quick succession.
You should regard "a source of random numbers" as a dependency like any other, IMO - injectable in order to be testable. Of course, if you're not using dependency injection then this argument may not apply... but then you've got other problems.
You probably want one instance of Random per thread, as Random isn't thread-safe.
See my article on random numbers for more details and code samples.
This question already has answers here:
YouTube URL algorithm?
(11 answers)
Closed 3 years ago.
I noticed on YouTube their keys look like this "BwgT06NY1FE". I was just wondering how is this type of key created? Is this based on a GUID?
This is most likely Base36. All letters and numbers. It's pretty common, because you can use a "SERIAL" in a database and just increment it, and then just parse from Base36 in your URL.
It makes for nice URLs (bit.ly also uses this format), but has some drawbacks. Ie, you wouldn't want to use it for any sort of private data because people can just type in a random number and get a result (it's unlikely someone could guess a GUID in use by your database unless they try a few billion)..
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Is a GUID unique 100% of the time?
Basically:
Guid.NewGuid() - Does it loop around or generate through some algorithm?
I want to use Guid because it offers 2^128 possibilities. According to the MSDN:
The chance that the value of the new
Guid will be all zeros or equal to any
other Guid is very low.
The problem is they don't say why it is low. Is it low because the chances are unlikely or is it low because it is unlikely to loop all the way around?
This is a pseudo unique value. The algorithm exists of course, but the probability of getting the same value twice is super small.
They certainly can collide, but MS implementation is quite stable and uses several iterations of hashing (including BIOS timers etc), so that the value is something you can actually rely on.
Update.
There are many more GUID/UUID implementations performed for other purposes (e.g. Guid.comb algorithm for DB surrogate keys) - they actually can collide and I faced this myself in high loaded environments.
Check out: http://en.wikipedia.org/wiki/Globally_unique_identifier#Algorithm
In the OSF-specified algorithm for
generating new (V1) GUIDs, the user's
network card MAC address is used as a
base for the last group of GUID
digits... Most
of the other digits are based on the
time while generating the GUID.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I want to know how many parameters can be passed to function, I mean what is good programming practice, regarding passing the parameters to function?
Code Complete suggests a maximum of 7. This is because of The Magical Number Seven, Plus or Minus Two:
...the number of objects an average human can hold in working memory is 7 ± 2; this is frequently referred to as Miller's Law.
Here's an excerpt from Code Complete 2nd Edition:
Limit the number of a routine’s parameters to about seven
Seven is a magic number for people’s comprehension. Psychological research has found that people generally cannot keep track of more than about seven chunks of information at once (Miller 1956). This discovery has been applied to an enormous number of disciplines, and it seems safe to conjecture that most people can’t keep track of more than about seven routine parameters at once.
The fewer the better, but only if it still makes sense. I've never heard of a standard number of params to be passed, but I have heard of ways to keep them down better.
For example, don't do this:
public void DoSomething(string name, int age, int weight, ...) { }
but rather:
public void DoSomething(Person person) { }
but hopefully that goes without saying. But also, I would recommend not creating a weird class just to trim down the parameter count.
IMHO 5 at MAX.
6 is too much for me and 7 overwhelming!
According to Clean Code - maximum 3
If you have many things you would like to pass to a function you may want to look at some other means of transferring that data as opposed to simple parameter passing. For example in certain cases it may be better to generate an XML file and then pass values related to getting data around that XML file. If you are running a web app it may be simply passing data through sessions or post rather than get or function calls that will simplify your life.
Also you may want to store some of that information as member variables.
I would recommend no more than 4. You don't want your lines to get much longer than 30 characters long unless you are generating some massive string, but even then it becomes really unreadable and gross (although necessary especially for javascript).
It's good programming practice to write programs so that they are easy to read. Personally I try not to write functions which have more parameters than can be displayed on one line on the screen. Usually that is no more than five or six parameters at most.
some ARM compilers pass three or less parameters using registers and any more than three are stacked. The stacked type call is slower than the call using registers so in this case you should use three or less parameters, for speed.
Depending on the architecture, more than 1-3 will cause passing on the stack. This is slower than passing via registers. From a performance standpoint, it is best to pass either a pointer to a wrapper class or a pointer to a struct. This ensures that only one value is passed in and saves some writes/reads to memory.
If you don't know how many parameters you are going to pass to a function use param for sending variable arguments to a method.