Endianness et sockets

Bonjour à tous,

J'implémente un protocole appelé RP basé sur UDP. La partie DATA d'un datagramme UDP contient donc :

- entête RP : entier non signé sur 8 bits + entier non signé sur 16 bits.
- données : void *.

Je suis un peu perdu concernant les problèmes d'endianness : dois-je utiliser la fonction htons sur l'entier 16 bits de l'entête RP avant d'envoyer le message par sendto ? Ou faut-il se préocupper de l'ordre de l'ensemble de l'entête ? Faut-il s'occuper également de l'ordre des données ? ...

Merci de m'éclairer sur ce sujet...

Citation:

---

Envoyé par j0o0

Merci de m'éclairer sur ce sujet...

---

Disons qu'un protocole réseau bien écrit doit être indépendant de la machine sur laquelle il est implémenté. C'est donc à toi de définir si ton protocole est little-endian ou big-endian. Ce que tu transmets dans ton paquet UDP ne regarde donc que toi et tes applications, et ne l'empêchera pas d'être transmis.

Mais d'une manière générale, les fonctions que tu cites sont justement faites pour ne pas avoir à s'en soucier. Donc, c'est une bonne idée, effectivement, de les utiliser systématiquement.

Je pense que quand ce n'est pas spécifié, c'est l'ordre "réseau" (network byte order), donc oui, il faut utiliser htons() ou un équivalent. Pareil en lecture, où tu dois utiliser ntohs() ou un équivalent.

Ok merci pour vos réponses, donc il faut utiliser htons (pour l'écriture) sur l'entier 16 bits de l'entête et ntohs lors de la réception, mais pourquoi n'a-t-on pas besoin de se préoccuper de l'endianness pour la partie données ?

Qui te dit que tu n'en as pas besoin?

En fait, tout ce qu'il faut savoir, c'est quel composant sérialise les données (si les données en question sont un fichier, il s'agit du programme qui a créé le fichier) : C'est à se composant de se préoccuper de l'endianness.

parce que l'endianness ne concerne que les données de plus de 8 bits. Comme tes données semblent être du type void * (donc un pointeur sur un buffer de unsigned char), elles ne sont pas concernées (a priori)

Pour info, il y a aussi ntohl() et htonl() pour les données de 32 bits

Citation:

---

Envoyé par j0o0

Mais pourquoi n'a-t-on pas besoin de se préoccuper de l'endianness pour la partie données ?

---

Il faut s'en préoccuper ! Simplement, c'est à toi de dire d'abord si, dans ton protocole, les données sont little ou big endian. Une fois que tu as pris cette décision, tu écris ton code en conséquence.

Que tu choisisses l'un ou l'autre n'a pas d'importance. La seule chose est que tu vas te retrouver confronté aux mêmes problèmes qu'avec tous les autres protocoles : comme tu reçois des données par le réseau, tu ne sauras pas si la machine qui te les a envoyées est en little ou en big endian. Tu es donc obligé de convenir d'une norme et de faire en sorte que toutes tes implémentations la suivent.

Le bon sens t'indique alors de te calquer sur le format déjà en vigueur dans les protocoles réseaux existants et d'utiliser les fonctions déjà à ta disposition mais ce n'est pas une obligation ... si tant est que tu arrives à t'y retrouver !

Enfin, comme précisé plus haut, cela n'a de sens que si tu transmets telles quelles des données sur lesquelles ton microprocesseur applique lui-même le big ou little endian. Si tu transmets des caractères, ou que tu écris tes nombres en toutes lettres, etc., par définition, la conversion n'a pas lieu d'être.

Ok merci pour vos éclaircissements les gars !