E — K ermit — Kermit do osadzania

Original article: https://kermitproject.org/k95.html

 

Kompaktowy, szybki, solidny, przenośny kod źródłowy do przesyłania plików Kermit do osadzenia w urządzeniach lub programach C

Wersja: 1.8

Data: 27 maja 2021 r.

Ostatnia aktualizacja tej strony: środa 24 maja 2023 r., 16:24:30

 POBIERAĆ

Ogłoszenie o otwartym kodzie źródłowym: Od 30 marca 2011 r. w wersji 1.6 E-Kermit jest wydawany „tak jak jest” na podstawie poprawionej licencji BSD składającej się z 3 klauzul .

E-Kermit 1.8 z 26 maja 2021 r. naprawia błąd w wersji demonstracyjnej Uniksa, polegający na odwróceniu argumentów wiersza poleceń -B i -T (odpowiednio w celu wymuszenia trybu przesyłania plików binarnych i tekstowych). Dziękujemy Toddowi Markleyowi za zgłoszenie.

27 maja 2021 r.: wszystkie łącza FTP na tej stronie zostały przekonwertowane na HTTP/HTTPS, ponieważ Chrome, Firefox i nie wiadomo jakie inne przeglądarki już ich nie obsługują; szczegóły tutaj .

Zawartość

  1. PROGRAM KONTROLI
  2. TRANSFER PLIKÓW
  3. KOD ŹRÓDŁOWY
  4. WERSJA UNIXOWA
  5. PORT NA NOWĄ PLATFORMĘ
  6. DEBUGOWANIE
  7. HISTORIA WYDANIA
  8. POBIERAĆ

EK (Embedded Kermit, E-Kermit) to implementacja protokołu przesyłania plików Kermit napisana w ANSI C i przeznaczona do osadzania w urządzeniach lub oprogramowaniu sprzętowym, do stosowania w aplikacjach czasu rzeczywistego lub do tworzenia bibliotek DLL i bibliotek. EKSW to nowa wersja E-Kermit, która umożliwia transport pakietów w prawdziwie przesuwnych oknach. Należy ponownie pogodzić EK i EKSW w jedną bazę kodu, ale jak dotąd tak się nie stało.

Czym zajmuje się E-Kermit

EK spełnia tylko dwie funkcje: wysyłanie plików i odbieranie plików. Jest kompaktowy, przenośny i w pełni współbieżny. Na SPARC (RISC), kermit.o wynosi około 25 tys. Na Intelu (CISC) jest to około 15 tys. Zmniejszając rozmiary buforów i eliminując opcjonalne lub niepożądane funkcje, można uzyskać mniejsze rozmiary.

Czego E-Kermit NIE robi

EK nie obejmuje funkcji klient/serwer; język programowania poleceń lub skryptów; konwersja zestawu znaków; szyfrowanie transportu; lub jakąkolwiek formę komunikacji lub wejścia/wyjścia plików. Nie wybiera modemów, nie realizuje połączeń, nie posiada wbudowanego stosu TCP/IP ani interfejsu do zewnętrznego. Jeśli potrzebujesz tych funkcji, powinieneś skorzystać z pełnego programu Kermit, takiego jak C-Kermit lub Kermit 95 .

EK nie jest aplikacją samą w sobie, jest to podprogram, który można wywołać z aplikacji głównej. Jest użyteczny tylko dla programistów, którzy muszą dostarczyć aplikację główną lub środowisko wywołujące, a także procedury wejścia/wyjścia dotyczące plików i komunikacji. Środowisko wywołujące musi z kolei nawiązać i skonfigurować połączenie komunikacyjne, jeśli jest ono wymagane i nie jest jeszcze otwarte. Przykładowe środowisko wywoływania i obsługa we/wy są dostępne dla systemu Unix.

Klienci przystosowali EK do różnych środowisk i platform, w tym Palm Pilot, różnego rodzaju sprzętu technicznego (np. do diagnostyki i konserwacji masztów telefonii komórkowej), a czasami wnoszą swoje adaptacje lub procedury we/wy, a my możemy je udostępnić ściśle według aktualnego stanu. Nie jesteśmy w stanie wspierać ani utrzymywać kodu przesłanego przez klienta; dlatego (na przykład) jeśli zostanie wydana nowa wersja EK, moduły przesłane przez klienta niekoniecznie zostaną zaktualizowane. Kod przesłany przez klienta obejmuje:

  • Port szeregowy i wejście/wyjście plików Microsoft Windows 9x/ME/NT/2000/XP/Vista/7 dla EK 1.3 i nowszych wersji.
  • Wind River VxWorks dla EK 1.1.
  • EK 1.2 przetłumaczony na Javę .

EK zawiera następujące funkcje protokołu Kermit:

  • Długie paczki
  • Przesuwane okna z odzyskiwaniem błędów Go-Back-to- N (prawdziwe selektywne powtórzenie w EKSW).
  • Kompresja z liczeniem powtórzeń
  • Przedrostek i usuwanie prefiksu znaków kontrolnych
  • Prefiks 8-bitowy (do przesyłania 8-bitowych danych w łączach 7-bitowych) (= parzystość)
  • Atrybut pakietów (typ, rozmiar i data)
  • Wysyłanie i odbieranie jednego lub wielu plików.
  • Automatyczne przełączanie trybu tekstowego/binarnego dla poszczególnych plików.
  • Wszystkie trzy typy kontroli bloków (6- i 12-bitowa suma kontrolna, 16-bitowy CRC).
  • Raporty o stanie (stan protokołu, nazwa pliku, rozmiar, znacznik czasu, dotychczasowa liczba bajtów).
  • Anulowanie przelewu przez którąkolwiek ze stron.

Następujące funkcje protokołu Kermit nie są zaimplementowane:

  • Okna przesuwne z selektywną retransmisją (z wyjątkiem EKSW)
  • Zestawy znaków
  • Blokowanie zmian
  • Klient/serwer

Za przekroczenie limitu czasu odpowiada program Kermit po drugiej stronie połączenia lub, jeśli zajdzie taka potrzeba w samym E-Kermit, zależna od platformy procedura odczytu pakietów, którą możesz napisać.

Począwszy od wersji 1.5, E-Kermit zawiera konstrukcje preprocesorów, które pozwalają wykluczyć różne funkcje, takie jak długie pakiety, przesuwające się okna i sprawdzanie bloków wyższego rzędu, aby osiągnąć najmniejsze możliwe miejsce w pamięci, a także może być zbudowany w konfiguracji tylko do odbioru .

PROGRAM KONTROLI

EK został zaprojektowany do pracy w kooperacyjnym środowisku wielozadaniowym, ale nie wymaga takiego środowiska. Program sterujący zajmuje się planowaniem. Oto, co program sterujący musi (i/lub może) zrobić:

  • W razie potrzeby otwórz urządzenie komunikacyjne, jeśli takie istnieje.
  • W razie potrzeby przełącz urządzenie komunikacyjne, jeśli takie istnieje, w „tryb pakietowy”.
  • Zainicjuj strukturę Kermita z żądanymi parametrami operacyjnymi.
  • Dzwonić Kermit(K_INIT, …) aby Kermit zainicjował się.
  • Jeżeli wysyłasz pliki zadzwoń Kermit(K_SEND) aby rozpocząć transfer.

(Kiedy E-Kermit ma odebrać pliki, czeka pasywnie na pierwszy pakiet od nadawcy pliku; w ten sposób po prostu wchodzi do pętli pakietów.) W pętli pakietów E-Kermit:

  • Pobiera bufor i wczytuje do niego przychodzący pakiet.
  • Sprawdza, czy użytkownik nie przerwał.
  • Połączenia Kermit(K_RUN, …) aby wykonać kolejny krok protokołu.
  • Robi wszystko, co chce (np. uruchamia inne zadania).
  • Zamyka lub kontynuuje pętlę w oparciu o Kermit() kod powrotu.

Za każdym razem, gdy program sterujący wywołuje metodę Kermit() funkcja, która przyznaje mu pozwolenie na obsługę jednego pakietu; zatem jeden pakiet = jeden kawałek czasu. Jeśli program sterujący nie ma nic innego do roboty, po prostu przetwarza pakiety w sposób ciągły, jak zwykły program Kermita. Będąc w pętli przesyłania danych, każdy Kermit() call zwraca strukturę zawierającą:

  • Bieżący stan protokołu;
  • Bieżąca nazwa pliku;
  • Rozmiar pliku, jeśli jest znany, lub -1;
  • Znacznik czasu pliku, jeśli jest znany;
  • Liczba bajtów przesłanych do tej pory.

Po zakończeniu program sterujący:

  • Przywraca i (w razie potrzeby) zamyka urządzenie komunikacyjne.

Kody funkcji, które może wywołać program sterujący Kermit() z są:

K_INIT— Inicjuj struktury danych.

K_WYŚLIJ — (Tylko wysyłanie) — Rozpocznij wysyłanie.

K_RUN— Uruchom protokół.

K_STATUS — Zwróć raport o stanie w strukturze k_response.

K_WYJDŹ — Odejdź natychmiast i po cichu.

K_ERROR — Wyślij pakiet błędów, a następnie zamknij.

Kody powrotne Kermit() funkcja to:

X_OK — OK, protokół aktywny.

X_GOTOWE — OK, protokół gotowy.

X_ERROR — Błąd krytyczny.

X_STATUS — Status zwracany w odpowiedzi na K_STATUS.

(W rzeczywistości status jest dostrajany przy każdym wywołaniu.) Kody stanu protokołu to:

-1 — Błąd krytyczny

0 — Odbiornik (protokół nie działa)

1 — Odbiornik czeka na pakiet S

2 — Odbiornik czeka na pakiet F lub B

3 — Odbiornik czeka na pakiet A lub D

4 — Odbiornik czeka na pakiet D lub Z

10 — Nadawca (protokół nie działa)

11 — Nadawca wysłał pakiet S (start)

12 — Nadawca wysłał pakiet F (nazwa pliku)

13 — Nadawca wysłał pakiet (atrybuty)

14 — Nadawca wysłał pakiet D (dane)

15 — Nadawca wysłał pakiet Z (EOF)

16 — Nadawca wysłał pakiet B (EOT)

TRANSFER PLIKÓW

Ponieważ EK jest przeznaczony głównie do osadzania, nie wykorzystuje przesyłania strumieniowego ani (z wyjątkiem EKSW) prawdziwych okien przesuwnych (chociaż większość kodu okien przesuwnych jest tam zawarta). Dzieje się tak z następujących powodów:

  • Użycie zwykłego protokołu ACK/NAK pozwala programowi sterującemu odzyskać kontrolę po każdym pakiecie. Dzięki temu może wykonywać wiele zadań jednocześnie, wyświetlać graficzny ekran przesyłania plików, cokolwiek. Przesyłanie strumieniowe lub przesuwanie okien może spowodować, że program sterujący przestanie działać na długi czas.
  • Przesyłanie strumieniowe lub prawdziwe okna przesuwne sprawiłyby, że interfejs pomiędzy programem sterującym a plikiem Kermit() moduł znacznie bardziej skomplikowany i w rzeczywistości wypchnąłby wiele szczegółów protokołu do przestrzeni programu sterującego, gdzie nie powinny.
  • Przesyłania strumieniowego można używać tylko w przypadku niezawodnych połączeń (takich jak TCP/IP), ale urządzenia z wbudowaną komunikacją zazwyczaj korzystają z portów szeregowych.

Brak prawdziwych przesuwanych okien w EK jest kompensowany przez to, że EK udaje, że je wspiera, choć tak naprawdę tego nie robi. Dzięki temu partner wysyłający może „strumieniować” pakiety zamiast czekać na potwierdzenia ACK po każdym z nich, o ile nie wystąpił błąd. Jeśli wystąpi błąd, strategią odzyskiwania jest „powrót do n ” (lub w niektórych przypadkach „wyjście z błędu”), a nie „selektywne powtarzanie”. EKSW, osobny program, który nie został zintegrowany z EK (a powinien być), obsługuje prawdziwe okna przesuwne z selektywnym powtarzaniem; oznacza to, że retransmitowane są tylko te pakiety, które faktycznie są potrzebne.

W każdym razie, ponieważ EK jest przeznaczony głównie do osadzania, przewiduje się, że opóźnienia w obie strony nie będą dużym czynnikiem; połączenia będą na ogół lokalne, krótkie, stosunkowo szybkie i, jeśli połączenie jest skutecznie kontrolowane pod względem przepływu, wolne od błędów. Gdy brakuje skutecznej kontroli przepływu, prędkość i/lub długość pakietu i/lub rozmiar okna można ustawić na kombinację wartości, która maksymalizuje przepustowość i minimalizuje utratę danych.

KOD ŹRÓDŁOWY

Pliki źródłowe to:

platforma.h

Plik nagłówkowy dla wszelkich potrzebnych #includes lub definicji specyficznych dla platformy. Wymagane, nawet jeśli jest puste, ponieważ kermit.c zawiera to.

kermit.h

Plik nagłówkowy dla wszystkich modułów. Definicja k_dane I k_odpowiedź konstrukcje.

kermit.c

To jest silnik protokołu Kermita. Działa wyłącznie na podstawie danych połączeń. Wszystkie informacje o stanie są zapisywane w strukturze danych Kermita, która jest przekazywana przez referencję z modułu głównego i pomiędzy wszystkimi funkcjami modułu Kermita i z powrotem do modułu głównego; dlatego powinno być możliwe, aby ten sam moduł przesyłał jednocześnie wiele plików różnymi połączeniami. Co więcej, w module Kermita nie ma żadnych odniesień do bibliotek, nawet żadnych, nawet na stdio (z wyjątkiem sytuacji, gdy włączone jest debugowanie) i nie ma /usr/include/* dołączone są pliki nagłówkowe. Zasady dot kermit.c :

  • Brak zmiennych globalnych (z wyjątkiem debugowania) i buforów.
  • Brak inicjowania tablic przez kompilator.
  • Tylko dla bezpieczeństwa, nie ma też inicjowania automatycznych skalarów.
  • Żadnych bibliotek ani wywołań systemowych, nie #uwzględnij <…> .
  • Całość komunikacji we/wy realizowana jest poprzez funkcje zdefiniowane w oddzielnych modułach.

Jedyny punkt wejścia dla kermit.c moduł to Kermit() funkcjonować:

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

Struktura k zawiera wszystkie parametry operacyjne, zmienne, informacje o stanie i bufory; struktura r informuje osobę wywołującą o bieżącym stanie protokołu, nazwie pliku i informacjach o pliku oraz postępie transferu (do tej pory w bajtach).

główny.c

Przykładowy program sterujący. W środowisku testowym Uniksa jest to po prostu tradycyjne główny() , który odczytuje argumenty wiersza poleceń, inicjuje protokół, następnie wywołuje moduł protokołu w pętli sterowanej stanem, aż do zakończenia swojej pracy, a następnie czyści. W środowisku wbudowanym funkcje te byłyby zintegrowane z programem sterującym.

unixio.c

Funkcje we/wy dla systemu Unix. Zastąp własny moduł, który implementuje te funkcje w środowisku docelowym i zmodyfikuj procedurę kompilacji, aby była z nią połączona. Punkty wejścia i konwencje wywoływania opisano poniżej.

WERSJA UNIXOWA

Rozwój EK odbywa się na konwencjonalnej platformie Unix, takiej jak Mac OS, AIX, Solaris, HP-UX, … lub obecnie, co bardziej prawdopodobne, na jakiejś odmianie BSD lub Linux, w którym EK jest zbudowany jako Kermit w trybie zdalnym program do przesyłania plików, podobny do G-Kermit i przetestowany na komputerze stacjonarnym Kermit, takim jak K95 lub C-Kermit. UWAGA: Wersja Unixowa działa na stdin/stdout; „linia” jest uwarunkowana w najgłupszy możliwy sposób ( system(«stty…») ). Daje to zmienne wyniki; np. pobieranie z EK na Solarisie może przebiegać z szybkością 17 Kcps, podczas gdy pobieranie z Linuksa w tej samej sieci na ten sam komputer może przebiegać z szybkością 1700 Kcps. Nie warto się tym martwić, ponieważ EK nie jest przeznaczony do użytku produkcyjnego w systemie Unix, który ma już G-Kermit i C-Kermit do produkcji.

Plik makefile Uniksa ma następujące cele (łatwo dodać więcej):

gcc: Kompiluj za pomocą gcc (domyślnie).

DW: Buduj za pomocą cc.

KM: Kompilacja dla HP-UX.

gccnd: Kompiluj za pomocą gcc, bez debugowania.

gprof: Kompiluj za pomocą gcc, uwzględnij profilowanie.

czysty: Usuń pliki obiektowe i podstawowe.

Plik makefile tworzy plik wykonywalny Uniksa o nazwie „ek” (wbudowany kermit). Próbka główny() rutyna zapewnia prosty interfejs wiersza poleceń:

$ ./ek -godzUżycie: opcje

./ek

Opcje:

-r Odbierz pliki

-s pliki Wyślij pliki

-p [neoms] Parzystość: brak, parzysty, nieparzysty, znak, spacja

-b [123] Typ sprawdzania bloku: 1, 2 lub 3 (domyślnie = 3)

-k Zachowaj niekompletne otrzymane pliki

-B Wymusza tryb binarny

-T Wymuś tryb tekstowy

-R Tryb zdalny (w porównaniu z lokalnym)

-L Tryb lokalny (w porównaniu ze zdalnym)

-E liczba Symulowany poziom błędów (0-100)

-d Utwórz plik debug.log

-h Pomoc (ten komunikat)

$

Jeśli podczas wysyłania plików nie określisz opcji Tekst lub Binarny, EK skanuje każdy plik i wybiera tryb tekstowy lub binarny na podstawie jego zawartości.

Tryb zdalny vs lokalny służy tylko do umożliwienia testu zakłóceń przesyłania plików przez klawiaturę.

PORT NA NOWĄ PLATFORMĘ

Wersja 1.0 EK została przeniesiona do VxWorks przez Airvana, Inc, Chelmsford MA. Kompletny pakiet VxWorks EK 1.1 został dołączony jako przykład systemu produkcyjnego za zgodą Airvany (należy pamiętać, że od tego czasu interfejs EK API uległ niewielkim zmianom, dlatego przed użyciem kodu VxWorks należy go zaktualizować). Aby przenieść na nową platformę:

  • Dodaj nowy wpis Makefile dla swojego celu lub napisz własną procedurę kompilacji.
  • Stwórz platforma.h plik dla Twojej platformy. Może to obejmować dowolne #include lub definicje, a także może zostać użyte do zastąpienia niektórych definicji w kermit.h :
    #zdefiniuj NODEBUGA do zbudowania bez debugowania kodu.
    #zdefiniuj HAVE_UCHAR Jeśli UCHAR jest już zdefiniowany lub typedef ‘d do unsigned char.
    #zdefiniuj HAVE_ULONG Jeśli ULONG jest już zdefiniowany lub typedef ‘d do unsigned long.
    #zdefiniuj IBUFLEN być żądanym rozmiarem bufora wejściowego pliku.
    #zdefiniuj OBUFLEN być żądanym rozmiarem bufora wyjściowego pliku.
    #zdefiniuj FN_MAX być maksymalną długością nazwy pliku.
    #zdefiniuj P_PKTLEN aby zastąpić domyślną maksymalną długość pakietu.
    #zdefiniuj P_WSLOTS aby zastąpić domyślne maksymalne szczeliny okien.
  • Wymień próbkę główny.c z własnym programem sterującym. Użyj tych samych plików nagłówkowych i konwencji wywoływania, co w przykładzie.
  • Kopiuj unixio.c Doxxx io.c (nazwa według własnego wyboru), edytuj ją, aby działała na Twojej platformie przy użyciu dokładnie tych samych konwencji wywoływania i dostosuj procedurę kompilacji, aby łączyła się z nowąxxx i moduł zamiast unixio . Należy pamiętać, że bufory wejściowe i wyjściowe wypełniają ( i_buf[] I o_buf[] ) musi być zdefiniowany w plikuxxx i rutyna.

Oto kilka wskazówek dotyczących tworzenia modułu we/wy:

Oczekuje się, że procedury we/wy urządzenia same będą obsługiwać parametry komunikacyjne, w tym prędkość linii komunikacyjnej, parzystość i kontrolę przepływu. W szczególności Kermit nie radzi sobie z parytetem, ale mimo to należy o tym powiedzieć. Odbywa się to w konfiguracji przez główny() . Twój przeczytaj plik() I tx_data() procedury powinny odpowiednio usunąć i dodać parzystość, jeśli to konieczne. W przypadku połączeń szeregowych być może można zaprogramować UART, aby to zrobił.

Zmiana API pomiędzy EK 1.1 i 1.2: Konwencje wywoływania (listy argumentów funkcji i wartości zwracane) zostały zmienione pomiędzy wersjami 1.1 do 1.2, głównie po to, aby zapewnić wszystkim procedurom spójny dostęp do struktury k , a także aby zapewnić lepszą informację zwrotną osobie wywołującej . W każdym przypadku, w którym dokonano zmiany, pokazany jest zarówno stary, jak i nowy format.

Funkcje wejścia/wyjścia urządzenia to:

int

devopen(char * urządzenie)

Otwiera dane urządzenie komunikacyjne. Może to być także host sieciowy, cokolwiek. Zwraca 0 w przypadku niepowodzenia, 1 w przypadku sukcesu.

int

devsettings(char * ustawienia)

Ten wykonuje wszelkie niezbędne ustawienia urządzenia, takie jak kontrola prędkości i przepływu dla urządzenia szeregowego. Ponieważ nie ma sposobu, aby dowiedzieć się, jakie są odpowiednie parametry, ta procedura pobiera po prostu ciąg znaków, który może mieć dowolny format, np. „ 9600;8N1 » Lub » prędkość=57600;przepływ=rts/cts «; procedura devsettings będzie musiała przeanalizować ciąg znaków. Zwraca 0 w przypadku niepowodzenia, 1 w przypadku powodzenia.

int

devrestore(void)

W razie potrzeby odłóż urządzenie z powrotem ustawienia dev() znalazłem, np. tuż przed zamknięciem.

int

devclose(void)

Zamyka urządzenie komunikacyjne.

int

readpkt(UCHAR * bufor, struktura k_data * k) (1.1)

readpkt(struct k_data * k, UCHAR * bufor, długość int) (1.2)

Ta procedura musi robić dokładnie to samo, co robi próbka: szukać początku pakietu, następnie kopiować wszystkie znaki aż do końca pakietu (ale nie włączając) do bufora pakietu, którego adres jest podany. Będziesz chciał zakodować to tak efektywnie, jak to możliwe, używając wszelkich dostępnych sztuczek: nieblokującego, buforowanego odczytu itp. Jeśli chcesz, aby Twój program Kermit przekroczył limit czasu, tutaj możesz umieścić kod. UWAGA: Limity czasu nie są konieczne, ponieważ szanse, że partner ek Kermita nie przekroczy limitu czasu, wynoszą około 0. Format EK 1.2 stawia k jako pierwszy argument zapewniający spójność z innymi procedurami i dodaje argument długości bufora.

Zwróć uwagę na funkcję F_CTRLC. Opcja ta jest domyślnie włączona. Umożliwia wyrwanie EK z trybu pakietowego poprzez wysłanie do niego trzech kolejnych kombinacji Ctrl-C w strumieniu danych. Zwykle nie trzeba by tego wyłączać, ponieważ nawet jeśli nadawca „usuwa prefiks” Ctrl-C, trzy z nich z rzędu zostaną zwykle zwinięte w sekwencję zliczania powtórzeń.

int

tx_data(UCHAR * dane, int długość, krótka parzystość) (1.1)

tx_data(struct k_data * k, UCHAR * dane, int długość) (1.2)

Tutaj ponownie musisz zwrócić uwagę na parzystość (jeśli nie jest to wykonywane automatycznie przez urządzenie komunikacyjne lub sterownik). Procedura ta powinna być zarówno skuteczna, jak i solidna. Powinien przesłać cały ciąg danych, w przeciwnym razie zakończy się niepowodzeniem. Zobacz unixio.c próbkę tego, co mam na myśli mówiąc „solidny”. W EK 1.2 i późniejszych ustawienia parzystości są pobierane ze struktury k .

Funkcje wejścia/wyjścia pliku są następujące; oczywiście można ich używać do odczytu lub zapisu czegokolwiek – nie tylko plików: pamięci, taśmy, kart, wiązek laserowych, sterowników instrumentów, czegokolwiek. Nie ma znaczenia, jak nazwiesz te procedury, ale lista argumentów i typ zwracany muszą być takie, jak pokazano; także jeśli nadasz im różne nazwy, będziesz musiał zmienić prototypy kermit.h :

int

openfile(UCHAR * nazwa pliku, tryb int, struktura k_data * k) (1.1)

openfile(struct k_date * k, UCHAR * nazwa pliku, tryb int) (1.2)

Otwiera nazwany plik w zadanym trybie (1 = odczyt, 2 = zapis, 3 = dołączanie). Zwraca X_OK w przypadku powodzenia, X_ERROR w przypadku niepowodzenia.

ULONG

informacje o pliku (UCHAR * nazwa pliku, UCHAR * buf, int buflen, krótki * typ, tryb krótki) (1.1)

informacje o pliku (struct k_data * k, UCHAR * nazwa pliku, UCHAR * buf, int buflen, krótki * typ, tryb krótki) (1.2)

Pobiera informacje o określonym istniejącym pliku lokalnym: rozmiar, datę i, jeśli tryb == 0, typ pliku (tekstowy lub binarny). buf i buflen dotyczą ciągu znaków daty/godziny pliku. Zwraca X_OK lub X_ERROR.

int

plik odczytu (struktura k_data *)

Odczytuje bufor z pliku wejściowego i jeśli transfer odbywa się w trybie tekstowym, konwertuje format rekordu na standardowy Kermit Stream CRLF. Zwraca X_OK lub X_ERROR.

int

plik zapisu (struktura k_data *, CHAR * bufor, długość int)

Zapisuje bufor do pliku wyjściowego, a jeśli transfer odbywa się w trybie tekstowym, konwertuje również standardowy format rekordu Kermit Stream CRLF na dowolny wymagany lokalnie. Zwraca X_OK lub X_ERROR.

wew

plik zamknięty(struktura k_data *, kod UCHAR, tryb int)

Zamyka plik. W przypadku plików wyjściowych opróżnia to oczywiście wszelkie oczekujące bufory do pliku przed jego zamknięciem; następnie sprawdza, czy wysyłający Kermit anulował przesyłanie pliku przed jego zakończeniem (kod == ‘D’), w takim przypadku odrzuca częściowy plik zamiast go zatrzymywać. Tryb wskazuje, czy jest to plik wejściowy, czy wyjściowy, więc niekompletne odebrane pliki można w razie potrzeby usunąć. Zwraca X_OK lub X_ERROR.

Dokładne konwencje wywoływania są pokazane w pliku unixio.c plik.

DEBUGOWANIE

Jeśli EK został zbudowany bez zdefiniowanego NODEBUG, to jeśli dołączysz plik -D w wierszu poleceń, przykładowa wersja EK oparta na systemie Unix tworzy plik debug.log plik w jego bieżącym katalogu. W wersji produkcyjnej dodałbyś -DNODEBUG do kompilatora C CFLAGS, aby wyeliminować kod debugujący. Rozmiary pokazane powyżej obejmują debugowanie. Możesz zaimplementować funkcję debugowania w dowolny sposób w module wejścia/wyjścia specyficznej dla platformy.

HISTORIA WYDANIA

Wersja Data Opis
1.1 2002.10.07 Pierwsze wydanie. Wersja VxWorks nadal na tym poziomie.
1.2 28.01.2003 Poprawione API, port Java (który nadal jest na tym poziomie).
1.3 2004.03.04 Napraw transfer plików za pomocą HyperTerminal.
1.4 20.03.2004 Napraw odbiór pustych plików.
1,5 2004.04.10 Napraw problem z pakietami A, zezwól na konfiguracje bardzo małe i/lub konfiguracje tylko do odbioru.
1,51 23.09.2004 Dostosuj do Philips XAG30 (John Dunlap)
EKSW 0,94 24.06.2010 Prawdziwie przesuwane okna z selektywną retransmisją ( John Dunlap )
1.6 30.03.2011 Opublikowane i wydane na podstawie poprawionej licencji BSD zawierającej 3 klauzule .
1.7 2011.06.06 Protokół FORCE-3, współpracuje z C-Kermit 9.0 (wyjaśniono tutaj )
1.8 26.06.2021 Napraw problem z argumentami wiersza poleceń -B i -T (tylko wersja demonstracyjna Uniksa)

POBIERAĆ

Do pobrania dostępnych jest kilka różnych wdrożeń E-Kermit. Sam E-Kermit, wersja 1.8, jest wersją pierwotną. Wersja 1.7 pozostaje dostępna. Pozostałe to adaptacje do różnych platform lub języków, które zostały wykonane podczas poprzednich wydań E-Kermit, jak wskazano w poprzedniej sekcji; innymi słowy, poprawki znalezione w E-Kermit 1.3, 1.4 i 1.5 nie znajdują się w wersjach VxWorks ani Java, a wersja VxWorks wykorzystuje API E-Kermit 1.1 zamiast ulepszonej wersji 1.2. EKSW ma pewne modyfikacje w API i inne niespójności, które należy usunąć, zanim będzie można go zintegrować z EK 1.6, ale doskonale nadaje się do samodzielnego użytku. W rzeczywistości jest to wersja działająca w nowej generacji pływaków oceanicznych Apex-EMi został przetestowany dokładniej w bardziej niesprzyjających warunkach niż jakakolwiek inna implementacja protokołu Kermita. Dało początek wersji 1.7, która implementuje nowy protokół sprawdzania błędów Force-3 . (EKSW też powinien to kiedyś otrzymać.)

Nazwa Opis Smoła * Zamek błyskawiczny Pliki źródłowe
E-Kermit 1.8 Przenośny na wszystkie platformy, z wersją demonstracyjną Uniksa. Pobierać Pobierać Pobierać
E-Kermit 1.7 Przenośny na wszystkie platformy, z wersją demonstracyjną Uniksa. Pobierać Pobierać Pobierać
EKSW 0,94 E-Kermit z prawdziwymi przesuwanymi oknami, dostosowany do Linuksa. Pobierać Pobierać Pobierać
EKVX 1.1 E-Kermit 1.1 dostosowany do VxWorks. Pobierać Pobierać Pobierać
Jawa E-Kermit 1.2 przekonwertowany na Javę Pobierać Pobierać Pobierać
Podobne Tester warunków skrajnych protokołu Kermita [ opis ] Pobierać Pobierać Pobierać

* Nie skompresowane, nie ma potrzeby, są bardzo małe.