J'ai un petit probleme avec un fork :
Je cherche a tester l'ensemble des ports d'une machine de mon r=E9seau
local pour voir lesquels sont ouverts, et j'=E9cris ces resultats dans
un fichier.
Pour v=E9rifier l'ouverture, j'utilise le module IO::Socket::INET.
J'ai plac=E9 le code pour se connecter au port dans un fork, de la
mani=E8re suivante :
//DEBUT DU CODE//
my $pid;
my $socket;
for (my $i =3D $start ; $i <=3D $stop ; $i++)
{
defined($pid =3D fork) or die "Pas de fork possible : $!";
unless($pid) {
$socket =3D IO::Socket::INET->new(
PeerAddr =3D> $adresse,
Proto =3D> $proto,
PeerPort =3D> $i
) or exit(0);
$socket =3D undef;
print "OPEN : \t$i\n";
print(FIC "OPEN : \t$i\n");
exit(0);
}
# waitpid($pid, 0);
}
//FIN DU CODE//
Mon probleme : quand je lance le scan sur un petit nombre de ports,
aucun probleme, ca va meme tr=E8s vite. Mais si je veux faire des
grandes s=E9ries, j'ai une erreur ( ressources momentan=E9ment
indisponibles ) .
Donc je suis obliger de remettre le waitpid, ce qui est tr=E8s long!
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
"Timothée POISOT" wrote in message :
Mon probleme : quand je lance le scan sur un petit nombre de ports, aucun probleme, ca va meme très vite. Mais si je veux faire des grandes séries, j'ai une erreur ( ressources momentanément indisponibles ) .
Le nombre de process est limité à plusieurs niveaux (limites imposées pour équilibrer l'usage des resources, limite globale à l'OS, limite de la mémoire de la machine). De toute évidence, cette limite est atteinte.
Donc je suis obliger de remettre le waitpid, ce qui est très long!
Est-ce que quelqu'un à une idée?
La méthode standard, c'est de se fixer un nombre de process en parallèle : tant qu'il y en a moins, on forke à fond, et quand la limite est atteinte on met des waitpid pour attendre que ça se libère.
On peut faire la même chose en visant la limite elle-même, mais ce n'est pas une bonne idée parce que ça va monopoliser toute la session, impossible de faire quelque chose en parallèle.
Une autre possibilité encore est de ne pas forker et d'utiliser les sockets de manière asynchrone, mais c'est plus pénible à gérer, et il y a aussi des limites sur les file descriptors qu'un processus peut avoir. On peut combiner les deux limites pour aller plus loin.
Ceci dit, la méthode la plus simple _et_ la plus efficace est certainement d'installer nmap, qui fait tout ça bien mieux que n'importe quel script perl. (Et en prime, comme dans certains modes il fait sa propre tambouille réseau, il est moins sujet aux limites.)
"Timothée POISOT" wrote in message
<1137495077.882021.202850@z14g2000cwz.googlegroups.com>:
Mon probleme : quand je lance le scan sur un petit nombre de ports,
aucun probleme, ca va meme très vite. Mais si je veux faire des
grandes séries, j'ai une erreur ( ressources momentanément
indisponibles ) .
Le nombre de process est limité à plusieurs niveaux (limites imposées pour
équilibrer l'usage des resources, limite globale à l'OS, limite de la
mémoire de la machine). De toute évidence, cette limite est atteinte.
Donc je suis obliger de remettre le waitpid, ce qui est très long!
Est-ce que quelqu'un à une idée?
La méthode standard, c'est de se fixer un nombre de process en parallèle :
tant qu'il y en a moins, on forke à fond, et quand la limite est atteinte on
met des waitpid pour attendre que ça se libère.
On peut faire la même chose en visant la limite elle-même, mais ce n'est pas
une bonne idée parce que ça va monopoliser toute la session, impossible de
faire quelque chose en parallèle.
Une autre possibilité encore est de ne pas forker et d'utiliser les sockets
de manière asynchrone, mais c'est plus pénible à gérer, et il y a aussi des
limites sur les file descriptors qu'un processus peut avoir. On peut
combiner les deux limites pour aller plus loin.
Ceci dit, la méthode la plus simple _et_ la plus efficace est certainement
d'installer nmap, qui fait tout ça bien mieux que n'importe quel script
perl. (Et en prime, comme dans certains modes il fait sa propre tambouille
réseau, il est moins sujet aux limites.)
Mon probleme : quand je lance le scan sur un petit nombre de ports, aucun probleme, ca va meme très vite. Mais si je veux faire des grandes séries, j'ai une erreur ( ressources momentanément indisponibles ) .
Le nombre de process est limité à plusieurs niveaux (limites imposées pour équilibrer l'usage des resources, limite globale à l'OS, limite de la mémoire de la machine). De toute évidence, cette limite est atteinte.
Donc je suis obliger de remettre le waitpid, ce qui est très long!
Est-ce que quelqu'un à une idée?
La méthode standard, c'est de se fixer un nombre de process en parallèle : tant qu'il y en a moins, on forke à fond, et quand la limite est atteinte on met des waitpid pour attendre que ça se libère.
On peut faire la même chose en visant la limite elle-même, mais ce n'est pas une bonne idée parce que ça va monopoliser toute la session, impossible de faire quelque chose en parallèle.
Une autre possibilité encore est de ne pas forker et d'utiliser les sockets de manière asynchrone, mais c'est plus pénible à gérer, et il y a aussi des limites sur les file descriptors qu'un processus peut avoir. On peut combiner les deux limites pour aller plus loin.
Ceci dit, la méthode la plus simple _et_ la plus efficace est certainement d'installer nmap, qui fait tout ça bien mieux que n'importe quel script perl. (Et en prime, comme dans certains modes il fait sa propre tambouille réseau, il est moins sujet aux limites.)
Timothée POISOT
Ouais...
Ok pour nmap, mais ca m'interessait de le faire tout seul... Je vais essayer de jouer avec la limite des pid.
Merci
Ouais...
Ok pour nmap, mais ca m'interessait de le faire tout seul...
Je vais essayer de jouer avec la limite des pid.
On Tue, 17 Jan 2006 11:51:17 +0100, Timothée POISOT"" wrote:
J'ai placé le code pour se connecter au port dans un fork
Question idiote: quel intérêt?
Jacques. -- Oxado http://www.oxado.com/
DoMinix
Timothée POISOT wrote:
Bonjour
J'ai un petit probleme avec un fork : ...
J'ai placé le code pour se connecter au port dans un fork, de la manière suivante :
//DEBUT DU CODE// ...
//FIN DU CODE//
Mon probleme : quand je lance le scan sur un petit nombre de ports, aucun probleme, ca va meme très vite. Mais si je veux faire des grandes séries, j'ai une erreur ( ressources momentanément indisponibles ) . Donc je suis obliger de remettre le waitpid, ce qui est très long!
Est-ce que quelqu'un à une idée?
Merci
si tu tient a faire des fork il y a chez Merlin un bon exemple http://www.stonehenge.com/merlyn/UnixReview/col41.html mais comme il dit lui meme tu peut utiliser Parallel::ForkManager pour faire ça.
-- dominix
Timothée POISOT wrote:
Bonjour
J'ai un petit probleme avec un fork :
...
J'ai placé le code pour se connecter au port dans un fork, de la
manière suivante :
//DEBUT DU CODE//
...
//FIN DU CODE//
Mon probleme : quand je lance le scan sur un petit nombre de ports,
aucun probleme, ca va meme très vite. Mais si je veux faire des
grandes séries, j'ai une erreur ( ressources momentanément
indisponibles ) .
Donc je suis obliger de remettre le waitpid, ce qui est très long!
Est-ce que quelqu'un à une idée?
Merci
si tu tient a faire des fork il y a chez Merlin un bon exemple
http://www.stonehenge.com/merlyn/UnixReview/col41.html
mais comme il dit lui meme tu peut utiliser Parallel::ForkManager
pour faire ça.
J'ai placé le code pour se connecter au port dans un fork, de la manière suivante :
//DEBUT DU CODE// ...
//FIN DU CODE//
Mon probleme : quand je lance le scan sur un petit nombre de ports, aucun probleme, ca va meme très vite. Mais si je veux faire des grandes séries, j'ai une erreur ( ressources momentanément indisponibles ) . Donc je suis obliger de remettre le waitpid, ce qui est très long!
Est-ce que quelqu'un à une idée?
Merci
si tu tient a faire des fork il y a chez Merlin un bon exemple http://www.stonehenge.com/merlyn/UnixReview/col41.html mais comme il dit lui meme tu peut utiliser Parallel::ForkManager pour faire ça.
-- dominix
Timothée POISOT
Parce qu'un crash dans fork ne plante pas le script... En gros, c'est une mesure de précaution...
Parce qu'un crash dans fork ne plante pas le script...
En gros, c'est une mesure de précaution...
Parce qu'un crash dans fork ne plante pas le script... En gros, c'est une mesure de précaution...
Paul Gaborit
À (at) 18 Jan 2006 07:18:35 -0800, "Timothée POISOT" écrivait (wrote):
Parce qu'un crash dans fork ne plante pas le script... En gros, c'est une mesure de précaution...
Mis à part un crash de perl lui-même (ce qui est très très rare et mérite un rapport de bug auprès des développeurs de perl), on peut toujours récupérer les erreurs d'exécution (ou traper les exceptions comme on dit). C'est l'un des usages intéressants de la forme :
eval {...};
Ce n'est donc pas le bon argument ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) 18 Jan 2006 07:18:35 -0800,
"Timothée POISOT" <t.poisot@gmail.com> écrivait (wrote):
Parce qu'un crash dans fork ne plante pas le script...
En gros, c'est une mesure de précaution...
Mis à part un crash de perl lui-même (ce qui est très très rare et
mérite un rapport de bug auprès des développeurs de perl), on peut
toujours récupérer les erreurs d'exécution (ou traper les exceptions
comme on dit). C'est l'un des usages intéressants de la forme :
eval {...};
Ce n'est donc pas le bon argument ;-)
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) 18 Jan 2006 07:18:35 -0800, "Timothée POISOT" écrivait (wrote):
Parce qu'un crash dans fork ne plante pas le script... En gros, c'est une mesure de précaution...
Mis à part un crash de perl lui-même (ce qui est très très rare et mérite un rapport de bug auprès des développeurs de perl), on peut toujours récupérer les erreurs d'exécution (ou traper les exceptions comme on dit). C'est l'un des usages intéressants de la forme :
eval {...};
Ce n'est donc pas le bon argument ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Timothée POISOT
Serait-il alors possible d'avoir le bon argument? (outre le fait qu'il y a toujours plusieurs façons de faire une seule tache)
Serait-il alors possible d'avoir le bon argument?
(outre le fait qu'il y a toujours plusieurs façons de faire une seule
tache)
Serait-il alors possible d'avoir le bon argument? (outre le fait qu'il y a toujours plusieurs façons de faire une seule tache)
Paul Gaborit
À (at) 18 Jan 2006 13:42:52 -0800, "Timothée POISOT" écrivait (wrote):
Serait-il alors possible d'avoir le bon argument?
C'est vous qui avez choisi d'utiliser 'fork', j'imagine donc que vous avez des arguments justifiant ce choix. Je soulignais juste que l'argument de la gestion des erreurs ne justifiait pas ce choix.
Je ne sais pas si vos autres arguments sont "bons" ou "mauvais". Et ne le surtout prenez pas comme une attaque personnelle : on a tous des "bonnes" ou "mauvaises" raisons de faire tel ou tel choix.
Personnellement, avant de choisir la solution du 'fork' (ou du multi-thread), j'aurais jeté un oeil du côté du module Net::Ping qui serait peut-être suffisant pour votre application...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) 18 Jan 2006 13:42:52 -0800,
"Timothée POISOT" <t.poisot@gmail.com> écrivait (wrote):
Serait-il alors possible d'avoir le bon argument?
C'est vous qui avez choisi d'utiliser 'fork', j'imagine donc que vous
avez des arguments justifiant ce choix. Je soulignais juste que
l'argument de la gestion des erreurs ne justifiait pas ce choix.
Je ne sais pas si vos autres arguments sont "bons" ou "mauvais". Et ne
le surtout prenez pas comme une attaque personnelle : on a tous des
"bonnes" ou "mauvaises" raisons de faire tel ou tel choix.
Personnellement, avant de choisir la solution du 'fork' (ou du
multi-thread), j'aurais jeté un oeil du côté du module Net::Ping qui
serait peut-être suffisant pour votre application...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) 18 Jan 2006 13:42:52 -0800, "Timothée POISOT" écrivait (wrote):
Serait-il alors possible d'avoir le bon argument?
C'est vous qui avez choisi d'utiliser 'fork', j'imagine donc que vous avez des arguments justifiant ce choix. Je soulignais juste que l'argument de la gestion des erreurs ne justifiait pas ce choix.
Je ne sais pas si vos autres arguments sont "bons" ou "mauvais". Et ne le surtout prenez pas comme une attaque personnelle : on a tous des "bonnes" ou "mauvaises" raisons de faire tel ou tel choix.
Personnellement, avant de choisir la solution du 'fork' (ou du multi-thread), j'aurais jeté un oeil du côté du module Net::Ping qui serait peut-être suffisant pour votre application...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Timothée POISOT
Je ne l'ai pas pris comme une attaque personelle, bien au contraire... Je vais regarder ce que le module Ping propose
Merci
Je ne l'ai pas pris comme une attaque personelle, bien au contraire...
Je vais regarder ce que le module Ping propose
