XMODEM - XMODEM

XMODEM
Protocole de communication
But Protocole de transfer de fichier
Développeur(s) Quartier Christensen
Introduit 1977 ; il y a 44 ans ( 1977 )
Influencé YMODEM , bien d'autres
Matériel modems

XMODEM est un protocole de transfert de fichiers simple développé comme un hack rapide par Ward Christensen pour une utilisation dans son programme de terminal MODEM.ASM de 1977 . Il permettait aux utilisateurs de transmettre des fichiers entre leurs ordinateurs lorsque les deux côtés utilisaient le MODEM. Keith Petersen a fait une mise à jour mineure pour toujours activer le "mode silencieux", et a appelé le résultat XMODEM.

XMODEM, comme la plupart des protocoles de transfert de fichiers, divise les données d'origine en une série de « paquets » qui sont envoyés au récepteur, ainsi que des informations supplémentaires permettant au récepteur de déterminer si ce paquet a été correctement reçu. Si une erreur est détectée, le récepteur demande que le paquet soit renvoyé. Une chaîne de paquets incorrects provoque l'abandon du transfert.

XMODEM est devenu extrêmement populaire sur le marché des premiers systèmes de tableau d'affichage (BBS), en grande partie parce qu'il était simple à mettre en œuvre. Il était également assez inefficace et, à mesure que les vitesses des modems augmentaient, ce problème a conduit au développement d'un certain nombre de versions modifiées de XMODEM pour améliorer les performances ou résoudre d'autres problèmes avec le protocole. Christensen croyait que son XMODEM original était « le programme le plus modifié de l'histoire de l'informatique ».

Chuck Forsberg a collecté un certain nombre de modifications courantes dans son protocole YMODEM , mais une mauvaise mise en œuvre a conduit à une nouvelle fracture avant qu'elles ne soient réunifiées par son protocole ZMODEM ultérieur . ZMODEM est devenu très populaire, mais n'a jamais complètement remplacé XMODEM sur le marché BBS.

Structure des paquets

Le XMODEM original utilisait un paquet de données de 128 octets, la taille de bloc de base utilisée sur les disquettes CP/M . Le paquet était préfixé par un simple en-tête de 3 octets contenant un caractère, un "numéro de bloc" de 0 à 255 et le numéro de bloc "inverse" - 255 moins le numéro de bloc. La numérotation des blocs commence par 1 pour le premier bloc envoyé, et non par 0. L'en-tête était suivi des 128 octets de données, puis d'une somme de contrôle à un octet . Le paquet complet faisait donc 132 octets de long, contenant 128 octets de données utiles , pour une efficacité totale du canal d'environ 97 %. <SOH>

La somme de contrôle était la somme de tous les octets du paquet modulo 256. L'opération modulo était facilement calculée en éliminant tous les bits sauf les huit les moins significatifs du résultat, ou alternativement sur une machine à huit bits, en ignorant le débordement arithmétique qui produirait le même effet automatiquement. De cette façon, la somme de contrôle a été limitée à une quantité de huit bits. Par exemple, si cette méthode de somme de contrôle a été utilisée sur un petit paquet de données contenant seulement deux octets portant les valeurs 130 et 130, le total de ces codes est de 260 et la somme de contrôle résultante est 4.

Le fichier a été marqué "complet" avec un caractère envoyé après le dernier bloc. Ce caractère n'était pas dans un paquet, mais envoyé seul sous forme d'un seul octet. Étant donné que la longueur du fichier n'a pas été envoyée dans le cadre du protocole, le dernier paquet a été rempli avec un "caractère connu" qui pouvait être supprimé. Dans la spécification d'origine, il s'agissait par défaut de 26 décimales, que CP/M utilisait comme marqueur de fin de fichier dans son propre format de disque. La norme suggérait que n'importe quel caractère pouvait être utilisé pour le remplissage, mais il n'y avait aucun moyen de le modifier dans le protocole lui-même - si une implémentation changeait le caractère de remplissage, seuls les clients utilisant la même implémentation interpréteraient correctement le nouveau caractère de remplissage. <EOT><SUB>

Détails du transfert

Les fichiers ont été transférés un paquet à la fois. Une fois reçu, la somme de contrôle du paquet a été calculée par le destinataire et comparée à celle reçue de l'expéditeur à la fin du paquet. Si les deux correspondaient, le destinataire renvoyait un message à l'expéditeur, qui envoyait ensuite le paquet suivant dans l'ordre. S'il y avait un problème avec la somme de contrôle, le destinataire envoyait à la place un fichier . Si un a été reçu, l'expéditeur renverrait le paquet et continuerait d'essayer plusieurs fois, normalement dix, avant d'interrompre le transfert. <ACK><NAK><NAK>

A <NAK>était également envoyé si le destinataire ne recevait pas de paquet valide dans les dix secondes tout en attendant toujours des données en raison de l'absence d'un <EOT>caractère. Un délai d'attente de sept secondes a également été utilisé dans un paquet, protégeant contre les connexions interrompues au milieu du paquet.

Les numéros de bloc ont également été examinés de manière simple pour vérifier les erreurs. Après avoir reçu un paquet avec succès, le prochain paquet doit avoir un numéro supérieur. S'il recevait plutôt le même numéro de bloc, cela n'était pas considéré comme grave, cela impliquait que le <ACK>n'avait pas été reçu par l'expéditeur, qui avait alors renvoyé le paquet. Tout autre numéro de paquet signalait que des paquets avaient été perdus.

Les transferts étaient commandés par le récepteur ; l'émetteur n'enverrait aucune donnée jusqu'à ce qu'une initiale <NAK>soit envoyée par le récepteur. Il s'agissait d'un résultat logique de la façon dont l'utilisateur interagissait avec la machine émettrice, qui serait située à distance. L'utilisateur naviguerait jusqu'au fichier demandé sur la machine émettrice, puis demanderait à cette machine de le transférer. Une fois cette commande émise, l'utilisateur exécuterait alors une commande dans son logiciel local pour commencer à recevoir. Étant donné que le délai entre la demande du fichier au système distant et l'émission d'une commande locale à recevoir était inconnu, XMODEM a accordé jusqu'à 90 secondes au récepteur pour commencer à émettre des demandes de paquets de données.

Problèmes

Bien que XMODEM était suffisamment robuste pour qu'un journaliste en 1982 transmette des histoires du Pakistan aux États-Unis avec un Osborne 1 et un coupleur acoustique sur des lignes téléphoniques de mauvaise qualité, le protocole présentait plusieurs défauts.

Problèmes mineurs

XMODEM a été écrit pour les machines CP/M et porte plusieurs marques de ce système d'exploitation . Notamment, les fichiers sur CP/M étaient toujours des multiples de 128 octets, et leur fin était marquée dans un bloc avec le <EOT>caractère. Ces caractéristiques ont été transplantées directement dans XMODEM. Cependant, d'autres systèmes d'exploitation ne présentaient aucune de ces particularités, et l'introduction généralisée de MS-DOS au début des années 1980 a obligé XMODEM à être mis à jour pour remarquer un <EOT> ou <EOF> comme marqueur de fin de fichier.

Pendant un certain temps, il a été suggéré que l'envoi d'un <CAN>caractère au lieu d'un <ACK>ou <NAK>devrait être pris en charge afin d'interrompre facilement le transfert depuis l'extrémité destinataire. De même, un <CAN>reçu à la place de l'a <SOH>indiqué que l'expéditeur souhaitait annuler le transfert. Cependant, ce personnage pourrait être facilement "créé" via de simples erreurs liées au bruit de ce qui était censé être un <ACK>ou <NAK>. Un double a <CAN>été proposé pour éviter ce problème, mais il n'est pas clair si cela a été largement mis en œuvre.

Problèmes majeurs

XMODEM a été conçu pour la simplicité, sans grande connaissance des autres protocoles de transfert de fichiers - qui étaient de toute façon assez rares. En raison de sa simplicité, il y avait un certain nombre d'erreurs très basiques qui pouvaient entraîner l'échec d'un transfert, ou pire, entraîner un fichier incorrect qui passait inaperçu par le protocole. La majeure partie de cela était due à l'utilisation d'une simple somme de contrôle pour la correction d'erreurs, qui est susceptible d'erreurs manquantes dans les données si deux bits sont inversés, ce qui peut se produire avec une rafale de bruit suffisamment courte. De plus, des dommages similaires à l'en-tête ou à la somme de contrôle pourraient entraîner un échec du transfert dans les cas où les données elles-mêmes n'étaient pas endommagées.

De nombreux auteurs ont introduit des extensions à XMODEM pour résoudre ces problèmes et d'autres. Beaucoup ont demandé que ces extensions soient incluses dans le nouveau standard XMODEM. Cependant, Ward Christensen a refusé de le faire, car c'était précisément l' absence de ces fonctionnalités et le codage associé nécessaire pour les prendre en charge, qui a conduit à l'utilisation généralisée de XMODEM. Comme il l'a expliqué :

C'était un hack rapide que j'ai mis en place, très imprévu (comme tout ce que je fais), pour satisfaire un besoin personnel de communiquer avec d'autres personnes. SEULEMENT le fait que cela ait été fait en 8/77, et que je l'aie mis dans le domaine public immédiatement, en a fait la norme qu'il est...
... Les personnes qui me suggèrent d'apporter des modifications IMPORTANTES au protocole, telles que « duplex intégral », « plusieurs blocs en suspens », « plusieurs destinations », etc. ne comprennent pas que l'incroyable simplicité du protocole est l'une des raisons il a survécu.

Transferts par lots

Un autre problème avec XMODEM était qu'il exigeait que le transfert soit piloté par l'utilisateur plutôt qu'automatisé. En général, cela signifiait que l'utilisateur naviguait sur le système de l'expéditeur pour sélectionner le fichier qu'il souhaitait, puis utilisait une commande pour mettre ce système en mode « prêt à envoyer ». Ils déclencheraient ensuite le transfert de leur côté à l'aide d'une commande dans leur émulateur de terminal. Si l'utilisateur voulait transférer un autre fichier, il devrait répéter ce processus à nouveau.

Pour les transferts automatisés entre deux sites, un certain nombre d'add-ons au protocole XMODEM ont été implémentés au fil du temps. Ceux-ci supposaient généralement que l'expéditeur continuerait à envoyer fichier après fichier, le récepteur tentant de déclencher le fichier suivant en envoyant un NAK normalement au début d'un transfert. Lorsque les NAK ont expiré, on pouvait supposer qu'il n'y avait plus de fichiers ou que le lien était de toute façon rompu.

MODEM7

MODEM7 , également connu sous le nom de MODEM7 batch ou Batch XMODEM , a été la première extension connue du protocole XMODEM. Un transfert de fichier XMODEM normal commence par l'envoi d'un seul caractère NAK par le destinataire à l'expéditeur, qui commence ensuite à envoyer un seul SOH pour indiquer le début des données, puis des paquets de données.

MODEM7 n'a que légèrement modifié ce comportement, en envoyant le nom de fichier, au format de nom de fichier 8.3 , avant le fichier<SOH> . Chaque caractère était envoyé individuellement et devait être repris par le récepteur comme une forme de correction d'erreur. Pour une implémentation XMODEM non consciente, ces données seraient simplement ignorées pendant qu'elles attendraient l' arrivée du SOH , de sorte que les caractères ne seraient pas renvoyés et l'implémentation pourrait revenir à XMODEM conventionnel. Avec un logiciel "aware", le nom du fichier peut être utilisé pour enregistrer le fichier localement. Les transferts pourraient continuer avec un autre <NAK> , chaque fichier est enregistré sous le nom envoyé au destinataire.

Jerry Pournelle en 1983 a décrit MODEM7 comme « probablement le programme de communication par micro-ordinateur le plus populaire qui existe ».

TeLink

MODEM7 a envoyé le nom de fichier sous forme de texte normal, ce qui signifiait qu'il pouvait être corrompu par les mêmes problèmes que XMODEM tentait d'éviter. Cela a conduit à l'introduction de TeLink par Tom Jennings , auteur des premiers mailers FidoNet .

TeLink a évité les problèmes de MODEM7 en standardisant un nouveau "paquet zéro" contenant des informations sur le fichier d'origine. Cela comprenait le nom, la taille et l' horodatage du fichier , qui ont été placés dans un bloc XMODEM normal de 128 octets. Alors qu'un transfert XMODEM normal commencerait par l'envoi par l'expéditeur du "bloc 1" avec un en- tête <SOH> , le paquet d'en-tête TeLink était étiqueté "bloc 0" et commençait par un <SYN> . Le paquet contenait la date et l'heure de création du fichier, le nom du fichier jusqu'à 16 caractères, la taille du fichier sous forme de valeur de 4 octets et le nom du programme envoyant le fichier.

Une implémentation XMODEM normale rejetterait simplement le paquet, l'hypothèse étant que le numéro de paquet a été corrompu. Mais cela entraînait un retard potentiel si le paquet était rejeté, car l'expéditeur ne pouvait pas dire si le récepteur avait répondu avec un <NAK> parce qu'il n'avait pas compris le paquet zéro ou parce qu'il y avait une erreur de transmission. Comme TeLink n'était normalement utilisé que par le logiciel FidoNet , qui l'exigeait dans le cadre des normes FidoNet, cela ne présentait pas de problème réel car les deux extrémités prendraient toujours en charge cette norme.

Le système de base « block 0 » est devenu un standard dans la communauté FidoNet et a été réutilisé par un certain nombre de futurs protocoles tels que SEAlink et YMODEM .

XMODEM-CRC

La somme de contrôle utilisée dans le protocole d'origine était extrêmement simple et les erreurs dans le paquet pouvaient passer inaperçues. Cela a conduit à l'introduction de XMODEM-CRC par John Byrns, qui utilisait un CRC 16 bits à la place de la somme de contrôle 8 bits. Les CRC encodent non seulement les données du paquet, mais également leur emplacement, ce qui lui permet de remarquer les erreurs de remplacement de bits qu'une somme de contrôle manquerait. Statistiquement, cela a permis de détecter une erreur de moins de 16 bits à 99,969%, et encore plus élevé pour les chaînes de bits d'erreur plus longues.

XMODEM-CRC a été conçu pour être rétrocompatible avec XMODEM. Pour ce faire, le destinataire a envoyé un caractère C(C majuscule) au lieu d'un <NAK>pour démarrer le transfert. Si l'expéditeur a répondu en envoyant un paquet, il a été supposé que l'expéditeur « connaissait » XMODEM-CRC, et le destinataire a continué à envoyer Cdes . Si aucun paquet n'arrivait, le récepteur supposait que l'expéditeur ne connaissait pas le protocole et envoyait un <NAK>pour démarrer un transfert XMODEM "traditionnel".

Malheureusement, cette tentative de compatibilité descendante a eu un inconvénient. Comme il était possible que le Ccaractère initial soit perdu ou corrompu, on ne pouvait pas supposer que le récepteur ne prendrait pas en charge XMODEM-CRC si la première tentative de déclenchement du transfert échouait. Le récepteur a donc tenté de lancer le transfert trois fois avec C, en attendant trois secondes entre chaque tentative. Cela signifiait que si l'utilisateur sélectionnait XMODEM-CRC tout en essayant de parler à n'importe quel XMODEM, comme prévu, il y avait un délai potentiel de 10 secondes avant le début du transfert.

Pour éviter le retard, l'expéditeur et le destinataire listeraient généralement XMODEM-CRC séparément de XMODEM, permettant à l'utilisateur de sélectionner XMODEM "de base" si l'expéditeur ne l'avait pas explicitement répertorié. Pour l'utilisateur moyen, XMODEM-CRC était essentiellement un "second protocole" et traité comme tel. Cependant, ce n'était pas le cas des expéditeurs FidoNet, où le CRC était défini comme la norme pour tous les transferts TeLink.

Débit plus élevé

Étant donné que le protocole XMODEM obligeait l'expéditeur à s'arrêter et à attendre un message <ACK>ou <NAK>du destinataire, il avait tendance à être assez lent. A l'ère des modems 300 bit/s, l'ensemble du paquet de 132 octets nécessitait un peu plus de 3,5 secondes pour être envoyé (132 octets * (8 bits par octet + 1 bit de démarrage + 1 bit d'arrêt) / 300 bits par seconde). En supposant qu'il faut 0,2 seconde au récepteur <ACK>pour revenir à l'expéditeur et que le paquet suivant commence à toucher le récepteur (0,1 seconde dans les deux sens), le temps total pour un paquet serait de 3,7 secondes, soit un peu plus de 92 % de débit.

Au fur et à mesure que les vitesses des modems augmentaient, le délai fixe nécessaire pour envoyer le <ACK>/ <NAK>augmentait proportionnellement au temps nécessaire pour envoyer le paquet. Par exemple, à 2400 bit/s, les paquets ne prenaient que 0,44 seconde pour être envoyés, donc si le <ACK>/ <NAK>prenait encore 0,2 seconde pour revenir (il s'agit de la latence dans le réseau, pas du débit), le débit est tombé à moins de 60%. À 9600 bit/s, il est inférieur à 30 % – il faut plus de temps à attendre la réponse qu'il n'en faut pour envoyer le paquet.

Un certain nombre de nouvelles versions de XMODEM ont été introduites afin de résoudre ces problèmes. Comme les extensions précédentes, ces versions avaient tendance à être rétrocompatibles avec le XMODEM d'origine, et comme ces extensions, cela a conduit à une nouvelle fragmentation du paysage XMODEM dans l'émulateur de terminal de l'utilisateur. Au final, des dizaines de versions de XMODEM ont vu le jour.

Modem WX

WXmodem , abréviation de "Windowed Xmodem", est une variante de XMODEM développée par Peter Boswell en 1986 pour une utilisation sur les lignes à haute latence, en particulier les systèmes X.25 publics et PC Pursuit . Ceux-ci ont des latences bien supérieures à celles de l' ancien service téléphonique , ce qui entraîne une très mauvaise efficacité de XMODEM. De plus, ces réseaux utilisent souvent des caractères de contrôle pour le contrôle de flux et d'autres tâches, notamment XON/XOFF arrêtera le flux de données. Enfin, dans le cas d'une erreur nécessitant un renvoi, il était parfois difficile de savoir si un SOH était un indicateur de paquet ou plus de bruit. WXmodem a adapté XMODEM-CRC pour résoudre ces problèmes.

Un changement consistait à échapper à un petit ensemble de caractères de contrôle, DLE , XON , XOFF et SYN . Ceux-ci ont été échappés en insérant un DLE devant eux, puis en modifiant le caractère en le XOR avec 64. En théorie, cela signifiait que le paquet pouvait atteindre 264 octets s'il était à l'origine entièrement composé de caractères nécessitant un échappement. Ces caractères insérés et modifiés ne font pas partie du calcul du CRC, ils sont supprimés et convertis à la réception avant le calcul du CRC.

De plus, tous les paquets étaient préfixés par un caractère SYN , ce qui signifiait que l'entrée du paquet était SYN SOH , réduisant ainsi le risque qu'un SOH égaré soit confondu avec un en-tête de paquet dans divers cas d'erreur. Un SYN non échappé trouvé dans le corps d'un paquet était une erreur.

Le changement majeur dans WXMODEM est l'utilisation d'une fenêtre glissante pour améliorer le débit sur les liens à haute latence. Pour ce faire, les messages ACK étaient suivis du numéro de paquet qu'ils faisaient ACK ou NAK ing. Le récepteur n'a pas à ACK chaque paquet, il est autorisé à ACK n'importe quel nombre entre un et quatre paquets. Un ACK avec le quatrième numéro de séquence de paquet est supposé ACK tous les quatre paquets. Une erreur provoque l'envoi immédiat d' un NAK , avec tous les paquets provenant de ce numéro et après avoir été renvoyés.

Exiger un ACK tous les quatre paquets fait fonctionner le système comme s'il avait une taille de paquet de 512 octets, mais en cas d'erreur, il ne nécessite généralement que 128 octets pour être renvoyés. De plus, il réduit de quatre fois la quantité de données circulant dans le sens inverse. Ceci n'a que peu d'intérêt dans le fonctionnement en duplex intégral du modem typique , mais est important dans les systèmes semi-duplex comme les modèles Telebit qui ont une vitesse de 19 Ko dans une direction et 75 bits/s dans le canal de retour.

SEAlink

L' un des premiers expéditeurs de courrier tiers pour le FidoNet système était Seadog , écrit par le même auteur que l'époque populaire .arc compression de données format. SEAdog a inclus une grande variété d'améliorations, y compris SEAlink , un protocole de transfert amélioré basé sur le même concept de fenêtre coulissante que WXmodem. Il différait de WXmodem principalement dans les détails.

Une différence est que SEAlink a pris en charge le "paquet zéro" introduit par TeLink, qui est nécessaire pour fonctionner en remplacement de TeLink dans les systèmes FidoNet où l'en-tête était attendu. Les ACK et les NAK ont été étendus à des "paquets" de trois octets, en commençant par l' ACK ou le NAK , puis le numéro de paquet, puis le complément du numéro de paquet, de la même manière que l'en-tête de paquet XMODEM d'origine. La taille de la fenêtre était normalement fixée à six paquets.

SEAlink n'était pas censé fonctionner sur X.25 ou des liens similaires, et n'a donc pas effectué d'échappement. Cela était également nécessaire pour que le paquet zéro fonctionne correctement, car cette norme utilisait le caractère SYN que WXmodem avait réutilisé. En plus de ces changements, il a ajouté un mode "Overdrive" pour les liaisons semi-duplex. Cela a supprimé les ACK pour les paquets qui ont été transférés avec succès, rendant la fenêtre de taille infinie. Ce mode était indiqué par un drapeau dans le bloc zéro.

SEAlink a ensuite ajouté un certain nombre d'autres améliorations et était un protocole utile à usage général. Cependant, il restait rare en dehors du monde FidoNet et était rarement vu dans les logiciels destinés aux utilisateurs.

XMODEM-1K

Une autre façon de résoudre le problème de débit est d'augmenter la taille des paquets. Bien que le problème fondamental de la latence demeure, la vitesse à laquelle elle devient un problème est plus élevée. XMODEM-1K avec des paquets de 1024 octets était la solution la plus populaire. Dans ce cas, le débit à 9600 bit/s est de 81 %, compte tenu des mêmes hypothèses que ci-dessus.

XMODEM-1K était une version étendue de XMODEM-CRC, qui indiquait la taille de bloc plus longue dans l' expéditeur en commençant un paquet avec le <STX>caractère au lieu de <SOH>. Comme d'autres extensions XMODEM rétrocompatibles, il était prévu qu'un transfert -1K puisse être démarré avec n'importe quelle implémentation de XMODEM à l'autre extrémité, en supprimant les fonctionnalités si nécessaire.

XMODEM-1K était à l'origine l'une des nombreuses améliorations apportées à XMODEM introduites par Chuck Forsberg dans son protocole YMODEM . Forsberg a suggéré que les diverses améliorations étaient facultatives, s'attendant à ce que les auteurs de logiciels en implémentent autant que possible. Au lieu de cela, ils ont généralement mis en œuvre le strict minimum, conduisant à une profusion d'implémentations semi-compatibles et, finalement, à la séparation du nom "YMODEM" en "XMODEM-1K" et en une variété de YMODEM. Ainsi, XMODEM-1K est en fait postérieur à YMODEM, mais est resté assez courant de toute façon.

NMODEM

NMODEM est un protocole de transfert de fichiers développé par LB Neal, qui l'a publié en 1990. NMODEM est essentiellement une version de XMODEM-CRC utilisant des blocs plus grands de 2048 octets, par opposition aux blocs de 128 octets de XMODEM. NMODEM a été implémenté en tant que programme séparé, écrit en Turbo Pascal 5.0 pour la famille d'ordinateurs compatibles IBM PC . La taille de bloc a été choisie pour correspondre à la taille de cluster commune du système de fichiers MS-DOS FAT sur les disques durs contemporains , ce qui simplifie la mise en mémoire tampon des données pour l'écriture.

Usurpation de protocole

Sur des connexions fiables (sans erreur), il est possible d'éliminer la latence en "pré-acquittant" les paquets, une technique connue plus généralement sous le nom de " Protocol spoofing ". Ceci est normalement accompli dans le matériel de liaison, notamment les modems Telebit. Les modems, lorsque l'option était activée, remarquaient l'en-tête XMODEM et envoyaient immédiatement un ACK . Cela obligerait le programme XMODEM expéditeur à envoyer immédiatement le prochain paquet, rendant le transfert continu, comme une fenêtre de taille infinie. Les modems suppriment également l' ACK envoyé par le logiciel XMODEM à l'extrémité distante, libérant ainsi le canal de retour à faible vitesse.

Le système peut également être implémenté dans le protocole lui-même, et des variantes de XMODEM offraient cette fonctionnalité. Dans ces cas, le récepteur enverrait l' ACK dès le démarrage du paquet, de la même manière que les modems Telebit. Étant donné que cette fonctionnalité n'est qu'une modification du comportement côté récepteur, elle ne nécessite aucune modification du protocole du côté de l'expéditeur. YMODEM a formalisé ce dispositif.

Ce concept doit être mis en contraste avec celui utilisé dans SEAlink, qui modifie le comportement des deux côtés du lien. Dans SEAlink, le destinataire arrête complètement d' envoyer l' ACK et l'expéditeur modifie son comportement pour ne pas les attendre.

Voir également

Les références

Citations

Bibliographie

Liens externes