Transmission de données par réseaux

Patrick 'Zener' Brunet a écrit

D'où l'intéret de ASN.1 ou XML

Bien qu'il soit à la mode, je ne suis pas du tout convaincu de l'intérêt
technique de faire un encodage dans un format textuel.

Alors regarde ASN.1 ;-)

--{ ALain Montfranc a plopé ceci: }--

Bien qu'il soit à la mode, je ne suis pas du tout convaincu de l'intérêt
technique de faire un encodage dans un format textuel.

Alors regarde ASN.1 ;-)

Est-ce un successeur ou un remplaçant des XDR ?

--

http://mutah.free.fr/life_for_living.mp3 <<<<<<<<<<<<<<<<<

On 2007-09-30, Patrick 'Zener' Brunet wrote:

Bien qu'il soit à la mode, je ne suis pas du tout convaincu de l'intérêt
technique de faire un encodage dans un format textuel.

Notamment, le parsing à la réception est généralement écrit avec des moteurs
à objets qui moulinent du malloc et des copies de buffer à n'en plus finir,
donc du point de vue des performances, c'est catastrophique tant pour la
transmission que pour la manipulation.

"L'optimisation prématurée est le source de tous les maux"...

Un encodage textuel ne présente que deux intérêts:

- être humainement lisible, ce qui implique une indentation correcte et donc
rajoute du poids. Si on doit régénérer une forme lisible à partir d'une
forme compacte, nul besoin que celle-ci utilise le même encodage,

- si on peut se limiter au jeu de caractères ASCII, donc encodés sur 8 bits,
le texte ne pose pas de problèmes d'endianness. Mais les caractères
exotiques (de plus en plus fréquents) doivent être encodés en &entities; ou
autres &#69; ce qui peut vite faire lourd, et je ne parle pas des pointeurs,
transformés en liens vers des balises...

L'encodage textuel a aussi l'avantage d'etre une représentation
univoque des entiers et flottants.

Et bien je pense que compiler une forme structurée en une forme binaire
portable (sans pointeurs sortants) à endianness connue représente une énorme
optimisation dans l'objectif énoncé qui est de communiquer des données sur
un réseau. Même si l'une des stations a la malchance d'être du mauvais sexe,
retourner systématiquement tous les champs binaires coutera toujours moins
cher que la rédaction et le parsing du langage textuel.

Tout à fait.

Quel que soit l'encodage choisi, c'est ce travail d'analyse qui n'est pas
simple du tout à réaliser, mais il est inévitable dès lors qu'on doit
sérialiser une structure, qu'il s'agisse de la transmettre sur le réseau ou
de l'écrire sur un média.

Oui, mais il y a un compromis à faire entre portabilité, efficacité et
temps de développement. Ne défendre qu'un aspect n'est AMHA ni très
professionel, ni très aidant pour un débutant.


Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

On 2007-09-29, michko <langevin@univ-tln.fr> wrote:

On 25 sep, 12:19, none <""vb"@(none)"> wrote:

Bonjour,

Créer une communication réseaux via les appel systèmes ne pose
généralement aucun soucis, ceci quelquel soit l'OS utilisé. Les données
alors transmise sont au préalable mise dans un buffer.

La question que je me pose depuis que je fait ce genre de manipulation,
c'est comment faites-vous pour transmettre le contenu d'une structure ?
Surtout lorsque celle-ci possède des pointeurs sur autre structure ou
tableau de char.

Ce que je fait depuis longtemps, c'est un construction d'une chaine pour
transmettre les informations. Mais il faut que je modifie cette
construction de chaine chaque fois que je modifie la structure,
nécessitant également le décodage de l'autre coté.

Donc la question est simple, avez-vous une méthode différente pour
transmettre le contenu d'une structure? Y compris lorsque elle est
chainées?

Merci pour vos commentaires.
Vincent

Je ne suis pas sur de comprendre ce que tu veux dire par "une
construction de chaine pour transmettre ". Pour
une variable x, il te suffit d'envoyer
sendto( sd , &x, sizeof(x)) , .. , .. , ..);

En priant pour que le récepteur sache décoder ce flot de
bit (pb de taille, d'encodage, etc).
Je ne parle même pas des vrais pb réseaux, des gens qui ne
savent pas que TCP n'est pas en mode message mais flot de bits,
et qu'un jour, ça peut faire boum...

ne s'agit pas d'une probemetique de type reseau
Tu as exactement la meme problematique quand
tu transmets tes donnees via un disque..

Qu'on appelle en général 'serialisation' ou 'serialization'
(pour les recherches sur Google, Wikipedia...).

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

En news:1191069323.871000.92060@w3g2000hsg.googlegroups.com,
michko va escriure:

Ce que je fait depuis longtemps, c'est un construction d'une chaine
pour transmettre les informations.

Je ne suis pas sur de comprendre ce que tu veux dire par "une
construction de chaine pour transmettre ".

Bah, cela signifie probablement qu'il utilise un protocole en mode texte
(exemple avec TCP: NNTP ou SMTP).

Tu as exactement la meme problematique quand
tu transmets tes donnees via un disque..

Plutôt via une bande (et encore).
Avec un disque (ou la mémoire), l'accès aléatoire te permet de faire du
backpatching, par exemple d'avoir un en-tête avec des grandeurs (qui
serviront à dimensionner à la relecture), que le processus écrivain ne grave
*qu'après* avoir émis les donnnées brutes.
Exemple: le nombre de lignes de cet article, quand il est transmis par NNTP.
Connu uniquement lorsque l'article est terminé (donc pour le moment, je ne
le connais pas !)


Antoine

En news:slrnfg1d9l.6bd.Marc.Boyer@ubu.enseeiht.fr,
Marc Boyer va escriure:

L'encodage textuel a aussi l'avantage d'etre une représentation
univoque des entiers et flottants.

Oui pour les entiers, pas vraiment d'accord pour les flottants (sauf si tu
utilises la même base ou une puissance de celle-ci pour les deux formes,
textuelle et binaire). Même si C99 a rajouté DECIMAL_DIG, peu de gens savent
l'utiliser à bon escient ; exemple, cf.
http://www.dinkumware.com/manuals/?page=float.html.

Qui plus est, il suffit de passer paranoia.c pour voir que la lecture et
l'écriture des flottants est un domaine toujours intéressant de la chasse
aux bogues...

On 2007-09-30, Patrick 'Zener' Brunet wrote:

Notamment, le parsing à la réception est généralement écrit avec des
moteurs à objets [...] c'est catastrophique tant pour la
transmission que pour la manipulation.

Côté réception je vois bien le handicap des moteurs à objets, mais côté
émission j'ai plus de mal à voir où se situe la « catastrophe ». Certes le
codage binaire->texte a un coup, mais il est minime par rapport à celui payé
en réception.

Même si l'une des stations a
la malchance d'être du mauvais sexe, retourner systématiquement tous
les champs binaires coutera toujours moins cher que la rédaction et
le parsing du langage textuel.

Le cas à considérer, c'est quand les deux stations sont du mauvais sexe.

Avec la contrainte complémentaire que les petits programmeurs malins peuvent
décider qu'il est « idiot » de retourner deux fois pour un résultat net
identique, ce qui conduit généalement à l'introduction d'une «
optimisation » de suppression du dit retournement, et donc à un nouveau
protocole... incompatible car trop élaboré (et retour à la case départ).

Ou bien, cas un peu meilleur, on précise que les deux sexes cohabitent (en
fait il y a plus que deux sexes, il y a l'ordre des bits, celui des octets,
éventuellement celui des mots si on se rappelle du FP-11 de DEC), que les
ordres sont indiqués dans le protocole, qu'ils suivent l'ordre de
l'émetteur, et seul le sexe du récepteur peut alors amener la malchance
d'une perte (minime) de performances pures.


Antoine

On 2007-10-01, Antoine Leca <root@localhost.invalid> wrote:

En news:slrnfg1d9l.6bd.Marc.Boyer@ubu.enseeiht.fr,
Marc Boyer va escriure:

L'encodage textuel a aussi l'avantage d'etre une représentation
univoque des entiers et flottants.

Oui pour les entiers, pas vraiment d'accord pour les flottants (sauf si tu
utilises la même base ou une puissance de celle-ci pour les deux formes,
textuelle et binaire). Même si C99 a rajouté DECIMAL_DIG, peu de gens savent
l'utiliser à bon escient ; exemple, cf.
http://www.dinkumware.com/manuals/?page=float.html.

J'ai dit "représentation univoque", pas représentation portable. La
nuance pour moi est qu'en choisissant le format d'affichage, tu choisis
le nombre de digits que tu veux communiquer/stocker. Après, oui, si ton archi
en propose plus ou moins, tu y perds.

Qui plus est, il suffit de passer paranoia.c pour voir que la lecture et
l'écriture des flottants est un domaine toujours intéressant de la chasse
aux bogues...

paranoia.c ?
D'après Google, c'est un code de Richard Karpinski & Kahan qui teste les
résultats de calculs. Je n'ai pas vu qu'il teste les I/O (mais j'ai
peut être regardé trop vite).

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

En news:slrnfg4ccf.6dp.Marc.Boyer@ubu.enseeiht.fr, Marc Boyer va escriure:

On 2007-10-01, Antoine Leca <root@localhost.invalid> wrote:

En news:slrnfg1d9l.6bd.Marc.Boyer@ubu.enseeiht.fr,
Marc Boyer va escriure:

L'encodage textuel a aussi l'avantage d'etre une représentation
univoque des entiers et flottants.

Oui pour les entiers, pas vraiment d'accord pour les flottants (sauf
si tu utilises la même base ou une puissance de celle-ci pour les
deux formes, textuelle et binaire). Même si C99 a rajouté
DECIMAL_DIG, peu de gens savent l'utiliser à bon escient ; exemple,
cf. http://www.dinkumware.com/manuals/?page=float.html.

J'ai dit "représentation univoque", pas représentation portable.

Certes. Au temps pour moi, j'avais lu « injection » (que je définirais comme
la faculté de pouvoir revenir à un et un seul nombre flottant étant donnée
une représentation textuelle intermédiaire), et il est exact que tu n'as pas
écrit cela.

Dans le langage courant, la notion d'univoque est souvent utilisée à tort à
la place de celle de bijection (en fait bi-univoque) ; il est évident que la
relation entre l'ensemble (fini) des nombres flottants représentables (une
fois données la taille de la mantisse et de l'exposant) vers l'ensemble
(infini) des représentations textuelles des nombres décimaux, ne peut pas
être une bijection ; c'est pourquoi j'étais descendu d'un cran, et m'étais
arrêté aux injections, qui me semble être une utilisation intéressante dans
le cadre en question (possibilité de revenir aux données d'origine).
Mais avec les nombres flottants, cette propriété d'injectivité est difficile
à obtenir dans la pratique. En général, les problèmes se situent à la
relecture, donc en dehors du cadre de la "représentation univoque" (qui ne
concerne que la partie écriture de la transmission).

C'est bien ce qui me préoccupe, d'ailleurs. Car je ne vois pas bien
l'intérêt d'utiliser une représentation univoque (seulement).
En poussant un peu le bouchon, j'ai du mal à comprendre en quoi la
possibilité d'écrire
printf("%5.2f", flottant);
est intéressante, dans le cadre de la transmission de données d'une machine
à une autre. Sachant tous les problèmes d'arrondis que cette représentation
tronquée va induire.


Pour ce qui est d'être portable, c'est une autre notion, liée à l'existence
d'une norme ou d'un standard (et en l'occurence, ce qui ressemble le plus à
un standard dans ce domaine, c'est la représentation dite « IEEE » !)

Et je distingue cela de « transportable », qualité (que j'imagine être
recherchée par le PO) de la possibilité de transporter les données, toutes
les données mais rien que les données, d'un ordinateur à un autre.
Qui nécessite (comme dit par d'autres, dont Marc) une analyse préalable de
ce que l'on a au départ (« toutes les données mais rien que les données »).

La nuance pour moi est qu'en choisissant le format d'affichage,
tu choisis le nombre de digits que tu veux communiquer/stocker.
Après, oui, si ton archi en propose plus ou moins, tu y perds.

Mmmh. En « choisissant un format » d'affichage (surtout %...f, évidemment),
tu définis une norme, donc tu t'intéresse plus à la portabilité qu'autre
chose.

Un format d'affichage est intéressant pour un résultat (car il précise bien
la qualité de la valeur) ; pour un résultat intermédiaire comme l'est une
forme destinée à la transmission, je vois moins. Qui plus est, la conversion
binaire-décimale va introduire un « flou » qui fait qu'après, on ne peut
plus séparer ce qui revient à la qualité initiale des données (représentée
par la précision exprimée) de ce qui revient aux arrondis binaires des
calculs déjà pratiqués, arrondis qui sont repris en partie dans l'arrondi
décimal de la conversion.

Qui plus est, il suffit de passer paranoia.c pour voir que la
lecture et l'écriture des flottants est un domaine toujours
intéressant de la chasse aux bogues...

paranoia.c ?
D'après Google, c'est un code de Richard Karpinski & Kahan

Oui (http://www.netlib.org/paranoia/)

qui teste les résultats de calculs. Je n'ai pas vu qu'il teste les I/O
(mais j'ai peut être regardé trop vite).

Le test classique est de passer paranoia.c sur un compilateur de Borland
(« réputés » pour la médiocre qualité de l'implémentation des flottants).
À une époque (je ne sais pas si c'est encore vrai aujourd'hui, mais une
rapide promenade sur Google donne de la matière), paranoia.c donnait des
résultats franchement mauvais avec ces compilos, quasiment uniquement parce
que la bibliothèque stdio pour les flottants faisait un arrondi incorrect
(particulièrement pour les long double, si je me souviens bien).
Je crois même que c'en était tellement grotesque qu'il y eu un patch pour la
code paranoia.c lui-même, pour pouvoir obtenir quand même les résultats de
manière lisible.

Autrement dit, un test sur la qualité des calculs en flottants teste aussi
(bien obligé) l'implémentation des conversions texte-binaire (et
vice-versa).


Antoine

"Antoine Leca" <root@localhost.invalid> a écrit dans le message de news:
fdtr97$82e$1@shakotay.alphanet.ch...

En news:slrnfg4ccf.6dp.Marc.Boyer@ubu.enseeiht.fr, Marc Boyer va escriure:

On 2007-10-01, Antoine Leca <root@localhost.invalid> wrote:

En news:slrnfg1d9l.6bd.Marc.Boyer@ubu.enseeiht.fr,
Marc Boyer va escriure:

L'encodage textuel a aussi l'avantage d'etre une représentation
univoque des entiers et flottants.

Oui pour les entiers, pas vraiment d'accord pour les flottants (sauf
si tu utilises la même base ou une puissance de celle-ci pour les
deux formes, textuelle et binaire). Même si C99 a rajouté
DECIMAL_DIG, peu de gens savent l'utiliser à bon escient ; exemple,
cf. http://www.dinkumware.com/manuals/?page=float.html.

J'ai dit "représentation univoque", pas représentation portable.

Certes. Au temps pour moi, j'avais lu « injection » (que je définirais
comme
la faculté de pouvoir revenir à un et un seul nombre flottant étant donnée
une représentation textuelle intermédiaire), et il est exact que tu n'as
pas
écrit cela.

Dans le langage courant, la notion d'univoque est souvent utilisée à tort
à
la place de celle de bijection (en fait bi-univoque) ; il est évident que
la
relation entre l'ensemble (fini) des nombres flottants représentables (une
fois données la taille de la mantisse et de l'exposant) vers l'ensemble
(infini) des représentations textuelles des nombres décimaux, ne peut pas
être une bijection ; c'est pourquoi j'étais descendu d'un cran, et m'étais
arrêté aux injections, qui me semble être une utilisation intéressante
dans
le cadre en question (possibilité de revenir aux données d'origine).
Mais avec les nombres flottants, cette propriété d'injectivité est
difficile
à obtenir dans la pratique. En général, les problèmes se situent à la
relecture, donc en dehors du cadre de la "représentation univoque" (qui ne
concerne que la partie écriture de la transmission).

Pour éviter les problèmes de representation décimale arrondie des flottants,
on peut utiliser le format hexadecimal introduit par C99 et supporté par
certains compilateurs: c'est le format %a pour printf et scanf, et cela
ressemble à ceci:

0.5 = 0x1.p-1

--
Chqrlie.

On 2007-10-02, Antoine Leca <root@localhost.invalid> wrote:

En news:slrnfg4ccf.6dp.Marc.Boyer@ubu.enseeiht.fr, Marc Boyer va escriure:

On 2007-10-01, Antoine Leca <root@localhost.invalid> wrote:

En news:slrnfg1d9l.6bd.Marc.Boyer@ubu.enseeiht.fr,
Marc Boyer va escriure:

L'encodage textuel a aussi l'avantage d'etre une représentation
univoque des entiers et flottants.

Oui pour les entiers, pas vraiment d'accord pour les flottants (sauf
si tu utilises la même base ou une puissance de celle-ci pour les
deux formes, textuelle et binaire). Même si C99 a rajouté
DECIMAL_DIG, peu de gens savent l'utiliser à bon escient ; exemple,
cf. http://www.dinkumware.com/manuals/?page=float.html.

J'ai dit "représentation univoque", pas représentation portable.

Certes. Au temps pour moi, j'avais lu « injection » (que je définirais comme
la faculté de pouvoir revenir à un et un seul nombre flottant étant donnée
une représentation textuelle intermédiaire), et il est exact que tu n'as pas
écrit cela.

Dans le langage courant, la notion d'univoque est souvent utilisée à tort à
la place de celle de bijection (en fait bi-univoque) ;

En fait, d'après le Wiktionaire, on a deux sens:
1. (Linguistique) Qui conserve le même sens dans des emplois différents.
2. (Algèbre, Chimie) Se dit d'une relation qui ne s'exerce que dans un sens.

Ce qui montre à la face du monde que je ne suis pas fort en maths ;-)

C'est bien ce qui me préoccupe, d'ailleurs. Car je ne vois pas bien
l'intérêt d'utiliser une représentation univoque (seulement).
En poussant un peu le bouchon, j'ai du mal à comprendre en quoi la
possibilité d'écrire
printf("%5.2f", flottant);
est intéressante, dans le cadre de la transmission de données d'une machine
à une autre. Sachant tous les problèmes d'arrondis que cette représentation
tronquée va induire.

Oui, mais
1) c'est simple à implanter
2) c'est compréhensible par la majorités des programmeurs

Pour ce qui est d'être portable, c'est une autre notion, liée à l'existence
d'une norme ou d'un standard (et en l'occurence, ce qui ressemble le plus à
un standard dans ce domaine, c'est la représentation dite « IEEE » !)

Avec la représentation textuelle de *scanf/*printf, on a une
portabilité. Ce que je lis avec printf("%5.2f", flottant); se lit
avec scanf, quelque soit l'implantation des flottants sur les
machines qui lisent et écrivent.
Après, oui, on ne maitrise pas les arrondis. Mais bon, vu qu'une
bonne partie des programmeurs ne maîtrise déjà pas les arrondis sur
une même machine...

Le calcul numérique est un monde en lui-même.

Pour édifier des débutants qui nous liraient, essayer:
double dixieme= 0.1;
double somme= 0;
int i;
for(i=0 ; i < 10 ; ++i)
somme+= dixieme;
if (somme == 1.0)
puts("La vie est simple");
else
puts("Les flottants, c'est pas si simple");

La nuance pour moi est qu'en choisissant le format d'affichage,
tu choisis le nombre de digits que tu veux communiquer/stocker.
Après, oui, si ton archi en propose plus ou moins, tu y perds.

Mmmh. En « choisissant un format » d'affichage (surtout %...f, évidemment),
tu définis une norme, donc tu t'intéresse plus à la portabilité qu'autre
chose.

Voui.

Un format d'affichage est intéressant pour un résultat (car il précise bien
la qualité de la valeur) ; pour un résultat intermédiaire comme l'est une
forme destinée à la transmission, je vois moins. Qui plus est, la conversion
binaire-décimale va introduire un « flou » qui fait qu'après, on ne peut
plus séparer ce qui revient à la qualité initiale des données (représentée
par la précision exprimée) de ce qui revient aux arrondis binaires des
calculs déjà pratiqués, arrondis qui sont repris en partie dans l'arrondi
décimal de la conversion.

Oui, quiconque cherche à savoir d'où viennent les arrondis, et tente
de les maîtriser, adoptera une approche différente. Mais bon...

Le test classique est de passer paranoia.c sur un compilateur de Borland
(« réputés » pour la médiocre qualité de l'implémentation des flottants).
À une époque (je ne sais pas si c'est encore vrai aujourd'hui, mais une
rapide promenade sur Google donne de la matière), paranoia.c donnait des
résultats franchement mauvais avec ces compilos, quasiment uniquement parce
que la bibliothèque stdio pour les flottants faisait un arrondi incorrect
(particulièrement pour les long double, si je me souviens bien).
Je crois même que c'en était tellement grotesque qu'il y eu un patch pour la
code paranoia.c lui-même, pour pouvoir obtenir quand même les résultats de
manière lisible.

Autrement dit, un test sur la qualité des calculs en flottants teste aussi
(bien obligé) l'implémentation des conversions texte-binaire (et
vice-versa).

OK, merci.

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)