Semplice prova che il GUID non è univoco [chiuso]

Vorrei dimostrare che un GUID non è unico in un semplice programma di test. Mi aspettavo che il seguente codice funzionasse per ore, ma non funziona. Come posso farlo funzionare?

BigInteger begin = new BigInteger((long)0);
BigInteger end = new BigInteger("340282366920938463463374607431768211456",10);  //2^128
for(begin; begin<end; begin++)
  Console.WriteLine(System.Guid.NewGuid().ToString());

Sto usando C #.

Kai, ho fornito un programma che farà quello che vuoi usando i thread. È concesso in licenza ai seguenti termini: è necessario pagarmi $ 0,0001 l'ora per core della CPU su cui lo si esegue. Le commissioni sono pagabili alla fine di ogni mese di calendario. Vi prego di contattarmi per i dettagli del mio account paypal al più presto.

using System;
using System.Collections.Generic;
using System.Linq;

namespace GuidCollisionDetector
{
    class Program
    {
        static void Main(string[] args)
        {
            //var reserveSomeRam = new byte[1024 * 1024 * 100];     // This indeed has no effect.

            Console.WriteLine("{0:u} - Building a bigHeapOGuids.", DateTime.Now);
            // Fill up memory with guids.
            var bigHeapOGuids = new HashSet<Guid>();
            try
            {
                do
                {
                    bigHeapOGuids.Add(Guid.NewGuid());
                } while (true);
            }
            catch (OutOfMemoryException)
            {
                // Release the ram we allocated up front.
                // Actually, these are pointless too.
                //GC.KeepAlive(reserveSomeRam);
                //GC.Collect();
            }
            Console.WriteLine("{0:u} - Built bigHeapOGuids, contains {1} of them.", DateTime.Now, bigHeapOGuids.LongCount());


            // Spool up some threads to keep checking if there's a match.
            // Keep running until the heat death of the universe.
            for (long k = 0; k < Int64.MaxValue; k++)
            {
                for (long j = 0; j < Int64.MaxValue; j++)
                {
                    Console.WriteLine("{0:u} - Looking for collisions with {1} thread(s)....", DateTime.Now, Environment.ProcessorCount);
                    System.Threading.Tasks.Parallel.For(0, Int32.MaxValue, (i) =>
                    {
                        if (bigHeapOGuids.Contains(Guid.NewGuid()))
                            throw new ApplicationException("Guids collided! Oh my gosh!");
                    }
                    );
                    Console.WriteLine("{0:u} - That was another {1} attempts without a collision.", DateTime.Now, ((long)Int32.MaxValue) * Environment.ProcessorCount);
                }
            }
            Console.WriteLine("Umm... why hasn't the universe ended yet?");
        }
    }
}

PS: volevo provare la libreria di estensioni parallele. È stato facile.

E usare OutOfMemoryException come flusso di controllo sembra sbagliato.

MODIFICARE

Bene, sembra che questo attiri ancora voti. Quindi ho risolto il problema GC.KeepAlive (). E lo ha cambiato per funzionare con C # 4.

E per chiarire i miei termini di supporto: il supporto è disponibile solo il 28 febbraio 2010. Si prega di utilizzare una macchina del tempo per effettuare richieste di supporto solo in quel giorno.

EDIT 2 Come sempre, il GC fa un lavoro migliore di me nella gestione della memoria; ogni precedente tentativo di farlo da solo era destinato al fallimento.

Questo durerà per molto più di ore. Supponendo che si giri a 1 GHz (che non lo farà - sarà molto più lento di così), funzionerà per 10790283070806014188970 anni. Che è circa 83 miliardi di volte più lungo dell'età dell'universo.

Supponendo che la legge di Moores sia valida, sarebbe molto più veloce non eseguire questo programma, attendere diverse centinaia di anni ed eseguirlo su un computer miliardi di volte più veloce. In effetti, qualsiasi programma che impiega più tempo a funzionare di quanto richieda il raddoppio della velocità della CPU (circa 18 mesi) si completerà prima se aspetti che le velocità della CPU siano aumentate e acquisti una nuova CPU prima di eseguirla (a meno che tu non lo scriva in modo che può essere sospeso e ripreso sul nuovo hardware).

Un GUID è teoricamente non unico. Ecco la tua prova:

• Il GUID è un numero a 128 bit
• Non è possibile generare 2 ^ 128 + 1 o più GUID senza riutilizzare i vecchi GUID

Tuttavia, se l'intera potenza del sole fosse diretta a svolgere questo compito, si raffredderebbe molto prima che finisse.

I GUID possono essere generati utilizzando una serie di tattiche diverse, alcune delle quali adottano misure speciali per garantire che un determinato computer non generi lo stesso GUID due volte. La ricerca di collisioni in un particolare algoritmo mostrerebbe che il tuo metodo particolare per la generazione di GUID è negativo, ma non proverebbe nulla sui GUID in generale.

Naturalmente i GUID possono scontrarsi. Poiché i GUID sono a 128 bit, basta generarli 2^128 + 1e in base al principio del buco del piccione ci deve essere una collisione.

Ma quando diciamo che un GUID è univoco, ciò che realmente intendiamo è che lo spazio delle chiavi è così grande che è praticamente impossibile generare accidentalmente lo stesso GUID due volte (supponendo che stiamo generando i GUID in modo casuale).

Se si genera una sequenza di nGUID in modo casuale, la probabilità di almeno una collisione è approssimativamente p(n) = 1 - exp(-n^2 / 2 * 2^128)(questo è il problema del compleanno con il numero di possibili compleanni 2^128).

   n     p(n)
2^30 1.69e-21
2^40 1.77e-15
2^50 1.86e-10
2^60 1.95e-03

Per rendere questi numeri concreti, 2^60 = 1.15e+18. Quindi, se generi un miliardo di GUID al secondo, ci vorranno 36 anni per generare 2^60GUID casuali e anche allora la probabilità che tu abbia una collisione è ancora 1.95e-03. È più probabile che tu venga ucciso ad un certo punto della tua vita ( 4.76e-03) rispetto a trovare una collisione nei prossimi 36 anni. In bocca al lupo.

Se sei preoccupato per l'unicità, puoi sempre acquistare nuovi GUID in modo da poter eliminare quelli vecchi. Ne metterò un po 'su eBay, se lo desideri.

Personalmente, penso che il "Big Bang" sia stato causato quando due GUID si sono scontrati.

Puoi mostrarlo in O (1) tempo con una variante dell'algoritmo quantistico di bogosort .

Guid g1 = Guid.NewGuid();
Guid g2 = Guid.NewGuid();
if(g1 != g2) Universe.Current.Destroy();

Eventuali due GUID sono probabilmente unici (non uguali).

Vedi questa voce SO e da Wikipedia

Sebbene non sia garantito che ogni GUID generato sia univoco, il numero totale di chiavi univoche (2 ^ 128 o 3.4 × 10 ^ 38) è così grande che la probabilità che lo stesso numero venga generato due volte è molto piccola. Ad esempio, considera l'universo osservabile, che contiene circa 5 × 10 ^ 22 stelle; ogni stella potrebbe quindi avere 6,8 × 10 ^ 15 GUID universalmente unici.

Quindi probabilmente devi aspettare ancora molti miliardi di anni e sperare di averne colpito uno prima dell'universo, dato che sappiamo che finisce.

[Aggiornamento:] Come sottolineato nei commenti seguenti, i più recenti GUID MS sono V4 e non usano l'indirizzo MAC come parte della generazione GUID (non ho visto alcuna indicazione di un'implementazione V5 da parte di MS, quindi se qualcuno ha un link di conferma che fammi sapere). Con V4, però, il tempo è ancora un fattore, e le probabilità contro la duplicazione dei GUID rimangono così piccole da essere irrilevanti per qualsiasi uso pratico. Certamente non sarebbe probabilmente mai possibile generare un GUID duplicato da un solo test di sistema come quello che l'OP stava cercando di fare.

Alla maggior parte di queste risposte manca un punto vitale sull'implementazione GUID di Microsoft. La prima parte del GUID si basa su un timestamp e un'altra parte si basa sull'indirizzo MAC della scheda di rete (o su un numero casuale se non è installata alcuna scheda NIC).

Se lo capisco correttamente, significa che l'unico modo affidabile per duplicare un GUID sarebbe quello di eseguire simultaneamente generazioni GUID su più macchine in cui gli indirizzi MAC erano gli stessi E dove gli orologi su entrambi i sistemi erano nello stesso momento esatto in cui la generazione si è verificato (il timestamp si basa su millisecondi se lo capisco correttamente) .... anche allora ci sono molti altri bit nel numero che sono casuali, quindi le probabilità sono ancora minuscole.

Per tutti gli scopi pratici i GUID sono universalmente unici.

C'è una descrizione abbastanza buona del MS GUID sul blog "The Old New Thing"

Ecco un piccolo metodo di estensione che puoi usare se vuoi controllare l'unicità di guid in molti punti del tuo codice.

internal static class GuidExt
{
    public static bool IsUnique(this Guid guid)
    {
        while (guid != Guid.NewGuid())
        { }
        return false;
    }
}

Per chiamarlo, è sufficiente chiamare Guid.IsUnique ogni volta che si genera un nuovo guid ...

Guid g = Guid.NewGuid();
if (!g.IsUnique())
{
    throw new GuidIsNotUniqueException();
}

... diamine, ti consiglio persino di chiamarlo due volte per assicurarmi che sia andato bene nel primo round.

Contando fino a 2 ^ 128 - ambizioso.

Immaginiamo di poter contare 2 ^ 32 ID al secondo per macchina - non così ambizioso, dal momento che non è nemmeno 4,3 miliardi al secondo. Dedichiamo 2 ^ 32 macchine a tale compito. Inoltre, consente di ottenere 2 ^ 32 civiltà per dedicare ciascuna le stesse risorse all'attività.

Finora, possiamo contare 2 ^ 96 ID al secondo, il che significa che conteremo per 2 ^ 32 secondi (poco più di 136 anni).

Ora, tutto ciò di cui abbiamo bisogno è di ottenere 4.294.967.296 civiltà a ciascuna dedicata 4.294.967.296 macchine, ogni macchina in grado di contare 4.294.967.296 ID al secondo, puramente per questo compito per i prossimi 136 anni circa - suggerisco di iniziare subito questo compito essenziale; -)

Bene, se il tempo di esecuzione di 83 miliardi di anni non ti spaventa, pensa che dovrai anche archiviare i GUID generati da qualche parte per verificare se ne hai un duplicato; la memorizzazione di 2 ^ 128 numeri a 16 byte richiederebbe solo di allocare 4951760157141521099596496896 terabyte di RAM in anticipo, quindi immaginando di avere un computer che potrebbe adattarsi a tutto ciò e che in qualche modo trovi un posto per acquistare DIMM terabyte a 10 grammi ciascuno, combinati pesa più di 8 masse terrestri, quindi puoi spostarla seriamente dall'orbita attuale, prima ancora di premere "Esegui". Pensa due volte!

for(begin; begin<end; begin)
    Console.WriteLine(System.Guid.NewGuid().ToString());

Non stai incrementando, beginquindi la condizione begin < endè sempre vera.

Se le collisioni GUID sono un problema, consiglierei invece di utilizzare ScottGuID .

Presumibilmente hai motivo di credere che l'algoritmo per la produzione di Guide non stia producendo numeri veramente casuali, ma in realtà sta pedalando con un periodo << 2 ^ 128.

ad esempio il metodo RFC4122 utilizzato per derivare GUID che fissa i valori di alcuni bit.

La prova del ciclismo dipenderà dalla possibile dimensione del periodo.

Per piccoli periodi, la tabella hash di hash (GUID) -> GUID con sostituzione in caso di collisione se i GUID non corrispondono (terminano in caso affermativo) potrebbe essere un approccio. Considera anche di fare la sostituzione solo una frazione casuale del tempo.

In definitiva, se il periodo massimo tra le collisioni è abbastanza grande (e non è noto in anticipo), qualsiasi metodo produrrà solo una probabilità che la collisione sarebbe trovata se esistesse.

Tieni presente che se il metodo di generazione delle guide è basato sull'orologio (vedi RFC), potrebbe non essere possibile determinare se esistono collisioni perché (a) non sarai in grado di attendere abbastanza a lungo affinché l'orologio si avvolga, oppure (b) non è possibile richiedere un numero sufficiente di Guide entro un orologio per forzare una collisione.

In alternativa, potresti essere in grado di mostrare una relazione statistica tra i bit nella Guida o una correlazione di bit tra le Guide. Tale relazione potrebbe rendere altamente probabile che l'algoritmo sia difettoso senza essere necessariamente in grado di trovare una collisione effettiva.

Ovviamente, se vuoi solo dimostrare che le Guide possono scontrarsi, allora una prova matematica, non un programma, è la risposta.

Non capisco perché nessuno abbia menzionato l'aggiornamento della tua scheda grafica ... Sicuramente se avessi una NVIDIA Quadro FX 4800 di fascia alta o qualcosa del genere (192 core CUDA) questo andrebbe più veloce ...

Ovviamente se potessi permetterti un paio di NVIDIA Qadro Plex 2200 S4 (a 960 core CUDA ciascuno), questo calcolo urlerebbe davvero . Forse NVIDIA sarebbe disposta a prestarti alcuni per una "dimostrazione di tecnologia" come acrobazia pubblicitaria?

Sicuramente vorrebbero far parte di questo calcolo storico ...

Ma devi essere sicuro di avere un duplicato o ti importa solo se può esserci un duplicato. Per essere sicuro di avere due persone con lo stesso compleanno, hai bisogno di 366 persone (senza contare l'anno bisestile). Perché ci sia una probabilità superiore al 50% di avere due persone con lo stesso compleanno, hai bisogno solo di 23 persone. Questo è il problema del compleanno .

Se si dispone di 32 bit, sono necessari solo 77.163 valori per avere una probabilità superiore al 50% di un duplicato. Provalo:

Random baseRandom = new Random(0);

int DuplicateIntegerTest(int interations)
{
    Random r = new Random(baseRandom.Next());
    int[] ints = new int[interations];
    for (int i = 0; i < ints.Length; i++)
    {
        ints[i] = r.Next();
    }
    Array.Sort(ints);
    for (int i = 1; i < ints.Length; i++)
    {
        if (ints[i] == ints[i - 1])
            return 1;
    }
    return 0;
}

void DoTest()
{
    baseRandom = new Random(0);
    int count = 0;
    int duplicates = 0;
    for (int i = 0; i < 1000; i++)
    {
        count++;
        duplicates += DuplicateIntegerTest(77163);
    }
    Console.WriteLine("{0} iterations had {1} with duplicates", count, duplicates);
}

1000 iterations had 737 with duplicates

Adesso 128 bit sono molti, quindi stai ancora parlando di un gran numero di elementi, dandoti comunque una bassa possibilità di collisione. Avresti bisogno del seguente numero di record per le probabilità date usando un'approssimazione:

• 0,8 miliardi di miliardi per una probabilità 1/1000 di una collisione
• 21,7 miliardi di miliardi con il 50% di probabilità che si verifichi una collisione
• 39,6 miliardi di miliardi con una probabilità del 90% di una collisione

Ci sono circa 1E14 e-mail inviate all'anno, quindi sarebbero circa 400.000 anni a questo livello prima che tu abbia il 90% di possibilità di averne due con lo stesso GUID, ma è molto diverso dal dire che devi eseguire un computer 83 miliardi volte l'età dell'universo o che il sole diventasse freddo prima di trovare un duplicato.

Non vi mancate tutti un punto importante?

Ho pensato che i GUID fossero generati usando due cose che rendono le probabilità che fossero globalmente uniche piuttosto alte. Uno è che vengono seminati con l'indirizzo MAC della macchina su cui ci si trova e due usano il tempo in cui sono stati generati più un numero casuale.

Quindi, a meno che non lo si esegua sulla macchina reale e si esegua tutto ciò che si suppone nel minor tempo che la macchina utilizza per rappresentare un tempo nel GUID, non si genererà mai lo stesso numero, indipendentemente dal numero di ipotesi effettuate utilizzando la chiamata di sistema.

Immagino che se si conosce il modo in cui viene realizzato un GUID si accorcerebbe effettivamente il tempo di indovinare sostanzialmente.

Tony

È possibile eseguire l'hashing dei GUID. In questo modo, dovresti ottenere un risultato molto più velocemente.

Oh, ovviamente, anche eseguire più thread contemporaneamente è una buona idea, in questo modo aumenterai la possibilità che una condizione di competizione generi lo stesso GUID due volte su thread diversi.

I GUID sono 124 bit perché 4 bit contengono il numero di versione.

1. Vai al laboratorio di criogenia a New York City.
2. Congelati per (circa) 1990 anni.
3. Trova un lavoro presso Planet Express.
4. Acquista una CPU nuova di zecca. Costruisci un computer, esegui il programma e posizionalo in un luogo sicuro con una macchina da movimento pseudo-perpetua come la macchina del giorno del giudizio.
5. Attendere fino all'invenzione della macchina del tempo.
6. Salta al futuro usando la macchina del tempo. Se hai acquistato una CPU a 1 bit da 128 bit, vai a 3,938,453,320 days 20 hours 15 minutes 38 seconds 463 ms 463 μs 374 ns 607 psdopo quando hai iniziato a eseguire il programma.
7. ...?
8. PROFITTO!!!

... Ci vogliono almeno 10,783,127anni anche se hai una CPU da 1YHz che è 1,000,000,000,000,000(o 1,125,899,906,842,624se preferisci usare il prefisso binario) volte più veloce della CPU da 1GHz.

Quindi, piuttosto che attendere il completamento del calcolo, sarebbe meglio nutrire i piccioni che hanno perso la casa perché altri npiccioni hanno preso la loro casa. :(

In alternativa, è possibile attendere fino all'invenzione del computer quantistico a 128 bit. Quindi potresti provare che il GUID non è unico, usando il tuo programma in tempi ragionevoli (forse).

Hai provato begin = begin + new BigInteger((long)1)al posto di begin ++?

Se il numero di UUID che viene generato segue la legge di Moore, l'impressione di non rimanere mai senza GUID nel prossimo futuro è falsa.

Con 2 ^ 128 UUID, ci vorranno solo 18 mesi * Log2 (2 ^ 128) ~ = 192 anni, prima che finiamo tutti gli UUID.

E credo (senza prove statistiche di sorta) negli ultimi anni dall'adozione in massa dell'UUID, la velocità che stiamo generando UUID sta aumentando molto più velocemente di quanto impone la legge di Moore. In altre parole, probabilmente abbiamo meno di 192 anni prima di dover affrontare la crisi UUID, che è molto prima della fine dell'universo.

Ma dal momento che sicuramente non li esauriremo entro la fine del 2012, lasceremo ad altre specie di preoccuparsi del problema.

Le probabilità di un bug nel codice di generazione del GUID sono molto più alte delle probabilità dell'algoritmo che genera una collisione. Le probabilità di un bug nel tuo codice per testare i GUID sono ancora maggiori. Abbandonare.

Il programma, sebbene i suoi errori, mostra la prova che un GUID non è univoco. Coloro che cercano di dimostrare il contrario non hanno ragione. Questa affermazione dimostra solo la debole implementazione di alcune delle varianti GUID.

Un GUID non è necessario univoco per definizione, è altamente unico per definizione. Hai appena raffinato il significato di altamente. A seconda della versione, dell'attuatore (MS o di altri), dell'uso di VM, ecc., La tua definizione di cambiamenti significativi. (vedi link nel post precedente)

Puoi abbreviare la tabella a 128 bit per dimostrare il tuo punto. La soluzione migliore è utilizzare una formula di hash per abbreviare la tabella con i duplicati, quindi utilizzare il valore completo una volta che l'hash si scontra e sulla base di quella rigenerazione di un GUID. Se corri da posizioni diverse, dovresti archiviare le tue coppie di chiavi hash / complete in una posizione centrale.

Ps: se l'obiettivo è solo generare un numero x di valori diversi, crea una tabella hash di questa larghezza e controlla semplicemente il valore hash.

Non per p ** s sul falò qui, ma in realtà succede, e sì, capisco lo scherzo che hai dato a questo ragazzo, ma il GUID è unico solo in linea di principio, mi sono imbattuto in questo thread perché c'è un bug nell'emulatore WP7 che significa che ogni volta che si avvia emette il SAME GUID la prima volta che viene chiamato! Quindi, laddove in teoria non si può avere un conflitto, se si verifica un problema durante la generazione di detta GUI, è possibile ottenere duplicati

http://forums.create.msdn.com/forums/p/92086/597310.aspx#597310

Poiché parte della generazione di Guid si basa sul tempo della macchina corrente, la mia teoria per ottenere una guida duplicata è:

1. Eseguire un'installazione pulita di Windows
2. Crea uno script di avvio che reimposta l'ora al 01-01-2010 alle 12:00:00 proprio all'avvio di Windows.
3. Subito dopo lo script di avvio, avvia l'applicazione per generare un Guid.
4. Clonare questa installazione di Windows, in modo da escludere eventuali sottili differenze che potrebbero verificarsi nei successivi avviamenti.
5. Ri-immagine del disco rigido con questa immagine e avviare il computer alcune volte.

Per me .. il tempo impiegato da un singolo core per generare un UUIDv1 garantisce che sarà unico. Anche in una situazione multi-core se il generatore UUID consente di generare un solo UUID alla volta per la tua risorsa specifica (tieni presente che più risorse possono utilizzare totalmente gli stessi UUID, anche se è improbabile poiché la risorsa è intrinsecamente parte dell'indirizzo) avrà UUID più che sufficienti per durare fino allo scadere del timestamp. A quel punto dubito davvero che ti importerebbe.

Ecco anche una soluzione:

int main()
{
  QUuid uuid;
  while ( (uuid = QUuid::createUuid()) != QUuid::createUuid() ) { }
  std::cout << "Aha! I've found one! " << qPrintable( uuid.toString() ) << std::endl;
}

Nota: richiede Qt, ma garantisco che se lo lasci funzionare abbastanza a lungo, potrebbe trovarne uno.

(Nota nota: in realtà, ora che lo sto guardando, potrebbe esserci qualcosa nell'algoritmo di generazione che impedisce a due uuidi successivamente generati di scontrarsi, ma ne dubito).

L'unica soluzione per dimostrare che i GUID non sono unici sarebbe avere un pool di GUID mondiali. Ogni volta che un GUID viene generato da qualche parte, dovrebbe essere registrato nell'organizzazione. O diamine, potremmo includere una standardizzazione che tutti i generatori GUID devono registrare automaticamente e per questo ha bisogno di una connessione Internet attiva!