Discussion :

[atum25]

Bonjour a tous,

Voila je réalise actuellement un programme de scrutation réseau.

Le programme ping chaque adresse d'une plage reseau (en ICMP), puis si l'adresse repond au ping, je crée un objet "Poste" qui a l'aide de ces méthodes, récupere le nom NetBios et l'adresse Mac.

Le problème est que la durée d'une scrutation pour environ 100Adresses qui repondent est de plus ou moin 10min.

Etant novice dans la programmation, j'aimerais connaitre les possibilités d'améliorer ce temps d'execution. ( rajouter des time-out, ou alors modifier complètement la structure du programme ...)

Voila merci a tous

[Ekleog]

Le plus simple serait de faire tourner chaque adresse dans un thread particulier.
Après, pour optimiser les performances, il est possible de créer un pool de threads qui va traiter les IP, mais ce ne sera utile que si tu as vraiment beaucoup d'IP à tester.

En gros, l'idée (pseudo-code) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
// Avant :
for (addr in addr_list)
   analyser_addresse(addr);
// Après
for (addr in addr_list)
   lancer_thread(analyser_addresse(addr));

Tu peux te renseigner sur std::thread (c++11) ou boost::thread, pour plus de détails techniques.

[srvremi]

Plusieurs exécutions simultanées je suis d'accord. Mais tu peux te contenter de forks je pense, pas obligatoire de passer par des thread à mon avis.

@+
Rémi

[atum25]

Merci a vous pour ces réponses.

J'ai oublier de préciser que je suis sous Windows, et avec C++Builder 6.

J'avais déja regarder un peu les threads mais je ne connais pas les fork(), pourrait tu m'en dire plus stp

[jblecanard]

Merci a vous pour ces réponses.

J'ai oublier de préciser que je suis sous Windows, et avec C++Builder 6.

J'avais déja regarder un peu les threads mais je ne connais pas les fork(), pourrait tu m'en dire plus stp

fork() crée un nouveau processus à la place d'un nouveau thread. Les processus peuvent communiquer entre eux via des pipes. Je ne vois pas ce que ça apporte par rapport au multi-threading (dans notre cas).

[therwald]

fork() est une fonction de la norme POSIX (et présente sous linux, par exemple) pour créer un processus fils identique au processus courant.
Sous Windows, utilises CreateThread.
Process ou Thread, à mon avis la difficulté reste la même: il faut à la fois faire attention à éviter les interférences entre les traitements parallèles et pourtant réussir à collecter les données de manière cohérente. Il sera peut-être bien plus simple de coordonner des threads que des processus indépendants.
Ton problème étant principalement le temps d'attente réseau, je pense que tu gagneras effectivement à créer des thread, pour éviter d'ajouter les temps d'attente réseau les uns aux autres (si n threads attendent la réponse réseau en //, tant que tu ne satures pas le réseau tu divises approximativement par n le temps consacré à attendre la réponse).

[srvremi]

Sous Linux les forks sont plus simples à mettre en place que des threads. Mais si tu es sous Windows je pense effectivement que tu en baveras moins avec des threads.

@+
Rémi

[Emmanuel Deloget]

Le plus simple serait de faire tourner chaque adresse dans un thread particulier.
Après, pour optimiser les performances, il est possible de créer un pool de threads qui va traiter les IP, mais ce ne sera utile que si tu as vraiment beaucoup d'IP à tester.

En gros, l'idée (pseudo-code) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
// Avant :
for (addr in addr_list)
   analyser_addresse(addr);
// Après
for (addr in addr_list)
   lancer_thread(analyser_addresse(addr));

Tu peux te renseigner sur std::thread (c++11) ou boost::thread, pour plus de détails techniques.

Sans aller jusque là : si l'écho est géré par un trhead, et l'écho reply est géré par un autre thread, alors l'écho n'a pas besoin d'attendre l'écho reply, et les paquets peuvent être envoyés en séquence, sans délai entre deux paquets.

Plusieurs exécutions simultanées je suis d'accord. Mais tu peux te contenter de forks je pense, pas obligatoire de passer par des thread à mon avis.

@+
Rémi

Il y a une petite erreur : fork() crée un process fils du process appelant ; les threads sont nécessairement plus légers que les process, quel que soit l'OS.

je dirais donc : tu peux te contenter de thread, pas obligé par passer par des fork.

[atum25]

Sans aller jusque là : si l'écho est géré par un trhead, et l'écho reply est géré par un autre thread, alors l'écho n'a pas besoin d'attendre l'écho reply, et les paquets peuvent être envoyés en séquence, sans délai entre deux paquets.

Je ne comprend pas ce que tu veux dire, peut tu détailler plus stp,
Qu'appelle tu "l'echo" ? "Les paquets" ?
merci

[atum25]

La quatrième paramètre, juste après l'adresse de la fonction à appeler, est un pointeur typé void qui sera passé à la thread.
Imaginons que ce pointeur soit par exemple l'adresse de ton objet nouvellement créé . Tu pourrais alors faire comme avant en utilisant ta référence d'objet.

il faut donc que je crée un nouvelle objet avant de crée mon thread c'est sa ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
      PosteDeTravail Poste(ansAddip,ansAddIpFin,i);
                th = CreateThread(&attr,0,&MyThread,&Poste, 0,NULL);

Comme sa a peu près ?

[therwald]

PosteDeTravail Poste(ansAddip,ansAddIpFin,i);
th = CreateThread(&attr,0,&MyThread,&Poste, 0,NULL);

Oui. Après ta fonction MyThread peut récupérer l'instance de Poste dans la thread (donc en mode parallèle) et travailler dessus, c-à-d lancer le ping et traiter la réponse pour un poste.

@Emmanuel: c'est un producteur/consommateur? Mais comment ferais-tu pour gérer l'incertitude sur l'ordre d'arrivée des réponses côté consommateur?

[Emmanuel Deloget]

Je ne comprend pas ce que tu veux dire, peut tu détailler plus stp,
Qu'appelle tu "l'echo" ? "Les paquets" ?
merci

Si tu utilises ICMP sans connaitre les termes "echo" et "echo reply", je ne vais pas pouvoir t'aider vraiment

Si tu fais un ping, tu envoies des paquets de type "echo", et tu reçois des paquets de type "echo reply". C'est aussi simple que ça.

@Emmanuel: c'est un producteur/consommateur? Mais comment ferais-tu pour gérer l'incertitude sur l'ordre d'arrivée des réponses côté consommateur?

Non. En envoyant un paquet "echo", tu ne garanti rien sur le fait que la paquet de retour arrive, ou qu'il arrive dans un timeframe donné. Donc inutile de mettre en place un système producteur/consommateur.

ICMP est un protocole de type datagramme au même niveau que IP, donc il ne travaille pas en mode connecté ; ce qui fait que le thread d'envoi et le thread de réception n'ont rien à partager. Les deux peuvent se trouver dans des process différents, pour ce qui nous intéresse.

La seule chose à vérifier, c'est que toutes les IP auxquelles ont envoie une requête echo ICMP répondent par un paquet "echo reply". Cette vérification peut être faite une fois un timeout défini atteint - par exemple, 5 secondes après le dernier envoi de paquet "echo".

Au niveau du code, deux thread prennent en paramètre une référence (pointeur) sur une std::map<ip, état>. Le premier thread parcours de map<>::begin() à map<>::end() pour envoyer un message ICMP "echo" à chaque adresse IP (pour plus de sécurité, il serait bon d'envoyer le message 4 fois ; c'est mieux de le faire en 4 parcours plutôt que d'envoyer le message 4 fois de suite, histoire de laisser un peu de temps entre deux envois du message ICMP "echo" ; certaines machines peuvent ne pas répondre du tout à ce qu'elles considèrent comme du flood). Après le dernier envoi, il attends 5 secondes et envoie une message "suicide toi immediatement" au second thread.

Le second thread se met en attente ; dès qu'il reçoit un message ICMP "echo reply", il met à 1 l'état correspondant à cette IP (puisque c'est un datagramme, on récupère l'IP en même temps que le message ; cf. man recvfrom ; Winsock2 propose un équivalent, voire la même fonction (par contre, je ne suis pas sûr que Win32 accepte de jouer avec ICMP; il faudra peut-être utiliser la lib winpcap, beaucoup plus puissante)). Dès qu'on lui demande de se suicider, le thread se termine.

Le programme appelant crée les deux thread, et attends la fin de leur exécution (join). Une fois les deux thread terminés, il parcours de map<>::begin() à map<>::end() pour déterminer quelles sont les adresses IP qui n'ont pas répondu au ping.