GUID'in benzersiz olmadığının basit kanıtı [kapalı]

Basit bir test programında bir GUID'in benzersiz olmadığını kanıtlamak istiyorum. Aşağıdaki kodun saatlerce çalışmasını bekledim, ancak çalışmıyor. Nasıl çalıştırabilirim?

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());

C # kullanıyorum.

Kai, iş parçacıklarını kullanarak istediğinizi yapacak bir program sağladım. Aşağıdaki şartlar altında lisanslanmıştır: Çalıştırdığınız CPU çekirdeği başına saatte 0.0001 $ ödemeniz gerekir. Ücretler her takvim ayının sonunda ödenir. Paypal hesap detayları için en kısa zamanda lütfen benimle iletişime geçin.

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?");
        }
    }
}

Not: Paralel uzantılar kitaplığını denemek istedim. Kolaydı.

OutOfMemoryException'ı kontrol akışı olarak kullanmak yanlış geliyor.

DÜZENLE

Görünüşe göre bu hala oy alıyor. Bu yüzden GC.KeepAlive () sorununu çözdüm. Ve C # 4 ile çalışacak şekilde değiştirdi.

Ve destek şartlarını açıklığa kavuşturmak için: destek yalnızca 28 / Şubat / 2010'da kullanılabilir. Lütfen yalnızca o gün destek talepleri yapmak için bir zaman makinesi kullanın.

DÜZENLEME 2 Her zaman olduğu gibi, GC hafızayı yönetmede benden daha iyi bir iş çıkarır; daha önce kendim yapma girişimleri başarısızlığa mahkum edildi.

Bu saatten fazla sürecek. 1 GHz'de döngüye girdiğini varsayarsak (ki olmayacak - bundan çok daha yavaş olacaktır), 10790283070806014188970 yıl boyunca çalışacaktır. Bu, evrenin yaşından yaklaşık 83 milyar kat daha uzun.

Moores yasasının geçerli olduğunu varsayarsak , bu programı çalıştırmamak, birkaç yüz yıl beklemek ve milyarlarca kez daha hızlı bir bilgisayarda çalıştırmak çok daha hızlı olacaktır. Aslında, CPU hızlarının iki katına çıkmasından (yaklaşık 18 ay) daha uzun süren herhangi bir program, CPU hızları yükselene kadar beklerseniz ve çalıştırmadan önce yeni bir CPU satın alırsanız (daha önce yazmazsanız) askıya alınabilir ve yeni donanımda devam ettirilebilir).

Bir GUID teorik olarak benzersiz değildir. İşte kanıtınız:

• GUID 128 bitlik bir sayıdır
• Eski GUID'leri yeniden kullanmadan 2 ^ 128 + 1 veya daha fazla GUID oluşturamazsınız

Ancak, güneşin tüm güç çıkışı bu görevi yerine getirmeye yönelmişse, bitmeden çok önce soğuyacaktır.

GUID'ler, bazıları belirli bir makinenin aynı GUID'yi iki kez oluşturmayacağını garanti etmek için özel önlemler alan bir dizi farklı taktik kullanılarak üretilebilir. Belirli bir algoritmada çakışma bulmak, GUID oluşturma yönteminizin kötü olduğunu, ancak genel olarak GUID'ler hakkında hiçbir şey kanıtlamayacağını gösterir.

Tabii ki GUID'ler çarpışabilir. GUID'ler 128 bit olduğundan, 2^128 + 1bunları oluşturun ve güvercin deliği prensibi ile bir çarpışma olması gerekir.

Ancak bir GUID'nin benzersiz olduğunu söylediğimizde, gerçekten kastettiğimiz, anahtar alanın o kadar büyük olduğu ve yanlışlıkla aynı GUID'yi iki kez oluşturmanın neredeyse imkansız olduğu (rastgele GUID'ler oluşturduğumuzu varsayarak).

nRastgele bir GUID dizisi oluşturursanız , en az bir çarpışma olasılığı yaklaşıktır p(n) = 1 - exp(-n^2 / 2 * 2^128)(bu, olası doğum günlerinin sayısıyla ilgili doğum günü problemidir2^128 ).

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

Bu sayıları somutlaştırmak 2^60 = 1.15e+18. Yani, saniyede bir milyar GUID oluşturursanız, 2^60rastgele GUID'ler oluşturmak 36 yılınızı alır ve o zaman bile bir çarpışma olasılığınız hala devam eder 1.95e-03. Önümüzdeki 36 yıl içinde bir çarpışma bulmanızdan ( ) hayatınızın bir noktasında öldürülme olasılığınız daha yüksektir 4.76e-03. İyi şanslar.

Benzersizlik konusunda endişeleriniz varsa her zaman yeni GUID'ler satın alabilirsiniz, böylece eskilerinizi atabilirsiniz. İsterseniz eBay'e biraz koyacağım.

Şahsen, "Büyük Patlama" nın iki GUID çarpıştığında ortaya çıktığını düşünüyorum.

Bunu kuantum bogosort algoritmasının bir varyantı ile O (1) zamanında gösterebilirsiniz .

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

Herhangi iki GUID büyük olasılıkla benzersizdir (eşit değildir).

Bkz bu SO girişi ve gelen Vikipedi

Oluşturulan her GUID'in benzersiz olduğu garanti edilmese de, toplam benzersiz anahtar sayısı (2 ^ 128 veya 3.4 × 10 ^ 38) o kadar büyüktür ki aynı sayının iki kez üretilme olasılığı çok azdır. Örneğin, yaklaşık 5 × 10 ^ 22 yıldız içeren gözlemlenebilir evreni düşünün; her yıldız, evrensel olarak benzersiz GUID'lere 6.8 × 10 ^ 15 sahip olabilir.

Bu yüzden muhtemelen milyarlarca yıl daha beklemelisiniz ve bunun sona erdiğini bildiğimiz için evrenden birine çarpmanızı umuyoruz.

[Güncelleme:] Aşağıdaki yorumların işaret ettiği gibi, daha yeni MS GUID'leri V4'tür ve MAC adresini GUID neslinin bir parçası olarak kullanmazlar (MS'den bir V5 uygulaması belirtisi görmedim, bu yüzden eğer bana bildiren bağlantı). Bununla birlikte V4 ile, zaman hala bir faktördür ve GUID'lerin çoğaltılmasına karşı olasılıklar, herhangi bir pratik kullanım için önemsiz olmaya devam etmektedir. Kesinlikle OP yapmaya çalıştığı gibi tek bir sistem testinden yinelenen bir GUID üretme olasılığınız yoktur.

Bu yanıtların çoğunda Microsoft'un GUID uygulaması hakkında önemli bir nokta eksik. GUID'in ilk kısmı bir zaman damgasına, diğer kısmı ise ağ kartının MAC adresine (veya NIC takılı değilse rastgele bir sayıya) dayanır.

Bunu doğru anlarsam, bir GUID'yi çoğaltmanın tek güvenilir yolunun, MAC adreslerinin aynı olduğu VE her iki sistemdeki saatlerin aynı zamanda aynı zamanda olduğu birden çok makinede eşzamanlı GUID nesilleri çalıştırmak olduğu anlamına gelir. (doğru anladıysam zaman damgası milisaniyeye dayanır) .... o zaman bile rastgele sayıdaki bir sürü başka bit vardır, bu yüzden oranlar hala kaybolmaktadır.

Tüm pratik amaçlar için GUID'ler evrensel olarak benzersizdir.

"Eski Yeni Şey" blogunda MS GUID hakkında oldukça iyi bir açıklama var

Kodunuzdaki birçok yerde guid benzersizliğini kontrol etmek istiyorsanız kullanabileceğiniz şık küçük bir uzantı yöntemi.

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

Bunu aramak için, yeni bir rehber oluşturduğunuzda Guid.IsUnique'yi aramanız yeterlidir ...

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

... heck, ilk turda doğru olduğundan emin olmak için iki kez aramanızı öneririm.

2 ^ 128 olarak sayılıyor - iddialı.

Makine başına saniyede 2 ^ 32 kimlik sayabileceğimizi düşünelim - bu iddialı değil , saniyede 4,3 milyar bile değil. Bu işe 2 ^ 32 makine ayıralım. Ayrıca, her biri için aynı kaynakları görev için 2 ^ 32 medeniyet alalım.

Şimdiye kadar, saniyede 2 ^ 96 kimlik sayabiliriz, yani 2 ^ 32 saniye (136 yıldan biraz fazla) sayacağız.

Şimdi, ihtiyacımız olan tek şey, her biri 4.294.967.296 makineye 4.294.967.296 medeniyet almak, her makine saniyede 4.294.967.296 kimliği sayabilir, sadece bu görev için önümüzdeki 136 yıl boyunca başlamamızı öneriyorum; -)

Peki, 83 milyar yıllık çalışma süresi sizi korkutmuyorsa, yinelenen olup olmadığınızı kontrol etmek için oluşturulan GUID'leri bir yerde saklamanız gerektiğini düşünün; 2 ^ 128 16 baytlık sayıları depolamak için sadece 4951760157141521099596496896 terabayt RAM ayırmanız gerekir, bu yüzden her şeye sığabilecek bir bilgisayara sahip olduğunuzu ve her nasılsa 10 gramda terabayt DIMM satın almak için bir yer bulduğunuzu hayal edin. 8'den fazla Dünya kütlesini tartın, böylece "Run" tuşuna basmadan önce mevcut yörüngeden ciddi şekilde kaydırabilirsiniz. İki kere düşün!

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

Artış yapmıyorsunuz, beginbu yüzden durum begin < endher zaman doğrudur.

GUID çarpışmaları bir endişe ise, bunun yerine ScottGuID kullanmanızı tavsiye ederim .

Muhtemelen Kılavuzları üretmek için algoritmanın gerçekten rasgele sayılar üretmediğine, aslında << 2 ^ 128 periyodu ile döngüye girdiğine inanmak için nedeniniz var.

örneğin, bazı bitlerin değerlerini sabitleyen GUID'leri türetmek için kullanılan RFC4122 yöntemi.

Döngü kanıtı dönemin olası boyutuna bağlı olacaktır.

Küçük periyotlar için, GUID'ler eşleşmiyorsa (eşleşiyorsa sonlandırın) karma (GUID) -> GUID çarpışmada değiştirmeyle birlikte bir yaklaşım olabilir. Değişim yerine sadece zamanın rastgele bir kısmını yapmayı düşünün.

Nihayetinde, çarpışmalar arasındaki maksimum süre yeterince büyükse (ve önceden bilinmemektedir), herhangi bir yöntem sadece çarpışmanın mevcut olması halinde bulunma olasılığı verecektir.

Kılavuz oluşturma yöntemi saat temelli ise (bkz. RFC), çarpışma olup olmadığını belirlemek mümkün olmayabilir, çünkü (a) saatin yuvarlanması için yeterince uzun süre bekleyemeyeceksiniz, veya (b) bir saati işaretlemede bir çarpışmayı zorlamak için yeterli Rehber isteyemezsiniz.

Alternatif olarak, Rehber'deki bitler arasında istatistiksel bir ilişki veya Rehberler arasındaki bitlerin bir korelasyonunu gösterebilirsiniz. Böyle bir ilişki, gerçek bir çarpışma bulamadan algoritmanın kusurlu olmasını büyük olasılıkla sağlayabilir.

Tabii ki, sadece Rehberlerin çarpışabileceğini kanıtlamak istiyorsanız, cevap bir program değil, matematiksel bir kanıttır.

Neden hiç kimsenin grafik kartınızı yükseltmekten bahsetmediğini anlamıyorum ... Kesinlikle bir high-end NVIDIA Quadro FX 4800 veya bir şey (192 CUDA çekirdeği) varsa, bu daha hızlı gidecektir ...

Tabii ki birkaç NVIDIA Qadro Plex 2200 S4 (her biri 960 CUDA çekirdeğinde) alabilseydiniz, bu hesaplama gerçekten çığlık atardı . Belki de NVIDIA bir PR dublör olarak size bir "Teknoloji Gösteri" için birkaç kredi vermek istersiniz?

Elbette bu tarihi hesaplamanın bir parçası olmak istiyorlardı ...

Ama gerekiyor emin olun Eğer yinelenen bir örneği, ya da orada eğer sadece bakım yapmak olabilir kopyası olabilir. Aynı doğum gününe sahip iki kişiniz olduğundan emin olmak için 366 kişiye ihtiyacınız var (artık yıl saymıyor). Aynı doğum günü olan iki kişinin% 50'den fazla şansı olması için sadece 23 kişiye ihtiyacınız var. Bu doğum günü problemi .

32 bitiniz varsa,% 50'den fazla yinelenme şansına sahip olmak için sadece 77.163 değere ihtiyacınız vardır. Denemek:

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

Şimdi 128 bit çok fazla, bu yüzden hala düşük çarpışma şansı veren çok sayıda öğe konuşuyorsunuz. Bir tahmin kullanarak verilen oranlar için aşağıdaki kayıt sayısına ihtiyacınız olacaktır:

• 1/1000 çarpışma şansı için 0.8 milyar milyar
• % 50 çarpışma olasılığı için 21.7 milyar milyar
• % 90 çarpışma olasılığı için 39.6 milyar milyar

Yılda yaklaşık 1E14 e-posta gönderilir, bu nedenle aynı GUID'ye sahip olma şansınız% 90 olmadan önce bu seviyede yaklaşık 400.000 yıl olurdu, ancak bu, 83 milyar bilgisayar çalıştırmanız gerektiğini söylemekten çok farklı yinelemeden önce evrenin yaşı ya da güneşin soğuması.

Hepiniz önemli bir noktayı kaçırmıyor musunuz?

GUID'lerin Küresel olarak benzersiz olma şansını oldukça yüksek yapan iki şey kullanılarak oluşturulduğunu düşündüm. Birincisi, üzerinde bulunduğunuz makinenin MAC adresi ile tohumlanır ve iki tanesi üretildikleri zamanı ve rastgele bir sayıyı kullanırlar.

Bu yüzden, gerçek makinede çalıştırmazsanız ve makinenin GUID'de bir zamanı temsil etmek için kullandığı en küçük sürede çalıştırırsanız, sistem çağrısını kullanarak kaç tahminde bulunursanız olun asla aynı numarayı üretemezsiniz.

Bir GUID gerçekte nasıl yapıldığını biliyorsanız aslında tahmin etme süresini oldukça kısaltır sanırım.

Tony

GUID'leri karma yapabilirsiniz. Bu şekilde, sonucu çok daha hızlı almalısınız.

Oh, elbette, aynı anda birden fazla iş parçacığı çalıştırmak da iyi bir fikirdir, bu şekilde farklı iş parçacıkları üzerinde aynı GUID'yi iki kez üreten bir yarış koşulunun şansını artıracaksınız.

GUID'ler 124 bittir çünkü 4 bit sürüm numarasını tutar.

1. New York'taki kriyojenik laboratuvarına git.
2. Kendinizi (kabaca) 1990 yıl boyunca dondurun.
3. Planet Express'te bir iş bul.
4. Yepyeni bir CPU satın alın. Bir bilgisayar oluşturun, programı çalıştırın ve kıyamet günü makinesi gibi sahte bir sürekli hareket makinesiyle güvenli bir yere yerleştirin.
5. Makine icat edilene kadar bekleyin.
6. Zaman makinesini kullanarak geleceğe atlayın. 1YHz 128bit CPU satın aldıysanız 3,938,453,320 days 20 hours 15 minutes 38 seconds 463 ms 463 μs 374 ns 607 ps, programı çalıştırmaya başladığınızda sonrasına geçin .
7. ...?
8. KAR !!!

... 1GHz CPU'dan 1 kat daha hızlı (ya da ikili önek kullanmayı tercih ederseniz) en az 10,783,127yıl alır .1,000,000,000,000,0001,125,899,906,842,624

Bu nedenle, hesaplamanın bitmesini beklemek yerine, evlerini kaybeden güvercinleri beslemek daha iyi olurdu çünkü diğer ngüvercinler evlerini aldı. :(

Veya 128 bit kuantum bilgisayarı icat edilene kadar bekleyebilirsiniz. O zaman programınızı makul bir süre içinde (belki de) kullanarak GUID'in benzersiz olmadığını kanıtlayabilirsiniz.

begin = begin + new BigInteger((long)1)Start ++ yerine denediniz mi?

Oluşturulan UUID sayısı Moore yasalarına uyarsa, öngörülebilir gelecekte GUID'in hiç bitmemesi izlenimi yanlıştır.

2 ^ 128 UUID ile, tüm UUID'lerin tükenmesinden önce sadece 18 ay * Log2 (2 ^ 128) ~ = 192 yıl sürecektir.

Ve inanıyorum ki (UUID'nin kitlesel olarak benimsenmesinden bu yana geçen birkaç yıl içinde hiçbir istatistiksel kanıt olmadan), UUID üretme hızımız Moore yasasının öngördüğünden daha hızlı artıyor. Başka bir deyişle, UUID kriziyle başa çıkmak zorunda kalana kadar muhtemelen 192 yıldan daha az zamanımız var, bu evrenin sonundan çok daha erken.

Ancak 2012 sonunda kesinlikle tükenmeyeceğimiz için, sorun hakkında endişelenmek için onu diğer türlere bırakacağız.

GUID üreten koddaki bir hatanın olasılığı, bir çarpışma oluşturan algoritmanın oranından çok daha yüksektir. GUID'leri test etmek için kodunuzdaki bir hatanın olasılığı daha da fazladır. Pes etmek.

Program, hataları da olsa, bir GUID'in benzersiz olmadığının kanıtıdır. Aksini kanıtlamaya çalışanlar bu noktayı kaçırıyorlar. Bu ifade, bazı GUID varyasyonlarının zayıf bir şekilde uygulandığını kanıtlamaktadır.

Bir GUID tanım gereği benzersiz değildir, tanım gereği oldukça benzersizdir. Az önce anlamını geliştirdiniz. Sürüme bağlı olarak, uygulayıcı (MS veya diğerleri), VM'lerin kullanımı, vb. (önceki yayındaki bağlantıya bakın)

Noktanızı kanıtlamak için 128 bitlik masanızı kısaltabilirsiniz. En iyi çözüm, tablonuzu kopyalarla kısaltmak için bir karma formül kullanmak ve ardından karma çarpıştığında ve buna göre bir GUID yeniden oluşturmak için tam değeri kullanmaktır. Farklı konumlardan koşuyorsanız, karma / tam anahtar çiftlerinizi merkezi bir konumda saklarsınız.

Ps: Hedef sadece farklı sayıda x değeri oluşturmaksa, bu genişlikte bir karma tablosu oluşturun ve karma değerini kontrol edin.

Burada şenlik ateşinde p ** s değil, ama aslında oluyor ve evet, bu adama verdiğiniz şaka anlıyorum, ama GUID sadece prensipte benzersiz, bu konuya çarptım çünkü bir hata var WP7 öykünücüsünde, yani her önyükleme yaptığında SAME GUID'i ilk çağrıldığında verir! Teoride, söz konusu GUI'yi yaratan bir sorun varsa, o zaman kopyalar alabilirsiniz.

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

Guid jenerasyonunun bir kısmı mevcut makinenin zamanına dayandığından, yinelenen bir Guid alma teorim:

1. Windows'un temiz bir kurulumunu gerçekleştirin
2. Windows açılırken saati 2010-01-01 12:00:00 olarak sıfırlayan bir başlangıç ​​komut dosyası oluşturun.
3. Başlangıç ​​komut dosyasından hemen sonra, bir Guid oluşturmak için uygulamanızı tetikler.
4. Sonraki Windows açılışlarında oluşabilecek küçük farklılıkları ortadan kaldırmak için bu Windows kurulumunu kopyalayın.
5. Sabit sürücüyü bu görüntü ile yeniden görüntüye alın ve makineyi birkaç kez önyükleyin.

Benim için .. bir UUIDv1 oluşturmak için tek bir çekirdek için gereken zaman benzersiz olacağını garanti eder. Çok çekirdekli bir durumda bile, UUID jeneratörü belirli bir kaynağınız için aynı anda yalnızca bir UUID'nin oluşturulmasına izin veriyorsa (birden fazla kaynağın aynı UUID'leri tamamen kullanabileceğini unutmayın, ancak kaynak adresin doğal olarak adresinin bir parçası olduğundan) zaman damgası tükenene kadar size yetecek kadar UUID'ye sahip olacak. Bu noktada gerçekten umursadığınızdan şüpheliyim.

İşte size bir çözüm:

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

Not: Qt gerektirir, ancak yeterince uzun süre çalışmasına izin verirseniz bir tane bulabileceğini garanti ederim.

(Not: aslında, şimdi ona baktığımda, daha sonra üretilen iki çarpışmayı önleyen nesil algoritması hakkında bir şeyler olabilir - ama biraz şüpheliyim).

GUID'lerin benzersiz olmadığını kanıtlamanın tek çözümü, bir Dünya GUID Havuzu'na sahip olmak olacaktır. Her yerde bir GUID oluşturulduğunda, kuruluşa kaydedilmesi gerekir. Veya tüm GUID jeneratörlerinin otomatik olarak kaydetmesi gereken bir standardizasyon ekleyebiliriz ve bunun için aktif bir internet bağlantısına ihtiyaç duyarız!