Il est assez facile de designer un protocole ne prenant pas en compte la couche du dessous et de faire un truc qui rame plus qu'il ne devrait (hello HTTP !). Un exemple très simple est de tunneler du TCP dans du TCP. La gestion de congestion de TCP ayant été entièrement conçue en utilisant la perte de paquet, ça donne des résultats bien pourri par ce que la connexion tunnelée ne voit jamais de perte de paquet puisqu'elle est elle même dans un flux TCP. Tiens on peut ca avec SSH d'ailleurs ! Après je connais pas les détails sur ce sujet. Le fait de multiplexer plusieurs chanels dans une seule connexion TCP comme le fait SSH peut aussi poser des problèmes quand il y a des pertes de paquets, à chaque paquet perdu TCP prend ca pour une congestion et ralenti; tout les chanels multiplexés sont ralenti.
Un autre exemple concret avec SSH c'est qu'il effectue son propre flow control. Celui ci étant assez simpliste il bride complètement TCP (qu'on doit déjà configurer) sur des "long fat pipes", des liens au produit Bandwidth-delay élevé). Cf. http://www.psc.edu/networking/projects/hpn-ssh/
Bref c'est pas impossible, mais dans ce cas c'est intéressant d'avoir les références :p
[^] # Re: ssh vraiment adapté aux réseaux moisis?
Posté par ckyl . En réponse au journal Le TCP keepalive m'a tué. Évalué à 4.
Il est assez facile de designer un protocole ne prenant pas en compte la couche du dessous et de faire un truc qui rame plus qu'il ne devrait (hello HTTP !). Un exemple très simple est de tunneler du TCP dans du TCP. La gestion de congestion de TCP ayant été entièrement conçue en utilisant la perte de paquet, ça donne des résultats bien pourri par ce que la connexion tunnelée ne voit jamais de perte de paquet puisqu'elle est elle même dans un flux TCP. Tiens on peut ca avec SSH d'ailleurs ! Après je connais pas les détails sur ce sujet. Le fait de multiplexer plusieurs chanels dans une seule connexion TCP comme le fait SSH peut aussi poser des problèmes quand il y a des pertes de paquets, à chaque paquet perdu TCP prend ca pour une congestion et ralenti; tout les chanels multiplexés sont ralenti.
Un autre exemple concret avec SSH c'est qu'il effectue son propre flow control. Celui ci étant assez simpliste il bride complètement TCP (qu'on doit déjà configurer) sur des "long fat pipes", des liens au produit Bandwidth-delay élevé). Cf. http://www.psc.edu/networking/projects/hpn-ssh/
Bref c'est pas impossible, mais dans ce cas c'est intéressant d'avoir les références :p