Voila : je bosse sur un projet perso & free qui touche aux reseaux TCP/IP.
Il s'agit d'un petit demon qui teste si les station d'un reseau sont 'up'.
pour le lancer, je fais :
root # eco -D -t 192.168.100.2
(le -D veut dire 'daemonize' et le -t specifie l'adresse de la cible)
et lorsque la station correspondante (station cible) a la dite adresse
ne repond plus, le demon en prend bonne note et adopte un comportement
adequat.
C'est ce que fait la version actuelle.
Ceci dit, mon objectif est de pouvoir tester non une seule adresse IP,
mais tout un ensemble.
Ainsi, je devrais pouvoir specifier comme cible :
192.168.100.1/255.255.255.0
192.168.200.21
192.168.210.76
et etc.
Et donc, mon probleme est de trouver un algorithme efficace pour
parcourir toute les adresses ainsi définies (stockees dans une variable
de type chaine de caractere avec zero terminal)
voila :)
la definition de ces adresses doit etre faite dans un format standard /
universel.
j'imagine que ce genre de code doit etre tres courant (ah oui, je
developpe ce demon sous Linux) vu tous les fichiers de config et autres
scripts mentionnant des adresses / reseaux IP se trouvant sur mon systeme.
C'est pourquoi il me semble qu'il a du etre etabli un algorithme optimal
pour faire ce boulot, qui ne laissa pas place a quelque obscur bug et
qui suivit une syntaxe universelle.
Alors s'il existe ici une personne qui puisse m'apporter quelque lumiere
a ce sujet, je lui en serai extremement reconnaissant de le faire.
MERCI :)
PS : EVIDEMENT que le code que je cherche a faire sera en C. ben alors !
parce que oui, je sais et s'il en avait ete autrement que je m'en serais
alle sur un autre forum.
Et si je ne mets pas les accents sur les lettres c'est parce que j'ai un
petit pbm de config que je n'ai pas encore resolu et comme je ne
considere pas cela comme etant reellement prioritaire, cela risque de
durer encore un peu. Et alors ? ca ne limite que tres peu dans la
comprehension de ce que j'ecris meme si, par ailleurs, il se peut que ma
presentation des choses fut un peu confuse.
En plus ca va plus vite de ne pas faire les accents quand on tape au
clavier.
D'ailleurs ... mais bon, non. jm'en fous apres tout. je n'empeche
personne d'ajouter les accents qu'il veut sur les lettres qu'il veut moi.
Enfin, quoi qu'il en soit, ce qu'il me faut c'est une reponse a ma
question et non une polemique sur un truc si derisoire, alors hop !
on chasse de son esprit toute idee parasite et on se met au boulot.
Le ou la premier(e) qui m'aura fourni la bonne reponse aura gagne toute
mon estime. Alors ca, si ca n'en vaut pas la peine...
On peut aussi vouloir inférer des masques automatiquement. Par exemple, si on écrit: 10 on veut probablement dire: 10/8 mais si on écrit: 10.1 on veut probablement dire: 10.1/16
On peut aussi vouloir inférer des masques automatiquement. Par
exemple, si on écrit: 10 on veut probablement dire: 10/8
mais si on écrit: 10.1 on veut probablement dire: 10.1/16
On peut aussi vouloir inférer des masques automatiquement. Par exemple, si on écrit: 10 on veut probablement dire: 10/8 mais si on écrit: 10.1 on veut probablement dire: 10.1/16
alors que 10.1 signifie 10.0.0.1
Laurent Wacrenier
david écrit:
Et donc, mon probleme est de trouver un algorithme efficace pour parcourir toute les adresses ainsi définies (stockees dans une variable de type chaine de caractere avec zero terminal)
faire (en interne) une liste avec la première adresse du bloc et la dernière. Incrémenter de 1 de la première à la dernière.
Attention aux endians.
S'il y a beaucoup d'addresses à tester, faire les requetes en assynchrone (utiliser un pool de sockets non bloquantes, envoyer les résultats en rafale et traiter les réponses).
david <nobody@free.fr> écrit:
Et donc, mon probleme est de trouver un algorithme efficace pour
parcourir toute les adresses ainsi définies (stockees dans une variable
de type chaine de caractere avec zero terminal)
faire (en interne) une liste avec la première adresse du bloc et la
dernière. Incrémenter de 1 de la première à la dernière.
Attention aux endians.
S'il y a beaucoup d'addresses à tester, faire les requetes en
assynchrone (utiliser un pool de sockets non bloquantes, envoyer les
résultats en rafale et traiter les réponses).
Et donc, mon probleme est de trouver un algorithme efficace pour parcourir toute les adresses ainsi définies (stockees dans une variable de type chaine de caractere avec zero terminal)
faire (en interne) une liste avec la première adresse du bloc et la dernière. Incrémenter de 1 de la première à la dernière.
Attention aux endians.
S'il y a beaucoup d'addresses à tester, faire les requetes en assynchrone (utiliser un pool de sockets non bloquantes, envoyer les résultats en rafale et traiter les réponses).
david
Laurent Wacrenier wrote:
Pascal Bourguignon écrit:
On peut aussi vouloir inférer des masques automatiquement. Par exemple, si on écrit: 10 on veut probablement dire: 10/8 mais si on écrit: 10.1 on veut probablement dire: 10.1/16
alors que 10.1 signifie 10.0.0.1
que veux tu dire là ?
10.1 équivaut à 10.0.0.1 ?
si je m'en tiens au résultats de ipcalc, 10.1 <==> 10.1.0.0
On peut aussi vouloir inférer des masques automatiquement. Par
exemple, si on écrit: 10 on veut probablement dire: 10/8
mais si on écrit: 10.1 on veut probablement dire: 10.1/16
alors que 10.1 signifie 10.0.0.1
que veux tu dire là ?
10.1 équivaut à 10.0.0.1 ?
si je m'en tiens au résultats de ipcalc, 10.1 <==> 10.1.0.0
On peut aussi vouloir inférer des masques automatiquement. Par exemple, si on écrit: 10 on veut probablement dire: 10/8 mais si on écrit: 10.1 on veut probablement dire: 10.1/16
alors que 10.1 signifie 10.0.0.1
que veux tu dire là ?
10.1 équivaut à 10.0.0.1 ?
si je m'en tiens au résultats de ipcalc, 10.1 <==> 10.1.0.0
david
Laurent Wacrenier wrote:
david écrit:
Et donc, mon probleme est de trouver un algorithme efficace pour parcourir toute les adresses ainsi définies (stockees dans une variable de type chaine de caractere avec zero terminal)
faire (en interne) une liste avec la première adresse du bloc et la dernière. Incrémenter de 1 de la première à la dernière.
Attention aux endians.
oui ? ils sont ou les indians ?? peux-tu préciser ?
S'il y a beaucoup d'addresses à tester, faire les requetes en assynchrone (utiliser un pool de sockets non bloquantes, envoyer les résultats en rafale et traiter les réponses).
mais, encore ?
Laurent Wacrenier wrote:
david <nobody@free.fr> écrit:
Et donc, mon probleme est de trouver un algorithme efficace pour
parcourir toute les adresses ainsi définies (stockees dans une variable
de type chaine de caractere avec zero terminal)
faire (en interne) une liste avec la première adresse du bloc et la
dernière. Incrémenter de 1 de la première à la dernière.
Attention aux endians.
oui ? ils sont ou les indians ??
peux-tu préciser ?
S'il y a beaucoup d'addresses à tester, faire les requetes en
assynchrone (utiliser un pool de sockets non bloquantes, envoyer les
résultats en rafale et traiter les réponses).
Et donc, mon probleme est de trouver un algorithme efficace pour parcourir toute les adresses ainsi définies (stockees dans une variable de type chaine de caractere avec zero terminal)
faire (en interne) une liste avec la première adresse du bloc et la dernière. Incrémenter de 1 de la première à la dernière.
Attention aux endians.
oui ? ils sont ou les indians ?? peux-tu préciser ?
S'il y a beaucoup d'addresses à tester, faire les requetes en assynchrone (utiliser un pool de sockets non bloquantes, envoyer les résultats en rafale et traiter les réponses).
mais, encore ?
Pascal Bourguignon
david writes:
DONC, LA QUESTION DU MASQUE de type '/31' RESTE SANS REPONSE !!
Oui, /31 devrait être considéré comme une erreur, car les seules adresses valides dans un tel sous-réseau sont celle du sous-réseau et la broadcast: on ne peut pas identifier un seul host dans un tel sous-réseau. On doit surement pouvoir trouver une RFC qui en parle...
La QUESTION :
vaut-il mieux laisser un socket ouvert Pendant TOUTE UNE JOURNEE alors qu'il sert une fois toutes les 5mn pour envoyer et recevoir un seul paquet, ou alors vaut - il mieux l'ouvrir et le refermer une fois / 5mn ??????
quels sont les impacts ?
TCP doit envoyer des packets "keep-alive" quand il n'y a pas de trafic. Faudrait lire les RFC sur TCP pour savoir exactement à quelle fréquence...
-- __Pascal_Bourguignon__ http://www.informatimago.com/ Do not adjust your mind, there is a fault in reality.
david <nobody@free.fr> writes:
DONC, LA QUESTION DU MASQUE de type '/31' RESTE SANS REPONSE !!
Oui, /31 devrait être considéré comme une erreur, car les seules
adresses valides dans un tel sous-réseau sont celle du sous-réseau et
la broadcast: on ne peut pas identifier un seul host dans un tel
sous-réseau. On doit surement pouvoir trouver une RFC qui en parle...
La QUESTION :
vaut-il mieux laisser un socket ouvert Pendant TOUTE UNE JOURNEE alors
qu'il sert une fois toutes les 5mn pour envoyer et recevoir un seul
paquet, ou alors vaut - il mieux l'ouvrir et le refermer une fois /
5mn ??????
quels sont les impacts ?
TCP doit envoyer des packets "keep-alive" quand il n'y a pas de
trafic. Faudrait lire les RFC sur TCP pour savoir exactement à quelle
fréquence...
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
DONC, LA QUESTION DU MASQUE de type '/31' RESTE SANS REPONSE !!
Oui, /31 devrait être considéré comme une erreur, car les seules adresses valides dans un tel sous-réseau sont celle du sous-réseau et la broadcast: on ne peut pas identifier un seul host dans un tel sous-réseau. On doit surement pouvoir trouver une RFC qui en parle...
La QUESTION :
vaut-il mieux laisser un socket ouvert Pendant TOUTE UNE JOURNEE alors qu'il sert une fois toutes les 5mn pour envoyer et recevoir un seul paquet, ou alors vaut - il mieux l'ouvrir et le refermer une fois / 5mn ??????
quels sont les impacts ?
TCP doit envoyer des packets "keep-alive" quand il n'y a pas de trafic. Faudrait lire les RFC sur TCP pour savoir exactement à quelle fréquence...
-- __Pascal_Bourguignon__ http://www.informatimago.com/ Do not adjust your mind, there is a fault in reality.
Pascal Bourguignon
david writes:
Laurent Wacrenier wrote:
david écrit:
Et donc, mon probleme est de trouver un algorithme efficace pour parcourir toute les adresses ainsi définies (stockees dans une variable de type chaine de caractere avec zero terminal) faire (en interne) une liste avec la première adresse du bloc et la
dernière. Incrémenter de 1 de la première à la dernière. Attention aux endians.
oui ? ils sont ou les indians ?? peux-tu préciser ?
On peut manipuler les adresses IPv4 comme des entiers non signés sur 32 bits. Ainsi, les calculs avec les masques, et les parcours sont aisés (utilisation des opérations &, | et ^, ++ et --, etc).
Mais les nombres entiers sont stockés en mémoire différement selon les processeurs. Il y en a qui commencent par écrire le petit bout de l'entier, alors que d'autres commencent par le gros bout (il y en a même eu qui écrivaient en mélangeant les quatres bouts!). Donc, on a des processeurs petit-boutiens, et des processeurs gros-boutiens. En anglais, ça fait little-endian and big-endian.
Quand on a une adresse IP 10.11.12.13, on peut la convertir en entier ainsi:
((((10*256)+11)*256)+12)*256+13 = 168496141
Le problème, c'est que les petit boutiens écrivent ce nombre en mémoire à l'adresse n ainsi:
Il y a des fonctions en bibliothèque ( htonl, ntohl, etc) pour faire ces conversions, c'est à dire pour lire ou écrire des entiers dans l'ordre voulu par les protocoles Internet.
S'il y a beaucoup d'addresses à tester, faire les requetes en assynchrone (utiliser un pool de sockets non bloquantes, envoyer les résultats en rafale et traiter les réponses).
mais, encore ?
-- __Pascal_Bourguignon__ http://www.informatimago.com/ Do not adjust your mind, there is a fault in reality.
david <nobody@free.fr> writes:
Laurent Wacrenier wrote:
david <nobody@free.fr> écrit:
Et donc, mon probleme est de trouver un algorithme efficace pour
parcourir toute les adresses ainsi définies (stockees dans une
variable de type chaine de caractere avec zero terminal)
faire (en interne) une liste avec la première adresse du bloc et la
dernière. Incrémenter de 1 de la première à la dernière.
Attention aux endians.
oui ? ils sont ou les indians ??
peux-tu préciser ?
On peut manipuler les adresses IPv4 comme des entiers non signés sur
32 bits. Ainsi, les calculs avec les masques, et les parcours sont
aisés (utilisation des opérations &, | et ^, ++ et --, etc).
Mais les nombres entiers sont stockés en mémoire différement selon les
processeurs. Il y en a qui commencent par écrire le petit bout de
l'entier, alors que d'autres commencent par le gros bout (il y en a
même eu qui écrivaient en mélangeant les quatres bouts!). Donc, on a
des processeurs petit-boutiens, et des processeurs gros-boutiens. En
anglais, ça fait little-endian and big-endian.
Quand on a une adresse IP 10.11.12.13, on peut la convertir en entier
ainsi:
((((10*256)+11)*256)+12)*256+13 = 168496141
Le problème, c'est que les petit boutiens écrivent ce nombre en
mémoire à l'adresse n ainsi:
Il y a des fonctions en bibliothèque ( htonl, ntohl, etc) pour faire
ces conversions, c'est à dire pour lire ou écrire des entiers dans
l'ordre voulu par les protocoles Internet.
S'il y a beaucoup d'addresses à tester, faire les requetes en
assynchrone (utiliser un pool de sockets non bloquantes, envoyer
les résultats en rafale et traiter les réponses).
mais, encore ?
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
Et donc, mon probleme est de trouver un algorithme efficace pour parcourir toute les adresses ainsi définies (stockees dans une variable de type chaine de caractere avec zero terminal) faire (en interne) une liste avec la première adresse du bloc et la
dernière. Incrémenter de 1 de la première à la dernière. Attention aux endians.
oui ? ils sont ou les indians ?? peux-tu préciser ?
On peut manipuler les adresses IPv4 comme des entiers non signés sur 32 bits. Ainsi, les calculs avec les masques, et les parcours sont aisés (utilisation des opérations &, | et ^, ++ et --, etc).
Mais les nombres entiers sont stockés en mémoire différement selon les processeurs. Il y en a qui commencent par écrire le petit bout de l'entier, alors que d'autres commencent par le gros bout (il y en a même eu qui écrivaient en mélangeant les quatres bouts!). Donc, on a des processeurs petit-boutiens, et des processeurs gros-boutiens. En anglais, ça fait little-endian and big-endian.
Quand on a une adresse IP 10.11.12.13, on peut la convertir en entier ainsi:
((((10*256)+11)*256)+12)*256+13 = 168496141
Le problème, c'est que les petit boutiens écrivent ce nombre en mémoire à l'adresse n ainsi:
Il y a des fonctions en bibliothèque ( htonl, ntohl, etc) pour faire ces conversions, c'est à dire pour lire ou écrire des entiers dans l'ordre voulu par les protocoles Internet.
S'il y a beaucoup d'addresses à tester, faire les requetes en assynchrone (utiliser un pool de sockets non bloquantes, envoyer les résultats en rafale et traiter les réponses).
mais, encore ?
-- __Pascal_Bourguignon__ http://www.informatimago.com/ Do not adjust your mind, there is a fault in reality.
Laurent Wacrenier
david écrit:
mais si on écrit: 10.1 on veut probablement dire: 10.1/16
alors que 10.1 signifie 10.0.0.1
que veux tu dire là ?
10.1 équivaut à 10.0.0.1 ?
Oui. C'est l'hôte 1 de la classe A 10.
si je m'en tiens au résultats de ipcalc, 10.1 <==> 10.1.0.0
Il a faux en ce qui concerne la désignation des hôtes. Mieux vaut s'en tenir au résultat de inet_aton (ou mieux inet_pton)
david <nobody@free.fr> écrit:
mais si on écrit: 10.1 on veut probablement dire: 10.1/16
alors que 10.1 signifie 10.0.0.1
que veux tu dire là ?
10.1 équivaut à 10.0.0.1 ?
Oui. C'est l'hôte 1 de la classe A 10.
si je m'en tiens au résultats de ipcalc, 10.1 <==> 10.1.0.0
Il a faux en ce qui concerne la désignation des hôtes.
Mieux vaut s'en tenir au résultat de inet_aton (ou mieux inet_pton)
mais si on écrit: 10.1 on veut probablement dire: 10.1/16
alors que 10.1 signifie 10.0.0.1
que veux tu dire là ?
10.1 équivaut à 10.0.0.1 ?
Oui. C'est l'hôte 1 de la classe A 10.
si je m'en tiens au résultats de ipcalc, 10.1 <==> 10.1.0.0
Il a faux en ce qui concerne la désignation des hôtes. Mieux vaut s'en tenir au résultat de inet_aton (ou mieux inet_pton)
Erwann ABALEA
On Tue, 30 Sep 2003, david wrote:
Laurent Wacrenier wrote:
Pascal Bourguignon écrit:
On peut aussi vouloir inférer des masques automatiquement. Par exemple, si on écrit: 10 on veut probablement dire: 10/8 mais si on écrit: 10.1 on veut probablement dire: 10.1/16
si je m'en tiens au résultats de ipcalc, 10.1 <==> 10.1.0.0
Mauvais logiciel, changer logiciel?
Cela dit, je ne parviens pas à trouver la RFC expliquant le comportement à adopter.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Neuneu, moi ? Peut-être. En tout cas, je ne le fais pas exprès. Ca vient tout seul. Des fois, un mot, même insignifiant, et ça part. Tenez, dites pour voir un mot, au hasard je précise. -+- C In Guide du Neuneu d'Usenet : Neuneu avoué est à demi pardonné -+-
On peut aussi vouloir inférer des masques automatiquement. Par
exemple, si on écrit: 10 on veut probablement dire: 10/8
mais si on écrit: 10.1 on veut probablement dire: 10.1/16
si je m'en tiens au résultats de ipcalc, 10.1 <==> 10.1.0.0
Mauvais logiciel, changer logiciel?
Cela dit, je ne parviens pas à trouver la RFC expliquant le comportement à
adopter.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Neuneu, moi ? Peut-être. En tout cas, je ne le fais pas exprès. Ca vient
tout seul. Des fois, un mot, même insignifiant, et ça part. Tenez, dites
pour voir un mot, au hasard je précise.
-+- C In Guide du Neuneu d'Usenet : Neuneu avoué est à demi pardonné -+-
On peut aussi vouloir inférer des masques automatiquement. Par exemple, si on écrit: 10 on veut probablement dire: 10/8 mais si on écrit: 10.1 on veut probablement dire: 10.1/16
si je m'en tiens au résultats de ipcalc, 10.1 <==> 10.1.0.0
Mauvais logiciel, changer logiciel?
Cela dit, je ne parviens pas à trouver la RFC expliquant le comportement à adopter.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Neuneu, moi ? Peut-être. En tout cas, je ne le fais pas exprès. Ca vient tout seul. Des fois, un mot, même insignifiant, et ça part. Tenez, dites pour voir un mot, au hasard je précise. -+- C In Guide du Neuneu d'Usenet : Neuneu avoué est à demi pardonné -+-
Laurent Wacrenier
Pascal Bourguignon écrit:
david writes:
DONC, LA QUESTION DU MASQUE de type '/31' RESTE SANS REPONSE !!
Oui, /31 devrait être considéré comme une erreur, car les seules adresses valides dans un tel sous-réseau sont celle du sous-réseau et la broadcast: on ne peut pas identifier un seul host dans un tel sous-réseau.
En ethernet et autres CCMACD, peut être, mais avec d'autres couches pas forcément. Par exemple, on peut désigner une route de deux adresses sur un lien avec cette notation.
On doit surement pouvoir trouver une RFC qui en parle...
Je ne pense pas à une interdication générale. La notation correspond à un préfixe légal.
DONC, LA QUESTION DU MASQUE de type '/31' RESTE SANS REPONSE !!
Oui, /31 devrait être considéré comme une erreur, car les seules
adresses valides dans un tel sous-réseau sont celle du sous-réseau et
la broadcast: on ne peut pas identifier un seul host dans un tel
sous-réseau.
En ethernet et autres CCMACD, peut être, mais avec d'autres couches
pas forcément. Par exemple, on peut désigner une route de deux
adresses sur un lien avec cette notation.
On doit surement pouvoir trouver une RFC qui en parle...
Je ne pense pas à une interdication générale. La notation correspond à
un préfixe légal.
DONC, LA QUESTION DU MASQUE de type '/31' RESTE SANS REPONSE !!
Oui, /31 devrait être considéré comme une erreur, car les seules adresses valides dans un tel sous-réseau sont celle du sous-réseau et la broadcast: on ne peut pas identifier un seul host dans un tel sous-réseau.
En ethernet et autres CCMACD, peut être, mais avec d'autres couches pas forcément. Par exemple, on peut désigner une route de deux adresses sur un lien avec cette notation.
On doit surement pouvoir trouver une RFC qui en parle...
Je ne pense pas à une interdication générale. La notation correspond à un préfixe légal.
Laurent Wacrenier
Erwann ABALEA écrit:
Cela dit, je ne parviens pas à trouver la RFC expliquant le comportement à adopter.
Je ne suis pas sûr que ce soit une RFC (j'ai cherché aussi) C'est en tout cas le comportement d'un inet_addr() POSIX.
La notation avec un seul nombre décimal correspond à au numéro de machine (2130706433 = 127.0.0.1)
Dans la notation décimale pointée avec deux nombres, le premier indique la classe A et le second le numéro de machine (127.1 127.0.0.1, 127.65536 = 127.1.0.0)
Dans la notation décimale pointée avec trois nombres, les deux premiers indiquent la classe B et le dernier le numéro de machine (172.32.1 172.32.0.1, 172.32.256 = 127.32.1.0)
Erwann ABALEA <erwann@abalea.com> écrit:
Cela dit, je ne parviens pas à trouver la RFC expliquant le comportement à
adopter.
Je ne suis pas sûr que ce soit une RFC (j'ai cherché aussi) C'est en
tout cas le comportement d'un inet_addr() POSIX.
La notation avec un seul nombre décimal correspond à au numéro de
machine (2130706433 = 127.0.0.1)
Dans la notation décimale pointée avec deux nombres, le premier
indique la classe A et le second le numéro de machine (127.1 127.0.0.1, 127.65536 = 127.1.0.0)
Dans la notation décimale pointée avec trois nombres, les deux premiers
indiquent la classe B et le dernier le numéro de machine (172.32.1 172.32.0.1, 172.32.256 = 127.32.1.0)
Cela dit, je ne parviens pas à trouver la RFC expliquant le comportement à adopter.
Je ne suis pas sûr que ce soit une RFC (j'ai cherché aussi) C'est en tout cas le comportement d'un inet_addr() POSIX.
La notation avec un seul nombre décimal correspond à au numéro de machine (2130706433 = 127.0.0.1)
Dans la notation décimale pointée avec deux nombres, le premier indique la classe A et le second le numéro de machine (127.1 127.0.0.1, 127.65536 = 127.1.0.0)
Dans la notation décimale pointée avec trois nombres, les deux premiers indiquent la classe B et le dernier le numéro de machine (172.32.1 172.32.0.1, 172.32.256 = 127.32.1.0)
