Présentation

TailTalk est un toolkit open‑source qui propose une implémentation complète d’AppleTalk en espace utilisateur. Le projet, hébergé sur GitHub, cible Linux, macOS et Windows et repose exclusivement sur le langage Rust (version ≥ 1.90) et la bibliothèque d’exécution Tokio. Aucun composant du noyau (Netatalk, pilotes spécifiques) n’est requis ; la pile fonctionne avec un simple raw socket ou avec un dispositif TashTalk USB compatible LocalTalk.

Architecture et fonctionnement

La pile se compose de modules séparés pour chaque protocole AppleTalk majeur : AARP, DDP, NBP, ATP, PAP, ASP, AFP et ADSP. Chaque module expose une API fully async, ce qui permet d’écrire du code non bloquant tout en conservant la sémantique d’AppleTalk d’origine. Le sous‑système AARP/DDP peut être exécuté en processus unique (comportement par défaut) ou externalisé dans le démon tailtalkd. Ce démon possède les interfaces réseau, gère l’adressage et la table de routage, puis partage les sockets DDP via un protocole protobuf sur un socket Unix ou UDP, accessible depuis Rust (TalkStack::builder().daemon_unix(..)) ou depuis des clients C.

let stack = TalkStack::builder()
    .daemon_unix("/tmp/tailtalkd.sock")
    .build();

Le projet inclut également une interface graphique (tailtalk-gui) qui intègre un serveur AFP, la prise en charge des archives Stuff‑It et des images de disquettes, ainsi que la conversion de périphériques LocalTalk (LaserWriter, ImageWriter, StyleWriter) en imprimantes AirPrint/IPP modernes.

Analyse des performances et limites

Le choix de Rust garantit l’absence de fuites de mémoire et une exécution proche du natif, tandis que Tokio fournit un modèle d’E/S non bloquant optimisé pour les environnements multi‑cœurs. Cependant, la pile fonctionne actuellement uniquement en mode « routerless », c’est‑à‑dire sans prise en charge du routage entre plusieurs segments AppleTalk. Le développeur indique que l’ajout d’un routage complet est en cours de développement mais n’est pas encore intégré à la branche principale. De plus, la dépendance à un dispositif TashTalk USB impose l’utilisation d’un pont CP210x (VID 0x10c4, PID 0xea60) sous Linux, nécessitant le module cp210x du noyau, et sous Windows requiert le SDK npcap (version 1.13) pour accéder aux paquets bruts.

Le processus de construction repose sur cargo build --release puis sur cargo packager pour générer des paquets natifs : AppImage sous Linux, bundles macOS et installateurs NSIS sous Windows. Cette chaîne d’outils assure une distribution cohérente mais implique que les utilisateurs doivent disposer de cargo‑packager installé au préalable.

Perspectives d’évolution

Les contributeurs envisagent d’ajouter le support du routage multi‑segment, ce qui élargirait l’usage de TailTalk aux réseaux AppleTalk plus complexes. L’intégration d’un mode « daemon‑client » plus générique pourrait également permettre à des applications tierces (par exemple des émulateurs ou des outils de sauvegarde) de partager la même instance de pile, réduisant ainsi la consommation de ressources. Enfin, la migration vers des API plus récentes de Tokio (par ex. les timers basés sur le système d’exploitation) pourrait améliorer la latence des protocoles transactionnels comme ATP.