pourquoi un programme peut planter et pourquoi on ajoute un CRC aux trames TCP

[docEmmettBrown]

Bonjour à tous,

voila j'ai deux questions, la premiere est pourquoi un programme peut planter alors que le code est correctement fait (en tout cas en à l'air), normalement les portes logiques qui composent un ordinateur sont fiables, alors l'erreur vient du programmeur ?

Pourquoi dans la communication TCP, on rajoute parfois un CRC pour vérifier la trame. Normalement le protocole TCP/IP vérifie à travers un checksum si la trame est bonne, et cette méthode est tres fiable normalement. C'est des programmeurs qui connaissent pas trop le protocole TCP/IP ?

merci d'avance pour vos réponses
-----

[antek]

voila j'ai deux questions, la premiere est pourquoi un programme peut planter alors que le code est correctement fait (en tout cas en à l'air), normalement les portes logiques qui composent un ordinateur sont fiables, alors l'erreur vient du programmeur ?

D'une façon générale l'erreur est humaine.
Pour les gros programmes les erreurs peuvent être amplifiées par la politique de production de l'entreprise.
Voir les débuggueurs buggués de Microchip . . .

[jiherve]

Bonsoir,
Aucun programme un peu gros n'est exempt d'erreurs (d'origine humaine) et ensuite il advient plus rarement que le processeur ou les mémoires soient perturbés par des événements aussi inattendus que délétères les deux causes conduisant au bug.
En ce qui concerne les communications il n'existe pas non plus de canal 100% sur et intègre donc on peut rajouter une checksum qui détecte les erreurs(pas toutes) et un CRC qui permettra de les corriger (pas toutes), c'est toute une science.
En résumé le zéro défaut n'est qu'une illusion que propagent les ignorants ou les escrocs!
JR

[invite5ac0c3ae]

Avec le temps c'est devenue anodain, À une certaine époque les outilles de transmission étais moins pérformants alors des pérturbations magnétiques peuvent modifier ou faire disparaitre des packets.

[A voir en vidéo sur Futura]

[invite0bbe92c0]

Avec le temps c'est devenue anodain, À une certaine époque les outilles de transmission étais moins pérformants alors des pérturbations magnétiques peuvent modifier ou faire disparaitre des packets.

Ah bon ? Je n'ai pas constaté de chute spectaculaire des taux d'erreurs de transmission avec l'augmentation des vitesses.
Vous avez une source à l'appui de votre affirmation ?

[Paraboloide_Hyperbolique]

Bonjour,

voila j'ai deux questions, la premiere est pourquoi un programme peut planter alors que le code est correctement fait (en tout cas en à l'air), normalement les portes logiques qui composent un ordinateur sont fiables, alors l'erreur vient du programmeur ?

Comme déjà dit, les erreurs présentes dans un programme sont d'origine humaine. Les autres causes de plantages peuvent être d'origine matérielle (aucun support de stockage, traitement et transmission d'information n'est fiable à 100%) ou dues à des manipulations par l'utilisateur non prévues lors du développement initial du programme*.

*C'est comme ça que sont "nées" les failles XSS.

[inviteeecca5b6]

Bonjour à tous,

voila j'ai deux questions, la premiere est pourquoi un programme peut planter alors que le code est correctement fait (en tout cas en à l'air), normalement les portes logiques qui composent un ordinateur sont fiables, alors l'erreur vient du programmeur ?

C'est intéressant parce que l'origine du mot Bug elle-même pointe le fait que le matériel PEUT être défaillant. Si tu es certain que ton code est bon, il ne faut pas exclure une cause matériel. J'ai déjà eu ce genre de cas, liés à une surchauffe CPU (pate thermique HS) ou à une RAM HS, ou des secteurs disques défaillants. Peut-être même que de vrais bugs peuvent nuire dans certaines conditions.

[Jack]

Pourquoi dans la communication TCP, on rajoute parfois un CRC pour vérifier la trame. Normalement le protocole TCP/IP vérifie à travers un checksum si la trame est bonne

Je n'ai pas bien compris ce que tu voulais dire. Qui rajoute un CRC? Le crc est présent dans la trame, donc qui voudrait en rajouter un? Et de quelle manière, sans avoir à réécrire le code gérant ce protocole?

[invite0bbe92c0]

Je n'ai pas bien compris ce que tu voulais dire. Qui rajoute un CRC? Le crc est présent dans la trame, donc qui voudrait en rajouter un? Et de quelle manière, sans avoir à réécrire le code gérant ce protocole?

Je pense qu'on doit trouver des cas d'encapsulation mal branlée où cela existe; mais lesquelles ?

peut être aussi des adaptations d'applications réseaux non initialement prévues pour TCP/IP (quoique tous les protocoles civilisés depuis des temps immémoriaux ont des contrôles de sommation).

[invite5ac0c3ae]

Ah bon ? Je n'ai pas constaté de chute spectaculaire des taux d'erreurs de transmission avec l'augmentation des vitesses.
Vous avez une source à l'appui de votre affirmation ?

Je ne gère parler de la vitesse mais de l'évolution des types de resaux et protocols, Pour en citer quelques uns: Le reseau BNC avec le cable coaxial et la topologie en aneau.

[docEmmettBrown]

Je n'ai pas bien compris ce que tu voulais dire. Qui rajoute un CRC? Le crc est présent dans la trame, donc qui voudrait en rajouter un? Et de quelle manière, sans avoir à réécrire le code gérant ce protocole?

si un programmeur veut envoyer la donnée :"hello world", il va envoyer "hello world"+CRC (fait par le programmeur qui peut etre des bits de parité). mais je ne comprend pas l'utilité car dans le protocole TCP il y a déja un checksum

[Jack]

Si je veux envoyer des données à l'aide d'une socket TCP, il ne me viendrait pas à l'esprit d'ajouter un CRC.

Prends le protocole modbus par exemple. Si on veut envoyer une requête à l'aide d'une liaison série, il faut ajouter un checksum (CRC ou LRC) en fin de trame. En revanche, avec modbus TCP, le CRC disparait car l'intégrité de la trame est prise en charge par le protocole TCP.