Aucun protocole moderne digne de ce nom ne prévoirait d'utiliser le canal principal pour l'échange binaire! Un échange binaire sur le même canal implique de bloquer la connexion le temps du transfert. Même le vieux ftp, qui est un protocole à la base fait pour transférer des fichiers (donc on pourrait naïvement penser "autant tout faire dans la même connexion: contrôles et transferts!") ouvre une connexion de données séparées, ce qui permet de continuer à naviguer dans l'arborescence et d'exécuter diverses commandes de contrôle.
Bien sûr, on peut aménager le protocole pour ne pas bloquer la connexion, par exemple en coupant en petits bouts le fichier (permettant pleins de petits transferts entre lesquelles des commandes peuvent se placer). Néanmoins cela a pour conséquence de donner une sensation de ralentissement à la fois du transfert (envoyer pleins de petits bouts avec des caractères de contrôle à chaque fois est plus lent qu'envoyer en un bloc) mais aussi le flux non binaire (si on doit constamment attendre le chargement d'un bout binaire, même les messages textes pourraient se mettre à prendre quelques secondes le temps que le bout en cours se termine).
Et c'est sans compter que ça oblige en général de réencoder (par ex avec base64 dans XMPP) parce qu'on ne contrôle pas le contenu d'un binaire et que le mettre direct dans le flux cassera ce dernier chaque fois qu'un contenu de fichier utilise un caractère de contrôle du protocole. Donc le fichier à envoyer est plus gros (de l'ordre du tiers avec base64, de mémoire, ce qui n'est pas rien si on envoie de très gros fichiers!). Ça rallonge d'autant la durée du transfert.
Tout ça, c'est vraiment se faire chier pour rien alors que les connexions, de nos jours, sont tout à fait capables d'encaisser même plusieurs transferts de fichiers en parallèle à pleine vitesse chacune sur leur canal, tout en gardant un canal de contrôle non-encombré, parfaitement fluide et rapide aussi.
Donc non, franchement un protocole qui commencerait avec l'idée de tout faire dans le même canal, j'aurais pas confiance. Ça ne peut pas monter en charge notamment.
Par contre oui, comme solution de secours si on n'arrive pas à initier un canal binaire, ça ok, en bridant si besoin le transfert pour pas qu'il gêne trop le reste de l'expérience utilisateurs. C'est d'ailleurs ce que fait XMPP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Bibinaire
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Parlons XMPP - épisode 9 - copie de fichiers et Jingle. Évalué à 7.
Aucun protocole moderne digne de ce nom ne prévoirait d'utiliser le canal principal pour l'échange binaire! Un échange binaire sur le même canal implique de bloquer la connexion le temps du transfert. Même le vieux ftp, qui est un protocole à la base fait pour transférer des fichiers (donc on pourrait naïvement penser "autant tout faire dans la même connexion: contrôles et transferts!") ouvre une connexion de données séparées, ce qui permet de continuer à naviguer dans l'arborescence et d'exécuter diverses commandes de contrôle.
Bien sûr, on peut aménager le protocole pour ne pas bloquer la connexion, par exemple en coupant en petits bouts le fichier (permettant pleins de petits transferts entre lesquelles des commandes peuvent se placer). Néanmoins cela a pour conséquence de donner une sensation de ralentissement à la fois du transfert (envoyer pleins de petits bouts avec des caractères de contrôle à chaque fois est plus lent qu'envoyer en un bloc) mais aussi le flux non binaire (si on doit constamment attendre le chargement d'un bout binaire, même les messages textes pourraient se mettre à prendre quelques secondes le temps que le bout en cours se termine).
Et c'est sans compter que ça oblige en général de réencoder (par ex avec base64 dans XMPP) parce qu'on ne contrôle pas le contenu d'un binaire et que le mettre direct dans le flux cassera ce dernier chaque fois qu'un contenu de fichier utilise un caractère de contrôle du protocole. Donc le fichier à envoyer est plus gros (de l'ordre du tiers avec base64, de mémoire, ce qui n'est pas rien si on envoie de très gros fichiers!). Ça rallonge d'autant la durée du transfert.
Tout ça, c'est vraiment se faire chier pour rien alors que les connexions, de nos jours, sont tout à fait capables d'encaisser même plusieurs transferts de fichiers en parallèle à pleine vitesse chacune sur leur canal, tout en gardant un canal de contrôle non-encombré, parfaitement fluide et rapide aussi.
Donc non, franchement un protocole qui commencerait avec l'idée de tout faire dans le même canal, j'aurais pas confiance. Ça ne peut pas monter en charge notamment.
Par contre oui, comme solution de secours si on n'arrive pas à initier un canal binaire, ça ok, en bridant si besoin le transfert pour pas qu'il gêne trop le reste de l'expérience utilisateurs. C'est d'ailleurs ce que fait XMPP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]