Discussion :

[cosmoff]

Bonjour à tous,

voila en me renseignant sur les réseaux avec le modele OSI, j'ai vu qu'on pouvait corriger des erreurs de transmission dans la couche liaison de données en insérant un bit de parité dans chaque caractère ASCII et en insérant le CRC (groupe de bits) entre chaque trame.
est ce quand on envoie des messages on utilise toujours la parité et le CRC pour corriger (si possible) et détecter les erreurs, car on me renseignant sur l'architecture TCP/IP j'ai observé un checksum pour la correction et detection d'erreur. est ce la meme chose?

merci d'avance pour vos éclaircissements

[JML19]

Bonsoir

Il y a le contrôle de la transmission et le contrôle des données transmises.

TCP/IP est un système qui contrôle la transmission, mais qui ne contrôle pas les données transmises.

[matrix788]

Bonsoir

Il y a le contrôle de la transmission et le contrôle des données transmises.

TCP/IP est un système qui contrôle la transmission, mais qui ne contrôle pas les données transmises.

Salut,

attention, ne pas tout mélanger: tcp/ip est un lot. Ok, pour le contrôle de la transmission via le protocle TCP, mais tu oublies l'IP v4 ou 6 selon, l'UDP, l'ICMP. Ils utilisent tous le même algorithme de détection de corruption de paquets.

Si je peux te conseiller, ce serait d’étudier la RFC correspondante au protocole TCP/IP: https://tools.ietf.org/html/rfc3819#page-18

[JML19]

Le protocole IP est un protocole non fiable voici ce que dit Wikipédia (ICI).

[cosmoff]

euh vous avez lu ce que j'ai écrit?

[sevyc64]

Que ce soit parité, checksum, crc, etc, ils ne servent pas à corriger les erreurs. Ils ne servent qu'à détecter qu'une erreur a eu lieu mais sans dire où.
Pour être pointilleux et exact, ils n'indiquent pas qu'il y a eu une erreur, mais valide plutôt que la transmission s'est faite correctement, les données reçues correspondent aux données envoyées. Mais forcément s'ils ne valident pas, ça veut dire erreur quelque part.

Que ce soit les protocoles IP, TCP, UDP, ICMP, ..., ils n'ont pas de corrections d'erreurs, juste une indication si la données est arrivée correctement. Si la donnée n'est pas correcte, la correction consiste simplement à demander à l’émetteur de renvoyer cette donnée.

Par contre, au niveau au dessus de TCP, le protocole utilisé peut lui intégrer une correction d'erreur, comme par exemple le codage de Hamming. Ce codage consiste à découper les bits d'un octet en plusieurs groupe et d’adjoindre une parité à chaque groupe. Là c'est idem, les parités ne corrigent pas, elles indiquent juste si ça arrive ok ou pas. Mais, avec le découpage judicieux des groupes et les valeurs des parités correspondantes, le récepteur peut arriver à savoir quel bit dans la transmission a été modifié et donc le corriger de lui-même sans en redemander la retransmission de la donnée entière. Cependant, si malgré tout, le récepteur n'est pas capable de déterminer quel bit est en erreur, il n'aurait pas d'autre choix que de redemander la donnée à l’émetteur

[cosmoff]

Que ce soit parité, checksum, crc, etc, ils ne servent pas à corriger les erreurs. Ils ne servent qu'à détecter qu'une erreur a eu lieu mais sans dire où.
Pour être pointilleux et exact, ils n'indiquent pas qu'il y a eu une erreur, mais valide plutôt que la transmission s'est faite correctement, les données reçues correspondent aux données envoyées. Mais forcément s'ils ne valident pas, ça veut dire erreur quelque part.

Que ce soit les protocoles IP, TCP, UDP, ICMP, ..., ils n'ont pas de corrections d'erreurs, juste une indication si la données est arrivée correctement. Si la donnée n'est pas correcte, la correction consiste simplement à demander à l’émetteur de renvoyer cette donnée.

Par contre, au niveau au dessus de TCP, le protocole utilisé peut lui intégrer une correction d'erreur, comme par exemple le codage de Hamming. Ce codage consiste à découper les bits d'un octet en plusieurs groupe et d’adjoindre une parité à chaque groupe. Là c'est idem, les parités ne corrigent pas, elles indiquent juste si ça arrive ok ou pas. Mais, avec le découpage judicieux des groupes et les valeurs des parités correspondantes, le récepteur peut arriver à savoir quel bit dans la transmission a été modifié et donc le corriger de lui-même sans en redemander la retransmission de la donnée entière. Cependant, si malgré tout, le récepteur n'est pas capable de déterminer quel bit est en erreur, il n'aurait pas d'autre choix que de redemander la donnée à l’émetteur

Ok merci pour ton explication tres bien détaillée, j'ai vu sur le net que sur l'architecture TCP/IP on utilisé parfois le checksum, CRC mais y 'a t-il un avantage de privilégier un de ces protocoles selon la message qu'on envoie?

[sevyc64]

Les protocoles IP, TCP, UDP utilisent un checksum pas un CRC.

Les protocoles supérieurs peuvent utiliser checksum ou CRC ou autre suivant les protocoles.

Un CRC est plus fiable, mais nécessite plus de calculs.

[cosmoff]

merci beaucoup sevyc64

[Invité]

voila en me renseignant sur les réseaux avec le modele OSI, j'ai vu qu'on pouvait corriger des erreurs de transmission dans la couche liaison de données en insérant un bit de parité dans chaque caractère ASCII et en insérant le CRC (groupe de bits) entre chaque trame.
est ce quand on envoie des messages on utilise toujours la parité et le CRC pour corriger (si possible) et détecter les erreurs, car on me renseignant sur l'architecture TCP/IP j'ai observé un checksum pour la correction et detection d'erreur. est ce la meme chose?

Dans le modèle OSI, chaque couche est sensée embarquer des mécanismes de détection et/ou correction d'erreurs.
Dans un monde TCP/IP sur Ethernet, voici comment ça se passe.

Ethernet

Cette couche ne fait que de la détection d'erreur. Ethernet utilise l'algo CRC32 (et pour rebondir sur ton message sevy64, il me semble que CRC32 est un algo particulier des checksums mais c'est de la terminologie).

Pour faire simple, supposons qu'un émetteur veuille envoyer 32 bits sur Ethernet.
Les 32 bits sont associés au message polynômial M(x) (de degré 31).
On a ensuite besoin d'un générateur polynômial G(X).

L'IEEE802.3 a imposé pour l'Ethernet le générateur suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

G(X) = X^32 + X^26 + X^23 + X^22 + X^16 + X^12 + X^11 + X^10 + X^8 + X^7 + X^5 + X^4 + X^2 + X + 1

Le message polynômial est alors multiplié par X^32 (ce qui revient à ajouter 32 fois le bit 0 au message initial).
On fait ensuite la division euclidienne de ce résultat par G(X).
C'est le reste de cette division qui est le CRC32 du message, on l'appelle C(X).

Une fois calculé C(X), l'émetteur envoie le train de bits suivant : les 32 bits du message original + 32 fois le bit 0 + C(X).

Lorsque le destinataire Ethernet reçoit le message, il refait le calcul, compare le C(X) qu'il a calculé avec celui qu'il a reçu dans le message. Si les C(X) sont différents, la trame Ethernet est "jetée" par le destinaire et n'est donc pas passée à la couche 3.

A priori complexe, l'implémentation de CRC32 ne pose pas de problème particulier parce que les polynômes utilisés ont des propriétés particulières (notamment G(X), hérité de la théorie des Corps de Galois, c'est d'ailleurs pour ça qu'on l'a dénommé G). Toutes les opérations arithmétiques s'effectuent par manipulation de bits "assez simples" (padding et algèbre booléenne).

Vous devriez trouver sur le net pléthore d'exemple très pénibles à faire à la main

Point importantn, il n'y a pas de mécanisme de feedback entre OSI L2 et L3 quant à la détection d'erreurs : la couche datalink rejette le paquet sans en informer la couche IP.

Enfin, à noter que la détection d'erreurs Ethernet basée sur CRC32 est un défi pour les commutateurs dits "cut-through".
Parce qu'un tel commutateur commence à switcher la trame Ethernet avant d'avoir fini de la recevoir.
Il peut donc potentiellement envoyer des trames en erreur...

IP

Tout comme Ethernet, IP dispose d'un mécanisme de détection d'erreur.
Avec une différence fondamentale...

Ethernet calcule CRC32 en incluant tous les bits du message Ethernet à envoyer. Ca inclut MAC adresses (source/destination), Etype, 802.1 sub-header, data, etc.

En revanche, IP n'utilise que l'en-tête IP du paquet à envoyer pour calculer l'IP Checksum. C'est typiquement du "checksum" et c'est aussi basé sur de la manipulation simple de bits (calcul de carry bits et bit flipping).

Plusieurs exemples de calculs peuvent être trouvés dans ce forum, en voici un :

http://www.developpez.net/forums/d14...tie-manquante/

Un paquet IP reçu avec un mauvais checksum est droppé par le destinataire.
A noter également qu'un routeur vérifie le checksum IPv4 avant de forwarder le paquet.

Comme dans le cas d'Ethernet, si un routeur ou un destinataire IP reçoivent un paquet IP avec un mauvais checksum, le paquet est droppé sans en informer la couche supérieure.

En conclusion, les couches 2 et 3 n'embarquent que de la détection d'erreur.
Et lorsqu'il y a erreur de checksum ou de CRC, les trames/paquets sont rejetés.


C'est à partir de la couche 4 qu'on peut implémenter la correction d'erreur.
Hormis certains cas de figure rarissimes, la seule façon de faire du data recovery, c'est au travers de retransmissions.

Dans le cas de TCP, la retransmission est gérée par le protocole lui-même qui possède des propriétés avancées de contrôle/fenêtrage de flux. Dans le cas d'UDP, c'est à l'applicatif de générer une demande de retransmission au travers d'un nouveau message UDP.

Enfin, il y a une légende urbaine qui prétend que seuls les applicatifs à base de TCP sont robustes comme du roc... C'est faux.

Ainsi, SNMP (à base d'UDP) ou OSPF (à base d'encapsulation IP (id 89)) utilisent leurs propres mécanismes de retransmission et d'acquittement...

Steph