c'est précisément la possibilité de collisions qui autorise ce comportement
Non, même si historiquement le traitement des collisions dans les vieux ethernet a été un thème important, la fiabilité de certains protocoles de couches supérieures n'est clairement pas due à la nécessité de traiter uniquement ces collisions lors de la conception initiale, suivi d'une utilité plus large par effet de bord par la suite. La logique a été au contraire dès le départ de traiter tout type de perturbation ; collisions certes, mais aussi corruption provenant de la couche physique, puissance trop faible du récepteur pour suivre le rythme, débits dispos différents sur un routeur (ou un switch), et justement aussi des pertes internes rares dans les équippements pour simplifier leur conception, à tous les niveaux, que ça soit l'interface PHY / MAC, puis dans le MAC, puis l'interface MAC / CPU, puis enfin dans le logiciel. Les aspects fiabilités du TCP restent utiles même si par exemple tu passes sur un lien synchrone de très haute qualité au lieu de passer sur de l'ethernet.
Donc il n'y a aucune raison de désigner une perte de paquet quelconque n'étant pas due à une collision par ce ; ce n'est même plus de l'abus de langage compréhensible, c'est juste une fausse désignation de la cause de la perte de paquet.
[^] # Re: Collisions
Posté par Guillaume Knispel . En réponse au journal De la capacité d'un lien Ethernet. Évalué à 3.
Non, même si historiquement le traitement des collisions dans les vieux ethernet a été un thème important, la fiabilité de certains protocoles de couches supérieures n'est clairement pas due à la nécessité de traiter uniquement ces collisions lors de la conception initiale, suivi d'une utilité plus large par effet de bord par la suite. La logique a été au contraire dès le départ de traiter tout type de perturbation ; collisions certes, mais aussi corruption provenant de la couche physique, puissance trop faible du récepteur pour suivre le rythme, débits dispos différents sur un routeur (ou un switch), et justement aussi des pertes internes rares dans les équippements pour simplifier leur conception, à tous les niveaux, que ça soit l'interface PHY / MAC, puis dans le MAC, puis l'interface MAC / CPU, puis enfin dans le logiciel. Les aspects fiabilités du TCP restent utiles même si par exemple tu passes sur un lien synchrone de très haute qualité au lieu de passer sur de l'ethernet.
Donc il n'y a aucune raison de désigner une perte de paquet quelconque n'étant pas due à une collision par ce ; ce n'est même plus de l'abus de langage compréhensible, c'est juste une fausse désignation de la cause de la perte de paquet.