• (cs) in reply to AdT
    AdT:
    Cthulhu:
    It might be close enough though. If you generate random 128 bit IDs for 1000,000 users the chance of any two users having the same ID assigned is so low that it can be assumed never to occur.

    Also, you didn't take the so-called birthday problem into account.

    If you generate a million 128-bit random IDs for each of a billion users, you already have a non-negligible chance of producing a dupe. Still less than 0.00000002%, though, so it's more likely that an E.L.E. will happen in the next 10 years.

    I took it into account. When generating a thousand billion 128 bit UIDs, the probability of getting a duplicate UID is lower than 3e-13

  • S (unregistered) in reply to brazzy

    What do I do when I can't reproduce a problem? Take a look at the code the same as Dan did and see if I can spot the error...

    Surely any reasonable dev should be able to do that?

    If you can't spot the error, and can't reproduce that's something else to simply not being able to reproduce it.

  • (cs) in reply to S
    S:
    What do I do when I can't reproduce a problem? Take a look at the code the same as Dan did and see if I can spot the error...

    Surely any reasonable dev should be able to do that?

    If you can't spot the error, and can't reproduce that's something else to simply not being able to reproduce it.

    Not such a big difference. It's usually not at all obvious where in the copious amounts of code to look for the error - and if you can't reproduce the bug you have no way to narrow it down. Adding logging to get more info next time it occurs is then pretty much the only thing you can do.

  • Todd (unregistered) in reply to Cthulhu
    Cthulhu:
    Bisual Vasic:
    1 in a quintillion is still not zero.

    It might be close enough though. If you generate random 128 bit IDs for 1000,000 users the chance of any two users having the same ID assigned is so low that it can be assumed never to occur.

    Spending time implementing some other method that had absolute zero chance of producing duplicates may not be worth the time.

    Do you know what scope_identity()/SELECT @@IDENTITY does or what an outparameter is? That takes more time than using GUIDs?

    My favorite WTF with GUIDs is when I ordered something online got a nice confirmation page with a bolded GUID as the confirmation number but after waiting a few weeks with no response I emailed them with my confirmation html page that I saved and got the response, "Oh that's weird, we don't have anything on record." I have a feeling they were generating the guid on the web server and not caring if it actually got into the database.

    GUIDs are nice for distributed applications but you still have to (ok I guess, you don't have to, but you should) return something from the database that says the records actually got there, IMHO.

  • AdT (unregistered) in reply to brazzy
    brazzy:
    In any case I don't see what it has to do with the discussion at hand - HTTPS ensures nobody can eavesdrop and enables the client to verify the identity of the server, but does not enable the server to authenticate the client's identity, unless you use client certificates, which is very, very rarely done.

    You can safely use HTTP standard authentication mechanisms over SSL, obviating the need to use cookies.

    Cthulhu:
    Calling rand() multiple times will do it fine

    I don't know what language you are talking about. There is no rand() in Visual Basic, and rand() in PHP or Perl will not do it fine since they both produce a sequence of pseudo-random numbers which by default is based on a weak seed with way too little entropy.

    RTFM if you don't believe me, e.g. the documentation for Perl's srand function says:

    "For cryptographic purposes, however, you need something much more random than the default seed."

    and

    "If you're particularly concerned with this, see the Math::TrulyRandom module in CPAN."

  • (cs) in reply to Cthulhu
    Cthulhu:
    AdT:
    Cthulhu:
    It might be close enough though. If you generate random 128 bit IDs for 1000,000 users the chance of any two users having the same ID assigned is so low that it can be assumed never to occur.

    Also, you didn't take the so-called birthday problem into account.

    If you generate a million 128-bit random IDs for each of a billion users, you already have a non-negligible chance of producing a dupe. Still less than 0.00000002%, though, so it's more likely that an E.L.E. will happen in the next 10 years.

    I took it into account. When generating a thousand billion 128 bit UIDs, the probability of getting a duplicate UID is lower than 3e-13

    Many submitters have pointed out that using ordinals from 1 upwards would solve the problem.

    Go with what works. Use the database if necessary. Do not piss around with random numbers for no reason.

    Res ipsa loquitor.

  • Fubar (unregistered)

    Sounds like you aren't doing your job and need to be fired. I also would have fired that coder. You need to step up and be a man, if something is tell them do not beat around the bush.

  • Fubar (unregistered)

    Wrong (insert after something)

    Second solving the problem for them and then having a talk about randomness isn't helping anything or anyone. Your the manager and you need to manage. Not do two jobs. maybe you should be a coder and not a manager. Might save you getting fired in the end.

  • Al (unregistered) in reply to FredSaw

    I think thats the key. If a developer says that this is only going to happen once in every ten thousand times, someone has to make the decision as to whether it makes 'economic' sense to persue a fix to something that may not happen again.

    Second time out though, invite the developer to explain why that would be the case and why it has happened twice in a week.

  • Fool (unregistered)

    How about... Don't close a damn bug that hasn't been proven to be fixed?!!

  • Ze (unregistered) in reply to Fubar
    Fubar:
    Wrong (insert after something)

    Second solving the problem for them and then having a talk about randomness isn't helping anything or anyone. Your the manager and you need to manage. Not do two jobs. maybe you should be a coder and not a manager. Might save you getting fired in the end.

    I think the manager educating the developers is a good thing. I know I respect managers who actually know about development more than I respect managers who are just good at managers.

    If a manager is ahead of the developers in an area he should share his knowledge , if they are ahead of him in an area they should their knowledge.

  • Jenda (unregistered)

    I've seen worse. Much worse. Though it did not make it to production, we took over the project from that team in time.

    The indiot

    • connected to database
    • selected the max id
    • disconnected
    • incremented
    • did something fairly unrelated
    • connected to the database
    • turned IDENTITY_INSERT ON (MS SQL)
    • inserted the data into the table (or maybe not)
    • ignored any possible errors from the database within the data access layer
    • ignored any possible errors from the DAL
    • disconnected
    • reported success

    But everything worked fine when he presented the app ...

    Captcha: kungfu - yeah, that's what should have been used against those Vinods, Kumars and the rest of those indiots.

  • Anonymous (unregistered)

    Nice Microsoft ad there.

  • ELIZA (unregistered) in reply to Dev Mgr
    Dev Mgr:
    > Not true. Bizarre data flukes happen all the time.

    If you really believe that, do not bother to seek employment in my department. there is always a reason for 'data flukes'.

    A coder turned dev manager

    Yes, there is always a reason: The first instance, if I understood it correctly, was that the two were booked on the same flight (the double-booking was explicitly a consequence of this; that, of course, is unexcusable). There is no law of physics excluding two people booking the same flight within one tick of each other, as long as the tick is considerably larger than the processor clock rate. Suppose, conservatively, that there are 1000 flights per day (the US airliner count alone is reputedly over sixteen thousand, many of which (cf Aloha Airlines) make more than a dozen flights a day) that are booked uniformly over 2 days, each of which holds 201 passengers, and that there are 1000 possible equally popular booking agencies to choose from, and that the tick is one millisecond. What is the minimum period in which the probability is one half or greater that such a coincidence occurs? This is analogous to the supposed Birthday Paradox. The number of people minus 1, k, is 200, the number of days, n, is 172800000000, and we intend to find the lowest x such that, designating the individual coincidence probability p, (1-p)^(1000x)=<0.5 First, (1-p)=(n-1)(n-2)...(n-k+1)(n-k)/n^k =product(i=0 to ((k/2)-1),((n-1-i)(n-k+i)))/n^k // for even k (n-1-i)*(n-k+i)=n^2-n-nk (1-p)=((n-1-k)/n)^(k/2) (1-p)=(172799999799/172800000000)^100, or about 0.999999884, and a little trial and error shows that x = 5959 days. As an aside, since (1-p)^365.2425 is roughly 0.958405025, my calculation predicts a chance of greater than one in 25 that such a "data fluke" happens, somewhere, in a year. Assuming 16000 airliners and one flight per day, x = 373 days, and it is more likely than not that it happens at least once, somewhere, in any given year.

  • Zikan (unregistered) in reply to brazzy

    I seek help from a more senior developer. You know, one of those who make double my wage.

Leave a comment on “Identity Crisis ”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article