BugliL (Member)
Pro
 
Messaggi: 135
Iscritto: 09/08/2009
|
Voglio sviluppare un programma in Python per fare un brute-force attack su dei file Zip con password.
L'algoritmo per la generazione delle password è pronto, io ed un mio amico ci chiedevamo se l'attacco al file è più efficente (non chiedo se efficacie) se lo divido in più thread. (secondo me con 1 thread si fa meglio) Voi che ne pensate?
|
|
|
delta (Normal User)
Pro
Messaggi: 96
Iscritto: 01/09/2009
|
prova a fare una copia del file .zip e verifica quale ci mette di meno...
tutti e due arrivano alla stessa conclusione, quindi il risultato dovrebbe essere identico ma con tempi differenti!
EDIT: su uno fai lavorare quello ad un solo thread, alla copia quello da più thread...
Ultima modifica effettuata da delta il 25/10/2009 alle 18:09 |
|
|
BugliL (Member)
Pro
Messaggi: 135
Iscritto: 09/08/2009
|
Volevo che qualcuno mi chiarisse la cosa PRIMA di implementarlo 
Altrimenti non avrei postato avrei scritto una guuida sull'argomento...
|
|
|
TheKaneB (Member)
Guru^2
Messaggi: 1792
Iscritto: 26/06/2009
|
In generale un programma multithreaded si comporta in maniera diversa in base a tanti fattori:
- Singolo processore, programma che richiede calcoli intensivi (CPU Bound)
Meglio usare un singolo thread, per evitare l'overhead causato dal context switching.
- Singolo processore, programma che richiede numerose operazioni di input/output da rete o filesystem (I/O Bound)
Quando si effettua un'operazione di I/O, in genere, si introducono numerosi cicli di attesa dovuti ai lenti tempi di risposta delle periferiche di I/O (dischi, rete o altro...). Sfruttando un thread per ogni operazione da effettuare si parallelizza il tutto ottimizzando le attese. Ad esempio 10 thread effettuano contemporaneamente la propria richiesta di I/O, il kernel li blocca tutti e va risvegliando i thread man mano che completa le varie richieste, in questo modo non devi progettare delle complesse logiche per gestire le sincronizzazioni, ma ti affidi alla gestione delle risorse del sistema operativo.
- Multi processori, programma CPU Bound
Ha senso spezzare il programma in più thread ma con criterio. Se le operazioni da effettuare sono parallelizzabili (es: i dati intermedi dei calcoli hanno nessuna o poca dipendenza reciproca) allora è bene smontare il problema in N thread, uno per processore. Se i calcoli sono difficilmente parallelizzabili si introduce solo overhead e si rischia, tra l'altro, di perdere efficienza se più thread vanno a leggere di frequente un gruppo ristretto di dati. Se ciò accade si verificano 2 possibili scenari: 1) tutti i thread vogliono soltanto leggere quei dati: bene, la cache locale di ciascun processore si popolerà presto dei dati necessari e tutto filerà liscio; 2) alcuni dei thread vorranno scrivere su quei dati comuni: male, ogni scrittura necessita di un mutex lock che bloccherà tutti i thread che accedono a tale risorsa e in più la cache locale di ogni processore verrà costantemente invalidata, penalizzando di N volte l'efficienza rispetto ad una soluzione a thread singolo.
- Multi processori, programma I/O Bound
In questo caso ha sempre senso spezzare il programma in più thread, uno per ciascuna operazione di I/O, perchè generalmente ogni processore avrà le proprie linee di interrupt e i propri canali DMA per soddisfare le richieste di I/O senza intralciare gli altri processori che magari nel frattempo stanno eseguendo calcoli o sono impegnati in altri processi o altri thread dello stesso processo. Si verificano dei rallentamenti se più processori tentano di accedere allo stesso Bus contemporaneamente, ma sono comunque ampiamente compensati dai vantaggi.
Spero di averti dato delle delucidazioni utili per il tuo progetto. Nel tuo caso specifico si tratta di applicazione CPU Bound, quindi stai molto attento a come parallelizzi il calcolo.
Un ottimo metodo potrebbe essere creare ad esempio un thread che controlla tutte le password che iniziano per a*****, uno che prova quelle che iniziano per b*****, ecc... in questo modo eviti di creare dipendenze pericolose tra i dati intermedi. Ad esempio sarebbe troppo complicato da gestire il caso in cui un thread apre il file e lo legge, un altro genera la password, il terzo tenta di applicarla al file, e il quarto stampa il risultato. Se gestisci i thread in questo modo non solo avrai dei tremendi grattacapi dovuti alla sincronizzazione tra i thread, ma vedrai anche delle prestazioni basse dovute al fatto che, ad esempio, il thread che genera le password non potrà generare la prossima finchè il thread che le applica non avrà finito.
Ciao e buon divertimento! 
|
|
|
BugliL (Member)
Pro
Messaggi: 135
Iscritto: 09/08/2009
|
Postato originariamente da TheKaneB:
Spero di averti dato delle delucidazioni utili per il tuo progetto.....
|
Perfettamente quello che chiedevo....
In parallelo volevamo mettere solo l'attacco basandolo su "dividi et impera" in modo da aumentare l'efficacia del programma....
Grazie delle dritte TheKaneB.....  |
|
|
TheKaneB (Member)
Guru^2
Messaggi: 1792
Iscritto: 26/06/2009
|
Di nulla, figurati! Facci sapere come va a finire con il progetto
|
|
|
eddiewrc (Member)
Expert
Messaggi: 560
Iscritto: 30/04/2006
|
fallo multithread su macchine hyper-threaded, multiprocesso sumacchine multiprocessore e monoprocesso sulle altre.
|
|
|
