---

---

Kompakt, rask, robust, bærbar Kermit-filoverføringskildekode for å bygge inn i enheter eller C-programmer. (Versjon: 1.8. Dato: 27.mai 2021)

Åpen kildekode-kunngjøring: Med virkning fra 30. mars 2011 med versjon 1.6, er E-Kermit utgitt «som den er» under den «reviderte 3-klausulen BSD-lisensen.»

Hva E-Kermit gjør:

EK utfører bare to funksjoner: sende filer og motta filer. Den er kompakt, bærbar og fullstendig gjeninntrengende. På SPARC (RISC) er kermit.o omtrent 25K. På Intel (CISC) er det omtrent 15K. Ved å redusere bufferstørrelser og eliminere valgfrie eller uønskede funksjoner, kan mindre størrelser oppnås.

Hva E-Kermit IKKE gjør:

EK inkluderer ikke klient/server-funksjoner; et kommando- eller skriptprogrammeringsspråk; tegnsett konvertering; transport kryptering; eller noen form for kommunikasjon eller filinndata/utdata. Den ringer ikke til modemer, den oppretter ikke tilkoblinger, den har ikke en innebygd TCP/IP-stakk eller grensesnitt til ekstern bruk. Hvis du trenger disse funksjonene, bør du bruke et fullstendig Kermit-program, for eksempel C-Kermit eller Kermit 95. (link til original engelsk side)

EK er ikke en applikasjon i seg selv, det er en subrutine som skal fungere under hovedapplikasjonen din. Den er bare nyttig for utviklere, som må levere hovedapplikasjonen eller anropsmiljøet samt filen og kommunikasjon i/o rutiner. Det anropende miljøet må på sin side opprette og konfigurere kommunikasjonsforbindelsen hvis det er behov for en og den ikke allerede er åpen. Et eksempel på ringemiljø og i/o-støtte er gitt for Unix.

Kunder har tilpasset EK til ulike miljøer og plattformer, inkludert Palm Pilot, ulike typer teknikerutstyr (f.eks. for diagnose og vedlikehold av mobiltelefontårn), og noen ganger bidrar de med sine tilpasninger eller i/o-rutiner, og vi kan gjøre disse tilgjengelige strengt tatt som de er. Vi er ikke i stand til å støtte eller vedlikeholde kundebidragskode; dermed (for eksempel) hvis en ny versjon av EK slippes, blir ikke kundebidragsmoduler nødvendigvis oppdatert. Kundebidragskode inkluderer:

• Microsoft Windows 9x/ME/NT/2000/XP/Vista/7 seriell-port og fil-i/o for EK 1.3 og nyere.

• Wind River VxWorks for EK 1.1.

• EK 1.2 oversatt til Java.

EK inkluderer følgende Kermit Protocol-funksjoner:

• Lange pakker

• Skyvevinduer med Go-Back-to-N feilgjenoppretting (ekte selektiv repetisjon i EKSW)

• Gjenta-teller-komprimering

• Prefiksering og oppheving av kontrolltegn

• 8.-bits prefiks (for overføring av 8-bits data på 7-bits lenker) (= parity)

• Attributtpakker (type, størrelse og dato)

• Sende og motta enkelt eller flere filer

• Automatisk bytte av tekst/binær modus bytte

• Alle tre blokksjekktypene (6- og 12-biters checksum, 16-biters CRC).

• Statusrapporter (protokollstatus, filnavn, størrelse, tidsstempel, byte så langt).

• Kansellering av overføring av begge parter.

Følgende Kermit Protocol-funksjoner er ikke implementert:

• Skyvevinduer med selektiv omsending (unntatt i EKSW)

• Tegnsett

• Låse skift

• Klient / server

Tidsavbrudd vil være ansvaret til Kermit-programmet i den andre enden av forbindelsen eller, om nødvendig i E-Kermit selv, den plattformavhengige pakkeleserutinen som du vil skrive.

Fra og med versjon 1.5 inkluderer E-Kermit forprosessorkonstruksjoner som lar deg ekskludere ulike funksjoner som lange pakker, skyvevinduer og blokksjekker av høyere orden for å oppnå minst mulig minneavtrykk, og kan også bygges i en «kun-mottak-konfigurasjon»

---

KONTROLLPROGRAMMET

EK er designet for å fungere i et samarbeidende multitasking-miljø, men krever ikke et slikt miljø. Kontrollprogrammet tar seg av planlegging. Her er hva kontrollprogrammet må (og/eller kan) gjøre:

• Hvis ønskelig, åpne kommunikasjonsenheten, hvis noen.

• Hvis ønskelig, sett kommunikasjonsenheten, hvis noen, i «pakkemodus».

• Initialiser kermit-strukturen med ønskede driftsparametere.

• Ring kermit(K_INIT, …) for å få Kermit til å initialisere seg selv.

• Hvis du sender filer, ring kermit(K_SEND) for å starte overføringen.

(Når E-Kermit skal motta filer, venter den passivt på første pakke fra filavsenderen; dermed går den ganske enkelt inn i pakkeløkken.) I pakkeløkken, vil E-Kermit:

• Hente en buffer og leser en innkommende pakke inn i den.

• Sjekke for brukeravbrudd.

• Kalle kermit(K_RUN, …) for å gjøre neste trinn i protokollen.

• Gjøre hva den vil (f.eks. kjører andre oppgaver).

• Avslutte eller fortsette løkken basert på kermit()-returkoden.

Hver gang kontrollprogrammet kaller kermit()-funksjonen, gir dette tillatelse til å håndtere én pakke; dermed én pakke = én gang skive. Hvis kontrollprogrammet ikke har noe annet å gjøre, behandler det ganske enkelt pakker kontinuerlig, som et vanlig Kermit-program. Mens du er i dataoverføringsløkken, returnerer hvert kermit()-kall en struktur som inneholder:

• Gjeldende protokolltilstand;

• Gjeldende filnavn;

• Filstørrelsen, hvis kjent, eller -1;

• Filens tidsstempel, hvis kjent;

• Antall byte som er overført så langt.

Når det er gjort, vil kontrollprogrammet:

• Gjenoppretter og (om ønskelig) lukker kommunikasjonsenheten.

Funksjonskodene som kontrollprogrammet kan kalle kermit () med er:

K_INIT — Initialiser datastrukturer.

K_SEND — (Kun sending) — Start sending.

K_RUN — Kjør protokollen.

K_STATUS — Returner en statusrapport i k_response-strukturen.

K_QUIT — Avslutt umiddelbart og stille.

K_ERROR — Send feilpakke, og avslutt.

Returkodene til kermit()-funksjonen er:

X_OK — OK, protokollen er aktiv.

X_DONE — OK, protokollen er fullført.

X_ERROR — Fatal feil.

X_STATUS — Returnerer status som svar på K_STATUS.

(Faktisk stilles statusen inn på nytt ved hver samtale.) Protokolltilstandskoder er:

-1 — Fatal feil

0 — Mottaker (protokoll kjører ikke)

1 — Mottaker venter på S-pakke

2 — Mottaker venter på F- eller B-pakke

3 — Mottaker venter på A- eller D-pakke

4 — Mottaker venter på D- eller Z-pakke

10 — Avsender (protokoll kjører ikke)

11 — Avsender sendte S-pakke (start)

12 — Avsender sendte F-pakke (filnavn)

13 — Avsender sendte en pakke (attributter)

14 — Avsender sendte D-pakke (data)

15 – Avsender sendte Z-pakke (EOF)

16 – Avsender sendte B-pakke (EOT)

---

FILOVERFØRING

Fordi EK er designet primært for innebygging, bruker den ikke strømming eller (unntatt i EKSW) ekte skyvevinduer (selv om mye av skyvevinduskoden er der). Dette er av følgende grunner:

• Ved å bruke den vanlige ACK/NAK-protokollen kan kontrollprogrammet gjenvinne kontrollen etter hver pakke. Dette lar den multitaske, sette opp en grafisk filoverføringsskjerm, uansett. Streaming eller skyvevinduer kan sette kontrollprogrammet ut av drift i lange perioder.

• Streaming eller ekte skyvevinduer ville gjøre grensesnittet mellom kontrollprogrammet og kermit ()-modulen mye mer komplisert, og ville faktisk presse mange protokolldetaljer inn i kontrollprogrammets plass, der de ikke hører hjemme.

• Streaming kan bare brukes på pålitelige tilkoblinger (som TCP/IP), men enheter med innebygd kommunikasjon bruker vanligvis serielle porter.

Mangelen på ekte skyvevinduer i EK kompenseres ved at EK later til å støtte dem uten egentlig å gjøre det. Dette lar avsenderpartneren «streame» pakker i stedet for å vente på ACK-er etter hver, så lenge det ikke er en feil. Hvis det er en feil, er gjenopprettingsstrategien «gå tilbake til n» (eller kanskje i noen tilfeller «feil ut») i stedet for «selektiv gjentakelse». EKSW, et eget program som ikke er integrert med EK (men burde være det), støtter ekte skyvevinduer med selektiv repetisjon; det vil si at bare de pakkene som faktisk må sendes på nytt.

I alle fall, siden EK primært er ment for innebygging, forventes det at tur-retur-forsinkelser ikke vil være en stor faktor; tilkoblinger vil generelt være lokale, korte, relativt raske, og hvis tilkoblingen er effektivt flytkontrollert, feilfri. Når effektiv flytkontroll mangler, kan hastigheten og/eller pakkelengden og/eller vindusstørrelsen settes til en kombinasjon av verdier som maksimerer gjennomstrømningen og minimerer tap av data.

---

KILDEKODE

Kildefilene er:

plattform.h

Overskriftsfil for alle nødvendige plattformspesifikke #includes eller definisjoner. Påkrevd, selv om den er tom, fordi kermit.c inkluderer den.

kermit.h

Overskriftsfil for alle moduler. Definisjon av k_data og k_response structs.

kermit.c

Dette er Kermit-protokollmotoren. Den drives utelukkende av anropsdataene. All tilstandsinformasjon lagres i kermit-datastrukturen, som sendes ved referanse fra hovedmodulen og blant alle funksjonene i kermit-modulen og tilbake igjen til hovedmodulen; dermed bør det være mulig for samme modul å overføre flere filer samtidig på forskjellige tilkoblinger. Videre er det ingen bibliotekreferanser i kermit-modulen, ingen i det hele tatt, ikke engang stdio (bortsett fra når feilsøking er aktivert), og ingen /usr/include/* header-filer er inkludert. Regler for kermit.c:

• Ingen globale variabler (bortsett fra feilsøking) eller buffere.

• Ingen initialisering av arrays av kompilator.

• Bare for sikkerhets skyld, ingen initialisering av automatiske skalarer heller.

• Ingen bibliotek- eller systemanrop, ingen #inkluder <…>.

• All kommunikasjon i/o gjøres av funksjoner definert i separate moduler.

Det enkle inngangspunktet for kermit.c-modulen er kermit()-funksjonen:

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

k-strukturen inneholder alle driftsparametere, variabler, tilstandsinformasjon og buffere; r-strukturen holder den som ringer informert om gjeldende status for protokollen, filnavn og filinformasjon, og overføringsfremdrift (byte så langt).

main.c

Eksempel på kontrollprogram. I Unix-testbedet er dette bare den tradisjonelle main(), som leser kommandolinjeargumenter, initialiserer protokollen, deretter kaller protokollmodulen i en tilstandsdrevet sløyfe til arbeidet er ferdig, og deretter rydder opp. I det innebygde miljøet vil disse funksjonene bli integrert i kontrollprogrammet.

unixio.c

I/O-funksjoner for Unix. Bytt ut din egen modul som implementerer disse funksjonene i målmiljøet og modifiser byggeprosedyren for å koble til den. Inngangspunkter og ringekonvensjoner beskrevet nedenfor.

---

UNIX-VERSJONEN

Utvikling av EK skjer på en konvensjonell Unix-plattform, som Mac OS, AIX, Solaris, HP-UX, … eller i disse dager mer sannsynlig en rekke BSD eller Linux, der EK er bygget som en ekstern modus Kermit filoverføringsprogram, lik G-Kermit, og testet mot en stasjonær Kermit som K95 eller C-Kermit. MERK: Unix-versjonen fungerer over stdin/stdout; «linjen» er betinget på den dummeste mulige måten (system(«stty …»)). Dette gir variable resultater; f.eks. nedlastinger fra EK på Solaris kan kjøre med 17Kcps, mens nedlastinger fra Linux på samme nett til samme PC kan kjøre med 1700Kcps. Dette er ikke verdt å bekymre seg over fordi EK ikke er beregnet for produksjonsbruk på Unix, som allerede har G-Kermit og C-Kermit for produksjon.

Unix-makefilen har følgende mål (det er enkelt å legge til flere):

gcc: Bygg med gcc (standard).

cc: Bygg med cc.

hp: Bygg for HP-UX.

gccnd: Bygg med gcc, ingen feilsøking.

gprof: Bygg med gcc, inkluderer profilering.

clean: Fjern objekt- og kjernefiler.

Makefilen lager en Unix-kjørbar kalt «ek» (innebygd kermit). Eksempelet main ()-rutinen gir et enkelt kommandolinjegrensesnitt:

$ ./ek -h

Bruk: ./ek alternativer

Alternativer:

-r Motta filer

-s filer Send filer

-p [neoms] Paritet: ingen, partall, oddetall, merke, mellomrom

-b [123] Blokksjekktype: 1, 2 eller 3 (standard = 3)

-k Behold ufullstendig mottatte filer

-B Force binær modus

-T Tving tekstmodus

-R Remote-modus (vs lokal)

-L Lokal modus (i forhold til fjernkontroll)

-E-nummer Simulert feilrate (0-100)

-d Opprett debug.log

-h Hjelp (denne meldingen)

$

Når du sender filer, hvis du ikke spesifiserer tekst eller binær, skanner EK hver fil og velger tekst eller binær modus basert på innholdet.

Remote vs Local-modus brukes bare for å aktivere testen for tastaturavbrudd av filoverføring.

---

PORTER TIL EN NY PLATTFORM

Versjon 1.0 av EK ble overført til VxWorks av Airvana, Inc, Chelmsford MA. Den komplette VxWorks EK 1.1-pakken er inkludert som et eksempel på et produksjonssystem etter Airvanas tillatelse (merk at EK API har endret seg litt siden da, så før VxWorks-koden kan brukes, må den oppdateres). Slik porterer du til en ny plattform:

• Legg til en ny Makefile-oppføring for målet ditt, eller skriv din egen byggeprosedyre.

• Lag en platform.h-fil for plattformen din. Dette kan inkludere hvilke som helst #include’s eller definisjoner, og det kan også brukes til å overstyre visse definisjoner i kermit.h:

#define NODEBUG å bygge uten feilsøkingskode.

#define HAVE_UCHAR hvis UCHAR allerede er definert eller definert til usignert tegn.

#define HAVE_ULONG hvis ULONG allerede er definert eller typedef’d til unsigned long.

#define IBUFLEN til å være ønsket størrelse for filinndatabufferen.

#define OBUFLEN til å være ønsket størrelse for filutdatabufferen.

#define FN_MAX som maksimal lengde for et filnavn.

#define P_PKTLEN for å overstyre standard maksimal pakkelengde.

#define P_WSLOTS for å overstyre standard maksimale vindusplasser.

• Bytt ut prøven main.c med ditt eget kontrollprogram. Bruk de samme overskriftsfilene og kallekonvensjonene som i eksemplet.

• Kopier unixio.c til xxxio.c (navnet du velger), rediger det slik at det fungerer på plattformen din ved å bruke nøyaktig de samme kallekonvensjonene, og juster byggeprosedyren for å koble til den nye xxxio-modulen i stedet for unixio. Legg merke til at inn- og utfyllingsbufferne (i_buf[] og o_buf[]) må defineres i xxxio-rutinen din.

Her er noen tips for å lage en i/o-modul:

Enhetens i/o-rutiner forventes å håndtere kommunikasjonsparametere selv, inkludert kommunikasjonslinjehastighet, paritet og flytkontroll. Spesielt håndterer ikke Kermit paritet, men må likevel bli fortalt om det. Dette gjøres i oppsettet av main(). Readpkt()- og tx_data()-rutinene dine bør fjerne og legge til paritet, henholdsvis, om nødvendig. På seriekoblinger kan kanskje UART programmeres til å gjøre dette.

API-endring mellom EK 1.1 og 1.2: Anropskonvensjoner (funksjonsargumentlister og returverdier) ble endret mellom versjon 1.1 til 1.2, hovedsakelig for å gi alle rutiner tilgang til k-strukturen på en konsistent måte, og også for å gi bedre tilbakemelding til den som ringer . I hvert tilfelle der en endring ble gjort, vises både det gamle og det nye formatet.

Enhetens i/o-funksjoner er:

int

devopen(char * enhet)

Åpner den gitte kommunikasjonsenheten. Kan også være en nettverksvert, uansett. Returnerer 0 ved fiasko, 1 ved suksess.

int

devsettings(char * settings)

Denne utfører alle nødvendige innstillinger for enheten, for eksempel hastighet og flytkontroll for en seriell enhet. Siden det ikke er noen måte å vite hva de relevante parameterne er, dette

rutine tar bare en streng, som kan være i hvilket som helst format, f.eks. «9600;8N1» eller «speed=57600;flow=rts/cts»; Devsettings-rutinen må analysere strengen. Returnerer 0 ved fiasko, 1 ved suksess.

int

devrestore (void)

Hvis ønskelig, sett enheten tilbake slik devsettings() fant den, f.eks. rett før du lukker den.

int

devclose (void)

Lukker kommunikasjonsenheten.

int

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

readpkt(struct k_data * k, UCHAR * buffer, int lengde) (1.2)

Denne rutinen må gjøre akkurat det prøven man gjør: søke etter starten på pakken, kopier deretter alle tegnene opp til (men ikke inkludert) slutten av pakken inn i pakkebufferen hvis adresse er oppgitt. Du vil ønske å kode dette så effektivt som mulig, ved å bruke de triksene som er tilgjengelige for deg: ikke-blokkerende bufret avlesning, osv. Hvis du vil at Kermit-programmet skal tidsavbrytes, er det her du legger koden. MERK: Timeouts er ikke nødvendig, siden sjansen for at ek’s Kermit-partner ikke kan timeout er omtrent 0. EK 1.2-formatet setter k som det første argumentet for samsvar med andre rutiner, og legger til et bufferlengdeargument.

Legg merke til F_CTRLC-funksjonen. Dette er aktivert som standard. Den lar EK brytes ut av pakkemodus ved å sende den tre påfølgende Ctrl-C-er i datastrømmen. Du trenger vanligvis ikke å deaktivere dette siden, selv om avsenderen «unprefikser» Ctrl-C, vil tre av dem på rad normalt bli slått sammen til en gjentatt tellesekvens.

int

tx_data(UCHAR * data, int lengde, kort paritet) (1.1)

tx_data(struct k_data * k, UCHAR * data, int lengde) (1.2)

Også her må du slå på paritet (hvis det ikke gjøres automatisk av kommunikasjonsenheten eller driveren). Denne rutinen skal være både effektiv og robust. Det er ment å overføre hele datastrengen ellers mislykkes. Se unixio.c-eksemplet for hva jeg mener med «robust». I EK 1.2 og senere hentes paritetsinnstillingen fra k-strukturen.

Fil-i/o-funksjonene er som følger; selvfølgelig kan de brukes til å lese eller skrive hva som helst — ikke bare filer: minne, tape, kort, laserstråler, instrumentkontrollere, hva som helst. Det spiller ingen rolle hva du kaller disse rutinene, men argumentlisten og returtypen må være som vist; også hvis du gir dem forskjellige navn, må du endre prototypene i kermit.h:

int

openfile(UCHAR * filnavn, int-modus, struct k_date * k) (1.1)

openfile(struct k_date * k, UCHAR * filnavn, int-modus) (1.2)

Åpner den navngitte filen i gitt modus (1 = les, 2 = skriv, 3 = legg til). Returnerer X_OK ved suksess, X_ERROR ved feil.

ULONG

filinfo(UCHAR * filnavn, UCHAR * buf, int buflen, kort * type, kort modus) (1.1)

filinfo (struct k_data * k, UCHAR * filnavn, UCHAR * buf, int buflen, kort * type, kort modus) (1.2)

Får informasjon om den angitte eksisterende lokale filen: størrelse, dato og, hvis modus == 0, filtypen (tekst eller binær). buf og buflen gjelder for filens dato-/tidsstreng. Returnerer X_OK eller X_ERROR.

int

readfile(struct k_data *)

Leser en buffer fra inndatafilen, og hvis overføringen er i tekstmodus, konverterer postformatet til standard Kermit Stream CRLF. Returnerer X_OK eller X_ERROR.

int

skrivefil (struct k_data *, CHAR * buffer, int lengde)

Skriver en buffer til utdatafilen, og hvis overføringen er i tekstmodus, konverterer også standard Kermit Stream CRLF-postformat til det som kreves lokalt. Returnerer X_OK eller X_ERROR.

int

closefile (struct k_data *, UCHAR-kode, int-modus)

Lukker filen. For utdatafiler tømmer dette selvfølgelig eventuelle ventende buffere til filen før den lukkes; så sjekker den om avsenderen Kermit kansellerte filoverføringen før den ble fullført (kode == ‘D’), i så fall forkaster den den delvise filen i stedet for å beholde den. Modusen indikerer om det er en inngangs- eller utdatafil, så ufullstendig mottatte filer kan slettes om ønskelig. Returnerer X_OK eller X_ERROR.

De nøyaktige kallekonvensjonene vises i unixio.c-filen.

---

DEBUGGING

Hvis EK ble bygget uten NODEBUG definert, så hvis du inkluderer -d-alternativet på kommandolinjen, oppretter den Unix-baserte eksempelversjonen av EK en debug.log-fil i den gjeldende katalogen. I produksjonsversjonen vil du legge til -DNODEBUG til C-kompilatoren CFLAGS for å eliminere feilsøkingskoden. Størrelsene vist ovenfor inkluderer feilsøking. Du kan implementere feilsøkingsfunksjonen som du vil i din plattformspesifikke i/o-modul.

---

UTGIVELSESHISTORIE

• Versjon / Dato / Beskrivelse

• 1.1 2002/10/07 Første utgivelse. VxWorks-versjonen fortsatt på dette nivået.
• 1.2 2003/01/28 Forbedret API, Java-port (som fortsatt er på dette nivået).
• 1.3 2004/03/04 Fiks filoverføring med HyperTerminal.
• 1.4 2004/03/20 Fiks mottak av tomme filer.
• 1.5 2004/04/10 Løs problemer med A-pakker, tillat supersmå og/eller kun mottakskonfigurasjoner.
• 1,51 2004/09/23 Tilpasning til Philips XAG30 (John Dunlap)
• EKSW 0.94 2010/06/24 Ekte skyvevinduer med selektiv retransmission (John Dunlap)
• 1.6 2011/03/30 Publisert og utgitt under 3-klausul Revised BSD License
• 1.7 2011/06/06 FORCE-3-protokoll, fungerer sammen med C-Kermit 9.0 (forklart her)
• 1.8 2021/06/26 Løs problem med -B og -T kommandolinjeargument (kun Unix-demo)

---

NEDLASTING

Flere forskjellige E-Kermit-implementeringer er tilgjengelige for nedlasting. E-Kermit selv, versjon 1.8, er den primære. Versjon 1.7 er fortsatt tilgjengelig. De andre er tilpasninger til forskjellige plattformer eller språk som ble gjort under tidligere utgivelser av E-Kermit, som angitt i forrige seksjon; med andre ord, rettelsene som finnes i E-Kermit 1.3, 1.4 og 1.5 er ikke i VxWorks- eller Java-versjonene, og VxWorks-versjonen bruker E-Kermit 1.1 API i stedet for den forbedrede 1.2-versjonen. EKSW har noen modifikasjoner av API og andre inkonsekvenser som bør angres før den kan integreres med EK 1.6, men er perfekt brukbar alene. Faktisk er dette versjonen som kjører i den nye generasjonen av Apex-EM ocean float og har blitt testet mer grundig under mer ugunstige forhold enn muligens noen annen Kermit-protokollimplementering. Gir opphav til versjon 1.7, som implementerer den nye Force-3 feilsjekkingspakkeprotokollen. (EKSW bør få dette også på et tidspunkt.)

For å komme til nedlastninger; følg linken den originale siden: DOWNLOAD