अद्वितीय होने के लिए यादृच्छिक किलों पर भरोसा करने के लिए स्वीकार्य है?

Question

मैं एक नेटवर्क प्रोटोकॉल लागू कर रहा हूं, और मुझे विशिष्ट पहचानकर्ताओं के पैकेट की आवश्यकता है। अब तक, मैं सिर्फ यादृच्छिक 32-बिट पूर्णांक उत्पन्न कर रहा हूं, और यह मानते हुए कि यह खगोलीय रूप से संभावना नहीं है कि एक कार्यक्रम / कनेक्शन के जीवन काल के दौरान टकराव होगा। क्या इसे आमतौर पर उत्पादन कोड में एक स्वीकार्य अभ्यास माना जाता है, या टकराव को रोकने के लिए एक अधिक जटिल प्रणाली तैयार करनी चाहिए?

Comments

एक अनुक्रमिक पूर्णांक का उपयोग क्यों नहीं किया जा रहा है इसे काटने के लिए?

— whatsisname

तुम सिर्फ एक वृद्धिशील int का उपयोग क्यों नहीं करते? GUIDs , जो आपके द्वारा बताए गए विशिष्ट गुणों के लिए डिज़ाइन किए गए हैं, आकार में 128 बिट्स हैं, 32 नहीं।

— रॉबर्ट हार्वे

वैकल्पिक रूप से, प्रत्येक कनेक्ट किए गए कंप्यूटर पर एक चैनल नंबर असाइन करें, और एक वृद्धि क्रम id का उपयोग करें। दो नंबर संयुक्त (उच्च क्रम बिट्स को ले जाने वाले चैनल नंबर के साथ) आपकी नई अनूठी आईडी बन जाती है।

— रॉबर्ट हार्वे

यदि आपका "रैंडम नंबर जनरेटर" गारंटी देता है कि किसी विशेष नंबर को तब तक दोहराया नहीं जाएगा जब तक कि हर दूसरी संख्या उत्पन्न न हो जाए, यह एक बहुत ही खराब रैंडम नंबर जनरेटर है! उसी तर्क से, सिक्के के टॉस का एकमात्र "यादृच्छिक" क्रम HTHTHTHTHT होगा ...

— alephzero

"मुझे विशिष्ट पहचानकर्ता के लिए पैकेट की आवश्यकता है" इस आवश्यकता के परिणाम का उल्लंघन किया जा रहा है? यदि आपको विशिष्ट पहचानकर्ताओं की आवश्यकता है , तो शब्द के सबसे सख्त पढ़ने में, आपके पास एक केंद्रीयकृत सिस्टम डॉल आउटिंग आइडेंटिफ़ायर होना चाहिए (जैसे एमएसी व्यक्तिगत नेटवर्क कार्ड कंपनियों को कैसे सौंपा जाता है)। सबसे अधिक संभावना है कि आपके पास "आवश्यकता" की एक नरम परिभाषा है। कोमलता के उस स्तर को समझना नाटकीय रूप से आपके द्वारा प्राप्त उत्तरों को बदल देगा।

— Cort Ammon

Answer 1

जन्मदिन के विरोधाभास से सावधान रहें ।

मान लीजिए कि आप आकार (N = 2 ^ 32 आपके मामले में) के एक सेट से यादृच्छिक मूल्यों (समान रूप से, स्वतंत्र रूप से) का एक क्रम उत्पन्न कर रहे हैं।

फिर, जन्मदिन के विरोधाभास के लिए अंगूठे का नियम बताता है कि एक बार जब आपने sqrt (N) मानों के बारे में जनरेट किया है, तो कम से कम 50% संभावना है कि टक्कर हुई है, यानी कि कम से कम दो समान मान हैं उत्पन्न क्रम।

N = 2 ^ 32 के लिए, sqrt (N) = 2 ^ 16 = 65536 है। इसलिए आपके द्वारा लगभग 65k पहचानकर्ता उत्पन्न करने के बाद, यह अधिक संभावना है कि उनमें से दो आपस में टकराएं! यदि आप प्रति सेकंड एक पहचानकर्ता उत्पन्न करते हैं, तो यह एक दिन से भी कम समय में होगा; कहने की जरूरत नहीं है, कई नेटवर्क प्रोटोकॉल उसी की तुलना में तेजी से काम करते हैं।

Comments

+1। मेरी आखिरी नौकरी में, हमारे एक साथी ने वास्तव में इस पहचान का उपयोग यादृच्छिक पहचानकर्ताओं को तैयार करने के लिए किया था (नेटवर्किंग पैकेट के लिए नहीं, बल्कि अंत में ग्राहकों द्वारा बनाई गई एक साझा व्यावसायिक वस्तु के लिए)। जब मैंने डेटा को इस ओर एक आंख से देखा, तो मैंने पाया कि हर दिन औसतन दो से तीन जोड़े नकल करते थे। (सौभाग्य से, यह केवल चीजों को

— तोड़ता है

(गणित रेंडर करने के लिए यहां क्लिक करें) इसके लायक क्या है, $ \ sqrt {N} $ सन्निकटन एक स्थिर कारक तक सटीक है; $ N = 2 ^ {32} $ के लिए, वास्तविक सीमा 77164 है, क्योंकि यह $ n $ का सबसे छोटा मूल्य है जैसे $ \ prod_ {k = 1} ^ {n-1} (1 - k / N) <1 / 2. $

— 22

@ शार्गिन: वास्तव में संभावना 0.5 की मार के बारे में कुछ भी जादुई नहीं है; उल्लेखनीय यह है कि संभावना तेजी से बढ़ रही है एन के साथ तेजी से बढ़ रहा है। यदि 32-बिट पहचानकर्ताओं में यादृच्छिक टक्कर की थोड़ी लेकिन गैर-तुच्छ संभावना होगी, तो 40-बिट पहचानकर्ता लगभग कोई भी नहीं होगा।

— सुपरकैट

@ सुपरकैट: यह सब सच है। मुझे लगा कि अगर कोई इस तरह का एक निरंतर प्रदान करता है, तो एक व्यक्ति को एक सटीक मूल्य दिया जा सकता है :-)

— wchargin

@wchargin: मैं उन चीज़ों के बारे में सोचना पसंद करता हूँ जहाँ किसी को डुप्लिकेट के बारे में चिंता करने की ज़रूरत है। यदि कोई sqrt (N) से बहुत नीचे चला जाता है, तो टकराव की संभावनाएं तेजी से गिर जाती हैं, इस बिंदु पर कि कोई सुरक्षित रूप से कह सकता है कि वे तब तक नहीं होंगे जब तक कि यादृच्छिक जनरेटर में कोई गंभीर खराबी न हो।

— 1

Answer 2

यह व्यापक रूप से स्वीकार्य माना जाता है कि यादृच्छिक संख्याओं पर भरोसा किया जा सकता है यदि उन संख्याओं में पर्याप्त बिट्स हैं। क्रिप्टोग्राफिक प्रोटोकॉल हैं जहां एक यादृच्छिक संख्या को दोहराने से पूरी सुरक्षा टूट जाएगी। और जब तक यादृच्छिक संख्या जनरेटर में गंभीर कमजोरियों का उपयोग नहीं किया जा रहा है, तब तक यह समस्या नहीं है।

यूयूआईडी बनाने के लिए एल्गोरिदम में से एक प्रभावी रूप से 122 यादृच्छिक बिट्स से मिलकर एक आईडी उत्पन्न करेगा और यह अद्वितीय होगा। और दो अन्य एल्गोरिदम एक हैश मूल्य पर निर्भर करते हैं जो कि 122 बिट्स के अद्वितीय होने के कारण काट दिया जाता है, जो टकराव का लगभग एक ही जोखिम होता है।

इसलिए एक यादृच्छिक आईडी को विशिष्ट बनाने के लिए 122 बिट्स पर निर्भर होने वाले मानक पर्याप्त हैं, लेकिन 32 बिट्स निश्चित रूप से पर्याप्त नहीं हैं। 32 बिट आईडी के साथ टकराव का जोखिम 50% तक पहुंचने से पहले केवल 2¹⁶ आईडी लेता है क्योंकि 2¹⁶ आईडी के साथ लगभग 2 each जोड़े होंगे, जिनमें से प्रत्येक एक टक्कर हो सकता है।

यहां तक ​​कि 122 बिट्स की तुलना में मैं किसी भी नए डिजाइन में सिफारिश करूंगा। यदि कुछ मानकीकरण का पालन करना आपके लिए महत्वपूर्ण है, तो यूयूआईडी का उपयोग करें। अन्यथा 122 बिट्स से कुछ बड़ा उपयोग करें।

160 बिट के आउटपुट के साथ SHA1 हैश फ़ंक्शन को अब सुरक्षित नहीं माना जाता है जो कि भाग में है क्योंकि 160 बिट्स आउटपुट की विशिष्टता की गारंटी देने के लिए पर्याप्त नहीं हैं। आधुनिक हैश फ़ंक्शन में 224 से 512 बिट्स के आउटपुट हैं। बेतरतीब ढंग से उत्पन्न आईडी को एक ही आकार के लिए एक अच्छा सुरक्षा मार्जिन के साथ विशिष्टता सुनिश्चित करने का लक्ष्य होना चाहिए।

Comments

SHA-1 को असुरक्षित माना जाता है क्योंकि एल्गोरिथ्म के खिलाफ विशिष्ट हमले (यानी गैर-यादृच्छिक) होते हैं जो ब्रूट बल की तुलना में तेजी से टकराव पा सकते हैं, इसलिए नहीं कि एक यादृच्छिक टक्कर का एक उच्च मौका है। एक मोटे अनुमान में कहा गया है कि 122 बिट्स और 1 बिलियन (10 ^ 9) प्रति सेकंड की जनरेशन दर के साथ, इसे टक्कर के 50% मौके तक पहुंचने से पहले 73 साल लग जाएंगे।

— 8bittree

sqrt(2^122)= 2.3 क्वाड्रिलियन क्वाड्रिलियन UUIDs

— noɐɹƆz

@ 8 बिटट्री बिटकॉइन नेटवर्क हर 10 मिनट में 2A SHA2 हैश की गणना करता है। अगर वह SHA1 हैश होता तो टकराव पैदा करने में केवल एक सप्ताह लगता। यदि UUIDs उसी गति से निर्मित होते हैं जो बिटकॉइन की गणना करता है तो टकराव उत्पन्न करने में इसे 2 सेकंड से भी कम समय लगेगा।

— कास्परड

बिटकॉइन सभी टकरावों को खोजने की कोशिश कर रहा है, और बेहद लोकप्रिय है और विशेष रूप से हैश खोजने के लिए तैयार किए गए हार्डवेयर को समर्पित किया है। अब, निश्चित रूप से, अगर ओपी एक बेतहाशा लोकप्रिय क्रिप्टोक्यूरेंसी बनाने की योजना बना रहा है, या कुछ समान है, तो उन्हें प्रति आईडी सैकड़ों या हजारों बिट्स की आवश्यकता हो सकती है। लेकिन तुरंत यह मानते हुए कि जो आवश्यकताएं हैं वे मानक यूयूआईडी पुस्तकालय पर्याप्त होने पर आवश्यकता से अधिक काम को प्रोत्साहित कर सकते हैं।

— 8bittree

@ 8bittree यदि मानक पुस्तकालयों का उपयोग करना किसी भी तरह का लाभ है, तो हर तरह से यूयूआईडी के लिए जाना चाहिए। लेकिन कुछ यादृच्छिक बाइट्स को बाहर निकालना urandomयूयूआईडी लाइब्रेरी का उपयोग करने से अधिक काम नहीं है। मैंने सिर्फ पायथन में तुलना के लिए दोनों को लागू किया, और प्रत्येक विधि स्रोत कोड के बिल्कुल 25 अक्षर थे।

— कास्परड

Answer 3

मैं इसे बुरा व्यवहार कहूंगा। रैंडम नंबर जेनरेट करता है बस यूनिक नंबर न बनाएं, वे सिर्फ रैंडम नंबर बनाते हैं। एक यादृच्छिक वितरण में कुछ डुप्लिकेट शामिल करने की संभावना है। आप समय के एक तत्व में जोड़कर इस परिस्थिति को सहज रूप से असंभाव्य बना सकते हैं। यदि आपको मिलीसेकंड में सिस्टम घड़ी से वर्तमान समय मिलता है। कुछ इस तरह:

parseToInt(toString(System.currentTimeMillis()) + toString(Random.makeInt()))

बहुत आगे जाएगा। स्पष्ट रूप से विशिष्टता की गारंटी देने के लिए आपको UUID / GUID का उपयोग करने की आवश्यकता है। लेकिन वे उत्पन्न करने के लिए महंगा हो सकते हैं, ऊपर की संभावना पर्याप्त है, ओवरलैप की एकमात्र संभावना के रूप में है, अगर यादृच्छिक उत्पन्न में एक ही मिलीसेकंड में एक डुप्लिकेट था।

Comments

कुछ सिस्टम में 1ms लंबा समय हो सकता है।

— मात्रा_देव

यह वास्तव में बिल्कुल भी टकराव की संभावना को कम नहीं करता है। एन संख्याओं के बाद टकराव की संभावना ओपी के मूल समाधान के बराबर है। बीज के रूप में वर्तमान समय का उपयोग करने की चाल का उपयोग आमतौर पर क्रमिक रूप से कुंजी सौंपते समय किया जाता है।

— Cort Ammon

@Fresheyeball मुझे विश्वास है कि इसका कोई प्रभाव नहीं है, जब तक कि random.makeInt () वास्तव में पूर्णांक के न्यूनतम मूल्य से पूर्णांक के अधिकतम मूल्य तक एक समान वितरण उत्पन्न नहीं करता है। इस फ़ंक्शन द्वारा उत्पन्न हर पिछले मूल्य के लिए, makeInt से एक यादृच्छिक मूल्य है, जो इस सटीक समय कदम के लिए, उस मूल्य को उत्पन्न करता है, जिससे टकराव पैदा होता है। चूंकि मेकइंट से सभी वैल्यू कंफर्टेबल होते हैं, टकराव की संभावना समय के बिना टकराव की संभावना के बराबर होती है।

— Cort Ammon

@CortAmmon यह बीज के रूप में वर्तमान समय का उपयोग नहीं कर रहा है , और यह निश्चित रूप से एक फर्क पड़ता है जब तक कि उन एन नंबर सभी एक ही मिलीसेकंड के दौरान उत्पन्न नहीं होते थे, क्योंकि अलग-अलग टाइमस्टैम्प भागों के साथ दो नंबर कभी नहीं टकराते हैं। यदि आप प्रति दिन एक पैकेट के दूसरे उत्तर के उदाहरण की कल्पना करते हैं, तो एक दिन से भी कम समय में टकराव की 50% संभावना है, यह एक पैकेट पर प्रति सेकंड टक्कर का 0% मौका है, कम से कम उस समय तक जब तक कि currentTimeMillisचारों ओर लपेटता है।

— हॉब्स

@ ओह आप पूर्णांक अतिप्रवाह के बारे में भूल जाते हैं। अब अगर ओपी की कुंजी एक संरचना होती है जिसमें 2 पूर्णांक, एक युक्त System.currentTimeMillisऔर एक युक्त होता है Random.makeInt(), तो टकराव की संभावना काफी हद तक बढ़ जाती है। हालाँकि, यह नहीं है कि इस उदाहरण में कोड क्या करता है। किसी भी पिछले समय और यादृच्छिक मूल्य को देखते हुए , और किसी भी मौजूदा समय में, टकराव की संभावना दो यादृच्छिक संख्या के पहले स्थान पर टकराने की संभावना के समान है।

— Cort Ammon

Answer 4

यह विफलता की संभावना और विफलता के परिणामों दोनों पर निर्भर करता है।

मुझे सॉफ्टवेयर और हार्डवेयर लोगों के बीच एक बहस याद है जहां हार्डवेयर लोगों ने माना था कि गलत परिणामों की एक छोटी संभावना के साथ एक एल्गोरिथ्म (100 वर्षों में 1 विफलता जैसी कोई चीज) स्वीकार्य थी, और सॉफ्टवेयर लोगों को लगा कि यह अनात्म है। यह पता चला कि हार्डवेयर लोगों ने नियमित रूप से अपेक्षित विफलता दरों की गणना की, और इस विचार के लिए बहुत उपयोग किया गया था कि सब कुछ कभी-कभी गलत उत्तर देगा, जैसे कि कॉस्मिक किरणों के कारण गड़बड़ी; उन्होंने पाया कि सॉफ्टवेयर लोगों को 100% विश्वसनीयता की उम्मीद थी।

Answer 5

ज़रूर, आपको दो यादृच्छिक 32-बिट पूर्णांकों के अनुक्रमिक होने की बहुत कम संभावनाएं मिली हैं, लेकिन यह पूरी तरह से असंभव नहीं है। इंजीनियरिंग का उचित निर्णय इस बात पर आधारित है कि टक्करों के परिणाम क्या होंगे, आपके द्वारा पैदा की जा रही संख्या की मात्रा का अनुमान, जिस पर जीवनकाल की आवश्यकता है और यदि कोई दुर्भावनापूर्ण उपयोगकर्ता टकराव का कारण बनने लगता है तो क्या होगा।

Answer 6

यह मानने के लिए स्वीकार्य हो सकता है कि यादृच्छिक संख्या अद्वितीय होगी लेकिन आपको सावधान रहना होगा।

मान लिया जाये कि अपने यादृच्छिक संख्या समान रूप से वितरित कर रहे हैं, एक टक्कर की संभावना लगभग (एन है ² /2) / k जहां n यादृच्छिक संख्या की संख्या आप उत्पन्न और कश्मीर संभावित मान एक "यादृच्छिक" संख्या ले जा सकते हैं की संख्या है।

आप खगोलीय रूप से असंभाव्य पर कोई संख्या नहीं डालते हैं, जिससे इसे 2 ³⁰ में 1 के रूप में लिया जा सकता है (लगभग एक अरब में)। आगे कहते हैं कि आप 2 ³⁰ पैकेट उत्पन्न करते हैं (यदि प्रत्येक पैकेट एक किलोबाइट डेटा का प्रतिनिधित्व करता है तो इसका मतलब कुल डेटा के एक टेराबाइट के बारे में है, बड़े लेकिन अकल्पनीय रूप से ऐसा नहीं)। हमें लगता है कि हमें कम से कम 2 ⁸⁹ संभावित मूल्यों के साथ एक यादृच्छिक संख्या की आवश्यकता है ।

सबसे पहले आपके रैंडम नंबर को काफी बड़ा होना चाहिए। एक 32 बिट यादृच्छिक संख्या में अधिकतम 2 ³² संभावित मान हो सकते हैं। एक व्यस्त सर्वर के लिए जो उच्च पर्याप्त के पास कहीं नहीं है।

दूसरी बात यह है कि आपके रैंडम नंबर जनरेटर के पास पर्याप्त बड़ी आंतरिक स्थिति होनी चाहिए। यदि आपके रैंडम नंबर जनरेटर में केवल 32-बिट आंतरिक स्थिति है, तो इससे कोई फर्क नहीं पड़ता कि आप इससे कितना बड़ा मूल्य उत्पन्न करते हैं, फिर भी आपको केवल 2 ³² संभव मान प्राप्त होंगे।

तीसरी बात यह है कि यदि आपको कनेक्शन के बजाय रैंडम नंबरों की आवश्यकता है तो केवल एक कनेक्शन के भीतर ही आपके रैंडम नंबर जेनरेटर को अच्छी तरह से बीजने की जरूरत है। यह विशेष रूप से सच है यदि आपका प्रोग्राम अक्सर पुनरारंभ होता है।

सामान्य तौर पर प्रोग्रामिंग भाषाओं में "नियमित" यादृच्छिक संख्या जनरेटर ऐसे उपयोग के लिए उपयुक्त नहीं हैं। क्रिप्टोग्राफी पुस्तकालयों द्वारा प्रदान किए गए यादृच्छिक संख्या जनरेटर आमतौर पर होते हैं।

Answer 7

ऊपर दिए गए कुछ उत्तरों में बनाया गया यह अनुमान है कि यादृच्छिक संख्या जनरेटर वास्तव में 'फ्लैट' है - कि किसी भी दो संख्याओं के अगले एक उत्पन्न होने की संभावना समान है।

यह शायद सबसे यादृच्छिक संख्या जनरेटर के लिए सच नहीं है। जिनमें से अधिकांश बीज के लिए बार-बार लगाए जाने वाले कुछ उच्च क्रम बहुपद का उपयोग करते हैं।

उस ने कहा, वहाँ कई प्रणालियाँ हैं जो इस योजना पर निर्भर करती हैं, आमतौर पर यूयूआईडी के साथ। उदाहरण के लिए, सेकंड लाइफ में हर ऑब्जेक्ट और एसेट में 128 बिट UUID होता है, जो बेतरतीब ढंग से उत्पन्न होता है, और वे शायद ही कभी टकराते हैं।

Answer 8

बहुत सारे लोगों ने पहले ही उच्च-गुणवत्ता वाले उत्तर दिए हैं, लेकिन मैं कुछ मामूली बिंदुओं को जोड़ना चाहूंगा: पहला, जन्मदिन के विरोधाभास के बारे में @nomadictype का बिंदु उत्कृष्ट है ।

एक और बिंदु: यादृच्छिकता उत्पन्न करने और लोगों को सामान्य मानने के रूप में परिभाषित करने के लिए सरल नहीं है। (वास्तव में, यादृच्छिकता के लिए वास्तव में सांख्यिकीय परीक्षण उपलब्ध हैं)।

इसके साथ ही कहा, जुआरी के पतन के बारे में जागरूक होना महत्वपूर्ण है , जो एक सांख्यिकीय पतन है जहां लोग मानते हैं कि स्वतंत्र घटनाएं किसी न किसी तरह से प्रभावित करती हैं। यादृच्छिक घटनाएँ आम तौर पर एक दूसरे से सांख्यिकीय रूप से स्वतंत्र होती हैं - अर्थात यदि आप "10" को बेतरतीब ढंग से उत्पन्न करते हैं तो यह कम से कम अधिक "10" उत्पन्न करने की आपकी भविष्य की संभावना को नहीं बदलता है। (हो सकता है कि कोई व्यक्ति उस नियम के अपवाद के साथ आ सकता है, लेकिन मुझे उम्मीद है कि बहुत सारे यादृच्छिक संख्या जनरेटर के लिए यही स्थिति होगी)।

तो मेरा उत्तर यह है कि यदि आप मान सकते हैं कि यादृच्छिक संख्याओं का पर्याप्त-लंबा क्रम अद्वितीय था, तो वे वास्तव में यादृच्छिक संख्याएँ नहीं होंगी क्योंकि यह एक स्पष्ट सांख्यिकीय प्रतिरूप होगा। इसके अलावा, यह होगा कि प्रत्येक नया नंबर एक स्वतंत्र घटना नहीं है क्योंकि यदि आप उदाहरण के लिए, 10 उत्पन्न करते हैं, तो इसका मतलब होगा कि किसी भी भविष्य के 10s उत्पन्न करने की संभावना 0% होगी (यह संभवतः नहीं हो सकता), प्लस इसका मतलब यह होगा कि आप 10 के अलावा एक नंबर प्राप्त करने की बाधाओं को बढ़ाएंगे (यानी जितने अधिक नंबर उत्पन्न करेंगे, शेष संख्याओं में से प्रत्येक की संभावना उतनी ही अधिक होगी)।

एक और बात पर विचार करें: एकल गेम खेलने से पावरबॉल जीतने का मौका है, जैसा कि मैं इसे समझता हूं, 175 मिलियन में लगभग 1। हालांकि, किसी की जीत की संभावना काफी अधिक है। आप किसी विशेष संख्या "जीतने" / एक डुप्लिकेट होने की तुलना में किसी के "जीतने" (यानी एक डुप्लीकेट होने के नाते) की बाधाओं में अधिक रुचि रखते हैं ।

Comments

यदि कोई इस तरह से 4096-बिट पहचानकर्ता उत्पन्न कर रहा है कि हर बिट समान रूप से 0 या 1 किसी भी अन्य बिट से स्वतंत्र होने की संभावना है जो उसी या किसी अन्य पहचानकर्ता में उत्पन्न हुई है, तो संभावना है कि कोई भी दो पहचानकर्ता कभी भी मेल खाएगा। भले ही वे गायब हो गए हों, भले ही वे अवलोकनीय ब्रह्मांड में मोटे तौर पर 4.0E81 परमाणुओं में से प्रत्येक के लिए एक अलग पहचान बनाने वाले थे। तथ्य यह है कि इस तरह के पहचानकर्ता लगभग निश्चित रूप से अद्वितीय होंगे किसी भी तरह से उन्हें "गैर-यादृच्छिक" नहीं बनाया जाएगा

— सुपरकैट

@supercat यह सच है - पर्याप्त रूप से बड़ी संख्या को देखते हुए इसकी अत्यधिक संभावना है कि डुप्लिकेट होंगे, लेकिन यह असंभव नहीं है। यह वास्तव में निर्भर करता है कि गैर-विशिष्टता के परिणाम कितने बुरे हैं कि क्या ओपी वर्णन कर रहा है यह एक अच्छा विचार है।

— EJoshuaS -

यदि एक यादृच्छिक मौका टकराने की संभावना एक मीट स्ट्राइक की संभावना से छोटी होती है, तो ऐसे उपकरण जो यूनिक आईडी पर निर्भर होते हैं, एक इंजीनियरिंग परिप्रेक्ष्य से, पूर्व के बारे में चिंता करने की कोई आवश्यकता नहीं है। ऐसी किसी भी चीज़ के बारे में चिंता करने की ज़रूरत होगी जो यादृच्छिक संख्याओं को स्वतंत्र नहीं होने का कारण बन सकती है, लेकिन यादृच्छिक टकराव एक गैर-मुद्दा होगा।

— सुपरकैट

@supercat मुझे लगता है कि आप इसे गलत बता रहे हैं, जन्मदिन के विरोधाभास पर अन्य उत्तर देखें, मुझे लगता है कि आप जितना गणना कर रहे हैं उससे कहीं अधिक संभावना है - ओपी सिर्फ 32-बिट संख्या का उपयोग कर रहा है, इसलिए मुझे यकीन नहीं है कि आप कहां हैं ' 4096 से फिर से मिल रहा है, और खानाबदोश के रूप में उस लंबाई की एक संख्या के साथ एक अंतिम टकराव की संभावना वास्तव में आश्चर्यजनक उच्च है।

— EJoshuaS -

यदि आप टकराव पूरी तरह से अस्वीकार्य हैं तो छोटी आबादी के लिए भी 32-बिट संख्या बहुत कम है। यदि कोई ऐसी संख्या का उपयोग करता है जो पर्याप्त रूप से बड़ी है तो यादृच्छिक टकराने की संभावना को उस बिंदु तक कम कर सकती है जहां कोई सुरक्षित रूप से यह मान सकता है कि वे बस नहीं होंगे, और कई मामलों में एक बड़ी संख्या का उपयोग करके अन्य साधनों का उपयोग करने की कोशिश करने से बेहतर हो सकता है। विशिष्टता सुनिश्चित करना, चूंकि बाद में आम तौर पर उन राज्य संक्रमणों तक पहुंच की आवश्यकता होती है जो पूर्ववत या लुढ़का नहीं जा सकता है, भले ही सिस्टम की घड़ी रीसेट हो या सिस्टम बैकअप से पुनः लोड किया गया हो।

— सुपरकैट

Answer 9

इससे कोई फर्क नहीं पड़ता कि आप कितने बिट्स का उपयोग करते हैं - आप यह गारंटी नहीं दे सकते कि दो "यादृच्छिक" नंबर अलग होंगे। इसके बजाय, मेरा सुझाव है कि आप कंप्यूटर के IP पते या अन्य नेटवर्क पते और अनुक्रमिक संख्या जैसी किसी चीज़ का उपयोग करते हैं, अधिमानतः एक HONKIN 'बड़ा अनुक्रमिक संख्या - 128 बिट (स्पष्ट रूप से अहस्ताक्षरित) एक अच्छी शुरुआत की तरह लगता है, लेकिन 256 बेहतर होगा।

Answer 10

नहीं बिलकुल नहीं। जब तक आप बिना प्रतिस्थापन के नमूनों का उपयोग कर रहे हैं, तब तक एक मौका है - हालांकि दोहराव का छोटा।