socket UDP - récupérer réponseRésolu

Question

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.

cs_aardman · Accepted Answer

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.

cs_aardman · Answer

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.

_Xav_ · Answer

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

cs_aardman · Answer

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.

_Xav_ · Answer

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

_Xav_ · Answer

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

Socket UDP - récupérer réponse

6 réponses

Votre réponse

Discussions similaires