Newsgroup: it.comp.lang.perl
Titolo: Digest::MD5 e valori da dargli

Vorrei creare una stringa lunga 32 byte e che sia univoca... 
code:
------------------------------------------------------------------------
use Digest::MD5;
 
$md5 = Digest::MD5->new;
$md5->add(time);
$md5->add(process_id);
$md5->add(numero_random);
$digest = $md5->hexdigest;
 
print "Digest is $digest\n";
------------------------------------------------------------------------
time c'è l'ho. 
qual'è variabile che determina il process_id del programma in 
esecuzione? 
come creo un numero di 10 cifre a random? 
Credete che ci debba buttare anche la REMOTE_PORT? 
grazie...

Vorrei creare una stringa lunga 32 byte e che sia univoca... 
Univoca in che ambito? Locale al programma, locale al sistema, globale...
Hai dato un'occhiata ai moduli Data::Uniqid e Sys::UniqueID?
Ciao.

 wrote:

locale al programma...
cmq aspetto risposta alla precedente domanda...

 wrote:
ripensandoci i moduli che mi hai consigliato sono buoni...ma cosa fanno 
di diverso rispetto al mio probabile script?

Hai dato un'occhiata ai moduli Data::Uniqid e Sys::UniqueID?
Questi moduli brillano per l'assenza di una documentazione
appropriata.
Qualcuno ha esperienza del loro uso? Sono moduli affidabili (nel senso
che mantengono ciň che promettono)
Daniele

cmq aspetto risposta alla precedente domanda...
La variabile $$ (o $PID, o $PROCESS_ID, se applichi il pragma use English)
dovrebbe contenere l'identificatore di processo. In Windows, però, potrebbe
essere meglio affidarsi a qualcosa di più specifico (Win32:.Process ecc.).
Ciao.

, scriveva:

Il punto più importante non è "cosa", ma "chi": se lo fanno già loro,
perché perdere tempo a rifarlo tu?
Comunque, questi moduli tentano di costruire un identificatore univoco
globale. Per fare questo, danno per scontato che sia disponibile un nome
host (Data::Uniqid) o un indirizzo IP (Sys::UniqueID) univoco. Nelle
situazioni in cui è veramente necessario un identificatore globale, di
solito questa condizione è soddisfatta.
Ciao.

alla fine ho potato pe questo:
#!/usr/bin/perl
use Digest::MD5;
$tempo = time;
$acaso = int(rand 100000) + 1;
$process_id = $$;
$md5 = Digest::MD5->new;
$md5->add($tempo);
$md5->add($acaso);
$md5->add($process_id);
$digest = $md5->hexdigest;
print "Content-type: text/plain", "\n\n";
print "Digest is $digest\n";
speriamo bene...

che mantengono ciò che promettono)
Non vedo perché no: creare un identificatore univoco non richiede poi
tecnologie estreme; è sufficiente avere a disposizione un identificatore
univoco di se stessi e aggiungere un identificatore univoco dell'oggetto.
Per se stessi, hostname o indirizzo IP vanno benissimo, per cominciare; se,
nell'ambito dello stesso IP, si pensa che qualcun altro, nello stesso
momento, possa generare un identificatore con la stessa tecnica, si può
aggiungere il numero di processo.
Per l'oggetto, potrebbe bastare anche un progressivo puro, ma di solito si
prende l'istante (secondo un'opportuna granularità: giorno, ora, secondo,
millisecondo...) in cui è generato l'identificatore. Sostanzialmente,
questa è la tecnica utilizzata da entrambi i moduli (Data::Uniqid fa uso di
Time::HiRes, per ridurre la granularità temporale; Sys::UniqueID aggiunge
un progressivo all'interno del secondo).
Credo che la possibilità di fallimento siano estremamente ridotte, purché
sia ben definito l'identificatore di se stessi.
Ciao.


Potrei sbagliarmi ma non sono del tutto convinto di questo. Penso
invece che sia un task non banale se si desidera la certezza che il
tuo ID sia unico su tutto il pianeta. 
Un' occhiata ai moduli mostra come l'algoritmo di formazione dell'ID
in entrambi i moduli non sia deterministico bensì aleatorio.I moduli
si basano  fondamentalmente sul 1) tempo e su 2) IP 
L'unicità di 1) non può ovviamente essere garantita e quella di 2) non
è garantita se il modulo è in esecuzione su un PC in una rete locale
sconnessa da altre reti, all'interno della quale in teoria è possibile
assegnare un IP a piacimento.
Quindi, in sostanza: l'ID generato è *assai probabilmente* unico -
credo - ma non hai certezze e questo potrebbe essere  un problema
fatale per alcune applicazioni.
Se così fosse  il nome della funzione UniqueID unitamente alla
mancanza di documentazione su quest'aspetto può indurre in errore. 
Ciao

$digest = $md5->hexdigest;
C'è un celebro episodio raccontato da Knuth in "The art of computer
programming" (non ricordo più in quale volume) in cui raccontava di un
proprio algoritmo che era stato costruito per produrre numeri a caso
che più a caso non si può utilizzando proprio metodi basati sulla
combinazione di numeri chiamati "a caso" con algoritmi deterministici
Dopo poche iterazioni la sequenza produceva un valore costante....
Daniele

 Dopo poche iterazioni la sequenza produceva un valore costante....
Ma LOL!
 Raffaello

Ma LOL!
Ci sono  molti aneddoti  umoristici nel mondo degli algoritmi
statistici o dei numeri casuali
Vetterling racconta in "Numerical recipes in C" che andò in un centro
di calcolo IBM che stava qualche piano sopra o qualche piano sotto al
suo ufficio protestando in quanto una analisi delle uscite di un
generatore di numeri casuali mostrava che le sequenze si addensavano
su una certa ipersuperficie. Gli fu risposto con le seguenti immortali
parole:
"Ma noi garantiamo che i singoli numeri siano casuali, non insiemi di
numeri" (sic!)
Trovate il testo originale da qualche parte nella sezione dei metodi
Montecarlo
Ciao

speriamo bene...
Più che altro, non capisco perché vuoi usare un digest. Non che introduca
un reale pericolo di sovrapposizione (se i valori sono uguali, i digest
sono uguali; se i valori sono diversi, il digest è, con grande probabilità,
diverso), ma non aggiunge neanche nulla, e complica (mi pare, inutilmente)
la cosa.
Ciao.

mancanza di documentazione su quest'aspetto può indurre in errore.
Certo, l'algoritmo di generazione dell'identificatore, e le condizioni da
soddisfare perché sia unico dovrebbero essere documentati. Il sorgente,
però, è pur sempre lì per essere letto.
Ciao.


Ottima segnalazione, assai pertinente.
Richiamo parte del testo:
"If the random number generator is good, this will *reduce* (enfasi
mia) the odds of a collision of message IDs to well below the odds
that a cosmic ray will cause the computer to miscompute a result. That
means that it's good enough"
Il punto è tenere presente la differenza tra probabilità e rischio.
Avere una bassa probabilità di una collisione tra due id associati a
messaggi di posta elettronica è una buona cosa. Avere la stessa
probabilità di un evento a seguito del quale si perdono vite umane o
milioni di euro è altra cosa. Ovvero  il rischio è il prodotto della
probabilità per il costo. Il fatto che un evento sia di per se poco
probabile non è una misura che da sola sia sufficiente per prendere
decisioni. Quello che mi premeva mettere in luce con il mio intervento
è il fatto che tutti quelli che usano questo modulo dovrebbero sapere
che l' ID ottenuto non è garantito sia unico. 
Quando un autore scrive: " luniqid generates a long id valid
everywhere and ever" mi pare stia facendo una affermazione
potenzialmente piuttosto pericolosa. Certo, come dici tu si può sempre
guardare il sorgente. Però....
Ooops. Mi sono accorto adesso che tutto questo non c'entra più nulla
con il perl...mi scuso

sub stringa_casuale {
my $byte=shift;
my $stringa;
$stringa.=chr int rand 256 while $byte-->0;
return $stringa;
}
se ti serve solo la stringa casuale questa funzione dovrebbe bastare.
Come parametro della funzioni gli passi il numero di byte della stringa da
generare.
print stringa_casuale(32);
La probabilità che la stringa collida con un altra è di 256^256.
Veramente alto, 16byte sono più che sufficenti.
Ciao ciao.

, "LordSaga640" <er...@fgfsd.sdf> 
wrote:

ti ringrazio Lord...ma veramente a me servirebbe un stringa composta da 
caratteri "Printable"...

dipende da una convenzione.
L'idea stessa di un identificatore univoco è, direi, intrinsecamente,
una questione di convenzioni. Se anche uno scienziato se ne uscisse
fuori con qualche entità naturale che può univocamente identificare il
soggetto che genera l'algoritmo (lo spettro solare, o il DNA, o chessò
io), si tratterebbe poi comunque di codificarla, e la codifica dipende
necessariamente dall'adozione di una fra innumerevoli convenzioni. 
Nulla può garantire che qualcuno, dall'altra parte della galassia,
usando il proprio caratterizzatore locale, di per sé unico, arrivi,
attraverso una diversa codifica, alla medesima sequenza di bit. O che
qualcuno, più incoscientemente, ignorando la raccomandazione del
suddetto scienzato, produca la stessa sequenza perché corrisponde al
numero di telefono della sua ragazza (scelta di per sé anche
difendibile: in fondo, nel suo ambito, anche quello è unico).
E` necessario un accordo preventivo anche sul modo in cui si genera
l'identificatore.
Siamo però, ammetterai, in un'accezione piuttosto esoterica di
"identificatore univoco". Se devo realizzare un sistema di gestione
del traffico areo, che 
08ulk0ts81lrstcvm...@4ax.com
identifichi un barattolo di pomodori sullo scaffale di un supermercato
di Aldebaran IV, o un messaggio su Usenet, non mi impedisce di usarlo
con assoluta confidenza per identificare un volo, nonostante la
possibile criticità dell'applicazione. Non sarà "universalmente unico"
in senso assoluto, ma lo è a sufficienza per i miei scopi, perché la
collisione fra aerei e barattoli di pomodori o messaggi è garantita
impossibile a priori.
Ai fini pratici, è sempre possibile ridursi ad un contesto
sufficientemente sicuro nell'ambito dell'applicazione e per i fini che
si perseguono. Sarà il male di mettersi d'accordo, una volta per
tutte, fra produttori di client di posta, che il Message-Id si
costruisce secondo le raccomandazioni contenute nel documento
http://www.jwz.org/doc/mid.html
, o stilare un protocollo ancora più
rigido per applicazioni più critiche. Date però queste premesse, la
generazione locale di un identificatore universale univoco è una
procedura praticabile.
Ciao.

 caratteri "Printable"...
 sub stringa_casuale {
 my $byte=shift;
 my $stringa;
$stringa.=chr int rand 256 while $byte--;
return unpack "H*", $stringa;
 }
Cosě ti ritorna in esadecimale.
Piů printable di cosě :D