1. Introduction

1.2. Les problèmes

1.2.1 Introduction

Le transfert transparent (c'est-à-dire à l'identique) de la suite binaire n'est pas le service attendu !

En effet une même suite binaire peut être interprétée de manières multiples :

ex : 0x31

soit code ASCII de `a'
soit représentation en complément à 2 du nombre décimal 49

Il faut un transfert de données qui conserve la sémantique.

On va transmettre non seulement la valeur de la données mais aussi

son type

Plusieurs facteurs sont à prendre en compte :

l'hétérogénéité des machines
les différentes techniques de représentation
les objets complexes
la longueur et le nombre instances de l'objet

1.2.2 L'hétérogénéité des architectures internes des ordinateurs

Si deux ordinateurs ayant des architectures différentes échangent des données à l'aide d'un service de transfert qui conserve totalement la suite binaire, l'interprétation des données reçues risque d'être incorrecte.

Méthode de placement des mots en mémoire :

Intel, DEC/Motorola, IBM
"little endian/ big endian war" (voyages de Gulliver [Swift])

La longueur des mots (2, 4, 8 octets), la longueur des caractères (7, 8, 16, 32 bits), etc.

1.2.3 La représentation des types simples

technique de représentation des caractères :

EBCDIC, ASCII, etc.

technique de représentation des nombres entiers :

représentation binaire en complément à 1, ou complément à 2, DCB, etc.

technique de représentation des nombres réels :

virgule flottante, mantisse + exposant, base décimale ou binaire, etc.

1.2.4 Les objets complexes (composés)

Les applications échangent des objets simples mais aussi des objets structurés :

exemple : liste, ensemble, tableau, vecteur, matrice, enregistrement, etc.iIl faut être capable de transmettre la structure !

1.2.5 Echanges en nombre et en ordre variable

Le nombre, l'ordre et le type des objets échangés dépend de l'état de l'émetteur sans que le récepteur soit préalablement mis au courant !

il faut être explicite : codage TLV

1.2.6 Spécification

Les applications réparties peuvent être développées non seulement sur des équipements hétérogènes mais aussi par des équipes différentes avec des moyens variés :

les structures de données doivent être spécifiées préalablement et formellement,
indépendamment de la représentation choisie (l'implémentation),
compréhensibles par le développeur de code (humain)

1.3. Les solutions

1.3.1 Présentation

Des fonctions de décodage tenant compte de la représentation utilisée :

dépendent des couples émetteur/récepteur
chaque station doit posséder un jeu complet de fonctions de décodage, si elles veulent communiquer avec n'importe quelles autres stations :
N types de représentation -> N*N-1 fonctions de décodage

Une seule et unique représentation conventionnelle :

définie par le réseau

solution proposée par Internet et XDR

tous doivent s'y plier, même si c'est sous-optimal !

par exemple : si l'émetteur et le récepteur utilisent la même représentation interne qui n'est pas la représentation conventionnelle, il y a deux opérations de transcodage inutiles lors de chaque échange.
trop rigide : pas d'adaptation vis-à-vis des applications vis-à-vis des évolutions futures

Spécification/Implémentation

On distingue trois types de syntaxe :

la syntaxe abstraite, commune, adaptée à l'être humain, partagée par les entités
la syntaxe concrète, dépendante et locale à chaque système (hors OSI)
la syntaxe de transfert (Règles d'encodage), pour la transmission sur le réseau

1.3.2 La normalisation

La norme définit :

un langage abstrait de spécification de la structure des données échangées

ex : ASN.1
interprétable par l'être humain (-> texte d'un programme)
notion de type
ressemble aus défintions de strutures de données des langages évolués
exemple :

numero INTEGER

des techniques d'encodage (règles)

plusieurs règles d'encodage : BER, PER, etc.
c'est la suite binaire réellement transmise (-> code machine du programme)
la technique d'encodage est choisie lors de l'établissement de la connexion
exemple :

{numero 17} -> 02 01 1116

L'utilisation :