[C] scanner internet

[misterx]

Originariamente inviato da WarDuck

Mi sembra un po' ambizioso in effetti farlo con una singola macchina usando la semplice forza bruta.

In ogni caso sarebbe interessante capire se e dove puoi arrivare prima di saturare la banda, quindi appoggio comunque la pazzia .

In realtà di quei 2^32 indirizzi ne dovresti esplorare un po' di meno perché dal mio punto di vista andrebbero escluse tutte le classi private (ad esempio il range di indirizzi tipicamente assegnati alle reti LAN). Diciamo ti risparmi poco più di 16 milioni di indirizzi, certo non sono niente in confronto ai 4 miliardi, ma comunque sempre meglio di niente.

Dopodiché partirei più in piccolo ad esempio restringendo gli IP a quelli Italiani o presunti tali. Inutile fare un censimento degli IP cinesi anche perché più ti allontani e più ti costa in termini di tempo.

Io procederei poi per passi, ad esempio, se tanto pensi di connetterti alla porta 80, tanto vale fare prima un censimento di quanti ti rispondono su quella porta.

Dal momento che tipicamente la connect() aspetta che il 3-way handshake di TCP sia completato, forse potrebbe valere la pena usare i socket raw per mandare prima un arbitrario numero di TCP SYN e vedere quanti rispondono con SYN ACK.

Cioè dal mio punto di vista come ti dicevo prima, la strategia migliore è quella di generare ed avere un numero di pacchetti in volo molto alto. Per fare questo non devi necessariamente aspettare che ti rispondano subito, ma lanciarne quanti più ne puoi e aspettare in seguito.

Il tempo di risposta del server non dipende da te, ma il tempo di generazione del pacchetto e l'invio si.

In alternativa, più semplice che usare i socket raw, puoi fare quello che ti dicevo prima quindi avere in volo tante "GET".

Non ho memoria dei socket Windows ma penso esistano funzioni che ti permettano di ascoltare gli eventi da più socket in contemporanea, stile select() o poll().

PS: mi sembra di ricordare che Windows abbia un limite per le connessioni half-opened (ovvero connessioni con SYN in attesa di SYN-ACK) quindi potrebbe essere per questo che hai problemi con più di 30 threads.

capisco che l'idea è folle ma interessante
Poi oramai sono lanciato e credo sia solo una questione di regolazioni del tutto. Come già detto, funzionicchia con 30 thread ed impiega un tempo abbastanza umano rispetto a quando aprivo un aolo socket ed attendevo, ora è una pacchia. Nella prima versione avevo messo un timer per chiudere la socket anzi tempo (dopo 2 secondi) in quanto, esiste una sorta di attesa di 21 secondi se dall'altra parte non risponde nessuno ed è un tempo che ho letto, non è modificabile almeno, io non ci sono riuscito.
Avevo provato anche col ping ma mi sono detto: e se ci sono server che se ne fregano del ping? questi non li vedo.
Diciamo che in questa prima versione testo solo la porta 80 ma nella successiva, intendo testare anche qualche porta in più se la 80 non mi risponde.

[WarDuck]

Originariamente inviato da misterx

capisco che l'idea è folle ma interessante
Poi oramai sono lanciato e credo sia solo una questione di regolazioni del tutto. Come già detto, funzionicchia con 30 thread ed impiega un tempo abbastanza umano rispetto a quando aprivo un aolo socket ed attendevo, ora è una pacchia. Nella prima versione avevo messo un timer per chiudere la socket anzi tempo (dopo 2 secondi) in quanto, esiste una sorta di attesa di 21 secondi se dall'altra parte non risponde nessuno ed è un tempo che ho letto, non è modificabile almeno, io non ci sono riuscito.
Avevo provato anche col ping ma mi sono detto: e se ci sono server che se ne fregano del ping? questi non li vedo.
Diciamo che in questa prima versione testo solo la porta 80 ma nella successiva, intendo testare anche qualche porta in più se la 80 non mi risponde.

Se usi una connect() TCP con socket bloccanti, la chiamata blocca fino a quando non viene stabilita una connessione (o il timeout scade), che nel caso TCP significa aspettare il 3-way handshake.

Anche abbreviando il timeout sulle connect() sull'ordine delle centinaia di millisecondi (assumendo IP Italiani) un eventuale ciclo di connect() il tuo throughput sarebbe comunque limitato ad una frequenza di 1/timeout tentativi di connessione al secondo.

Se assumi un timeout di 1s, un singolo thread tenterà 1 connessione al secondo, assumendo che tu abbia 30 thread e non ci siano overhead di gestione particolarmente significativi, 30 connessioni al secondo.

Come puoi vedere più abbassi il timeout e più aumenta il throughput, inteso come numero di tentativi che puoi fare nell'unità di tempo.

Infatti la cosa ideale è avere timeout=0 che è quello che ti suggerisco io .

Con socket non bloccanti o con le raw socket, puoi lanciare N SYN in parallelo a più server senza dover necessariamente aspettare che questi rispondano.

Questo significa che anche un thread singolo può lanciare in brevissimo tempo tanti tentativi di connessione.

Il motivo è che non sei più limitato dal tuo codice quanto dai cicli di clock della CPU (inteso anche come overhead del SO) e dalla banda di rete.

[misterx]

grazie per le info.
Sto provano con 65535 thread e si ferma a 1519 thread in esecuzione, molto probabilmente si esaurisce lo stack.
Mi chiedevo chi gestiche la concorrenza sulla scheda tra le varie connessioni: ci pensa l'SO visto che io istanzio tutti i thread e non me ne occupo?
Non vedendo messaggi di errore, a parte quelli delle connessioni mancate, devo pensare che sia l'SO a gestire la concorrenza.

[WarDuck]

Originariamente inviato da misterx

grazie per le info.
Sto provano con 65535 thread e si ferma a 1519 thread in esecuzione, molto probabilmente si esaurisce lo stack.
Mi chiedevo chi gestiche la concorrenza sulla scheda tra le varie connessioni: ci pensa l'SO visto che io istanzio tutti i thread e non me ne occupo?
Non vedendo messaggi di errore, a parte quelli delle connessioni mancate, devo pensare che sia l'SO a gestire la concorrenza.

Si, ci pensa il SO . O meglio il driver della scheda di rete .

[misterx]

Originariamente inviato da WarDuck

Si, ci pensa il SO . O meglio il driver della scheda di rete .

meglio, un problema di meno grazie 1000

Tra una send ed una receive io imposto un certo tempo di attesa, non sto usando gli eventi in quanto ero convinto che se si usano socket bloccanti questi non erano necessari, ma ho idea che mi sto sbagliando. Se setto 250 ms tra send e receive mi arrivano dati, se setto 1000 ms non arriva più nulla, come se il thread successivo o precedente svuoti la cache per lascar posto alle successive chiamate.
Cioè è come se il sistema mi stesse dicendo: se ti svegli prendi i dati altrimenti li perdi.
Ho idea che la miglior soluzione sia settare gli eventi ed è meglio che non mi chieda come fa il sistema a gestire tutte queste chiamate, che casotto

[WarDuck]

Originariamente inviato da misterx

meglio, un problema di meno grazie 1000

Tra una send ed una receive io imposto un certo tempo di attesa, non sto usando gli eventi in quanto ero convinto che se si usano socket bloccanti questi non erano necessari, ma ho idea che mi sto sbagliando. Se setto 250 ms tra send e receive mi arrivano dati, se setto 1000 ms non arriva più nulla, come se il thread successivo o precedente svuoti la cache per lascar posto alle successive chiamate.
Cioè è come se il sistema mi stesse dicendo: se ti svegli prendi i dati altrimenti li perdi.
Ho idea che la miglior soluzione sia settare gli eventi ed è meglio che non mi chieda come fa il sistema a gestire tutte queste chiamate, che casotto

La send() come detto non blocca mai a meno che il buffer della socket (lato SO) non sia pieno, mentre la receive() blocca fino a quando non ricevi almeno N bytes richiesti.

Quindi non hai bisogno di timers in questo caso a meno che appunto non vuoi forzare un timeout dopo un certo tempo che non ricevi nulla.

A quanto imposti la size della receive()? Tieni presente che appunto se chiedi di ricevere 100 bytes, la receive blocca fino a quando il buffer lato SO non contiene 100 bytes. Il che significa che se la risposta della GET è di 99 bytes, non vieni svegliato.

Questo mediamente, poi bisognerebbe capire se Windows ha qualche euristica particolare per cui magari si sveglia comunque dopo un certo tempo.

PS: con TCP non può mai succedere che perdi i dati a meno di leggerli e scartarli volontariamente.

[misterx]

Originariamente inviato da WarDuck

La send() come detto non blocca mai a meno che il buffer della socket (lato SO) non sia pieno, mentre la receive() blocca fino a quando non ricevi almeno N bytes richiesti.

Quindi non hai bisogno di timers in questo caso a meno che appunto non vuoi forzare un timeout dopo un certo tempo che non ricevi nulla.

A quanto imposti la size della receive()? Tieni presente che appunto se chiedi di ricevere 100 bytes, la receive blocca fino a quando il buffer lato SO non contiene 100 bytes. Il che significa che se la risposta della GET è di 99 bytes, non vieni svegliato.

Questo mediamente, poi bisognerebbe capire se Windows ha qualche euristica particolare per cui magari si sveglia comunque dopo un certo tempo.

PS: con TCP non può mai succedere che perdi i dati a meno di leggerli e scartarli volontariamente.

nel mio caso non imposto nessun size, anzi, chiamo il metodo ReceiveLength() il quale mi dice se ci sono dati da leggere ed in base a questo setto il buffer. Poi continuo a leggere sino a quando non trovo i caratteri \r\n\r\n che il protocollo HTTP, a quanto ho letto, usa per segnalare la fine dei dati; quindi, sino a quando non leggo \r\n\r\n tengo impegnato il socket con un while.
Se ad un certo punto non arriva nulla esco dal while per evitare deadlock.

Di TCP sapevo che non perdi nulla, di sicuro sbaglio io qualcosa nrl mio codice. Però ho notato se i thread si fermano a 10, non perdo alcun dato.
Molto probabilmente il ciclo che ho settato io per la lettura ha qualche problema quando tutto diventa più lento per via del maggior traffico enerato da molti thread.

Comunque, ottimi consigli, grazie.

[WarDuck]

Originariamente inviato da misterx

nel mio caso non imposto nessun size, anzi, chiamo il metodo ReceiveLength() il quale mi dice se ci sono dati da leggere ed in base a questo setto il buffer. Poi continuo a leggere sino a quando non trovo i caratteri \r\n\r\n che il protocollo HTTP, a quanto ho letto, usa per segnalare la fine dei dati; quindi, sino a quando non leggo \r\n\r\n tengo impegnato il socket con un while.
Se ad un certo punto non arriva nulla esco dal while per evitare deadlock.

Ok, non avevo mai sentito quel metodo, dev'essere custom dell'ambiente Borland. Tuttavia tieni presente che potrebbe non essere molto preciso, perché chiaramente nel frattempo possono arrivare altri dati.

Riguardo al timeout, di regola puoi impostarlo direttamente sulla socket usando la funzione setsockopt() abbinata al parametro SO_RCVTIMEO. Probabilmente ci sarà l'analoga funzione Borland.

Originariamente inviato da misterx

Di TCP sapevo che non perdi nulla, di sicuro sbaglio io qualcosa nrl mio codice. Però ho notato se i thread si fermano a 10, non perdo alcun dato.
Molto probabilmente il ciclo che ho settato io per la lettura ha qualche problema quando tutto diventa più lento per via del maggior traffico enerato da molti thread.

Comunque, ottimi consigli, grazie.

Mi sta venendo un dubbio: il buffer di ricezione è unico per tutti i thread o ne stai usando uno diverso per ogni thread?

Cioè da quello che ho capito io gestisci ogni socket con 1 thread, corretto? Ovvero, non hai niente di condiviso tra i thread, giusto?

Può darsi pure che ad un certo punto rallenta la rete e quindi ti trovi a ricevere i dati più tardi.

[misterx]

Originariamente inviato da WarDuck

Ok, non avevo mai sentito quel metodo, dev'essere custom dell'ambiente Borland. Tuttavia tieni presente che potrebbe non essere molto preciso, perché chiaramente nel frattempo possono arrivare altri dati.

Riguardo al timeout, di regola puoi impostarlo direttamente sulla socket usando la funzione setsockopt() abbinata al parametro SO_RCVTIMEO. Probabilmente ci sarà l'analoga funzione Borland.



Mi sta venendo un dubbio: il buffer di ricezione è unico per tutti i thread o ne stai usando uno diverso per ogni thread?

Cioè da quello che ho capito io gestisci ogni socket con 1 thread, corretto? Ovvero, non hai niente di condiviso tra i thread, giusto?

Può darsi pure che ad un certo punto rallenta la rete e quindi ti trovi a ricevere i dati più tardi.

è come hai intuito, ogni thread ha il suo buffer e socket personale, quindi non dovrebbero darsi fastidio in alcun modo cioè, l'unica risorsa in concorrenza è la scheda di rete ma mi hai detto che ci pensa l'SO e meno male che è così.

[WarDuck]

Volevo segnalare questo:

https://zmap.io/

[misterx]

Originariamente inviato da WarDuck

Volevo segnalare questo:

https://zmap.io/

molto interessante soprattuttto al momento, questo:

ZMap
ZMap è un veloce scanner di rete a pacchetto singolo ottimizzato per sondaggi di rete su Internet. Su un computer con una connessione Gigabit, ZMap può eseguire la scansione dell'intero spazio degli indirizzi IPv4 pubblico in meno di 45 minuti. Con una connessione 10gigE e PF_RING, ZMap può scansionare lo spazio degli indirizzi IPv4 in 5 minuti.


Comunque il mio progetto va avanti e istanziando n thread risulta piuttosto veloce, i 136 anni sono solo un ricordo lontano. Tempo di ottimizzarlo e se interessa vi dico le tempistiche che ottengo.

[misterx]

sto provando con 50 thread ma qualcuno mi ha detto che non ha senso superare il numero di core della CPU in quanto i thread vengono messi in attesa ma qui, secondo me, entra in ballo la statistica o sbaglio?

Potrei avere 50 thread in attesa oppure 50 che lavorano ma in questo caso è impossibile perchè non ho una CPU con 50 core, oppure la maggior parte che stanno fermi o viceversa. Quale strategia migliore?

Scusate, ho buttato li alcuni pensieri sparsi per capire come si ragiona in questi casi.

[WarDuck]

Originariamente inviato da misterx

sto provando con 50 thread ma qualcuno mi ha detto che non ha senso superare il numero di core della CPU in quanto i thread vengono messi in attesa ma qui, secondo me, entra in ballo la statistica o sbaglio?

Potrei avere 50 thread in attesa oppure 50 che lavorano ma in questo caso è impossibile perchè non ho una CPU con 50 core, oppure la maggior parte che stanno fermi o viceversa. Quale strategia migliore?

Scusate, ho buttato li alcuni pensieri sparsi per capire come si ragiona in questi casi.

Il livello di parallelismo effettivo è determinato principalmente dal numero di CPU che hai.

Tuttavia, ha senso aumentare il numero di thread quando puoi sovrapporre la computazione all'I/O e quindi molti di quei thread andrebbero spesso a dormire in attesa di avere dati pronti.

Ad esempio, hai diversi thread che fanno read() e bloccano in attesa di ricevere il dato, quando bloccano vengono messi in pausa dallo scheduler che assegna la CPU ad uno tra i thread pronti.

In questo modo, concedendo l'esecuzione ad altri thread, mascheri la latenza di ricezione dei dati da parte degli altri e nel frattempo fai lavoro utile.

Ovvio che oltre un certo numero sopraggiungono problemi di overhead dovuti ai cambi di contesto e al fatto che diventa più probabile che hai diversi thread pronti che ritardano la loro esecuzione perché non gli viene assegnata CPU dal SO.

Dipende dall'applicazione. Comunque te ne dovresti accorgere abbastanza facilmente, perché ad un certo punto se aumentando il numero di thread le prestazioni non aumentano o peggio diminuiscono vuol dire che sei arrivato a saturazione.

[misterx]

Originariamente inviato da WarDuck

Il livello di parallelismo effettivo è determinato principalmente dal numero di CPU che hai.

Tuttavia, ha senso aumentare il numero di thread quando puoi sovrapporre la computazione all'I/O e quindi molti di quei thread andrebbero spesso a dormire in attesa di avere dati pronti.

Ad esempio, hai diversi thread che fanno read() e bloccano in attesa di ricevere il dato, quando bloccano vengono messi in pausa dallo scheduler che assegna la CPU ad uno tra i thread pronti.

In questo modo, concedendo l'esecuzione ad altri thread, mascheri la latenza di ricezione dei dati da parte degli altri e nel frattempo fai lavoro utile.

Ovvio che oltre un certo numero sopraggiungono problemi di overhead dovuti ai cambi di contesto e al fatto che diventa più probabile che hai diversi thread pronti che ritardano la loro esecuzione perché non gli viene assegnata CPU dal SO.

Dipende dall'applicazione. Comunque te ne dovresti accorgere abbastanza facilmente, perché ad un certo punto se aumentando il numero di thread le prestazioni non aumentano o peggio diminuiscono vuol dire che sei arrivato a saturazione.

ottime osservazioni.
Però se rendessi tutto parallelo dovrei rinunciare ai socket bloccanti, reintrodurre quelli non bloccanti e gestire i vari eventi in quanto questi si attivano solo quando c'è qualcosa da fare.

Grazie 1000

[pabloski]

Originariamente inviato da WarDuck

Ovvio che oltre un certo numero sopraggiungono problemi di overhead dovuti ai cambi di contesto

Dò il mio piccolo contributo...è qui che entra in gioco Go e le sue goroutines! Green threading, con un'euristica molto astuta, che mappa i thread/goroutine sui thread nativi del sistema operativo ed è in grado di misurare l'overhead, in modo da decidere se/quando procedere con lo scheduling in modo da aumentare il throughput.

Nella pratica si possono lanciare centinaia di goroutine senza doversi preoccupare di misurare i livelli di saturazione.

Ovviamente l'ho buttata lì come informazione utile. Lungi da me forzare misterx a riscrivere il tutto in Go

[misterx]

quasi quasi, come mi è stato suggerito qualche post fa, farei prima a dialogare direttamente col driver della scheda di rete e togliere di mezzo l'SO con tutte le sue regole, forse impiegherei meno tempo.

[pabloski]

Originariamente inviato da misterx

quasi quasi, come mi è stato suggerito qualche post fa, farei prima a dialogare direttamente col driver della scheda di rete e togliere di mezzo l'SO con tutte le sue regole, forse impiegherei meno tempo.

Il problema sono quei limiti artificiali imposti da Windows. Che poi magicamente spariscono o salgono appena si appena alle versione Enterprise, Pro Workstation, ecc...

Interfacciarsi col driver non ti aiuterebbe coi limiti sui thread. E ovviamente dovresti implementare tutto quello che sta al di sopra del livello datalink.

[misterx]

Originariamente inviato da pabloski

Interfacciarsi col driver non ti aiuterebbe coi limiti sui thread. E ovviamente dovresti implementare tutto quello che sta al di sopra del livello datalink.

hai ragione, mi ero dimenticato di tutti i protocolli

[misterx]

Originariamente inviato da misterx

ottime osservazioni.
Però se rendessi tutto parallelo dovrei rinunciare ai socket bloccanti, reintrodurre quelli non bloccanti e gestire i vari eventi in quanto questi si attivano solo quando c'è qualcosa da fare.

Grazie 1000

mi rimangio quanto ho scritto. Effettuando delle prove con un numero di thread via via crescente si nota che l'attività aumenta. Però se non vi dico come ho costruito il programma non si capisce.
Parto con 250 thread ed ogni volta che uno termina il suo compito un altro prende il suo posto.

Ho provato con 5 e si addormenta tutto nel senso che, attendono il timeout per qualche ragione, se si sale l'attesa diminuisce. A volte le soluzioni migliori si nascondono nella semplicità

[pabloski]

Originariamente inviato da misterx

Parto con 250 thread ed ogni volta che uno termina il suo compito un altro prende il suo posto.

Nel senso che hai un pool di 250 thread e appena finisce il thread X associato al socket 1, metti al suo posto il thread Y associato al socket 2? O nel senso che l'esecuzione è serializzata? Non penso che l'ultima darebbe grandi risultati.

Originariamente inviato da misterx

Ho provato con 5 e si addormenta tutto nel senso che, attendono il timeout per qualche ragione, se si sale l'attesa diminuisce. A volte le soluzioni migliori si nascondono nella semplicità

Questioni di statistica. In 250 connessioni, una che si sbriga rapidamente la trovi. Poi dopo un tot si sbriga la seconda più veloce, ecc...

E vedo un flusso pressochè costante di connessioni che terminano a breve distanze le une dalle altre.

Su 5 thread è assai probabile incappare in 5 tartughe.