Socket UDP - récupérer réponse

[Résolu]
Signaler
Messages postés
6
Date d'inscription
vendredi 21 septembre 2007
Statut
Membre
Dernière intervention
30 avril 2008
-
Messages postés
6
Date d'inscription
vendredi 21 septembre 2007
Statut
Membre
Dernière intervention
30 avril 2008
-
Hello tout le monde, voici mon problème:

J'ai écris une class dns avec laquelle j'envoie des paquets (en udp) et j'aimerais recevoir les réponses faites par mon serveur dns.

Le problème est que je ne sais pas comment récupérer le port d'émission afin de mettre ce port en écoute pour récupérer la réponse.

Je pense que cela doit être tout bête donc si qqn aurait la solution ça m'aiderait beaucoup.

Merci

PS: sockets windows.

6 réponses

Messages postés
1905
Date d'inscription
mercredi 22 janvier 2003
Statut
Membre
Dernière intervention
17 septembre 2012
3
Salut,

En plus de select, il existe aussi WSAEventSelect et WSAAsyncSelect
pour gerer les sockets non bloquants, WSAAsyncSelect est
particulierement pratique si tu as une interface graphique (avec une
boucle de message).

Voici un ebook de reference qui contient la documentation et les
exemples pour utiliser select et les autres modeles cités ci dessus:

http://betouchi.free.fr/doc_et_ebook/prog_reseau/network2.chm pour l'ebook,

http://betouchi.free.fr/doc_et_ebook/prog_reseau/exemples-network2.zip pour les exemples.
Messages postés
1905
Date d'inscription
mercredi 22 janvier 2003
Statut
Membre
Dernière intervention
17 septembre 2012
3
Salut,

Logiquement la reponse devrait revenir sur le port qui a envoyé la
requete, donc il n'y a pas de deuxieme socket a binder pour recevoir
les requetes, tout se passe sur le premier.
Messages postés
6
Date d'inscription
vendredi 21 septembre 2007
Statut
Membre
Dernière intervention
30 avril 2008

Donc j'utilise le même descripteur (SOCKADDR_IN) dans mon appel à recvfrom...?

En clair j'ai:
                        sendto(sock, msg.c_str(), msg.size(), 0, (SOCKADDR*)&sin, sizeof(sin))
et ensuite
                        recvfrom(sock, buffer, sizeof(buffer), 0, (SOCKADDR*)&sin, &sinsize)

sock = ma socket
msg = string contenant mon message à envoyer
buffer = bufer de réception
sin = descripteurde type SOCKADDR_IN de ma socket
Messages postés
1905
Date d'inscription
mercredi 22 janvier 2003
Statut
Membre
Dernière intervention
17 septembre 2012
3
Salut,

C'est une mauvaise idée d'utiliser la meme structure pour ces deux appels, car ils ne representent pas la meme chose:

- la structure sin que tu passes a sendto est un parametre d'entrée qui specifie l'adresse de destination de ton paquet udp,

- la structure sin que tu passes a recvfrom est un parametre de sortie
(optionnel) qui specifie l'origine du paquet, autrement dit l'adresse
qu'elle contient avant l'appel a recvfrom n'a aucune importance, c'est
l'adresse une fois que la fonction a retourné qui est importante.


Il faut donc utiliser deux structures differentes, avec des noms un peu plus parlant que 'sin'.

D'autant plus que les paquets que tu recois ne proviennent pas
forcement de ton serveur dns, donc si tu écrases l'adresse de ton
serveur dns avec l'adresse d'origine tu paquet, ca sera plus compliqué
pour comparer les deux adresses.


Aussi, si tu dialogues uniquement avec un serveur dns, tu peux aussi
regarder ce que fait connect() sur msdn: ça permet de specifier une
adresse distante pour ton socket udp, et ça permet d'ignorer
silencieusement tout les paquets qui ne proviennent pas de cette
adresse, ce qui est pratique.
Messages postés
6
Date d'inscription
vendredi 21 septembre 2007
Statut
Membre
Dernière intervention
30 avril 2008

Salut,

j'ai finalement utilisé connect et qu'un descripteur (SOCKADDR_IN) contenant les infos sur la destination.

J'aurais encore une question stp:
    - Comment rendre recv() non-bloquant sans utiliser de threads. Il existe select je crois? As-tu un exemple sous la main? Sinon     je googlerais...

Merci
Messages postés
6
Date d'inscription
vendredi 21 septembre 2007
Statut
Membre
Dernière intervention
30 avril 2008

merci aardman, je crois que maintenant j'ai de quoi faire...