UUCP

UUCP ( Unix-to-Unix Copy ) est une suite de programmes informatiques et de protocoles permettant l'exécution à distance de commandes et le transfert de fichiers , de courriers électroniques et de nouvelles entre ordinateurs .

Une commande nommée uucpest l'un des programmes de la suite ; elle fournit une interface utilisateur pour demander des opérations de copie de fichiers. La suite UUCP comprend également uux(interface utilisateur pour l'exécution de commandes à distance), uucico(le programme de communication qui effectue les transferts de fichiers), uustat(rapports de statistiques sur l'activité récente), uuxqt(exécution de commandes envoyées depuis des machines distantes) et uuname(rapport du nom UUCP du système local). Certaines versions de la suite incluent uuencode/ uudecode(conversion de fichiers binaires 8 bits au format texte 7 bits et vice versa).

Bien que UUCP ait été développé à l'origine sur Unix dans les années 1970 et 1980, et soit plus étroitement associé aux systèmes de type Unix , des implémentations UUCP existent pour plusieurs systèmes d'exploitation non de type Unix, notamment DOS , OS/2 , OpenVMS (pour le matériel VAX uniquement), AmigaOS , Mac OS classique et même CP/M .

Le protocole UUCP a été écrit à l'origine par Mike Lesk dans les laboratoires AT&T Bell . En 1978, il était utilisé sur 82 machines UNIX au sein du système Bell, principalement pour la distribution de logiciels. Il a été publié en 1979 dans le cadre de la version 7 d'Unix .

Les premiers courriers électroniques UUCP en provenance des États-Unis sont arrivés au Royaume-Uni en 1979 et les échanges de courriers électroniques entre le Royaume-Uni, les Pays-Bas et le Danemark ont ​​commencé en 1980, devenant un service régulier via EUnet en 1982.

L'UUCP original a été réécrit par les chercheurs d'AT&T Peter Honeyman, David A. Nowitz et Brian E. Redman vers 1983. La réécriture est appelée HDB ou HoneyDanBer uucp, qui a ensuite été amélioré, corrigé des bugs et reconditionné sous le nom de BNU UUCP (« Basic Network Utilities »).

Chacune de ces versions a été distribuée en tant que logiciel propriétaire, ce qui a inspiré Ian Lance Taylor à écrire une nouvelle version de logiciel libre en 1991. Taylor UUCP a été publié sous la licence publique générale GNU . Taylor UUCP a comblé des failles de sécurité qui permettaient à certains des vers de réseau d'origine d'exécuter à distance des commandes shell inattendues. Taylor UUCP a également incorporé des fonctionnalités de toutes les versions précédentes d'UUCP, lui permettant de communiquer avec n'importe quelle autre version et même d'utiliser des formats de fichiers de configuration similaires à ceux d'autres versions.

UUCP a également été implémenté pour les systèmes d'exploitation non UNIX , notamment les systèmes DOS . Des packages tels que UUSLAVE/GNUUCP ( John Gilmore , Garry Paxinos, Tim Pozar), UUPC/extended (Drew Derbyshire de Kendra Electronic Wonderworks) et FSUUCP (Christopher Ambler d'IODesign) ont apporté une connectivité Internet précoce aux ordinateurs personnels, étendant le réseau au-delà des systèmes universitaires interconnectés. FSUUCP a constitué la base de nombreux packages de système de tableau d'affichage (BBS) tels que Major BBS de Galacticomm et Wildcat! BBS de Mustang Software pour se connecter au réseau UUCP et échanger des e-mails et du trafic Usenet . À titre d'exemple, UFGATE (John Galvin, Garry Paxinos, Tim Pozar) était un package qui fournissait une passerelle entre les réseaux exécutant les protocoles Fidonet et UUCP.

FSUUCP était la seule autre implémentation du protocole « i » amélioré de Taylor, une amélioration significative par rapport au protocole standard « g » utilisé par la plupart des implémentations UUCP.

Avant la généralisation de l'accès à Internet , les ordinateurs n'étaient connectés que par des réseaux locaux plus petits au sein d'une entreprise ou d'une organisation. Ils étaient également souvent équipés de modems pour pouvoir être utilisés à distance à partir de terminaux en mode caractère via des lignes téléphoniques commutées . UUCP utilisait les modems des ordinateurs pour se connecter à d'autres ordinateurs, établissant des liens temporaires point à point entre eux. Chaque système d'un réseau UUCP dispose d'une liste de systèmes voisins, avec des numéros de téléphone, des noms de connexion et des mots de passe, etc. Lorsqu'un travail (transfert de fichiers ou demandes d'exécution de commandes) est mis en file d'attente pour un système voisin, le programme appelle généralement ce système pour traiter le travail. Le programme peut également interroger périodiquement ses voisins pour vérifier si du travail est en file d'attente de leur côté ; cela permet aux voisins sans capacité de connexion de participer. uucicouucico

Au fil du temps, les liaisons commutées ont été remplacées par des connexions Internet et UUCP a ajouté un certain nombre de nouveaux protocoles de couche de liaison . Ces nouvelles connexions ont également réduit le besoin d'UUCP, car de nouveaux protocoles d'application ont été développés pour tirer parti des nouveaux réseaux. Aujourd'hui, UUCP est rarement utilisé sur les liaisons commutées, mais il est parfois utilisé sur TCP/IP . son basculement natif vers l'accès commuté et à sa gestion persistante des files d'attente.

Le démarrage d'UUCP se fait généralement par la connexion d'un utilisateur au système cible, puis par l'exécution du programme UUCP. Dans la plupart des cas, cette opération est automatisée par la connexion à un compte utilisateur connu utilisé pour les transferts, dont le shell du compte a été défini sur uucico. Ainsi, pour les transferts automatisés, une autre machine doit simplement ouvrir une connexion modem à la machine appelée et se connecter au compte connu.

Lors de son exécution, uucico s'attend à recevoir des commandes d'un autre programme UUCP sur la machine de l'appelant et à démarrer une session. La session comporte trois étapes distinctes :

1. Poignée de main initiale
2. Demande(s) de fichier
3. Poignée de main finale

Au démarrage, uucico répond en envoyant une chaîne d'identification, , où \20 est le caractère de contrôle-P et \0 est un null final. L'UUCP de l'appelant répond avec , où options est une chaîne contenant zéro ou plusieurs commutateurs d'options de type Unix. Ceux-ci peuvent inclure les tailles de paquets et de fenêtres, la taille de fichier maximale prise en charge, les options de débogage et autres. \20Shere=hostname\0\20Scallername options\0

Selon la configuration des deux systèmes, l'appel peut se terminer ici. Par exemple, lorsque l'appelant répond avec son nom de système, le système appelé peut éventuellement raccrocher s'il ne reconnaît pas l'appelant, en envoyant la RYou are unknown to me\0chaîne de réponse puis en se déconnectant.

Si les deux systèmes parviennent à établir une liaison, l'appelant va alors commencer à envoyer une série de demandes de fichiers. Il existe quatre types :

La commande S provoque l'envoi d'un fichier de l'appelant au système appelé (téléchargement). Les noms de l'expéditeur et du destinataire sont fournis, ce qui permet de modifier le nom du fichier sur le récepteur. Lorsque la commande S est reçue sur le système appelé, il répond avec SY si elle a réussi et qu'il est prêt à accepter le fichier, ou SNx si elle a échoué, où x est une raison d'échec. Si une commande SY est reçue par l'appelant, il commence à télécharger le fichier en utilisant le protocole sélectionné lors de la négociation initiale (voir ci-dessous). Une fois le transfert terminé, le système appelé répond avec CY s'il a reçu le fichier avec succès, ou CN5 s'il a échoué.

R est une requête pour que le système appelé envoie un fichier à l'appelant (téléchargement). Par ailleurs, il est similaire à S, utilisant RY et RN pour indiquer que la commande a été acceptée et qu'il va commencer à envoyer des données ou qu'il y a eu un problème, et attendant un CY et CN5 de l'appelant à la fin du transfert.

X télécharge les commandes à exécuter sur le système appelé. Cela peut être utilisé pour que ce système en appelle un autre et lui livre des fichiers. Le système appelé répond avec XY s'il a réussi, ou XN s'il a échoué.

H , pour Raccrocher, indique que l'appelant a terminé. Le système appelé répond avec HY s'il a réussi, ou HN s'il a échoué.

Après avoir envoyé une commande H, le système appelant envoie un paquet final \20OOOOOO\0(control-P, six ohs, null-terminator) et le système appelé répond avec \20OOOOOO\0(control-P, sept ohs, null-terminator). Certains systèmes raccrochent simplement après la réception réussie de la commande H et ne s'occupent pas de la négociation finale.

Dans la suite de protocoles UUCP, le protocole g sous-jacent est responsable du transfert d'informations sous une forme sans erreur. Le protocole est à l'origine un système à usage général pour la livraison de paquets et offre donc un certain nombre de fonctionnalités qui ne sont pas utilisées par le package UUCP dans son ensemble. Il s'agit notamment d'un canal secondaire qui peut envoyer des données de commande entrecoupées d'un transfert de fichiers et de la possibilité de renégocier les tailles de paquet et de fenêtre pendant la transmission. Ces fonctionnalités supplémentaires peuvent ne pas être disponibles dans certaines implémentations de la pile UUCP.

Le format du paquet était composé d'un en-tête de 6 octets, puis de zéro à 4096 octets dans la charge utile. Le paquet commence par un seul \020 (contrôle-P). Il est suivi d'un seul octet, appelé « K », contenant une valeur de 1 à 8 indiquant une taille de paquet de 32 à 4096 octets, ou un 9 indiquant un paquet de contrôle. De nombreux systèmes ne prenaient en charge que K=2, soit 64 octets. Les deux octets suivants étaient une somme de contrôle de 16 bits de la charge utile, sans compter l'en-tête. L'octet suivant est le type de données et enfin, le dernier octet est le XOR de l'en-tête, ce qui permet de le vérifier séparément de la charge utile.

L'octet de contrôle se compose de trois champs de bits au format TTXXXYYY. TT est le type de paquet, 0 pour les paquets de contrôle (qui nécessitent également que K=9 soit valide), 1 pour les données alternatives (non utilisées dans UUCP), 2 pour les données et 3 indique un paquet court qui redéfinit la signification de K. Dans un paquet de données, XXX est le numéro de paquet pour ce paquet de 0 à 7 et YYY est le dernier qui a été reçu correctement. Cela fournit jusqu'à 8 paquets dans une fenêtre. Dans un paquet de contrôle, XXX indique la commande et YYY est utilisé pour divers paramètres. Par exemple, les transferts sont démarrés en envoyant un paquet de contrôle court avec TT=0 (contrôle), XXX=7 et YYY le nombre de paquets dans une fenêtre, puis en envoyant un autre paquet avec XXX=6 et YYY comme longueur de paquet (codé comme il le serait en K) puis un troisième paquet identique au premier mais XXX=5.

Le protocole g utilise un système de fenêtre glissante simple pour gérer les latences potentiellement longues entre les points de terminaison. Le protocole permet aux paquets d'avoir une taille comprise entre 64 et 4096 octets 8 bits et des fenêtres comprenant de 1 à 7 paquets. En théorie, un système utilisant des paquets de 4 000 et des fenêtres de 7 paquets (4096x7) offrirait des performances égales ou supérieures à celles des meilleurs protocoles de transfert de fichiers comme ZMODEM . En pratique, de nombreuses implémentations ne prenaient en charge qu'un seul paramètre de 64x3. En conséquence, le protocole g a une réputation imméritée de performances médiocres. La confusion sur les tailles de paquets et de fenêtres a conduit au protocole G, qui ne diffère que par le fait qu'il utilise toujours 4096x3. Taylor UUCP ne prenait pas en charge G, mais prenait en charge toute fenêtre ou taille de paquet demandée valide, de sorte que les systèmes distants démarrant G fonctionneraient bien avec le g de Taylor, tandis que deux systèmes Taylor pourraient négocier des connexions encore plus rapides.

Les modems Telebit utilisaient l'usurpation de protocole pour améliorer les performances des transferts du protocole g en détectant les marqueurs de fin de paquet envoyés au système distant et en renvoyant immédiatement un ACKmessage à l'hôte local, en prétendant que le système distant avait déjà reçu le paquet et l'avait décodé correctement. Cela a déclenché la pile logicielle pour envoyer le paquet suivant, si rapidement que le transfert est devenu presque continu. Les données entre les deux modems ont été corrigées en utilisant un protocole propriétaire basé sur MNP qui fonctionnait sur les connexions semi-duplex de Telebit bien mieux que le protocole g ne le ferait normalement, car dans le cas courant de 64x3, le système distant enverrait un flux constant de ACKs qui déborderait le canal de retour à faible vitesse. Combinés aux débits de données naturellement plus élevés du modem, ils ont considérablement amélioré le débit global et ont généralement atteint une vitesse environ sept fois supérieure à celle d'un modem 2400 bit/s. Ils étaient largement utilisés sur les hôtes UUCP car ils pouvaient rapidement s'amortir grâce à des frais longue distance réduits.

Les implémentations UUCP incluent également d’autres protocoles de transfert à utiliser sur certaines liaisons.

Le protocole f est conçu pour fonctionner sur des liaisons à correction d'erreurs de 7 bits. Il était initialement prévu pour être utilisé sur des liaisons X.25 , qui étaient populaires pendant un certain temps dans les années 1980. Il ne met pas les données en paquets, mais le fichier entier est envoyé sous la forme d'une seule longue chaîne suivie d'une somme de contrôle du fichier entier. Le protocole x similaire semble avoir été peu ou pas utilisé. Le protocole d était similaire à x, mais destiné à être utilisé sur les réseaux Datakit qui connectaient de nombreux bureaux de Bell Labs .

Le protocole t est issu des versions BSD de UUCP et, comme certains protocoles similaires, est conçu pour fonctionner sur des liaisons TCP/IP 8 bits sans erreur . Il ne comporte aucune correction d'erreur et le protocole consiste simplement à décomposer les données de commande et de fichier en paquets de 512 ou 1024 octets pour s'adapter facilement aux trames TCP classiques.

Le protocole e (« e » pour Ethernet) a été développé par Clem Cole chez MASSCOMP et a été largement diffusé par Brian Redman dans les versions ultérieures de HoneyDanBer. Il a été développé et diffusé avant le protocole t, mais ce dernier était plus couramment utilisé car la version BSD de UUCP était l'implémentation dominante. Le protocole e diffère du protocole t uniquement dans le sens où les commandes ne sont pas mises en paquets et sont envoyées sous forme de chaînes normales, tandis que les fichiers sont complétés aux 20 octets les plus proches.

Les fonctionnalités uucpet uuxqtpeuvent être utilisées pour envoyer des e-mails entre machines, avec des interfaces utilisateur de messagerie et des programmes d'agent de distribution adaptés. Une adresse de messagerie UUCP simple était formée à partir du nom de la machine adjacente, d'un point d'exclamation (souvent prononcé bang ), suivi du nom d'utilisateur sur la machine adjacente. Par exemple, l'adresse barbox!user ferait référence à l'utilisateur user sur la machine adjacente barbox .

Le courrier peut également être acheminé via le réseau, en passant par un nombre quelconque de nœuds intermédiaires avant d'arriver à destination. Au départ, cela devait être fait en spécifiant le chemin complet, avec une liste de noms d'hôtes intermédiaires séparés par des points d'exclamation. Par exemple, si la machine barbox n'est pas connectée à la machine locale, mais que l'on sait que barbox est connectée à la machine foovax qui communique avec la machine locale, l'adresse appropriée pour envoyer le courrier serait foovax!barbox!user .

L'utilisateur barbox!user publierait généralement son adresse e-mail UUCP sous une forme telle que …!bigsite!foovax!barbox!user . Cela incite les gens à acheminer leur courrier vers la machine bigsite (probablement une machine bien connue et bien connectée accessible à tous) et de là via la machine foovax vers le compte de l'utilisateur user sur barbox . Publier un chemin complet serait inutile, car il serait différent, selon l'endroit où se trouve l'expéditeur. (par exemple, Ann sur un site peut devoir envoyer via le chemin gway!tcol!canty!uoh!bigsite!foovax!barbox!user , tandis que depuis un autre site, Bill doit envoyer via le chemin pdp10!router22!bigsite!foovax!barbox!user ). De nombreux utilisateurs suggéreraient plusieurs itinéraires à partir de divers grands sites bien connus, offrant un service de connexion encore meilleur et peut-être plus rapide de la part de l'expéditeur du courrier.

Une adresse électronique de cette forme était connue sous le nom de chemin d'accès . Les chemins d'accès de huit à dix machines (ou sauts ) n'étaient pas rares en 1981, et les liaisons UUCP par ligne commutée tard dans la nuit pouvaient entraîner des délais de transmission d'une semaine. Les chemins d'accès étaient souvent sélectionnés à la fois en fonction du temps de transmission et de la fiabilité, car les messages se perdaient souvent. Certains hôtes allaient jusqu'à essayer de « réécrire » le chemin, en envoyant le courrier via des routes « plus rapides » - cette pratique avait tendance à être mal vue.

L'extension de pseudo-domaine .uucp était parfois utilisée pour désigner un nom d'hôte comme étant accessible par le réseau UUCP, bien que cela n'ait jamais été officiellement enregistré dans le système de noms de domaine (DNS) en tant que domaine de premier niveau . La communauté uucp s'administrait elle-même et ne s'accordait pas bien avec les méthodes d'administration et les réglementations régissant le DNS ; .uucp fonctionne là où il le faut ; certains hôtes envoient le courrier de la file d'attente SMTP vers les files d'attente uucp sur les machines de passerelle si une adresse .uucp est reconnue sur une connexion SMTP entrante.

À l'origine, le trafic Usenet était transmis via le protocole UUCP à l'aide de chemins de bang. Ceux-ci sont toujours utilisés dans les lignes d'en-tête de chemin de format de message Usenet . Ils n'ont désormais qu'un but informatif et ne sont pas utilisés pour le routage, bien qu'ils puissent être utilisés pour garantir l'absence de boucles.

En général, comme d'autres formats d'adresses électroniques plus anciens , les chemins d'accès ont désormais été remplacés par la notation « @ », même par les sites utilisant toujours UUCP. Un site exclusivement UUCP peut enregistrer un nom de domaine DNS et faire en sorte que le serveur DNS qui gère ce domaine fournisse des enregistrements MX qui permettent de transmettre le courrier Internet de ce site à un hôte UUCP sur Internet qui peut ensuite transmettre le courrier au site UUCP.

UUCPNET était le nom donné à l'ensemble du réseau d'ordinateurs connectés via UUCP. Ce réseau était très informel, maintenu dans un esprit de coopération mutuelle entre des systèmes appartenant à des milliers d'entreprises privées, d'universités, etc. Souvent, en particulier dans le secteur privé, les liaisons UUCP étaient établies sans l'approbation officielle de la haute direction des entreprises. Le réseau UUCP était en constante évolution, à mesure que de nouveaux systèmes et des liaisons par ligne commutée étaient ajoutés, d'autres étaient supprimés, etc.

Le projet de cartographie UUCP était un effort bénévole, largement couronné de succès, visant à établir une carte des connexions entre les machines qui étaient des relais de courrier électronique ouverts et à établir un espace de noms géré. Chaque administrateur système soumettait, par courrier électronique, une liste des systèmes auxquels le sien se connecterait, ainsi qu'un classement pour chaque connexion de ce type. Ces entrées de carte soumises étaient traitées par un programme automatique qui les combinait en un seul ensemble de fichiers décrivant toutes les connexions du réseau. Ces fichiers étaient ensuite publiés mensuellement dans un groupe de discussion dédié à cet effet. Les fichiers de carte UUCP pouvaient ensuite être utilisés par des logiciels tels que « pathalias » pour calculer le meilleur chemin d'accès d'une machine à une autre pour le courrier électronique, et pour fournir cet itinéraire automatiquement. Les cartes UUCP répertoriaient également les coordonnées des sites, ce qui permettait aux sites souhaitant rejoindre UUCPNET de trouver facilement des voisins potentiels.

De nombreux hôtes UUCP, notamment ceux des universités, étaient également connectés à Internet au cours de ses premières années, et des passerelles de courrier électronique entre le courrier SMTP Internet et le courrier UUCP ont été développées. Un utilisateur d'un système avec des connexions UUCP pouvait ainsi échanger du courrier avec des utilisateurs Internet, et les liens Internet pouvaient être utilisés pour contourner de grandes parties du réseau UUCP lent. Une « zone UUCP » a été définie dans l'espace de noms de domaine Internet pour faciliter ces interfaces.

Grâce à cette infrastructure, l'avantage de l'UUCP était qu'il permettait à un site d'accéder à la messagerie électronique et à la connectivité Usenet par le biais d'une simple liaison modem commutée vers un autre ordinateur coopérant. À l'époque, un véritable accès à Internet nécessitait une ligne de données louée fournissant une connexion à un point de présence Internet , deux services coûteux et difficiles à mettre en place. En revanche, une liaison vers le réseau UUCP pouvait généralement être établie en quelques appels téléphoniques aux administrateurs des systèmes voisins potentiels. Les systèmes voisins étaient souvent suffisamment proches pour éviter tous les frais, à l'exception des plus élémentaires, pour les appels téléphoniques.

uux est une exécution de commande à distance via UUCP. La commande uux est utilisée pour exécuter une commande sur un système distant ou pour exécuter une commande sur le système local à l'aide de fichiers provenant de systèmes distants. La commande est exécutée par le uucicodémon, qui gère les demandes d'exécution à distance comme un simple autre type de fichier à envoyer par lots au système distant chaque fois qu'un nœud de saut suivant est disponible. Le système distant exécutera alors la commande demandée et renverra le résultat, lorsque le système d'origine sera disponible. Ces deux transferts peuvent être indirects, via des chemins multi-sauts, avec des fenêtres de disponibilité arbitraires. Même lors de l'exécution d'une commande sur un voisin toujours disponible, uux n'est pas instantané.

L'utilisation du protocole UUCP a commencé à disparaître avec l'essor des fournisseurs de services Internet proposant des services SLIP et PPP bon marché . Le projet de cartographie UUCP a été officiellement arrêté fin 2000.

Le protocole UUCP a maintenant été en grande partie remplacé par les protocoles Internet TCP/IP SMTP pour le courrier électronique et NNTP pour les actualités Usenet.

En juillet 2012, le fournisseur d'accès Internet néerlandais XS4ALL a fermé son service UUCP, affirmant qu'il était « probablement l'un des derniers fournisseurs au monde à le proposer encore » ; il ne comptait alors que 13 utilisateurs (avant sa fermeture, il avait refusé les demandes de nouveaux utilisateurs pendant plusieurs années).

L'une des fonctionnalités survivantes d'UUCP est le format de fichier de discussion, largement hérité par le progiciel Expect .

L'UUCP a été utilisé sur des liaisons spéciales à coût élevé (par exemple, les liaisons par satellite maritimes) longtemps après sa disparition ailleurs, et reste toujours utilisé traditionnellement. En plus de l'utilisation traditionnelle, en 2021, de nouvelles utilisations innovantes de l'UUCP se développent, en particulier pour les télécommunications dans la bande HF , par exemple, pour les communautés de la forêt amazonienne pour l'échange de courriers électroniques et d'autres utilisations. Un correctif pour l'UUCP d'Ian a été apporté au paquet UUCP Debian Linux pour s'adapter au projet HERMES (High-Frequency Emergency and Rural Multimedia Exchange System), qui fournit une connectivité UUCP HF.

Au milieu des années 2000, UUCP sur TCP/IP (souvent crypté, en utilisant le protocole SSH ) a été proposé pour être utilisé lorsqu'un ordinateur n'a pas d' adresse IP fixe mais est toujours prêt à exécuter un agent de transfert de courrier standard (MTA) comme Sendmail ou Postfix .

Les chemins de type Bang sont toujours utilisés dans le réseau Usenet , mais pas pour le routage. Ils sont utilisés pour enregistrer, dans l'en-tête d'un message, les nœuds par lesquels ce message est passé, plutôt que pour indiquer où il ira ensuite. Le « chemin Bang » est également utilisé comme expression pour tout chemin de routage explicitement spécifié entre les hôtes du réseau. Cette utilisation ne se limite pas nécessairement à UUCP, au routage IP, à la messagerie électronique ou à Usenet.

Le concept de protocoles réseau tolérants aux retards a été revisité au début des années 2000. Des techniques similaires à celles utilisées par UUCP peuvent s'appliquer à d'autres réseaux qui subissent des retards ou des perturbations importantes.