port de source <-> port de destination

Bonjour.

Je me suis tenté à créer un petit client-serveur UDP, juste pour l'avoir fait au moins une fois par moi-meme, et ma foi ça ne marche pas trop mal.

Le serveur envoie des paquets qui contiennent les chaines "paquet 1", "paquet 2", etc...
et le client affiche ce qu'il reçoit. (et il affiche bien "paquet 1", "paquet 2",...)

comme le client et le serveur tournent sur la même machine, ip=127.0.0.1. Donc je ne peux pas sniffer avec ethereal.

Et il y a une chose que je ne comprend pas:
le server utilise sendto(...). Dans sendto, j'indique le SOCKADDR_IN de l'adresse de destination, qui contient le port UDP. (j'ai choisit au bol 5555). Mais quel est le port de source? Est-ce que je peux le choisir, ou est-ce que c'est windows qui me l'impose?

Dans le Client, j'utilisais recv(...) et ça marchait bien, mais j'ai cru comprendre que pour une connection UDP, recvfrom(...) etait plus approprié. Or pour que ça marche, je dois faire un recvfrom avec un SOCKADDR_IN qui contient 127.0.0.1:5555. Mais ce 5555, c'est le port de destination, pas de source? Selon msdn, ce paramètre (de la fct recvfrom) est l'adresse de la source...

Je m'y perds (comme vous le constatez surement)

Pouvez-vous m'aider?
Merci

Prenons l'exemple d'un navigateur Web

Le navigateur (client) se connecte au site via le port 80.
Le serveur reponds donc au client mais pas via le port 80 mais par un port (privé il me semble) > 1024.

Pourquoi tout simplement pour que l'on puisse avoir 2 navigateurs en meme temps parce que si tout le monde repondait sur le port 80, on ne saurai pas quoi et pour qui.

Une table est donc tenue à jour avec toutes les infos.

Je ne sais pas si tu peux choisir toi-meme le port (ca m'etonerait d'ailleurs).

recvfrom demande un pointeur sur la structure, la fonction remplie la structure. Elle ne s'en sert pas.

Comme dis dans la msdn ce pointeur est optionnel.

merci pour ces précisions.

mais alors si je comprends bien, mon serveur envoie vers le port udp 5555 du client, "par" son propre port source dont je ne connais pas la valeur.

Dans ce cas ce qui est curieux, c'est que si je met dans mon client, dans recvfrom une SOCKADDR_IN avec un autre port que 5555 (par ex 5554), je ne reçoit plus rien? (effectivement, si je met NULL, ça marche). Pourtant en effet, selon la msdn, le paramètre from est de type [out]. Je ne comprend pas pourquoi ça ne marche pas

Enfin, si ces 2 derniers paramètres sont effectivement optionnel, je vais les laisser à NULL c'est plus simple. Mais parfois j'aime éviter le "plus simple", surtout quand je comprends mal ce que je fais.

Hum. Bizarre, ce comportement... Tu n'aurais pas oublié de faire un bind() de ton socket avant le RecvFrom() ?

Car une telle réaction serait possible si le port, non-lié, utilise le paramètre de RecvFrom() pour trouver sur quel port écouter...

Non, je fais bien le bind. Mais que du coté du client

En résumé:
Server:
1- WSAStartup
2- sock = socket(...)
3- init de "sin" (mon SOCKADDR_IN: AF_INET, 127.0.0.1:5555)
4- boucle qui envoie des paquets avec sendto

Client:
1- WSAStartup
2- sock = socket(...)
3- init de "sin" (mon SOCKADDR_IN: AF_INET, 127.0.0.1:5555)
4- bind de mon sin et ma sock
5- boucle qui reçoit des paquets avec recvfrom

et si le client je met 5554 au lieu de 5555, je reçoit plus rien.
par contre si je met 5555 ou NULL, ou si j'utilise recv, c'est OK

Je précise que pour toutes ces fonctions, je vérifie la valeur de retour pour voir si la fonction s'est executée avec succès

Tu as essayé en passant l'adresse d'une structure sockaddr_in ne contenant que des zéros?

je viens d'essayer:
c'est assez curieux:

si je met ip:port = 0.0.0.0:5555
alors ça marche, et apres le premier recvfrom j'ai 127.0.0.1:52237
donc ça semble etre le comportement correct: j'ai "reçu" l'adresse et le port source (je suppose que 52237 est le port source)

par contre si je met ip:port = 0.0.0.0:5554 ou 0.0.0.0:0 ou autre, ça ne marche plus! (la fonction recvfrom se gèle en attente de data, mais ne retourne jamais)

Citation:

---

Envoyé par Biosox

comme le client et le serveur tournent sur la même machine, ip=127.0.0.1. Donc je ne peux pas sniffer avec ethereal.

---

Rien ne t'empêche d'utiliser l'IP réseau de ta machine (si ton FW est d'accord). Là, tu pourras sniffer...

Citation:

---

Et il y a une chose que je ne comprend pas:
le server utilise sendto(...). Dans sendto, j'indique le SOCKADDR_IN de l'adresse de destination, qui contient le port UDP. (j'ai choisit au bol 5555). Mais quel est le port de source? Est-ce que je peux le choisir, ou est-ce que c'est windows qui me l'impose?

---

A ma connaissance, le port source est toujours attribué automatiquement.

Citation:

---

Dans le Client, j'utilisais recv(...) et ça marchait bien,

---

En UDP ? Non. Marche pas (ou alors par hasard, de façon incomplète...)

Citation:

---

mais j'ai cru comprendre que pour une connection UDP, recvfrom(...) etait plus approprié.

---

Absolument. Tu t'en apercevra si tu as plusieurs sockets en même temps

Citation:

---

Or pour que ça marche, je dois faire un recvfrom avec un SOCKADDR_IN qui contient 127.0.0.1:5555. Mais ce 5555, c'est le port de destination, pas de source? Selon msdn, ce paramètre (de la fct recvfrom) est l'adresse de la source...

---

Dans une architecture client/serveur, ça marche comme ça :

requête client -> serveur :

from to
1234 5555

réponse serveur -> client :

from to
5555 1234

Un coup de Ethereal et tu le verras..

Citation:

---

Envoyé par Emmanuel Delahaye

Rien ne t'empêche d'utiliser l'IP réseau de ta machine (si ton FW est d'accord). Là, tu pourras sniffer...

---

j'ai utilisé l'adresse reseau de ma machine, et ethereal ne sniffait rien.
puis j'ai executé le server depuis un autre poste, afin d'être sur que les paquets allaient bien arriver de l'extérieur sur ma machine et cette fois ethereal les a capturés.

Citation:

---

Envoyé par Emmanuel Delahaye

En UDP ? Non. Marche pas (ou alors par hasard, de façon incomplète...)

---

alors c'est par hasard car ça marche. mais effectivement je n'ai pas essayé avec plusieurs socket en meme temps...

Merci pour ces précisions. Mais ça ne m'explique toujours pas pourquoi recvfrom ne reçoit rien quand je lui passe un pointeur vers un sin qui contient le faux port TCP. d'autant plus que ce paramètre est un [out] donc il ne devrait rien changer?

Enfin je m'en sort avec ça. Merci de votre aide