Discussion :

[beLz]

Je cherche à récupérer la taille d'un packet UDP. En gros le seul moyen de savoir la quantité que je dois recevoir est de la calculer à partir de l'information de taille de packet UDP. Comment faire ca en C ??

J'ai essayé de trouver ca sur le net mais bif bof je vois pas :s

Merci de m'éclairer

[Ksempac]

Ta question n'est pas tres precise, mais je vais tacher d'y repondre. Je suppose que tu as ton datagramme sous forme de chaine de caractere et que tu veux extraire le champ length.

D'apres la norme UDP, le champ Length se situe au 32eme bit et contient 16 bits soit 2 octets.

Donc en C tu copies (fonction memcpy) dans une variable de type short (qui a au minimum 2 octets) les bits 32 a 47 de ton datagramme.

Cependant la valeur obtenue n'est pas forcement bonne : tu dois tenir compte des problemes d'endianess. Il te faut utiliser la fonction ntohs (network to host short) pour convertir la variable recue dans l'endian de ta machine.

Une fois cela fait, tu peux utiliser ta variable

[stephl]

Je suppose que tu as ton datagramme sous forme de chaine de caractere...

Et comment fait-on? Ce n'est pas obtenu par recvfrom().

[Ksempac]

Et comment fait-on? Ce n'est pas obtenu par recvfrom().

Tout d'abord, j'ai bien précisé que sa question n'est pas tres claire, on ne sait pas où il bloque exactement (creation de socket ? récupération du message ? lecture du champ length ?). C'est bien pour cela que j'ai dit que je "supposais" quelquechose.

En ce qui concerne recvfrom il remplit un buffer a l'adresse que tu lui fournis. Rien ne t'empeche de passer une adresse pointée par un char*.

[stephl]

En ce qui concerne recvfrom il remplit un buffer a l'adresse que tu lui fournis. Rien ne t'empeche de passer une adresse pointée par un char*.

OK, mais recvfrom() retourne juste la partie DATA du datagramme, pas le datagramme complet. La taille n'est donc pas -je pense- accessible de cette manière.

[Ksempac]

En fait si il utilise recvfrom, celui ci renvoie le nombre d'octets du message.

Donc si ce que tu dis est vrai, il faut ensuite obtenir la taille du header (entre 4 et 8 octets) pour pouvoir obtenir la valeur du champ length
Cela dit je suis pas sur que tout ca a un interet...pourquoi recuperer la taille du header si il est séparé du message...il faudrait vraiment plus d'information sur ce qu'il veut faire pour l'aider.

Je serais interessé de savoir ou tu as trouvé le fait que recvfrom ne renvoie que la partie DATA du message ?

[stephl]

En fait si il utilise recvfrom, celui ci renvoie le nombre d'octets du message.

Pas exactement. Si le buffer n'est pas assez grand, alors recvfrom() renvoie WSAEMSGSIZE (Windows) et le reste des données est perdu. Sinon, si on peut connaître à l'avance la taille maximale, je suis d'accord que l'on peut allouer un buffer suffisament grand et utiliser la valeur de retour de recvfrom().

Je serais interessé de savoir ou tu as trouvé le fait que recvfrom ne renvoie que la partie DATA du message ?

Il n'y a qu'à tester: le buffer passé à recvfrom() contient seulement les données du buffer passé en paramètre à sendto(), ce qui correspond au champ DATA du datagramme; le reste du datagramme ne semble pas accessible de cette manière.

[beLz]

C'est effectivement la que je bloque. J'utilise a priori un recvfrom. Il me semble effectivement que celui-ci ne renvoie que le champ DATA. Je ne vois pas comment accéder à l'header UDP

[stephl]

Personnellement, je ne sais pas comment récupérer la totalité du datagramme. Je pense qu'il serait plus simple de convenir d'un message de fin entre le serveur et le client.

[Ksempac]

Mais pourquoi veux tu absolument récuperer le header et ce champ length ?

L'adresse source tu peux la récuperer via le champ from de recvfrom, l'adresse de destination tu la connais (puisque c'est la tienne), la length ne te sert pas si tu n'as pas le header, et le checksum, si il existe, a déjà été vérifié à la réception de ton datagramme.

[stephl]

Mais pourquoi veux tu absolument récuperer le header et ce champ length ?

Peut-être pour savoir quelle taille doit faire le buffer servant à récupérer les données envoyées?

[Emmanuel Delahaye]

Je cherche à récupérer la taille d'un packet UDP. En gros le seul moyen de savoir la quantité que je dois recevoir est de la calculer à partir de l'information de taille de packet UDP. Comment faire ca en C ??

Bah, recvfrom() te dis combien d'octets tu as reçu (valeur de retour)...

[Emmanuel Delahaye]

Je serais interessé de savoir ou tu as trouvé le fait que recvfrom ne renvoie que la partie DATA du message ?

Bah, c'est la base des sockets. Si tu veux la trame complète, il faut utiliser les raw sockets. Rien à voir.

[Emmanuel Delahaye]

Peut-être pour savoir quelle taille doit faire le buffer servant à récupérer les données envoyées?

Absurde. En théorie, en UDP, le buffer doit être 'grand' (64k pour être tranquille...).

Mais dans la pratique, en UDP, on envoi pas de grosses trames, trop risqué (l'UDP, c'est du send & forget). On connait l'ordre de grandeur (1k, 10k...) et on dimensionne le buffer de réception en conséquence.

Maintenant, rien n'empêche, au niveau applicatif, d'ajouter des informations supplémentaires genre taille et nom du fichier, taille max des trames (1ere trame), trame N° x / n etc. Mais c'est du protocole applicatif. Les sockets ne sont pas concernées.

[stephl]

Absurde. En théorie, en UDP, le buffer doit être 'grand' (64k pour être tranquille...).

Mais dans la pratique, en UDP, on envoi pas de grosses trames, trop risqué (l'UDP, c'est du send & forget). On connait l'ordre de grandeur (1k, 10k...) et on dimensionne le buffer de réception en conséquence.

OK, mais 1k et 10k ce n'est pas la même chose. Alors ce n'est pas si absurde que cela. En outre, en toute généralité, il ne peut peut-être pas connaître à l'avance la taille des données.

[Emmanuel Delahaye]

OK, mais 1k et 10k ce n'est pas la même chose. Alors ce n'est pas si absurde que cela. En outre, en toute généralité, il ne peut peut-être pas connaître à l'avance la taille des données.

De toutes façons, c'est 64 k maximum... Affaire réglée.

[beLz]

Je peux effectivement résoudre mon problème en récupérant la valeur de retour du recvfrom. Ca résout mon problème à ce niveau Je m'interroge toujours par contre sur la manière de récupérer le header UDP en C par contre ^^

[stephl]

Je m'interroge toujours par contre sur la manière de récupérer le header UDP en C par contre ^^

cf Emmanuel:
http://www.developpez.net/forums/sho...0&postcount=13
Je n'ai jamais utilisé cela personnellement, mais je ne vois pas de raison pour que ça ne marche pas.