È accettabile affidarsi che gli ints casuali siano unici?

Ho implementato un protocollo di rete e ho bisogno che i pacchetti abbiano identificatori univoci. Finora, ho appena generato numeri interi casuali a 32 bit e presumo che sia astronomicamente improbabile che ci sia una collisione durante la durata di un programma / connessione. Questo è generalmente considerato una pratica accettabile nel codice di produzione o si dovrebbe escogitare un sistema più complesso per prevenire le collisioni?

Attenti al paradosso del compleanno .

Supponiamo di generare una sequenza di valori casuali (uniformemente, indipendentemente) da un insieme di dimensioni N (N = 2 ^ 32 nel tuo caso).

Quindi, la regola empirica per il paradosso del compleanno afferma che una volta generato circa i valori sqrt (N), esiste almeno il 50% di probabilità che si sia verificata una collisione, ovvero che ci siano almeno due valori identici nel sequenza generata.

Per N = 2 ^ 32, sqrt (N) = 2 ^ 16 = 65536. Quindi, dopo aver generato circa 65k identificatori, è più probabile che due di loro si scontrino che no! Se si genera un identificatore al secondo, ciò avverrebbe in meno di un giorno; inutile dirlo, molti protocolli di rete funzionano molto più velocemente di così.

È ampiamente accettabile fare affidamento sul fatto che numeri casuali siano univoci se quei numeri hanno abbastanza bit. Esistono protocolli crittografici in cui la ripetizione di un numero casuale interromperà l'intera sicurezza. E fintanto che non ci sono gravi vulnerabilità nel generatore di numeri casuali in uso, questo non è stato un problema.

Uno degli algoritmi per la generazione di UUID genererà effettivamente un ID costituito da 122 bit casuali e presuppone che sarà univoco. E due degli altri algoritmi si basano sul fatto che un valore di hash troncato a 122 bit sia unico, il che ha all'incirca lo stesso rischio di collisioni.

Quindi ci sono standard che fanno affidamento sul fatto che 122 bit sono sufficienti per rendere univoco un ID casuale, ma 32 bit non sono assolutamente sufficienti. Con ID a 32 bit sono necessari solo circa 2¹⁶ ID prima che il rischio di una collisione raggiunga il 50% perché con 2¹⁶ ID ci saranno quasi 2³¹ coppie ciascuna delle quali potrebbe essere una collisione.

Anche 122 bit è inferiore a quello che consiglierei in qualsiasi nuovo design. Se per te è importante seguire una certa standardizzazione, usa gli UUID. Altrimenti usa qualcosa di più grande di 122 bit.

La funzione hash SHA1 con un'uscita di 160 bit non è più considerata sicura, in parte perché 160 bit non sono sufficienti per garantire l'univocità delle uscite. Le moderne funzioni hash hanno output da 224 a 512 bit. Gli ID generati casualmente dovrebbero puntare alle stesse dimensioni per garantire unicità con un buon margine di sicurezza.

Definirei questa cattiva pratica. Il numero casuale genera semplicemente non crea numeri univoci, ma solo numeri casuali. È probabile che una distribuzione casuale includa alcuni duplicati. È possibile rendere questa circostanza accettabilmente improbabile aggiungendo un elemento di tempo. Se si ottiene l'ora corrente dall'orologio di sistema in millisecondi. Qualcosa come questo:

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

Farà molta strada. Ovviamente per garantire veramente l'unicità è necessario utilizzare UUID / GUID. Ma possono essere costosi da generare, quanto sopra è probabilmente sufficiente, poiché l'unica possibilità di sovrapposizione è se la generazione casuale avesse un duplicato nello stesso millisecondo.

Dipende sia dalla probabilità di fallimento che dalle conseguenze del fallimento.

Ricordo un dibattito tra persone del software e dell'hardware in cui le persone dell'hardware consideravano accettabile un algoritmo con una piccola probabilità di risultati errati (qualcosa come 1 errore in 100 anni) e la gente del software pensava che fosse un anatema. Si è scoperto che la gente dell'hardware calcolava abitualmente i tassi di guasto previsti e si era molto abituata all'idea che ogni tanto avrebbe dato risposte errate di tanto in tanto, ad esempio a causa di disturbi causati dai raggi cosmici; hanno trovato strano che i software si aspettassero un'affidabilità del 100%.

Certo, hai probabilità piuttosto basse di due numeri interi casuali a 32 bit sequenziali, ma non è del tutto impossibile. La decisione ingegneristica appropriata si basa su quali sarebbero le conseguenze delle collisioni, una stima del volume di numeri che stai generando, la durata in cui è richiesta l'unicità e cosa succede se un utente malintenzionato inizia a tentare di causare collisioni.

Può essere accettabile supporre che i numeri casuali saranno univoci ma devi stare attento.

Supponendo che i tuoi numeri casuali siano equamente distribuiti, la probabilità di una collisione è approssimativamente (n ^2/2 ) / k dove n è il numero di numeri casuali che generi e k è il numero di possibili valori che un numero "casuale" può assumere.

Non inserisci un numero astronomicamente improbabile, quindi prendiamolo come 1 su 2 ³⁰ (all'incirca in un miliardo). Supponiamo inoltre di generare 2 ³⁰ pacchetti (se ogni pacchetto rappresenta circa un kilobyte di dati, ciò significa circa un terabyte di dati totali, grandi ma non inimmaginabili). Troviamo che abbiamo bisogno di un numero casuale con almeno 2 ⁸⁹ valori possibili.

Innanzitutto i tuoi numeri casuali devono essere abbastanza grandi. Un numero casuale a 32 bit può avere al massimo 2 ³² possibili valori. Per un server impegnato che non è abbastanza vicino.

In secondo luogo, il generatore di numeri casuali deve avere uno stato interno sufficientemente ampio. Se il tuo generatore di numeri casuali ha solo uno stato interno a 32 bit, non importa quanto sia grande il valore che generi da esso otterrai comunque solo 2 ³² valori possibili.

In terzo luogo, se hai bisogno che i numeri casuali siano univoci tra le connessioni piuttosto che all'interno di una connessione, il tuo generatore di numeri casuali deve essere ben strutturato. Ciò è particolarmente vero se il programma viene riavviato frequentemente.

In generale, i generatori di numeri casuali "regolari" nei linguaggi di programmazione non sono adatti a tale uso. I generatori di numeri casuali forniti dalle librerie di crittografia sono generalmente.

integrato in alcune delle risposte di cui sopra è il presupposto che il generatore di numeri casuali sia effettivamente "piatto" - che la probabilità che uno qualsiasi dei due numeri sia il successivo generato è lo stesso.

Questo probabilmente non è vero per la maggior parte dei generatori di numeri casuali. La maggior parte dei quali utilizza alcuni polinomi di alto ordine applicati ripetutamente a un seme.

Detto questo, ci sono molti sistemi là fuori che dipendono da questo schema, di solito con UUID. Ad esempio, ogni oggetto e risorsa in Second Life ha un UUID a 128 bit, generato casualmente e raramente si scontrano.

Molte persone hanno già dato risposte di alta qualità, ma vorrei aggiungere alcuni punti minori: in primo luogo, il punto di @nomadictype sul paradosso del compleanno è eccellente .

Un altro punto: la casualità non è così semplice da generare e definire come la gente potrebbe presumere. (In effetti, sono disponibili test statistici per la casualità ).

Detto questo, è importante essere consapevoli dell'errore del giocatore d'azzardo , che è un errore statistico in cui le persone presumono che gli eventi indipendenti in qualche modo si influenzino a vicenda. Gli eventi casuali sono generalmente statisticamente indipendenti l'uno dall'altro - vale a dire se si genera casualmente un "10" non cambia la probabilità futura di generare più "10" in meno. (Forse qualcuno potrebbe escogitare un'eccezione a quella regola, ma mi aspetto che sarebbe il caso di quasi tutti i generatori di numeri casuali).

Quindi la mia risposta è che se potessi supporre che una sequenza sufficientemente lunga di numeri casuali fosse univoca, non sarebbero davvero numeri casuali perché sarebbe un chiaro schema statistico. Inoltre, ciò implicherebbe che ogni nuovo numero non è un evento indipendente perché se si genera, ad esempio, un 10, ciò significherebbe che la probabilità di generare 10s futuri sarebbe dello 0% (non potrebbe accadere), inoltre ciò significherebbe che aumenteresti le probabilità di ottenere un numero diverso da 10 (ovvero, più numeri genererai, maggiore sarà la probabilità di ciascuno dei numeri rimanenti).

Un'altra cosa da considerare: la possibilità di vincere il Powerball fuori dal gioco in una singola partita è, a mio avviso, circa 1 su 175 milioni. Tuttavia, le probabilità che qualcuno vinca sono considerevolmente più alte. Sei più interessato alle probabilità che qualcuno "vinca" (ovvero essere un duplicato) che alle probabilità di un determinato numero "vincente" / essere un duplicato.

Non importa quanti bit usi - NON PUOI garantire che due numeri "casuali" saranno diversi. Invece, ti suggerisco di usare qualcosa come l'indirizzo IP o altro indirizzo di rete del computer e un numero sequenziale, preferibilmente un numero sequenziale HONKIN BIG - 128 bit (ovviamente senza segno) sembra un buon inizio, ma 256 sarebbe meglio.

No certo che no. A meno che non utilizzi campioni senza sostituzione, c'è una possibilità, per quanto piccola, di duplicazioni.