Non, ne fonctionne qu'en local. Le timer n'est pas une méthode appropriée pour scanner les ip du net (le winsock reste a l'état 6 : is connecting puis passe au port suivant après ton delay de 10 ms, tu aurais mis c'était pareil).
Petite rectif sans arrière pensée,
EBArtSoft nous dis :
User Datagram Protocol RFC 768 (UDP)
Transmission Transfert Protocol RFC 793 (TCP) -> En fait c'est, Transmission Control Protocol
Ce sont deux protocoles de communication :
Le premier...
Précision, ce sont les protocoles de la couche transport du modèle TCP/IP :
"La couche transport contient deux protocoles permettant à deux applications d'échanger des données indépendamment du type de réseau emprunté (c'est-à-dire indépendamment des couches inférieures...), il s'agit des protocoles suivants :
* TCP, un protocole orienté connexion qui assure le contrôle des erreurs
* UDP, un protocole non orienté connexion dont le contrôle d'erreur est archaïque"
Donc dans la majorité des cas, le protocole TCP sera utilisé, sauf lors de transport de données ne nécessitant pas de contrôle d'erreur.
Par contre, je ne vois pas ce que vient faire le DNS là dedans (ex pour protocole UDP)?
Le DNS est la translation d'une adresse IP en un nommage plus familier, ie www.trucmuche.com :
"il est possible d'associer des noms en langage courant aux adresses numériques grâce à un système appelé DNS (Domain Name System). On appelle résolution de noms de domaines (ou résolution d'adresses) la corrélation entre les adresses IP et le nom de domaine associé.".
J'ai plutôt rencontré de la vidéo transmise en UDP, cela permet de gagner du temps sur l'encapsulation et ne nécessite pas forcement un contrôle d'erreur.
Les trucs entre guillements sont tirés de bouquins ou autres, je sais plus, bref.
Voila, ce n'était pas capital mais utile pour la compréhension.
Cela dis bonne source, elle ne résoud pas mon problème mais ça marche bien.
@+
Ok merci, bon je vais surement mettre la source à jour ce soir pour prendre en compte les 2 protocoles...
tenez bah c'est fait : protocole au choix
j'ai aussi mis des informations que vous m'avez donné sur les protocoles, merci à tous
ah ok merci EBArtSoft, alors si je scanne les ports ouverts, je doit scanner ceux ouverts en UCP et ceux ouverts en TCP séparemment ou alors c'est pas important ?
et le contenu du buffer du port est-il différent selon le mode de connexion ?
Ensuite je modifierais ma source pour prendre en compte les 2 modes de connexion
MadM@tt> les ports sont les mêmes dans la numerotation et l'utilisation est la meme c'est
le mode de fonctionnement de la connexion
et des paquets qui est differente.
Sinon l'erreur que tu décris x28x je ne voit pas quoi faire d'autre à part gérer les erreurs et sauter le port quand il y a une erreur...
Sinon je vais modifier la source pour qu'elle scanne les ports UDP et TCP (ou au choix).
Une question : les ports TCP et UDP sont différents, ou c'est l'utilisation qu'on en fait qui est différente ?
Ah ok mais alors si je veux scanner les ports UDP il suffit juste de changer l'option dans le Winsock...
Ah mais c'est super ça !! Merci beaucoup je viens d'apprendre des trucs super... merci EBArtSoft
Mais il y a un truc que je ne comprend pas, si je lance un scan de 1 à 100 et meme si une page internet est en chargement, le port 80 n'est pas détecté comme ouvert ?? Pourtant c'est le port pour les protocoles http et je scanne bien en mode ... euh comment s'appelle l'autre mode, pas le UDP ?
Sur la capture ce qui est marqué correspond à ce que j'ai lu avec la commande .PeekData, et la définition de cette commande c'est (a peut près) :
Lit ce qu'il y a sur le port sans vider le buffer.
Donc j'en ai déduis que ce qui arrivait sur ce port était stocké dans un buffer et qu'en le lisant, on pourrai faire comme un firewall, mais si je me suis trompé je suis désolé je suis débutant dans ce domaine. Dans ce cas expliquez moi mon erreur
tu peut nous expliquer ce que c le buffer d'un port ?
car sur la capture je ne vois que la reponse d'un serveur pop3 a une connection (dont juste une commande repondant a un protocole particulier) !
Petite rectif sans arrière pensée,
EBArtSoft nous dis :
User Datagram Protocol RFC 768 (UDP)
Transmission Transfert Protocol RFC 793 (TCP) -> En fait c'est, Transmission Control Protocol
Ce sont deux protocoles de communication :
Le premier...
Précision, ce sont les protocoles de la couche transport du modèle TCP/IP :
"La couche transport contient deux protocoles permettant à deux applications d'échanger des données indépendamment du type de réseau emprunté (c'est-à-dire indépendamment des couches inférieures...), il s'agit des protocoles suivants :
* TCP, un protocole orienté connexion qui assure le contrôle des erreurs
* UDP, un protocole non orienté connexion dont le contrôle d'erreur est archaïque"
Donc dans la majorité des cas, le protocole TCP sera utilisé, sauf lors de transport de données ne nécessitant pas de contrôle d'erreur.
Par contre, je ne vois pas ce que vient faire le DNS là dedans (ex pour protocole UDP)?
Le DNS est la translation d'une adresse IP en un nommage plus familier, ie www.trucmuche.com :
"il est possible d'associer des noms en langage courant aux adresses numériques grâce à un système appelé DNS (Domain Name System). On appelle résolution de noms de domaines (ou résolution d'adresses) la corrélation entre les adresses IP et le nom de domaine associé.".
J'ai plutôt rencontré de la vidéo transmise en UDP, cela permet de gagner du temps sur l'encapsulation et ne nécessite pas forcement un contrôle d'erreur.
Les trucs entre guillements sont tirés de bouquins ou autres, je sais plus, bref.
Voila, ce n'était pas capital mais utile pour la compréhension.
Cela dis bonne source, elle ne résoud pas mon problème mais ça marche bien.
@+
je scanne un IP, il me trouve 23,25,etc, et je relance le scan et il trouve que 80
et c'est aleatoire, c'est très mystique !!!
si qq'un a une explication
bye
- Messages postés
-
2167
- Date d'inscription
- mardi 11 novembre 2003
- Statut
- Membre
- Dernière intervention
- 16 juillet 2009
1@ ++
(et pis pensez à noter ;-)