Discussion :

[divayht]

Bonjour à tous

Je dois envoyer des trames en 16 bits. A priori il n'y aura que des entiers dedans. J'avais donc pensé à utiliser Qt et des qint16. Le souci est qu'à l'envoi des trames j'utilise bien Qt, mais pas à la réception. Ce sera une machine utilisant un langage de programmation que je ne connais à peine, alors j'ai besoin que ce soit un type standard qui transite, ou alors que la conversion quint16 vers un type standard (long long ?) soit facile.

Je ne trouve pas beaucoup d'informations à ce sujet. Quelles solutions pouvez-vous me proposer ?

Merci d'avance pour tout commentaire.

[Gulish]

Salut,

Alors, d'abord, un qint16 est une valeur entière codée sur 16 bits, ce qui correspond communément au type short (certains langages et certaines machines codent parfois le short sur plus de 16 bits).

Si tu parles de réseau IP classique, alors tu peux utiliser TCP ou UDP selon ton besoin, pour envoyer tes paquets de qint16. Ces protocoles sont standards, donc tu pourras facilement utiliser une autre technologie pour lire ces paquets. La seule chose qu'il faut regarder est l'Endianness utilisée des deux côtés (il faut bien sûr que ce soit le même), mais il me semble qu'Ethernet force le big endian de manière standard.

G.

[gbdivers]

Bonjour

En fait, je ne pense pas que le réseau utilisé soit important : seul compte l'encodage et de décodage effectué par les applications.

Il faut faire attention de ne pas confondre le type (standard du C++) et l'encodage (c'est à dire la représentation binaire de ce type). Les standards du C++ ne définissent pas l'encodage : un même type (par exemple int) peut être en 16 ou 32 bits, en little ending ou big ending ; il faut davoir aussi s'il est signé ou non, etc. Tout dépend de la machine sur laquelle tourne le programme.

Si tu utilises QDataStream et qint16, tu es assuré que tes données sont encodées en :
- 16 bits
- signé
- big ending

Pour créer ton programme qui reçoit les données, tu as plusieurs solutions :
- Si tu pouvais utiliser Qt, tu lirais simplement tes données directement avec QDataStream.
- Si le langage utilisé permet la sérialisation, regarde quels sont les encodages supportés et utilises les mêmes. (solution portable, c'est à dire fonctionnant sur plusieurs machines différentes)
- Si ton programme est destiné à tourner sur 1 seul type de machine, tu peux y aller à la barbare (solution non portable) : tu regardes l'encodage d'un type entier sur la cible (int par exemple) et tu utilises le type correspondant dans ton application Qt (qint16 ou qint32 pour 16 et 32 bits, quint ou qint pour signé ou non signé, QDataStream::LittleEndian ou QDataStream::BigEndian, etc.)
- Si tu veux une solution portable, tu écris une fonction de sérialisation qui lit bit par bit les données et les convertis dans le format adéquat (solution portable)

Quel est le langage utilisé pour la réception et pourquoi ne pas utiliser Qt ? (Qt est porté sur de nombreux systèmes et même de l'embarqué)

[_skip]

Je dirai que pour garantir l'interopérabilité maximal, il faudrait passer par une représentation textuelle. (JSon, XML) si cela est possible.

[gbdivers]

J'avais pensé également à la représentation textuelle. Mais même si cela est possible, je ne pense pas que cela soit forcement une bonne idée :

- la représentation textuelle ne change rien à l'interopérabilité (son but est seulement d'avoir un format lisible par l'homme directement) : si tu fournit la documentation du format utilisé, n'importe quelle application pourra interagir avec tes données, quel que soit le format (binaire ou textuelle) ; si au contraire, ta documentation est incomplète (surtout si tes données sont complexes), il sera difficile pour une autre application des les utiliser. (je simplifie un peu ici)

- la représentation textuelle ajoute une étape supplémentaire mais ne supprime pas forcement la sérialisation (le problème des little/big ending se pose toujours, le nombre de bit par caractère n'est pas forcement le même en fonction du langage, chaine de caractère avec un \0 terminal ou un SIZE initial, etc.). Donc au lieu d'avoir : (données -> sérialisation) -> réseau -> (dé-sérialisation -> données), tu auras : (données -> texte -> sérialisation) -> réseau -> (dé-sérialisation -> texte -> données). Cela pourrait avoir un intérêt à la rigueur pour un enregistrer les données dans un fichier mais pour envoyer des données sur un réseau, je n'en vois pas.

- si le but est de transmettre beaucoup de données (par exemple des données provenant d'un capteur) ou de travailler en temps réel (par exemple pour commander un système embarqué), alors le fait de passer à une représentation textuelle augmente le volume de données à transmettre. Par exemple, un quint16 (2 octets) peut représenter le chiffre 65 535, ce qui représente 6 octets en char*. Donc une augmentation du volume de données de 3 fois (cas extrême, en moyenne, l'augmentation réelle sera variable). Avec le travail supplémentaire de transformation en texte, cela peut être gênant pour les performances.

Donc ici, je dirais que la textualisation n'est pas forcement une bonne approche.

[_skip]

- la représentation textuelle ne change rien à l'interopérabilité (son but est seulement d'avoir un format lisible par l'homme directement) : si tu fournit la documentation du format utilisé, n'importe quelle application pourra interagir avec tes données, quel que soit le format (binaire ou textuelle) ; si au contraire, ta documentation est incomplète (surtout si tes données sont complexes), il sera difficile pour une autre application des les utiliser. (je simplifie un peu ici)

C'est très discutable comme argument. Il y a des langages de programmation qui sont très friendly avec les notions de bits et de byte-ordering comme le C++, d'autres ou ces notions ne sont même pas documentées et ne font l'objet d'aucune spécification.
Par contre tous offrent une possibilité de passer d'une chaîne de caractère à un nombre de façon consistante.

- la représentation textuelle ajoute une étape supplémentaire mais ne supprime pas forcement la sérialisation (le problème des little/big ending se pose toujours, le nombre de bit par caractère n'est pas forcement le même en fonction du langage, chaine de caractère avec un \0 terminal ou un SIZE initial, etc.).

Faux problème, la seule chose qui compte, c'est l'encodage. Il suffit de se mettre d'accord sur le fait qu'il s'agit par exemple d'UTF-8, c'est suffisamment standard pour assurer la retranscription fidèle d'un flux texte entre les 2 parties. Et même pour prendre le cas de SOAP, cela est spécifié dans l'entête du document.

Donc au lieu d'avoir : (données -> sérialisation) -> réseau -> (dé-sérialisation -> données), tu auras : (données -> texte -> sérialisation) -> réseau -> (dé-sérialisation -> texte -> données). Cela pourrait avoir un intérêt à la rigueur pour un enregistrer les données dans un fichier mais pour envoyer des données sur un réseau, je n'en vois pas.

L'interopérabilité de l'information, rien de plus. Un objet sérialisé en texte possède une représentation universelle sans dépendance aucune envers une plate-forme ou une architecture processeur. Le consommateur peut faire ce qu'il veut de cette information sans se soucier de la représentation en mémoire sur sa plate-forme ou dans sa machine virtuelle ou que sais-je.

- si le but est de transmettre beaucoup de données (par exemple des données provenant d'un capteur) ou de travailler en temps réel (par exemple pour commander un système embarqué), alors le fait de passer à une représentation textuelle augmente le volume de données à transmettre. Par exemple, un quint16 (2 octets) peut représenter le chiffre 65 535, ce qui représente 6 octets en char*. Donc une augmentation du volume de données de 3 fois (cas extrême, en moyenne, l'augmentation réelle sera variable). Avec le travail supplémentaire de transformation en texte, cela peut être gênant pour les performances.

Si le volume de la donnée à transmettre est suffisamment conséquent, ou que le cycle se répète à très grande vitesse, en effet. Après il faut voir d'où viennent les limitations.

Donc ici, je dirais que la textualisation n'est pas forcement une bonne approche.

Je comprend, moi je crois que ça dépend vraiment de ce qu'il compte faire concrètement et ce qu'il peut raisonnablement attendre comme technologie côté consommateur.

[divayht]

Merci pour vos réponses

Je ne sais pas exactement quel langage sera utilisé à la réception, c'est sur un logiciel tres pres de l'électronique, ou beaucoup de choses se font avec des "boites" qui ressemblent à des composants électroniques.

La réception n'est pas faite en Qt tout simplement car l'ingé qui s'en occupe ne le connaît pas du tout, et utilise uniquement son truc bizarre et apparemment proche du hardware.

Avant la liaison était faite en gpib, c'est dans la nouvelle version du logiciel qu'il a été décidé de modifier la liaison en ethernet.

Je vais étudier les différentes solutions proposées

[_skip]

Les 2 solutions ont leurs avantages est leurs inconvénients, mais puisque tu as la chance de connaître la personne qui va écrire le programme consommateur, c'est bien si tu lui demandes ce qui va le mieux pour lui question format et protocole d'échange.

[gbdivers]

@divayht
Le mieux est en effet de demander à l'ingé le format le plus adapté. Avec Qt, tu es libre d'encoder comme tu veux tes données en paramétrant QDataStream et en choisissant le type de données adéquat.

Rem : si tu travailles avec un langage bas niveau à la réception, les fonctions de conversion texte->entier ne sont peut être pas dispo. A vérifier

@_skip
On sort un peu de la question initiale posée par divayht (mais c'est pour ma culture personnelle)

Un objet sérialisé en texte possède une représentation universelle sans dépendance aucune envers une plate-forme ou une architecture processeur.

A partir du moment que des données sont sérialisées, elles sont indépendantes de la plateforme et de l'architecture (c'est justement le but de la sérialisation), qu'elles soient sous forme binaire ou textuelle, non ?

A mon sens, la seule différence entre la sérialisation binaire et la sérialisation texte, c'est que la seconde est lisible par l'humain. L'intérêt est très limité pour une communication réseau (sauf pour dupliquer le flux vers un fichier à des fins de débogage mais dans ce cas, je préfère transmettre en binaire et recoder en texte lors de l'enregistrement, pour des raisons de performance en prod)