E - Kermit — Kermit pour l'intégration

Source: https://kermitproject.org/ek.html

Annonce Open Source : à compter du 30 mars 2011, avec la version 1.6, E-Kermit est publié « tel quel » sous la licence BSD révisée à 3 clauses .

E-Kermit 1.8 du 26 mai 2021 corrige un bug dans la version démo Unix où les arguments de ligne de commande -B et -T (pour forcer respectivement les modes de transfert de fichiers Binaire et Texte) étaient inversés. Merci à Todd Markley de l'avoir signalé.

27 mai 2021 : tous les liens FTP de cette page ont été convertis en HTTP/HTTPS car Chrome et Firefox et qui sait quoi d'autres navigateurs ne les prennent plus en charge ; détails ici .

EK (Embedded Kermit, E-Kermit) est une implémentation du protocole de transfert de fichiers Kermit écrit en ANSI C et conçu pour être intégré dans des appareils ou des micrologiciels, pour une utilisation dans des applications en temps réel ou pour la construction de DLL et de bibliothèques. EKSW est une nouvelle version d'E-Kermit qui inclut un véritable transport de paquets par fenêtres coulissantes. EK et EKSW devraient être réconciliés en une seule base de code, mais jusqu'à présent, cela n'a pas été le cas.

Ce que fait E-Kermit

EK ne remplit que deux fonctions : envoyer des fichiers et recevoir des fichiers. Il est compact, portable et entièrement rentrant. Sur SPARC (RISC), kermit.o est d'environ 25K. Sur Intel (CISC), c'est environ 15K. En réduisant la taille des tampons et en éliminant les fonctionnalités facultatives ou indésirables, des tailles plus petites peuvent être obtenues.

Ce qu'E-Kermit ne fait PAS

EK n'inclut pas les fonctions client/serveur ; un langage de programmation de commandes ou de scripts ; conversion de jeux de caractères ; cryptage des transports ; ou toute forme de communication ou d’entrée/sortie de fichier. Il ne compose pas de modems, n'établit pas de connexions, n'a pas de pile TCP/IP intégrée ni d'interface avec une pile externe. Si vous avez besoin de ces fonctionnalités, vous devez utiliser un programme Kermit complet, tel que C-Kermit ou Kermit 95 .

EK n'est pas une application en soi, c'est un sous-programme à appeler depuis votre application principale. Il n'est utile qu'aux développeurs, qui doivent fournir l'application principale ou l'environnement d'appel ainsi que les routines d'E/S de fichiers et de communications. L'environnement appelant doit, à son tour, établir et configurer la connexion de communication si une connexion est requise et n'est pas déjà ouverte. Un exemple d'environnement d'appel et de prise en charge des E/S sont fournis pour Unix.

Les clients ont adapté EK à divers environnements et plates-formes, y compris le Palm Pilot, divers types d'équipements techniques (par exemple pour le diagnostic et la maintenance des tours de téléphonie cellulaire), et parfois ils apportent leurs adaptations ou routines d'E/S, et nous pouvons les mettre à disposition. strictement tel quel. Nous ne sommes pas en mesure de prendre en charge ou de maintenir le code fourni par le client ; ainsi (par exemple) si une nouvelle version d'EK est publiée, les modules fournis par le client ne sont pas nécessairement mis à jour. Le code fourni par le client comprend :

Port série et E/S de fichiers Microsoft Windows 9x/ME/NT/2000/XP/Vista/7 pour EK 1.3 et versions ultérieures.
Wind River VxWorks pour EK 1.1.
EK 1.2 traduit en Java .

EK inclut les fonctionnalités suivantes du protocole Kermit :

Paquets longs
Fenêtres coulissantes avec récupération d'erreur Go-Back-to- N (véritable répétition sélective dans EKSW).
Compression par comptage répété
Préfixage et dépréfixage des caractères de contrôle
Préfixe 8 bits (pour transférer des données 8 bits sur des liaisons 7 bits) (= parité)
Paquets d'attributs (type, taille et date)
Envoi et réception de fichiers uniques ou multiples.
Commutation automatique du mode texte/binaire par fichier.
Les trois types de contrôle de bloc (somme de contrôle 6 et 12 bits, CRC 16 bits).
Rapports d'état (état du protocole, nom du fichier, taille, horodatage, octets jusqu'à présent).
Annulation du transfert par l'une ou l'autre des parties.

Les fonctionnalités suivantes du protocole Kermit ne sont pas implémentées :

Fenêtres coulissantes à retransmission sélective (sauf en EKSW)
Jeux de caractères
Verrouillage des quarts de travail
Serveur client

Les délais d'attente relèveraient de la responsabilité du programme Kermit à l'autre extrémité de la connexion ou, si nécessaire dans E-Kermit lui-même, de la routine de lecture de paquets dépendante de la plate-forme que vous écririez.

Depuis la version 1.5, E-Kermit inclut des constructions de préprocesseur pour vous permettre d'exclure diverses fonctionnalités telles que les paquets longs, les fenêtres glissantes et les vérifications de blocs d'ordre supérieur afin d'obtenir la plus petite empreinte mémoire possible, et peut également être construit dans une configuration de réception uniquement. .

LE PROGRAMME DE CONTRÔLE

EK est conçu pour fonctionner dans un environnement multitâche coopératif mais ne nécessite pas un tel environnement. Le programme de contrôle s'occupe de la planification. Voici ce que le programme de contrôle doit (et/ou peut) faire :

Si vous le souhaitez, ouvrez le périphérique de communication, le cas échéant.
Si vous le souhaitez, mettez le périphérique de communication, le cas échéant, en « mode paquet ».
Initialisez la structure kermit avec les paramètres de fonctionnement souhaités.
Appel kermit(K_INIT, ...) pour que Kermit s'initialise.
Si vous envoyez des fichiers, appelez kermit(K_SEND) pour démarrer le transfert.

(Lorsque E-Kermit doit recevoir des fichiers, il attend passivement le premier paquet de l'expéditeur du fichier ; il entre donc simplement dans la boucle de paquets.) Dans la boucle de paquets, E-Kermit :

Obtient un tampon et y lit un paquet entrant.
Vérifie l’interruption de l’utilisateur.
Appels kermit(K_RUN, ...) pour passer à l'étape suivante du protocole.
Fait ce qu'il veut (par exemple, exécute d'autres tâches).
Quitte ou continue la boucle en fonction du Kermit() Code de retour.

Chaque fois que le programme de contrôle appelle le Kermit() fonction, cela lui accorde la permission de gérer un paquet ; donc un paquet = une tranche de temps. Si le programme de contrôle n'a rien d'autre à faire, il traite simplement les paquets en continu, comme un programme Kermit classique. Dans la boucle de transfert de données, chaque Kermit() call renvoie une structure contenant :

L'état actuel du protocole ;
Le nom de fichier actuel ;
La taille du fichier, si elle est connue, ou -1 ;
L'horodatage du fichier, s'il est connu ;
Le nombre d'octets transférés jusqu'à présent.

Une fois terminé, le programme de contrôle :

Restaure et (si vous le souhaitez) ferme le périphérique de communication.

Les codes fonctions que le programme de contrôle peut appeler Kermit() avec sont :

K_INIT-- Initialisez les structures de données.

K_ENVOYER -- (Envoi uniquement) -- Lancez l'envoi.

K_RUN-- Exécutez le protocole.

K_STATUT-- Renvoie un rapport d'état dans la structure k_response.

K_QUIT -- Arrêtez immédiatement et silencieusement.

K_ERREUR -- Envoyez le paquet d'erreur, puis quittez.

Les codes retour du Kermit() fonction sont :

X_OK -- OK, protocole actif.

X_FAIT -- OK, protocole terminé.

X_ERREUR -- Erreur fatale.

X_STATUS -- Renvoi du statut en réponse à K_STATUS.

(En fait, l'état est réajusté à chaque appel.) Les codes d'état du protocole sont :

-1 -- Erreur fatale

0 -- Récepteur (protocole non exécuté)

1 -- Récepteur en attente du paquet S

2 -- Récepteur en attente d'un paquet F ou B

3 -- Récepteur en attente d'un paquet A ou D

4 -- Récepteur en attente du paquet D ou Z

dix -- Expéditeur (protocole non exécuté)

11 -- L'expéditeur a envoyé le paquet S (début)

12 -- L'expéditeur a envoyé un paquet F (nom de fichier)

13 -- L'expéditeur a envoyé un paquet (attributs)

14 -- L'expéditeur a envoyé le paquet D (données)

15 -- L'expéditeur a envoyé un paquet Z (EOF)

16 -- L'expéditeur a envoyé le paquet B (EOT)

TRANSFERT DE FICHIER

Étant donné que EK est conçu principalement pour l'intégration, il n'utilise pas de streaming ni (sauf dans EKSW) de véritables fenêtres coulissantes (bien qu'une grande partie du code des fenêtres coulissantes soit là). Ceci pour les raisons suivantes :

L'utilisation du protocole ACK/NAK standard permet au programme de contrôle de reprendre le contrôle après chaque paquet. Cela lui permet d'effectuer plusieurs tâches à la fois, d'afficher un affichage graphique de transfert de fichiers, etc. Des fenêtres en continu ou glissantes pourraient mettre le programme de contrôle hors service pendant de longues périodes.
Des flux ou de véritables fenêtres coulissantes feraient l'interface entre le programme de contrôle et le Kermit() module beaucoup plus compliqué et, en fait, pousserait de nombreux détails du protocole dans l'espace du programme de contrôle, où ils n'ont pas leur place.
Le streaming ne peut être utilisé que sur des connexions fiables (telles que TCP/IP), mais les appareils dotés de communications intégrées utilisent généralement des ports série.

Le manque de véritables fenêtres coulissantes dans EK est compensé par le fait que EK prétend les soutenir sans vraiment le faire. Cela permet à son partenaire expéditeur de « diffuser » les paquets plutôt que d'attendre des ACK après chacun, tant qu'il n'y a pas d'erreur. S'il y a une erreur, la stratégie de récupération consiste à "revenir à n " (ou peut-être dans certains cas "erreur") plutôt qu'à "répéter sélectivement". EKSW, un programme distinct qui n'a pas été intégré à EK (mais devrait l'être), prend en charge les véritables fenêtres coulissantes avec répétition sélective ; c'est-à-dire que seuls les paquets qui doivent réellement l'être sont retransmis.

Quoi qu'il en soit, puisque EK est principalement destiné à l'intégration, il est prévu que les retards aller-retour ne seront pas un facteur important ; les connexions seront généralement locales, courtes, relativement rapides et, si la connexion est efficacement contrôlée en flux, sans erreur. Lorsqu'un contrôle de flux efficace fait défaut, la vitesse et/ou la longueur des paquets et/ou la taille de la fenêtre peuvent être définies sur une combinaison de valeurs qui maximise le débit et minimise la perte de données.

CODE SOURCE

Les fichiers sources sont :

plateforme.h

Fichier d'en-tête pour tous les #includes ou définitions spécifiques à la plate-forme nécessaires. Obligatoire, même s'il est vide, car kermit.c l'inclut.

kermit.h

Fichier d'en-tête pour tous les modules. Définition de k_données et k_réponse structures.

kermit.c

Il s'agit du moteur de protocole Kermit. Il est entièrement piloté par ses données d’appel. Toutes les informations d'état sont enregistrées dans la structure de données Kermit, qui est transmise par référence depuis le module principal et parmi toutes les fonctions du module Kermit et de nouveau vers le module principal ; il devrait donc être possible pour le même module de transférer plusieurs fichiers à la fois sur différentes connexions. De plus, il n'y a aucune référence de bibliothèque dans le module kermit, aucune, pas même stdio (sauf lorsque le débogage est activé), et aucune /usr/inclure/* les fichiers d'en-tête sont inclus. Règles pour kermit.c :

Pas de variables globales (sauf pour le débogage) ni de tampons.
Pas d'initialisation des tableaux par le compilateur.
Juste pour des raisons de sécurité, pas non plus d'initialisation de scalaires automatiques.
Pas d'appels de bibliothèque ou de système, non #inclure <...> .
Toutes les communications E/S sont effectuées par des fonctions définies dans des modules séparés.

Le point d'entrée unique pour le kermit.c le module est le Kermit() fonction:

int kermit(struct k_data * k, struct k_response * r)

La structure k contient tous les paramètres de fonctionnement, variables, informations d'état et tampons ; la structure r tient l'appelant informé de l'état actuel du protocole, du nom et des informations du fichier, ainsi que de la progression du transfert (octets jusqu'à présent).

principal c

Exemple de programme de contrôle. Dans le banc d'essai Unix, il s'agit simplement du traditionnel principal() , qui lit les arguments de ligne de commande, initialise le protocole, puis appelle le module de protocole dans une boucle pilotée par l'état jusqu'à ce que son travail soit terminé, puis nettoie. Dans l'environnement embarqué, ces fonctions seraient intégrées au programme de contrôle.

unixio.c

Fonctions d'E/S pour Unix. Remplacez votre propre module qui implémente ces fonctions dans l'environnement cible et modifiez votre procédure de construction pour établir un lien avec elle. Points d'entrée et conventions d'appel décrits ci-dessous.

LA VERSION UNIX

Le développement d'EK s'effectue sur une plate-forme Unix conventionnelle, telle que Mac OS, AIX, Solaris, HP-UX, ... ou, de nos jours, plus probablement sur une variété de BSD ou Linux, dans laquelle EK est construit comme un Kermit en mode distant. programme de transfert de fichiers, similaire à G-Kermit, et testé par rapport à un Kermit de bureau tel que K95 ou C-Kermit. REMARQUE : La version Unix fonctionne sur stdin/stdout ; la "ligne" est conditionnée de la manière la plus stupide possible ( système("stty...") ). Cela donne des résultats variables ; Par exemple, les téléchargements depuis EK sur Solaris peuvent fonctionner à 17 Kcps, tandis que les téléchargements depuis Linux sur le même réseau vers le même PC peuvent fonctionner à 1 700 Kcps. Cela ne vaut pas la peine de s'inquiéter car EK n'est pas destiné à une utilisation en production sous Unix, qui dispose déjà de G-Kermit et C-Kermit pour la production.

Le makefile Unix a les cibles suivantes (il est facile d'en ajouter d'autres) :

gcc : Construire avec gcc (par défaut).

cc : Construisez avec cc.

ch : Conçu pour HP-UX.

gccnd : Construisez avec gcc, pas de débogage.

gprof : Construisez avec gcc, incluez le profilage.

faire le ménage: Supprimez les fichiers d'objet et de base.

Le makefile crée un exécutable Unix appelé "ek" (kermit intégré). L'échantillon principal() routine fournit une interface de ligne de commande simple :

$ ./ek -h

Utilisation : options ./ek

Possibilités :

-r Recevoir des fichiers

-s fichiers Envoyer des fichiers

-p [neoms] Parité : aucune, paire, impaire, marque, espace

-b [123] Type de vérification de bloc : 1, 2 ou 3 (par défaut = 3)

-k Conserver les fichiers reçus de manière incomplète

-B Forcer le mode binaire

-T Forcer le mode texte

-R Mode distant (vs local)

-L Mode local (vs distant)-Numéro

E Taux d'erreur simulé (0-100)

-d Créer un fichier debug.log

-h Aide (ce message)

Lors de l'envoi de fichiers, si vous ne spécifiez pas Texte ou Binaire, EK analyse chaque fichier et choisit le mode texte ou binaire en fonction de son contenu.

Le mode Remote vs Local est utilisé uniquement pour activer le test d'interruption du clavier lors du transfert de fichiers.

PORTAGE SUR UNE NOUVELLE PLATEFORME

La version 1.0 d'EK a été portée sur VxWorks par Airvana, Inc, Chelmsford MA. Le package complet VxWorks EK 1.1 est inclus comme exemple de système de production avec la permission d'Airvana (notez que l'API EK a légèrement changé depuis lors, donc avant que le code VxWorks puisse être utilisé, il doit être mis à jour). Pour effectuer un portage sur une nouvelle plateforme :

Ajoutez une nouvelle entrée Makefile pour votre cible ou écrivez votre propre procédure de construction.
Créer un plateforme.h fichier pour votre plateforme. Cela peut inclure n'importe quel #include ou définition souhaité, et il peut également être utilisé pour remplacer certaines définitions dans kermit.h :
#définir NODEBUG pour construire sans déboguer le code.
#définir HAVE_UCHAR si UCHAR est déjà défini ou typedef 'd à un caractère non signé.
#définir HAVE_ULONG si ULONG est déjà défini ou typedef 'd à non signé longtemps.
#définir IBUFLEN être la taille souhaitée pour le tampon d’entrée du fichier.
#définir OBUFLEN être la taille souhaitée pour le tampon de sortie du fichier.
#définir FN_MAX être la longueur maximale d'un nom de fichier.
#définir P_PKTLEN pour remplacer la longueur maximale par défaut des paquets.
#définir P_WSLOTS pour remplacer le nombre maximal d'emplacements de fenêtre par défaut.
Remplacer l'échantillon principal c avec votre propre programme de contrôle. Utilisez les mêmes fichiers d’en-tête et conventions d’appel que dans l’exemple.
Copie unixio.c àxxx io.c (nom de votre choix), modifiez-le pour qu'il fonctionne sur votre plateforme en utilisant exactement les mêmes conventions d'appel, et ajustez votre procédure de build pour qu'elle soit liée à votre nouveauxxx io module au lieu de Unixio . Notez que les tampons d'entrée et de sortie de remplissage ( je_buf[] et o_buf[] ) doit être défini dans votrexxx io routine.

Voici quelques conseils pour créer un module d'E/S :

Les routines d'E/S du périphérique sont censées gérer elles-mêmes les paramètres de communication, notamment la vitesse de la ligne de communication, la parité et le contrôle de flux. Kermit ne s'occupe notamment pas de la parité, mais il faut quand même en être informé. Cela se fait dans la configuration par principal() . Ton readpkt() et tx_data() les routines doivent respectivement supprimer et ajouter la parité, si nécessaire. Sur les connexions série, l'UART peut peut-être être programmé pour ce faire.

Changement d'API entre EK 1.1 et 1.2 : les conventions d'appel (listes d'arguments de fonction et valeurs de retour) ont été modifiées entre la version 1.1 et 1.2, principalement pour donner à toutes les routines un accès cohérent à la structure k , et également pour fournir un meilleur retour à l'appelant. . Dans chaque cas où une modification a été effectuée, l'ancien et le nouveau format sont affichés.

Les fonctions d'E/S de l'appareil sont :

int

devopen (char * périphérique)

Ouvre le périphérique de communication donné. Peut-être aussi un hôte réseau, peu importe. Renvoie 0 en cas d'échec, 1 en cas de succès.

int

devsettings (paramètres char *)

Celui-ci effectue tous les paramètres nécessaires pour l'appareil, tels que le contrôle de la vitesse et du débit pour un périphérique série. Puisqu'il n'y a aucun moyen de savoir quels sont les paramètres pertinents, cette routine prend simplement une chaîne, qui peut être dans n'importe quel format, par exemple " 9600;8N1 " ou " vitesse = 57 600 ; débit = rts/cts " ; la routine devsettings devra analyser la chaîne. Renvoie 0 en cas d'échec, 1 en cas de succès.

int

devrestore (vide)

Si vous le souhaitez, remettez l'appareil dans le sens paramètres de développement() je l'ai trouvé, par exemple juste avant de le fermer.

int

devclose (vide)

Ferme le périphérique de communication.

int

readpkt (UCHAR * tampon, struct k_data * k) (1.1)

readpkt (struct k_data * k, UCHAR * tampon, longueur int) (1.2)

Cette routine doit faire exactement ce que fait l'exemple : rechercher le début du paquet, puis copier tous les caractères jusqu'à (mais sans inclure) la fin du paquet dans le tampon de paquet dont l'adresse est donnée. Vous souhaiterez coder cela aussi efficacement que possible, en utilisant toutes les astuces à votre disposition : lectures tamponnées non bloquantes, etc. Si vous souhaitez que votre programme Kermit expire, c'est ici que vous placerez le code. REMARQUE : les délais d'attente ne sont pas nécessaires, car les chances que le partenaire Kermit de ek ne puisse pas expirer sont d'environ 0. Le format EK 1.2 place k comme premier argument pour la cohérence avec les autres routines et ajoute un argument de longueur de tampon.

Notez la fonctionnalité F_CTRLC. C'est activé par défault. Il permet à EK de sortir du mode paquet en lui envoyant trois Ctrl-C consécutifs dans le flux de données. Vous n'auriez normalement pas besoin de désactiver cela car, même si l'expéditeur "dépréfixe" Ctrl-C, trois d'entre eux d'affilée seraient normalement réduits en une séquence de comptage répété.

int

tx_data (UCHAR * données, longueur int, parité courte) (1.1)

tx_data(struct k_data * k, UCHAR * données, longueur int) (1.2)

Là encore, il faudra miser sur la parité (si elle n'est pas effectuée automatiquement par le périphérique de communication ou le driver). Cette routine doit être à la fois efficace et robuste. Il est censé transmettre la totalité de la chaîne de données, sinon il échoue. Voir le unixio.c échantillon pour ce que j'entends par "robuste". Dans EK 1.2 et versions ultérieures, le paramètre de parité est récupéré de la structure k .

Les fonctions d'entrée/sortie de fichier sont les suivantes : bien sûr, ils peuvent être utilisés pour lire ou écrire n'importe quoi, pas seulement des fichiers : mémoire, bande, cartes, faisceaux laser, contrôleurs d'instruments, etc. Peu importe comment vous appelez ces routines, mais la liste d'arguments et le type de retour doivent être tels qu'indiqués ; aussi si vous leur donnez des noms différents, vous devrez changer les prototypes dans kermit.h :

int

openfile (UCHAR * nom de fichier, mode int, struct k_date * k) (1.1)

openfile(struct k_date * k, UCHAR * nom de fichier, mode int) (1.2)

Ouvre le fichier nommé dans le mode donné (1 = lecture, 2 = écriture, 3 = ajout). Renvoie X_OK en cas de succès, X_ERROR en cas d'échec.

ULONG

fileinfo (UCHAR * nom de fichier, UCHAR * buf, int buflen, short * type, mode court) (1.1)

fileinfo(struct k_data * k,UCHAR * nom de fichier,UCHAR * buf,int buflen,short * type,mode court) (1.2)

Obtient des informations sur le fichier local existant spécifié : taille, date et, si mode == 0, le type de fichier (texte ou binaire). buf et buflen s'appliquent à la chaîne date/heure du fichier. Renvoie X_OK ou X_ERROR.

int

readfile(struct k_data *)

Lit un tampon à partir du fichier d'entrée et, si le transfert est en mode texte, convertit le format d'enregistrement au format Kermit Stream CRLF standard. Renvoie X_OK ou X_ERROR.

int

writefile (struct k_data *, CHAR * tampon, longueur int)

Écrit un tampon dans le fichier de sortie et, si le transfert est en mode texte, convertit également le format d'enregistrement standard Kermit Stream CRLF en ce qui est requis localement. Renvoie X_OK ou X_ERROR.

int

closefile(struct k_data *, code UCHAR, mode int)

Ferme le fichier. Pour les fichiers de sortie, bien sûr, cela vide tous les tampons en attente dans le fichier avant de le fermer ; puis il vérifie si le Kermit expéditeur a annulé le transfert de fichier avant qu'il ne soit terminé (code == 'D'), auquel cas il supprime le fichier partiel au lieu de le conserver. Le mode indique s'il s'agit d'un fichier d'entrée ou de sortie, donc les fichiers incomplètement reçus peuvent être supprimés si vous le souhaitez. Renvoie X_OK ou X_ERROR.

Les conventions d'appel précises sont indiquées dans le unixio.c déposer.

DÉBOGAGE

Si EK a été construit sans que NODEBUG soit défini, alors si vous incluez le -d sur la ligne de commande, l'exemple de version Unix d'EK crée un journal de débogage fichier dans son répertoire courant. Dans la version de production, vous ajouteriez -DNODEBUG au compilateur C CFLAGS pour éliminer le code de débogage. Les tailles indiquées ci-dessus incluent le débogage. Vous pouvez implémenter la fonction de débogage comme vous le souhaitez dans le module d'E/S spécifique à votre plate-forme.

HISTORIQUE DES VERSION

Version	Date	Description
1.1	2002/10/07	Première version. Version VxWorks toujours à ce niveau.
1.2	2003/01/28	API améliorée, port Java (qui est encore à ce niveau).
1.3	2004/03/04	Correction du transfert de fichiers avec HyperTerminal.
1.4	2004/03/20	Correction de la réception de fichiers vides.
1,5	2004/04/10	Résoudre le problème avec les paquets A, autoriser des configurations très petites et/ou de réception uniquement.
1,51	2004/09/23	S'adapter à Philips XAG30 (John Dunlap)
EKSW 0.94	2010/06/24	Véritables fenêtres coulissantes à retransmission sélective ( John Dunlap )
1.6	30/03/2011	Publié et publié sous la licence BSD révisée à 3 clauses .
1.7	06/06/2011	Protocole FORCE-3, fonctionne avec C-Kermit 9.0 (expliqué ici )
1.8	2021/06/26	Correction d'un problème avec les arguments de ligne de commande -B et -T (démo Unix uniquement)

TÉLÉCHARGER

Plusieurs implémentations E-Kermit différentes sont disponibles en téléchargement. E-Kermit lui-même, version 1.8, est la version principale. La version 1.7 reste disponible. Les autres sont des adaptations à différentes plates-formes ou langages qui ont été réalisées lors de versions antérieures d'E-Kermit, comme indiqué dans la section précédente ; en d'autres termes, les correctifs trouvés dans E-Kermit 1.3, 1.4 et 1.5 ne figurent pas dans les versions VxWorks ou Java, et la version VxWorks utilise l'API E-Kermit 1.1 au lieu de la version 1.2 améliorée. EKSW présente quelques modifications à l'API et d'autres incohérences qui doivent être annulées avant de pouvoir être intégré à EK 1.6, mais est parfaitement utilisable seul. En fait, il s'agit de la version utilisée dans la nouvelle génération de flotteurs océaniques Apex-EM.et a été testé de manière plus approfondie dans des conditions plus défavorables que toute autre implémentation de protocole Kermit. Donnant naissance à la version 1.7, qui implémente le nouveau protocole de paquet de vérification d'erreurs Force-3 . (EKSW devrait également l'obtenir à un moment donné.)

Nom	Description	Goudron *	Fermeture éclair	Fichiers source
E-Kermit 1.8	Portable sur toutes les plateformes, avec démo Unix.	Télécharger	Télécharger	Télécharger
E-Kermit 1.7	Portable sur toutes les plateformes, avec démo Unix.	Télécharger	Télécharger	Télécharger
EKSW 0.94	E-Kermit avec de véritables fenêtres coulissantes, adapté à Linux.	Télécharger	Télécharger	Télécharger
EKVX 1.1	E-Kermit 1.1 adapté à VxWorks.	Télécharger	Télécharger	Télécharger
Java	E-Kermit 1.2 converti en Java	Télécharger	Télécharger	Télécharger
simiride	Testeur de stress du protocole Kermit [ description ]	Télécharger	Télécharger	Télécharger

* Non compressés, pas besoin, ils sont très petits.