XMODEM - XMODEM

XMODEM
Komunikační protokol
Účel protokol pro přenos souborů
Vývojáři Ward Christensen
Představeno 1977 ; Před 44 lety ( 1977 )
Ovlivněn YMODEM , mnoho dalších
Hardware modemy

XMODEM je jednoduchý přenos souborů protokol vyvinutý pro rychlý hack od Ward Christensen pro použití v jeho 1977 MODEM.ASM program terminálu . To umožnilo uživatelům přenášet soubory mezi jejich počítači, když obě strany používaly MODEM. Keith Petersen provedl menší aktualizaci, aby vždy zapnul „tichý režim“, a výsledek nazval XMODEM.

XMODEM, jako většina protokolů pro přenos souborů, rozděluje původní data na řadu „ paketů “, které jsou odesílány příjemci, spolu s dalšími informacemi, které přijímači umožňují určit, zda byl tento paket správně přijat. Pokud je detekována chyba, příjemce požaduje, aby byl paket znovu odeslán. Řetězec špatných paketů způsobí přerušení přenosu.

XMODEM se stal velmi populárním na trhu raného systému BBS (BBS), a to především proto, že jeho implementace byla jednoduchá. Bylo to také docela neefektivní a jak se zvyšovaly rychlosti modemu, tento problém vedl k vývoji řady upravených verzí XMODEM ke zlepšení výkonu nebo řešení dalších problémů s protokolem. Christensen věřil, že jeho původní XMODEM je „jediným nejvíce upraveným programem v historii počítačů“.

Chuck Forsberg shromáždil do svého protokolu YMODEM řadu běžných modifikací , ale špatná implementace vedla k dalšímu štěpení, než byly znovu sjednoceny jeho pozdějším protokolem ZMODEM . ZMODEM se stal velmi populárním, ale nikdy zcela nenahradil XMODEM na trhu BBS.

Struktura paketu

Původní XMODEM používal 128bajtový datový paket, základní velikost bloku používaná na disketách CP/M . Paketu předcházela jednoduchá 3bajtová hlavička obsahující znak, „číslo bloku“ od 0 do 255 a „inverzní“ číslo bloku-255 minus číslo bloku. Číslování bloků začíná 1 pro první odeslaný blok, ne 0. Po záhlaví následovalo 128 bajtů dat a poté jednobajtový kontrolní součet . Kompletní paket byl tedy dlouhý 132 bytů, obsahující 128 bytů dat užitečného zatížení , s celkovou účinností kanálu přibližně 97%. <SOH>

Kontrolní součet byl součtem všech bytů v paketu modulo 256. Operace modulo byla snadno vypočítána vyřazením všech kromě osmi nejméně významných bitů výsledku, nebo alternativně na osmibitovém počítači, ignorování aritmetického přetečení, které by produkovalo stejné účinek automaticky. Tímto způsobem byl kontrolní součet omezen na osmibitové množství. Pokud byla například tato metoda kontrolního součtu použita na malém datovém paketu obsahujícím pouze dva bajty s hodnotami 130 a 130, součet těchto kódů je 260 a výsledný kontrolní součet je 4.

Soubor byl označen jako „dokončený“ znakem odeslaným po posledním bloku. Tento znak nebyl v paketu, ale byl odeslán samostatně jako jeden bajt. Protože délka souboru nebyla odeslána jako součást protokolu, poslední paket byl vyplněn „známým znakem“, který bylo možné zahodit. V původní specifikaci to bylo výchozí nebo 26 desetinných míst, které CP/M použil jako značku konce souboru ve svém vlastním formátu disku. Standard navrhoval, aby pro odsazení mohl být použit jakýkoli znak, ale v samotném protokolu to nebylo možné změnit - pokud by implementace změnila znak odsazení, nový klientský znak by správně interpretovali pouze klienti používající stejnou implementaci. <EOT><SUB>

Podrobnosti o převodu

Soubory byly přenášeny po jednom paketu. Při přijetí byl přijímačem vypočítán kontrolní součet paketu a porovnán s součtem přijatým od odesílatele na konci paketu. Pokud se ti dva shodují, příjemce poslal zprávu zpět odesílateli, který pak poslal další paket v pořadí. Pokud byl problém s kontrolním součtem, příjemce místo toho poslal a . Pokud bylo přijato a, odesílatel paket znovu odešle a pokračuje ve zkoušení několikrát, obvykle deset, než přenos přeruší. <ACK><NAK><NAK>

A <NAK>bylo také odesláno, pokud příjemce neobdržel platný paket do deseti sekund, zatímco stále očekával data kvůli nedostatku <EOT>znaku. V rámci paketu byl také použit sedmisekundový časový limit , který chránil před vypadnutím spojení v polovině paketu.

Rovněž byla jednoduchým způsobem zkontrolována čísla bloků a zkontrolovány chyby. Po úspěšném přijetí paketu by měl mít další paket jedno vyšší číslo. Pokud místo toho obdrželo stejné číslo bloku, nebylo to považováno za vážné, znamenalo to, že <ACK>to nebylo přijato odesílatelem, který paket znovu odeslal. Jakékoli jiné číslo paketu signalizovalo ztrátu paketů.

Převody byly řízeny přijímačem; vysílač by neposílal žádná data, dokud <NAK>by přijímač neposlal iniciálu. To byl logický výsledek způsobu, jakým uživatel interagoval s odesílajícím strojem, který by byl vzdáleně umístěn. Uživatel by na odesílajícím počítači navigoval k požadovanému souboru a poté požádal tento počítač o jeho přenos. Jakmile byl tento příkaz vydán, uživatel poté provedl příkaz v místním softwaru, aby zahájil příjem. Protože zpoždění mezi žádáním vzdáleného systému o přijetí souboru a vydáním místního příkazu k přijetí nebylo známé, XMODEM umožnil přijímači zahájit vydávání požadavků na datové pakety až 90 sekund.

Problémy

Ačkoli XMODEM byl dostatečně robustní, aby novinář v roce 1982 mohl přenášet příběhy z Pákistánu do USA pomocí Osborne 1 a akustického spojovacího zařízení přes nekvalitní telefonní linky, protokol měl několik nedostatků.

Drobné problémy

XMODEM byl napsán pro stroje CP/M a nese několik značek tohoto operačního systému . Soubory na CP/M byly vždy násobky 128 bajtů a jejich konec byl označen v bloku <EOT>znakem. Tyto charakteristiky byly transplantovány přímo do XMODEM. Jiné operační systémy však nevykazovaly ani jednu z těchto zvláštností a rozsáhlé zavedení systému MS-DOS na začátku osmdesátých let vedlo k tomu, že XMODEM musel být aktualizován, aby si všiml značky a <EOT> nebo <EOF> jako konce souboru.

Nějakou dobu se navrhovalo, že by mělo být podporováno odesílání <CAN>znaku místo <ACK>nebo nebo <NAK>, aby se přenos z přijímacího konce snadno přerušil. Stejně tak <CAN>přijatý na místě <SOH>uvedeného odesílatele si přál převod zrušit. Tento znak však lze snadno „vytvořit“ pomocí jednoduchých chyb souvisejících s hlukem toho, co mělo být <ACK>or nebo <NAK>. <CAN>Aby se tomuto problému vyhnul, bylo navrženo dvojité řešení, ale není jasné, zda bylo toto široce implementováno.

Zásadní problémy

XMODEM byl navržen pro jednoduchost, bez velké znalosti dalších protokolů pro přenos souborů - které byly každopádně poměrně vzácné. Díky své jednoduchosti došlo k řadě velmi základních chyb, které by mohly způsobit selhání přenosu, v horším případě to mělo za následek nesprávný soubor, který si protokol nevšiml. Většina z toho byla způsobena použitím jednoduchého kontrolního součtu pro opravu chyb, který je citlivý na chybějící chyby v datech, pokud jsou obráceny dva bity, což se může stát při vhodně krátké dávce šumu. Navíc podobné poškození záhlaví nebo kontrolního součtu by mohlo vést k neúspěšnému přenosu v případech, kdy samotná data byla nepoškozena.

Mnoho autorů zavedlo rozšíření XMODEM k řešení těchto a dalších problémů. Mnozí žádali, aby byla tato rozšíření zahrnuta jako součást nového standardu XMODEM. Ward Christensen to však odmítl, protože to byl právě nedostatek těchto funkcí a související kódování potřebné k jejich podpoře, což vedlo k rozšířenému používání XMODEM. Jak vysvětlil:

Byl to rychlý hack, který jsem hodil dohromady, velmi neplánovaně (jako všechno, co dělám), abych uspokojil osobní potřebu komunikovat s některými dalšími lidmi. POUZE skutečnost, že to bylo provedeno v 8/77, a že jsem to okamžitě dal do veřejné sféry, z toho udělalo standard, že to je ...
... Lidé, kteří navrhují, abych provedl VÝZNAMNÉ změny v protokolu, jako například 'plný duplex', 'více nevyřízených bloků', 'více destinací' atd. Atd. Nechápou, že jedním z důvodů je neuvěřitelná jednoduchost protokolu přežilo to.

Dávkové převody

Dalším problémem XMODEM bylo, že vyžadoval, aby byl přenos řízen uživateli, nikoli automatizovaný. Obvykle to znamenalo, že uživatel přejde v systému odesílatele, aby vybral požadovaný soubor, a poté pomocí příkazu přepnul tento systém do režimu „připraven k odeslání“. Potom by spustili přenos ze svého konce pomocí příkazu v emulátoru terminálu. Pokud by uživatel chtěl přenést další soubor, musel by tento proces zopakovat znovu.

U automatizovaných přenosů mezi dvěma weby byla v průběhu času implementována řada doplňků k protokolu XMODEM. Tito obecně předpokládali, že odesílatel bude pokračovat v odesílání souboru po souboru, přičemž se příjemce pokusí spustit další soubor odesláním NAK jako obvykle na začátku přenosu. Když vypršel časový limit NAK , dalo se předpokládat, že buď nebyly žádné další soubory, nebo byl odkaz stejně přerušen.

MODEM7

MODEM7 , také známý jako MODEM7 batch nebo Batch XMODEM , byl prvním známým rozšířením protokolu XMODEM. Normální přenos souborů XMODEM začíná tím, že příjemce pošle odesílateli jeden znak NAK , který pak začne odesílat jeden SOH pro označení začátku dat, a pak pakety dat.

MODEM7 toto chování změnil jen nepatrně, odesláním názvu souboru ve formátu 8,3 názvu souboru před <SOH>. Každá postava byla odeslána jednotlivě a příjemce ji musel zopakovat jako formu opravy chyb. U nevědomé implementace XMODEM by tato data byla jednoduše ignorována, zatímco by čekala na příchod SOH , takže znaky by nebyly ozvěny a implementace by mohla spadnout zpět do konvenčního XMODEM. S "vědomým" softwarem by název souboru mohl být použit k místnímu uložení souboru. Přenosy mohou pokračovat dalším <NAK> , každý soubor je uložen pod jménem odesílaným do přijímače.

Jerry Pournelle v roce 1983 popsal MODEM7 jako „pravděpodobně nejpopulárnější existující mikropočítačový komunikační program“.

TeLink

MODEM7 odeslal název souboru jako normální text, což znamenalo, že může být poškozen stejnými problémy, kterým se XMODEM pokoušel vyhnout. To vedlo k zavedení TeLink od Toma Jenningsa , autora původních mailerů FidoNet .

TeLink se vyhnul problémům MODEM7 standardizací nového „nulového paketu“ obsahujícího informace o původním souboru. To zahrnovalo název souboru, velikost a časové razítko , které byly umístěny do pravidelného 128 bajtového bloku XMODEM. Zatímco normální přenos XMODEM by začínal odesílatelem odesílajícím "blok 1" se záhlavím <SOH> , paket záhlaví TeLink byl označen jako "blok 0" a začínal <SYN> . Paket obsahoval datum a čas vytvoření souboru, název souboru až 16 znaků, velikost souboru jako hodnotu 4 bajtů a název programu odesílajícího soubor.

Běžná implementace XMODEM by paket jednoduše zahodila, za předpokladu, že by bylo poškozeno číslo paketu. To však vedlo k potenciálnímu časovému zpoždění, pokud byl paket vyřazen, protože odesílatel nemohl zjistit, zda příjemce odpověděl <NAK>, protože nerozuměl nulovému paketu nebo došlo k chybě přenosu. Jelikož TeLink normálně používal pouze software FidoNet , který jej požadoval jako součást standardů FidoNet, nepředstavovalo to problém skutečného světa, protože oba konce tento standard vždy podporovaly.

Základní systém „block 0“ se stal standardem v komunitě Fidonet, a byla znovu použita celá řada dalších protokolů jako SEAlink a YMODEMU .

XMODEM-CRC

Kontrolní součet použitý v původním protokolu byl extrémně jednoduchý a chyby v paketu mohly zůstat bez povšimnutí. To vedlo k zavedení XMODEM-CRC Johnem Byrnsem, který místo 8bitového kontrolního součtu používal 16bitový CRC . CRC kódují nejen data v paketu, ale také jeho umístění, což mu umožňuje zaznamenat chyby při výměně bitů, které by kontrolní součet chyběly. Statisticky to znamenalo, že šance na detekci chyby kratší než 16 bitů je 99,9969%a ještě vyšší u delších řetězců chybových bitů.

XMODEM-CRC byl navržen tak, aby byl zpětně kompatibilní s XMODEM. Chcete -li to provést, příjemce odeslal znak C(velké C) místo a <NAK>ke spuštění přenosu. Pokud odesílatel odpověděl odesláním paketu, předpokládalo se, že odesílatel „znal“ XMODEM-CRC, a příjemce pokračoval ve odesílání C. Pokud nepřišel žádný paket, přijímač předpokládal, že odesílatel nezná protokol, a odeslal příkaz <NAK>k zahájení „tradičního“ přenosu XMODEM.

Bohužel tento pokus o zpětnou kompatibilitu měl stinnou stránku. Protože bylo možné, že původní Cznak bude ztracen nebo poškozen, nebylo možné předpokládat, že by přijímač nepodporoval XMODEM-CRC, pokud první pokus o spuštění přenosu selhal. Přijímač se tedy pokusil zahájit přenos třikrát, přičemž Cmezi každým pokusem čekal tři sekundy. To znamenalo, že pokud si uživatel vybral XMODEM-CRC při pokusu hovořit s jakýmkoli XMODEM, jak bylo zamýšleno, došlo k potenciálnímu 10sekundovému zpoždění před zahájením přenosu.

Aby se předešlo zpoždění, odesílatel a přijímač by obecně uváděli XMODEM-CRC odděleně od XMODEM, což by uživateli umožnilo vybrat „základní“ XMODEM, pokud jej odesílatel výslovně neuvádí. Pro průměrného uživatele byl XMODEM-CRC v podstatě „druhým protokolem“ a byl s ním zacházeno jako s takovým. To však neplatilo pro poštovní zásilky FidoNet, kde bylo CRC definováno jako standard pro všechny převody TeLink.

Vyšší propustnost

Vzhledem k tomu, že protokol XMODEM vyžadoval, aby odesílatel zastavil a čekal na zprávu <ACK>nebo <NAK>od příjemce, mělo to tendenci být docela pomalé. V éře modemů 300 bit / s vyžadoval celý 132bajtový paket odeslání jen něco málo přes 3,5 sekundy (132 bajtů * (8 bitů na byte + 1 počáteční bit + 1 stop bit) / 300 bitů za sekundu). Za předpokladu, že trvá 0,2 sekundy, než se přijímač dostane <ACK>zpět k odesílateli a další paket začne zasílat přijímač (0,1 sekundy v obou směrech), celkový čas pro jeden paket by byl 3,7 sekundy, což je o něco více než 92% propustnost.

Jak se zvyšovaly rychlosti modemu, pevná prodleva potřebná k odeslání <ACK>/ <NAK>rostla v poměru k času potřebnému k odeslání paketu. Například při 2400 bit / s trvalo odeslání paketů pouze 0,44 sekundy, takže pokud <ACK>/ <NAK>trvalo vrácení zpět 0,2 sekundy (jedná se o latenci v síti, nikoli o propustnost), propustnost klesla pod 60%. Při 9600 bit/s je to méně než 30% - čekáním na odpověď strávíte více času, než je nutné k odeslání paketu.

Za účelem řešení těchto problémů byla zavedena řada nových verzí XMODEM. Stejně jako dřívější rozšíření měly i tyto verze tendenci být zpětně kompatibilní s původním XMODEM a stejně jako tato rozšíření to vedlo k dalšímu rozbití krajiny XMODEM v emulátoru koncového uživatele. Nakonec vznikly desítky verzí XMODEM.

WXModem

WXmodem , zkratka pro „Windowed Xmodem“, je varianta XMODEM vyvinutá Peterem Boswellem v roce 1986 pro použití na linkách s vysokou latencí, konkrétně veřejných systémech X.25 a PC Pursuit . Mají latence, které jsou mnohem vyšší než obyčejná telefonní služba , což vede k velmi špatné efektivitě XMODEM. Tyto sítě navíc často používají řídicí znaky pro řízení toku a další úkoly, zejména XON/XOFF zastaví tok dat. Nakonec v případě chyby, která vyžadovala opětovné odeslání, bylo někdy obtížné zjistit, zda je SOH indikátorem paketu nebo více šumu. WXmodem přizpůsobil XMODEM-CRC k řešení těchto problémů.

Jednou změnou bylo uniknout z malé sady ovládacích znaků, DLE , XON , XOFF a SYN . Ty unikly vložením DLE před ně a následnou úpravou znaku XORingem s 64. Teoreticky to znamenalo, že paket může být dlouhý až 264 bytů, pokud původně sestával výhradně ze znaků, které vyžadovaly únik. Tyto vložené a upravené znaky nejsou součástí výpočtu CRC, jsou před výpočtem CRC odstraněny a převedeny na přijímacím konci.

Všechny pakety byly navíc opatřeny znakem SYN , což znamenalo, že zaváděcí paket byl SYN SOH , což snižuje pravděpodobnost záměny zbloudilého SOH za záhlaví paketu v různých chybových případech. Neuzavřená SYN nalezená v těle paketu byla chyba.

Hlavní změnou ve WXMODEM je použití posuvného okna pro zlepšení propustnosti odkazů s vysokou latencí. Aby to bylo možné, za zprávami ACK následovalo číslo paketu, kterým byli ACK ing nebo NAK ing. Přijímač nemusí ACK každý paket, je povoleno ACK libovolné číslo mezi jedním a čtyřmi pakety. Předpokládá se, že ACK se čtvrtým pořadovým číslem paketu ACK všechny čtyři pakety. Chyba způsobí, že NAK bude odeslán okamžitě, se všemi pakety z tohoto čísla a po opětovném odeslání.

Vyžadováním ACK každé čtyři pakety systém funguje, jako by měl velikost paketu 512 bajtů, ale v případě chyby je obvykle nutné znovu odeslat pouze 128 bajtů. Kromě toho čtyřikrát snižuje množství dat proudících v opačném směru. To je málo zajímavé pro plně duplexní provoz typického modemu , ale je to důležité u polovičních duplexních systémů, jako jsou modely Telebit, které mají rychlost 19 kB v jednom směru a 75 bitů/s ve zpětném kanálu.

SEAlink

Jedním z prvních mailerů třetích stran pro systém FidoNet byl SEAdog , napsaný stejným autorem jako tehdy populární formát komprese dat .arc . SEAdog zahrnoval celou řadu vylepšení, včetně SEAlink , vylepšeného přenosového protokolu založeného na stejném konceptu posuvných oken jako WXmodem. To se lišilo od WXmodem většinou v detailech.

Jeden rozdíl je v tom, že SEAlink podporoval „nulový paket“ zavedený společností TeLink, který je potřebný k tomu, aby fungoval jako náhrada za TeLink v systémech FidoNet, kde se očekávalo záhlaví. ACK s a NAK s byly rozšířeny na tříbajtové „pakety“, počínaje ACK nebo NAK , pak číslem paketu, pak doplňkem čísla paketu, stejným způsobem jako původní záhlaví paketu XMODEM. Velikost okna byla normálně nastavena na šest paketů.

Neočekávalo se, že SEAlink bude fungovat přes X.25 nebo podobné odkazy, a proto neprovedl únik. To bylo také zapotřebí, aby nulový paket fungoval správně, protože tento standard používal znak SYN, který WXmodem přepracoval. Kromě těchto změn přidal režim „Overdrive“ pro poloviční duplexní odkazy. Tím byly potlačeny ACK pro pakety, které byly úspěšně přeneseny, čímž ve skutečnosti bylo okno nekonečné velikosti. Tento režim byl indikován příznakem v nulovém bloku.

SEAlink později přidal řadu dalších vylepšení a byl užitečným protokolem pro obecné účely. Mimo svět FidoNet však zůstával vzácný a v softwaru orientovaném na uživatele se vyskytoval jen zřídka.

XMODEM-1K

Dalším způsobem, jak vyřešit problém s propustností, je zvětšit velikost paketu. Přestože základní problém latence zůstává, rychlost, s níž se stává problémem, je vyšší. Nejpopulárnějším takovým řešením byl XMODEM-1K s 1024 bajtovými pakety. V tomto případě je propustnost 9600 bit/s 81%, při stejných předpokladech jako výše.

XMODEM-1K byla rozšířená verze XMODEM-CRC, která indikovala delší velikost bloku u odesílatele spuštěním paketu se <STX>znakem místo <SOH>. Stejně jako ostatní zpětně kompatibilní rozšíření XMODEM bylo zamýšleno, že přenos -1K by mohl být zahájen s jakoukoli implementací XMODEM na druhém konci, podle potřeby zálohovat funkce.

XMODEM-1K byl původně jedním z mnoha vylepšení XMODEM, které zavedl Chuck Forsberg ve svém protokolu YMODEM . Forsberg navrhl, aby různá vylepšení byla volitelná, a očekával, že autoři softwaru implementují co nejvíce z nich. Místo toho obecně implementovali naprosté minimum, což vedlo k hojnosti polokompatibilních implementací a nakonec k rozdělení názvu „YMODEM“ na „XMODEM-1K“ a řadu YMODEMů. XMODEM-1K tedy vlastně datuje YMODEM, ale i tak zůstal docela běžný.

NMODEM

NMODEM je protokol pro přenos souborů vyvinutý LB Neal, který jej vydal v roce 1990. NMODEM je v podstatě verze XMODEM-CRC využívající větší bloky 2 048 bajtů, na rozdíl od 128 bajtů bloků XMODEM. NMODEM byl implementován jako samostatný program, napsaný v Turbo Pascal 5.0 pro rodinu počítačů kompatibilních s IBM PC . Velikost bloku byla zvolena tak, aby odpovídala běžné velikosti klastru systému souborů MS-DOS FAT na současných pevných discích , což usnadňuje ukládání dat do vyrovnávací paměti pro zápis.

Spoofing protokolu

Přes spolehlivá (bezchybná) připojení je možné eliminovat latenci „předběžným potvrzením“ paketů, což je technika obecněji známá jako „ falšování protokolů “. Toho je obvykle dosaženo v propojovacím hardwaru, zejména v modemech Telebit. Modemy, když byla možnost zapnutá, si všimnou záhlaví XMODEM a okamžitě odešlou ACK . To by způsobilo, že odesílající program XMODEM okamžitě odešle další paket, čímž bude přenos kontinuální, jako okno nekonečné velikosti. Modemy také potlačují ACK odesílané softwarem XMODEM na vzdálenějším konci, čímž uvolňují zpětný kanál s nízkou rychlostí.

Systém lze také implementovat do samotného protokolu a variace XMODEM tuto funkci nabízely. V těchto případech by přijímač odeslal ACK , jakmile paket začal, stejným způsobem jako modemy Telebit. Protože tato funkce je pouze změnou chování na straně příjemce, nevyžaduje žádné změny v protokolu na straně odesílatele. YMODEM tento systém formalizoval.

Tento koncept by měl být v kontrastu s konceptem použitým v SEAlink, který mění chování na obou stranách odkazu. V SEAlink přijímač zcela zastaví odesílání ACK a odesílatel změní své chování, aby je neočekával.

Viz také

Reference

Citace

Bibliografie

externí odkazy