XMODEM - XMODEM

XMODEM
Protokół komunikacyjny
Cel, powód Protokół Przesyłania Plików
Deweloper(zy) Ward Christensen
Wprowadzono 1977 ; 44 lata temu ( 1977 )
Pod wpływem YMODEM , wiele innych
Sprzęt komputerowy modemy

XMODEM to prosty protokół przesyłania plików opracowany jako szybki hack przez Warda Christensena do użytku w jego programie terminalowym MODEM.ASM z 1977 roku . Umożliwiał użytkownikom przesyłanie plików między ich komputerami, gdy obie strony korzystały z MODEMU. Keith Petersen dokonał drobnej aktualizacji, aby zawsze włączać „tryb cichy” i nazwał wynik XMODEM.

XMODEM, podobnie jak większość protokołów przesyłania plików, dzieli oryginalne dane na serię „ pakietów ”, które są wysyłane do odbiorcy, wraz z dodatkowymi informacjami umożliwiającymi odbiorcy określenie, czy pakiet został prawidłowo odebrany. W przypadku wykrycia błędu odbiorca żąda ponownego wysłania pakietu. Ciąg złych pakietów powoduje przerwanie przesyłania.

XMODEM stał się niezwykle popularny na rynku wczesnych systemów tablicy ogłoszeń (BBS), głównie dlatego, że był łatwy do wdrożenia. Był również dość nieefektywny, a wraz ze wzrostem prędkości modemu problem ten doprowadził do opracowania wielu zmodyfikowanych wersji XMODEM w celu poprawy wydajności lub rozwiązania innych problemów z protokołem. Christensen wierzył, że jego oryginalny XMODEM jest „najbardziej zmodyfikowanym programem w historii komputerów”.

Chuck Forsberg zebrał szereg typowych modyfikacji w swoim protokole YMODEM , ale słaba implementacja doprowadziła do dalszego pękania, zanim zostały one ponownie zunifikowane przez jego późniejszy protokół ZMODEM . ZMODEM stał się bardzo popularny, ale nigdy całkowicie nie zastąpił XMODEM na rynku BBS.

Struktura pakietów

Oryginalny XMODEM używał 128-bajtowego pakietu danych, podstawowego rozmiaru bloku używanego na dyskietkach CP/M . Pakiet był poprzedzony prostym 3-bajtowym nagłówkiem zawierającym znak, „numer bloku” od 0-255 i „odwrotny” numer bloku — 255 minus numer bloku. Numeracja bloków zaczyna się od 1 dla pierwszego wysłanego bloku, a nie od 0. Po nagłówku następowało 128 bajtów danych, a następnie jednobajtowa suma kontrolna . Kompletny pakiet miał zatem długość 132 bajtów i zawierał 128 bajtów danych użytkowych , co daje całkowitą wydajność kanału około 97%. <SOH>

Suma kontrolna była sumą wszystkich bajtów w pakiecie modulo 256. Operację modulo można było łatwo obliczyć, odrzucając wszystkie bity wyniku poza ośmioma najmniej znaczącymi lub alternatywnie na maszynie ośmiobitowej, ignorując przepełnienie arytmetyczne, które dałoby to samo efekt automatycznie. W ten sposób suma kontrolna została ograniczona do liczby ośmiobitowej. Na przykład, jeśli ta metoda sumy kontrolnej została użyta na małym pakiecie danych zawierającym tylko dwa bajty o wartościach 130 i 130, suma tych kodów wynosi 260, a wynikowa suma kontrolna wynosi 4.

Plik został oznaczony jako „kompletny” znakiem wysłanym po ostatnim bloku. Ten znak nie był w pakiecie, ale wysłany jako pojedynczy bajt. Ponieważ długość pliku nie została wysłana jako część protokołu, ostatni pakiet został uzupełniony „znanym znakiem”, który można było odrzucić. W oryginalnej specyfikacji było to domyślnie lub 26 dziesiętne, które CP/M używało jako znacznika końca pliku we własnym formacie dysku. Standard sugerował, że do wypełnienia można użyć dowolnego znaku, ale nie było możliwości jego zmiany w samym protokole – jeśli implementacja zmieniła znak dopełnienia, tylko klienci używający tej samej implementacji poprawnie zinterpretowaliby nowy znak dopełnienia. <EOT><SUB>

Szczegóły przelewu

Pliki były przesyłane po jednym pakiecie na raz. Po odebraniu suma kontrolna pakietu została obliczona przez odbiorcę i porównana z tą otrzymaną od nadawcy na końcu pakietu. Jeśli te dwa elementy pasowały, odbiorca wysłał wiadomość z powrotem do nadawcy, który następnie wysłał kolejny pakiet. Jeśli wystąpił problem z sumą kontrolną, odbiorca zamiast tego wysyłał . Jeśli odebrano a, nadawca wysłałby pakiet ponownie i kontynuował próbę kilka razy, zwykle dziesięć, przed przerwaniem przesyłania. <ACK><NAK><NAK>

A <NAK>zostało również wysłane, jeśli odbiorca nie odebrał ważnego pakietu w ciągu dziesięciu sekund, wciąż oczekując danych z powodu braku <EOT>znaku. Siedem-sekundowy limit czasu była również stosowana wewnątrz pakietu, ochronę przed spadła połączeń w połowie pakietu.

Numery bloków zostały również sprawdzone w prosty sposób pod kątem błędów. Po pomyślnym odebraniu pakietu następny pakiet powinien mieć numer o jeden wyższy. Jeśli zamiast tego otrzymał ten sam numer bloku, nie było to uważane za poważne, sugerowano, że <ACK>nie został odebrany przez nadawcę, który następnie ponownie wysłał pakiet. Każdy inny numer pakietu sygnalizował utratę pakietów.

Transfery były kierowane do odbiorcy; nadajnik nie wyśle ​​żadnych danych, dopóki inicjał nie <NAK>zostanie wysłany przez odbiornik. Był to logiczny wynik interakcji użytkownika z maszyną wysyłającą, która byłaby zlokalizowana zdalnie. Użytkownik przejdzie do żądanego pliku na maszynie wysyłającej, a następnie poprosi tę maszynę o przesłanie go. Po wydaniu tego polecenia użytkownik wykonał polecenie w swoim lokalnym oprogramowaniu, aby rozpocząć odbieranie. Ponieważ opóźnienie między zapytaniem zdalnego systemu o plik a wydaniem lokalnego polecenia do odbioru było nieznane, XMODEM pozwolił odbiornikowi na rozpoczęcie wysyłania żądań pakietów danych przez maksymalnie 90 sekund.

Problemy

Chociaż XMODEM był wystarczająco solidny, aby dziennikarz w 1982 r. mógł przesyłać historie z Pakistanu do Stanów Zjednoczonych za pomocą Osborne 1 i sprzęgacza akustycznego za pośrednictwem linii telefonicznych o niskiej jakości, protokół miał kilka wad.

Drobne problemy

XMODEM został napisany dla maszyn CP/M i nosi kilka znaków tego systemu operacyjnego . Warto zauważyć, że pliki na CP/M były zawsze wielokrotnościami 128 bajtów, a ich koniec zaznaczano w bloku <EOT>znakiem. Te cechy zostały przeniesione bezpośrednio do XMODEM. Jednak inne systemy operacyjne nie posiadały żadnej z tych osobliwości, a powszechne wprowadzenie MS-DOS na początku lat 80. spowodowało konieczność aktualizacji XMODEM, aby zauważyć albo znacznik końca pliku, <EOT> albo <EOF> jako znacznik końca pliku.

Od jakiegoś czasu sugerowano, że należy wspierać wysyłanie <CAN>znaku zamiast <ACK>lub <NAK>, aby łatwo przerwać transfer od strony odbiorczej. Podobnie <CAN>otrzymany w miejsce <SOH>wskazanego nadawcy przelew chciał anulować. Jednak ten znak można łatwo „stworzyć” za pomocą prostych błędów związanych z szumem tego, co miało być <ACK>lub <NAK>. Zaproponowano podwójne-, <CAN>aby uniknąć tego problemu, ale nie jest jasne, czy zostało to szeroko wdrożone.

Główne problemy

XMODEM został zaprojektowany z myślą o prostocie, bez dużej znajomości innych protokołów przesyłania plików – które i tak były dość rzadkie. Ze względu na swoją prostotę wystąpiło wiele bardzo podstawowych błędów, które mogły spowodować niepowodzenie transferu lub, co gorsza, skutkować nieprawidłowym plikiem, który został niezauważony przez protokół. Większość z nich była spowodowana użyciem prostej sumy kontrolnej do korekcji błędów, która jest podatna na brakujące błędy w danych, jeśli dwa bity są odwrócone, co może się zdarzyć przy odpowiednio krótkim impulsie szumu. Ponadto podobne uszkodzenie nagłówka lub sumy kontrolnej może prowadzić do nieudanego transferu w przypadkach, gdy same dane nie były uszkodzone.

Wielu autorów wprowadziło rozszerzenia do XMODEM, aby rozwiązać te i inne problemy. Wielu prosiło o włączenie tych rozszerzeń jako części nowego standardu XMODEM. Jednak Ward Christensen odmówił zrobienia tego, ponieważ to właśnie brak tych funkcji i związane z nimi kodowanie było potrzebne do ich obsługi, co doprowadziło do powszechnego wykorzystania XMODEM. Jak wyjaśnił:

To był szybki hack, który wykonałem razem, bardzo nieplanowany (jak wszystko, co robię), aby zaspokoić osobistą potrzebę komunikacji z innymi ludźmi. TYLKO fakt, że zostało to zrobione w 8/77 i że od razu umieściłem to w domenie publicznej, sprawił, że stało się to standardem, że jest...
...Ludzie, którzy sugerują, że wprowadzam ZNACZĄCE zmiany w protokole, takie jak „pełny dupleks”, „wiele zaległych bloków”, „wiele miejsc docelowych” itp., itp., nie rozumieją, że niesamowita prostota protokołu jest jednym z powodów przetrwało.

Transfery wsadowe

Innym problemem związanym z XMODEM było to, że wymagało to, aby transfer był sterowany przez użytkownika, a nie zautomatyzowany. Zazwyczaj oznaczało to, że użytkownik nawigował w systemie nadawcy, aby wybrać żądany plik, a następnie używał polecenia, aby przełączyć system w tryb „gotowy do wysłania”. Następnie uruchamialiby transfer ze swojego końca za pomocą polecenia w emulatorze terminala. Jeśli użytkownik chciałby przesłać kolejny plik, musiałby powtórzyć ten proces ponownie.

W celu zautomatyzowanych transferów między dwiema witrynami z czasem wdrożono szereg dodatków do protokołu XMODEM. Ogólnie zakładano, że nadawca będzie kontynuował wysyłanie pliku po pliku, a odbiorca będzie próbował wyzwolić następny plik, wysyłając NAK w normalny sposób na początku przesyłania. Po przekroczeniu limitu czasu NAK można było założyć, że albo nie było więcej plików, albo łącze i tak zostało zerwane.

MODEM7

MODEM7 , znany również jako MODEM7 batch lub Batch XMODEM , był pierwszym znanym rozszerzeniem protokołu XMODEM. Normalny transfer plików XMODEM rozpoczyna się od wysłania przez odbiorcę pojedynczego znaku NAK do nadawcy, który następnie rozpoczyna wysyłanie pojedynczego SOH, aby wskazać początek danych, a następnie pakietów danych.

MODEM7 zmienił to zachowanie tylko nieznacznie, wysyłając nazwę pliku w formacie 8.3 przed <SOH>. Każdy znak był wysyłany indywidualnie i musiał zostać powtórzony przez odbiorcę jako forma korekcji błędów. W przypadku nieświadomej implementacji XMODEM dane te byłyby po prostu ignorowane podczas oczekiwania na przybycie SOH , więc znaki nie byłyby powtarzane, a implementacja mogła wrócić do konwencjonalnego XMODEM. W przypadku oprogramowania „świadomego” można użyć nazwy pliku do zapisania pliku lokalnie. Transfery mogą być kontynuowane z kolejnym <NAK> , każdy plik jest zapisywany pod nazwą wysyłaną do odbiorcy.

Jerry Pournelle w 1983 roku opisał MODEM7 jako „prawdopodobnie najpopularniejszy istniejący program do komunikacji mikrokomputerowej”.

TeLink

MODEM7 wysłał nazwę pliku jako normalny tekst, co oznaczało, że mógł zostać uszkodzony przez te same problemy, których XMODEM próbował uniknąć. Doprowadziło to do wprowadzenia TeLink przez Toma Jenningsa , autora oryginalnych mailerów FidoNet .

TeLink uniknął problemów MODEM7, standaryzując nowy „zerowy pakiet” zawierający informacje o oryginalnym pliku. Obejmowały one nazwę pliku, rozmiar i znacznik czasu , które zostały umieszczone w zwykłym 128-bajtowym bloku XMODEM. Podczas gdy normalny transfer XMODEM zaczynałby się od nadawcy wysyłającego "blok 1" z nagłówkiem <SOH> , pakiet nagłówka TeLink był oznaczony jako "blok 0" i zaczynał się od <SYN> . Pakiet zawierał datę i godzinę utworzenia pliku, nazwę pliku do 16 znaków, rozmiar pliku jako wartość 4-bajtową oraz nazwę programu wysyłającego plik.

Normalna implementacja XMODEM po prostu odrzuciłaby pakiet, zakładając, że numer pakietu został uszkodzony. Prowadziło to jednak do potencjalnego opóźnienia czasowego, jeśli pakiet został odrzucony, ponieważ nadawca nie mógł stwierdzić, czy odbiorca odpowiedział <NAK>, ponieważ nie zrozumiał pakietu zerowego, czy też wystąpił błąd transmisji. Ponieważ TeLink był zwykle używany tylko przez oprogramowanie FidoNet , które wymagało go jako części standardów FidoNet, nie stanowiło to problemu w świecie rzeczywistym, ponieważ oba końce zawsze obsługują ten standard.

Podstawowy system „blok 0” stał się standardem w społeczności FidoNet i został ponownie wykorzystany przez wiele przyszłych protokołów, takich jak SEAlink i YMODEM .

XMODEM-CRC

Suma kontrolna użyta w oryginalnym protokole była niezwykle prosta, a błędy w pakiecie mogły pozostać niezauważone. Doprowadziło to do wprowadzenia XMODEM-CRC przez Johna Byrnsa, który używał 16-bitowego CRC zamiast 8-bitowej sumy kontrolnej. CRC koduje nie tylko dane w pakiecie, ale także ich lokalizację, co pozwala zauważyć błędy w zamianie bitów, które pominęłaby suma kontrolna. Statystycznie dawało to szansę wykrycia błędu o długości poniżej 16 bitów na 99,9999%, a nawet wyższą w przypadku dłuższych ciągów bitów błędów.

XMODEM-CRC został zaprojektowany tak, aby był wstecznie kompatybilny z XMODEM. W tym celu odbiorca wysłał znak C(duże C) zamiast litery <NAK>rozpoczynającej przekaz. Jeśli nadawca odpowiedział, wysyłając pakiet, zakładano, że nadawca „znał” XMODEM-CRC, a odbiorca kontynuował wysyłanie C. Jeśli nie nadchodził żaden pakiet, odbiorca zakładał, że nadawca nie znał protokołu i wysyłał an, <NAK>aby rozpocząć „tradycyjny” transfer XMODEM.

Niestety, ta próba wstecznej kompatybilności miała wadę. Ponieważ było możliwe, że początkowy Cznak zostanie utracony lub uszkodzony, nie można było założyć, że odbiornik nie obsługuje XMODEM-CRC, jeśli pierwsza próba uruchomienia transferu nie powiodła się. Odbiorca próbował więc rozpocząć transmisję trzy razy za pomocą C, czekając trzy sekundy między każdą próbą. Oznaczało to, że jeśli użytkownik wybrał XMODEM-CRC podczas próby rozmowy z dowolnym XMODEM, zgodnie z przeznaczeniem, przed rozpoczęciem przesyłania wystąpiło potencjalne 10-sekundowe opóźnienie.

Aby uniknąć opóźnień, nadawca i odbiorca zazwyczaj wyświetlają XMODEM-CRC oddzielnie od XMODEM, pozwalając użytkownikowi wybrać „podstawowy” XMODEM, jeśli nadawca nie wymienił go wyraźnie. Dla przeciętnego użytkownika XMODEM-CRC był zasadniczo „drugim protokołem” i jako taki traktowany. Nie dotyczyło to jednak mailerów FidoNet, gdzie CRC zostało zdefiniowane jako standard dla wszystkich transferów TeLink.

Większa przepustowość

Ponieważ protokół XMODEM wymagane nadawcę, aby zatrzymać się i czekać na <ACK>lub <NAK>wiadomości z odbiornika, to zazwyczaj jest dość powolne. W erze modemów 300 bit/s cały pakiet 132-bajtowy wymagał nieco ponad 3,5 sekundy do wysłania (132 bajty * (8 bitów na bajt + 1 bit startu + 1 bit stopu) / 300 bitów na sekundę). Zakładając, że odbiorca potrzebuje 0,2 sekundy na <ACK>powrót do nadawcy, a następny pakiet zacznie trafiać do odbiorcy (0,1 sekundy w obie strony), całkowity czas dla jednego pakietu wyniósłby 3,7 sekundy, czyli nieco ponad 92% przepustowości.

Wraz ze wzrostem prędkości modemu stałe opóźnienie potrzebne do wysłania <ACK>/ <NAK>rosło proporcjonalnie do czasu potrzebnego do wysłania pakietu. Na przykład przy 2400 bit/s wysłanie pakietów zajęło tylko 0,44 sekundy, więc jeśli <ACK>/ <NAK>nadal potrzebował 0,2 sekundy na powrót (jest to opóźnienie w sieci, a nie przepustowość), przepustowość spadła poniżej 60%. Przy 9600 bit/s jest to poniżej 30% – więcej czasu spędza się na oczekiwaniu na odpowiedź niż potrzeba na wysłanie pakietu.

W celu rozwiązania tych problemów wprowadzono szereg nowych wersji XMODEM. Podobnie jak wcześniejsze rozszerzenia, te wersje były kompatybilne wstecz z oryginalnym XMODEM i podobnie jak te rozszerzenia, doprowadziło to do dalszego rozbicia środowiska XMODEM w emulatorze terminala użytkownika. W końcu pojawiły się dziesiątki wersji XMODEM.

WXModem

WXmodem , skrót od „Windowed Xmodem”, to wariant XMODEM opracowany przez Petera Boswella w 1986 roku do użytku na liniach o dużym opóźnieniu, w szczególności w publicznych systemach X.25 i PC Pursuit . Mają one znacznie większe opóźnienia niż zwykłe usługi telefoniczne , co prowadzi do bardzo słabej wydajności XMODEM. Ponadto sieci te często używają znaków sterujących do sterowania przepływem i innych zadań, w szczególności XON/XOFF zatrzyma przepływ danych. Wreszcie, w przypadku błędu, który wymagał ponownego wysłania, czasami trudno było stwierdzić, czy SOH jest wskaźnikiem pakietu, czy więcej szumem. WXmodem dostosował XMODEM-CRC do rozwiązania tych problemów.

Jedną ze zmian była ucieczka od małego zestawu znaków kontrolnych, DLE , XON , XOFF i SYN . Uniknięto ich przez wstawienie przed nimi DLE , a następnie zmodyfikowanie znaku przez XORowanie go za pomocą 64. Teoretycznie oznaczało to, że pakiet może mieć długość nawet 264 bajtów, jeśli pierwotnie składał się wyłącznie ze znaków wymagających ucieczki. Te wstawione i zmodyfikowane znaki nie są częścią obliczania CRC, są usuwane i konwertowane po stronie odbiorczej przed obliczeniem CRC.

Dodatkowo, wszystkie pakiety były poprzedzone znakiem SYN , co oznaczało, że wiodącym pakietem był SYN SOH , co zmniejsza prawdopodobieństwo, że zabłąkany SOH zostanie pomylony z nagłówkiem pakietu w różnych przypadkach błędów. Nieuciekający SYN znaleziony w treści pakietu był błędem.

Główną zmianą w WXMODEM jest użycie przesuwanego okna w celu poprawy przepustowości łączy o dużym opóźnieniu. Aby to zrobić, po komunikatach ACK następował numer pakietu, który był ACK lub NAK ing. Odbiorca nie musi potwierdzać każdego pakietu, może potwierdzać dowolną liczbę z zakresu od jednego do czterech pakietów. Zakłada się, że ACK z czwartym numerem sekwencji pakietu potwierdza wszystkie cztery pakiety. Błąd powoduje natychmiastowe wysłanie NAK , ze wszystkimi pakietami z tego numeru i po ponownym wysłaniu.

Wymaganie ACK co cztery pakiety sprawia, że ​​system działa tak, jakby miał pakiet o rozmiarze 512 bajtów, ale w przypadku błędu zwykle do ponownego wysłania wymaga tylko 128 bajtów. Co więcej, czterokrotnie zmniejsza ilość danych przepływających w odwrotnym kierunku. Nie ma to większego znaczenia w typowym trybie pełnego dupleksu , ale jest ważne w systemach półdupleksowych , takich jak modele Telebit , które mają prędkość 19 kB w jednym kierunku i 75 bitów/sw kanale zwrotnym.

SEAlink

Jednym z pierwszych programów pocztowych innych firm dla systemu FidoNet był SEAdog , napisany przez tego samego autora jako popularny wówczas format kompresji danych .arc . SEAdog wprowadził szeroką gamę ulepszeń, w tym SEAlink , ulepszony protokół przesyłania oparty na tej samej koncepcji przesuwanego okna, co WXmodem. Od WXmodem różnił się głównie szczegółami.

Jedyną różnicą jest to, że SEAlink obsługiwał „zerowy pakiet” wprowadzony przez TeLinka, który jest potrzebny do działania jako zamiennik drop-in dla TeLinka w systemach FidoNet, gdzie oczekiwano nagłówka. ACK i NAK zostały rozszerzone do trzybajtowych „pakietów”, zaczynając od ACK lub NAK , następnie numeru pakietu, a następnie uzupełnienia numeru pakietu, w taki sam sposób jak oryginalny nagłówek pakietu XMODEM. Rozmiar okna był zwykle ustawiony na sześć pakietów.

SEAlink nie miał działać przez X.25 lub podobne łącza, a zatem nie wykonywał ucieczki. Było to również potrzebne, aby pakiet zerowy działał poprawnie, ponieważ ten standard używał znaku SYN, który WXmodem zmienił. Oprócz tych zmian dodano tryb „Overdrive” dla łączy półdupleksowych. To tłumiło potwierdzenia ACK dla pakietów, które zostały pomyślnie przesłane, w efekcie tworząc okno o nieskończonym rozmiarze. Ten tryb był sygnalizowany flagą w bloku zerowym.

SEAlink później dodał szereg innych ulepszeń i był użytecznym protokołem ogólnego przeznaczenia. Jednak poza światem FidoNet pozostawał rzadkością i rzadko widywano go w oprogramowaniu skierowanym do użytkownika.

XMODEM-1K

Innym sposobem rozwiązania problemu z przepustowością jest zwiększenie rozmiaru pakietu. Chociaż podstawowy problem latencji pozostaje, szybkość, z jaką staje się problemem, jest większa. Najpopularniejszym takim rozwiązaniem był XMODEM-1K z pakietami 1024 bajtów. W tym przypadku przepustowość przy 9600 bit/s wynosi 81%, przy takich samych założeniach jak powyżej.

XMODEM-1K był rozszerzoną wersją XMODEM-CRC, która wskazywała większy rozmiar bloku w nadawcy , rozpoczynając pakiet od <STX>znaku zamiast <SOH>. Podobnie jak w przypadku innych zgodnych wstecznie rozszerzeń XMODEM, zamierzano rozpocząć transfer -1K z dowolną implementacją XMODEM na drugim końcu, cofając funkcje zgodnie z wymaganiami.

XMODEM-1K był pierwotnie jednym z wielu ulepszeń XMODEM wprowadzonych przez Chucka Forsberga w jego protokole YMODEM . Forsberg zasugerował, że różne ulepszenia były opcjonalne, oczekując, że twórcy oprogramowania zaimplementują ich jak najwięcej. Zamiast tego generalnie zaimplementowali absolutne minimum, co doprowadziło do obfitości częściowo zgodnych implementacji, a ostatecznie do podziału nazwy „YMODEM” na „XMODEM-1K” i różne rodzaje YMODEM. Tak więc XMODEM-1K faktycznie jest starszy od YMODEM, ale i tak pozostał dość powszechny.

NMODEM

NMODEM to protokół przesyłania plików opracowany przez LB Neala, który wydał go w 1990 roku. NMODEM jest zasadniczo wersją XMODEM-CRC wykorzystującą większe 2048-bajtowe bloki, w przeciwieństwie do 128-bajtowych bloków XMODEM. NMODEM został zaimplementowany jako osobny program, napisany w Turbo Pascal 5.0 dla rodziny komputerów kompatybilnych z IBM PC . Rozmiar bloku został dobrany tak, aby odpowiadał typowemu rozmiarowi klastra systemu plików MS-DOS FAT na współczesnych dyskach twardych , ułatwiając buforowanie danych do zapisu.

Spoofing protokołu

Dzięki niezawodnym (wolnym od błędów) połączeniom możliwe jest wyeliminowanie opóźnień poprzez „wstępne potwierdzanie” pakietów, technikę znaną bardziej ogólnie jako „ spoofing protokołu ”. Jest to zwykle realizowane w sprzęcie łącza, zwłaszcza w modemach Telebit. Modemy, gdy opcja była włączona, zauważyłyby nagłówek XMODEM i natychmiast wysłały ACK . Spowodowałoby to, że wysyłający program XMODEM natychmiast wysłałby następny pakiet, czyniąc transfer ciągłym, jak okno o nieskończonej wielkości. Modemy tłumią również ACK wysyłane przez oprogramowanie XMODEM na odległym końcu, zwalniając w ten sposób kanał zwrotny o niskiej prędkości.

System można również zaimplementować w samym protokole, a odmiany XMODEM oferowały tę funkcję. W takich przypadkach odbiorca wysyła ACK natychmiast po uruchomieniu pakietu, w taki sam sposób jak modemy Telebit. Ponieważ ta funkcja jest jedynie zmianą zachowania po stronie odbiorcy, nie wymaga żadnych zmian w protokole po stronie nadawcy. YMODEM sformalizował ten system.

Ta koncepcja powinna być skontrastowana z tą stosowaną w SEAlink, która zmienia zachowanie po obu stronach łącza. W SEAlink odbiorca całkowicie przestaje wysyłać ACK , a nadawca zmienia swoje zachowanie, aby ich nie oczekiwać.

Zobacz też

Bibliografia

Cytaty

Bibliografia

Zewnętrzne linki