XMODEM - XMODEM

XMODEM
Kommunikasjonsprotokoll
Hensikt Filoverføringsprotokoll
Utvikler (er) Ward Christensen
Introdusert 1977 ; 44 år siden ( 1977 )
Påvirket YMODEM , mange andre
Maskinvare modemer

XMODEM er en enkel filoverføringsprotokoll utviklet som en rask hack av Ward Christensen for bruk i hans MODEM.ASM -terminalprogram fra 1977 . Det tillot brukere å overføre filer mellom datamaskinene når begge sider brukte MODEM. Keith Petersen gjorde en liten oppdatering for alltid å slå på "stille modus", og kalte resultatet XMODEM.

XMODEM, som de fleste filoverføringsprotokoller, bryter de originale dataene opp i en serie " pakker " som sendes til mottakeren, sammen med tilleggsinformasjon som gjør at mottakeren kan avgjøre om pakken er riktig mottatt. Hvis det oppdages en feil, ber mottakeren om at pakken sendes på nytt. En streng med dårlige pakker får overføringen til å avbrytes.

XMODEM ble ekstremt populær i markedet for tidlige oppslagstavler (BBS), hovedsakelig fordi det var enkelt å implementere. Det var også ganske ineffektivt, og ettersom modemhastighetene økte, førte dette problemet til utviklingen av en rekke modifiserte versjoner av XMODEM for å forbedre ytelsen eller løse andre problemer med protokollen. Christensen mente at hans originale XMODEM var "det mest mest modifiserte programmet i databehandlingshistorie".

Chuck Forsberg samlet en rekke vanlige modifikasjoner i YMODEM- protokollen, men dårlig implementering førte til ytterligere brudd før de ble gjenforent av hans senere ZMODEM- protokoll. ZMODEM ble veldig populær, men erstattet aldri XMODEM helt i BBS -markedet.

Pakkestruktur

Den originale XMODEM brukte en 128-byte datapakke, den grunnleggende blokkstørrelsen som ble brukt på CP/M- disketter . Pakken var prefikset med en enkel 3-byte overskrift som inneholder et tegn, et "blokknummer" fra 0-255 og det "inverse" blokknummeret-255 minus blokknummeret. Blokkeringsnummerering starter med 1 for den første blokken som sendes, ikke 0. Overskriften ble fulgt av 128 byte med data, og deretter en enkeltbytes kontrollsum . Hele pakken var dermed 132 byte lang og inneholdt 128 byte nyttelastdata for en total kanaleffektivitet på omtrent 97%. <SOH>

Kontrollsummen var summen av alle byte i pakken modulo 256. Moduloperasjonen ble lett beregnet ved å kaste alle bortsett fra de åtte minst signifikante bitene i resultatet, eller alternativt på en åtte-bits maskin, uten å overse aritmetisk overløp som ville produsere det samme effekt automatisk. På denne måten ble kontrollsummen begrenset til en åtte-bits mengde. For eksempel, hvis denne kontrollsummetoden ble brukt på en liten datapakke som bare inneholder to byte som bærer verdiene 130 og 130, er summen av disse kodene 260 og den resulterende kontrollsummen er 4.

Filen ble merket "komplett" med et tegn sendt etter den siste blokken. Denne karakteren var ikke i en pakke, men sendt alene som en enkelt byte. Siden fillengden ikke ble sendt som en del av protokollen, ble den siste pakken polstret ut med et "kjent tegn" som kunne slippes. I den opprinnelige spesifikasjonen er dette standard til eller 26 desimaler, som CP/M brukte som slutten av filmarkøren i sitt eget diskformat. Standarden foreslo at ethvert tegn kunne brukes til polstring, men det var ingen måte å endre det i selve protokollen - hvis en implementering endret polstringstegnet, ville bare klienter som bruker samme implementering tolke det nye polstringstegnet på riktig måte. <EOT><SUB>

Overføringsdetaljer

Filene ble overført en pakke om gangen. Når den ble mottatt, ble pakkens kontrollsum beregnet av mottakeren og sammenlignet med den mottatt fra avsenderen på slutten av pakken. Hvis de to passet, sendte mottakeren en melding tilbake til avsenderen, som deretter sendte den neste pakken i rekkefølge. Hvis det var et problem med kontrollsummen, sendte mottakeren i stedet en . Hvis a ble mottatt, sendte avsenderen pakken på nytt og fortsatte å prøve flere ganger, normalt ti, før avbruddet ble avbrutt. <ACK><NAK><NAK>

A <NAK>ble også sendt hvis mottakeren ikke mottok en gyldig pakke innen ti sekunder mens den fortsatt ventet data på grunn av mangel på et <EOT>tegn. En syv-sekunders timeout ble også brukt i en pakke, og beskyttet mot at forbindelser i midten av pakken falt.

Blokkertallene ble også undersøkt på en enkel måte for å se etter feil. Etter å ha mottatt en pakke, bør den neste pakken ha et tall høyere. Hvis den i stedet mottok det samme blokknummeret ble dette ikke ansett som alvorlig, det var underforstått at det <ACK>ikke var mottatt av avsenderen, som da hadde sendt pakken på nytt. Ethvert annet pakkenummer signaliserte at pakker hadde gått tapt.

Overføringer var mottakerdrevne; senderen ville ikke sende noen data før en initial <NAK>ble sendt av mottakeren. Dette var et logisk utfall av måten brukeren samhandlet med sendemaskinen, som ville bli lokalisert eksternt. Brukeren navigerer til den forespurte filen på sendemaskinen, og ber deretter maskinen om å overføre den. Når denne kommandoen ble utstedt, ville brukeren deretter utføre en kommando i sin lokale programvare for å begynne å motta. Siden forsinkelsen mellom å be det eksterne systemet om filen og utstedelse av en lokal kommando for å motta var ukjent, tillot XMODEM opptil 90 sekunder for mottakeren å begynne å sende forespørsler om datapakker.

Problemer

Selv om XMODEM var robust nok til at en journalist i 1982 kunne overføre historier fra Pakistan til USA med en Osborne 1 og akustisk kobler over telefonlinjer av dårlig kvalitet, hadde protokollen flere feil.

Mindre problemer

XMODEM ble skrevet for CP/M -maskiner, og har flere merker av det operativsystemet . Spesielt var filer på CP/M alltid multipler på 128 byte, og slutten var markert i en blokk med <EOT>tegnet. Disse egenskapene ble transplantert direkte inn i XMODEM. Andre operativsystemer inneholdt imidlertid ingen av disse særegenhetene, og den utbredte introduksjonen av MS-DOS på begynnelsen av 1980-tallet førte til at XMODEM måtte oppdateres for å legge merke til enten en <EOT> eller <EOF> som slutten av filmarkøren.

For en stund ble det foreslått at sending av et <CAN>tegn i stedet for et <ACK>eller <NAK>burde støttes for å enkelt avbryte overføringen fra mottakerenden. På samme måte ønsket en <CAN>mottatt i stedet for den <SOH>angitte avsenderen å avbryte overføringen. Imidlertid kan denne karakteren enkelt "skapes" via enkle støyrelaterte feil av det som var ment å være en <ACK>eller <NAK>. En dobbel <CAN>ble foreslått for å unngå dette problemet, men det er ikke klart om dette ble vidt implementert.

Store problemer

XMODEM ble designet for enkelhet, uten mye kunnskap om andre filoverføringsprotokoller - som uansett var ganske sjeldne. På grunn av sin enkelhet var det en rekke helt grunnleggende feil som kan føre til at en overføring mislykkes, eller verre, kan resultere i en feil fil som gikk upåaktet hen av protokollen. Det meste av dette skyldtes bruk av en enkel kontrollsum for feilretting, som er utsatt for manglende feil i dataene hvis to biter reverseres, noe som kan skje med en passende kort støy. I tillegg kan lignende skader på overskriften eller kontrollsummen føre til en mislykket overføring i tilfeller der selve dataene var uskadet.

Mange forfattere introduserte utvidelser til XMODEM for å løse disse og andre problemene. Mange ba om at disse utvidelsene skulle inkluderes som en del av en ny XMODEM -standard. Imidlertid nektet Ward Christensen å gjøre dette, ettersom det var nettopp mangelen på disse funksjonene, og den tilhørende kodingen som trengs for å støtte dem, noe som førte til XMODEMs utbredte bruk. Som han forklarte:

Det var en rask hack jeg kastet sammen, veldig uplanlagt (som alt jeg gjør), for å tilfredsstille et personlig behov for å kommunisere med noen andre mennesker. BARE det faktum at det ble gjort i 8/77, og at jeg la det i offentlig eiendom umiddelbart, gjorde at det ble standarden at det er ...
... Folk som foreslår at jeg gjør VESENTLIGE endringer i protokollen, for eksempel "full dupleks", "flere utestående blokker", "flere destinasjoner", osv. Osv. Forstår ikke at protokollens utrolige enkelhet er en av grunnene den overlevde.

Batchoverføringer

Et annet problem med XMODEM var at det krevde overføringen å være brukerdrevet i stedet for automatisert. Vanligvis betydde dette at brukeren ville navigere på avsenderens system for å velge filen de ønsket, og deretter bruke en kommando for å sette det systemet i "klar til å sende" -modus. De ville deretter utløse overføringen fra slutten ved hjelp av en kommando i terminalemulatoren. Hvis brukeren ønsket å overføre en annen fil, måtte de gjenta denne prosessen igjen.

For automatiserte overføringer mellom to nettsteder ble en rekke tillegg til XMODEM-protokollen implementert over tid. Disse antok generelt at avsenderen ville fortsette å sende fil etter fil, med mottakeren som forsøkte å utløse den neste filen ved å sende en NAK som normalt ved starten av en overføring. Da NAK -ene tok timeout, kunne man anta at det enten ikke var flere filer, eller at lenken ble brutt uansett.

MODEM7

MODEM7 , også kjent som MODEM7 batch eller Batch XMODEM , var den første kjente forlengelsen av XMODEM -protokollen. En normal XMODEM -filoverføring starter med at mottakeren sender et enkelt NAK -tegn til avsenderen, som deretter begynner å sende en enkelt SOH for å indikere starten på dataene, og deretter pakker med data.

MODEM7 endret denne oppførselen bare litt ved å sende filnavnet i 8.3 filformat før <SOH>. Hvert tegn ble sendt individuelt og måtte ekko av mottakeren som en form for feilretting. For en ikke-klar XMODEM-implementering ville disse dataene ganske enkelt bli ignorert mens de ventet på at SOH skulle komme, slik at tegnene ikke ble ekko og implementeringen kunne falle tilbake til konvensjonell XMODEM. Med "klar" programvare kan filnavnet brukes til å lagre filen lokalt. Overføringer kan fortsette med en annen <NAK> , hver fil lagres under navnet som sendes til mottakeren.

Jerry Pournelle i 1983 beskrev MODEM7 som "sannsynligvis det mest populære mikrodatamaskinkommunikasjonsprogrammet som eksisterer".

TeLink

MODEM7 sendte filnavnet som vanlig tekst, noe som betydde at det kunne bli ødelagt av de samme problemene som XMODEM forsøkte å unngå. Dette førte til introduksjonen av TeLink av Tom Jennings , forfatter av de originale FidoNet -mailerne.

TeLink unngikk MODEM7s problemer ved å standardisere en ny "nullpakke" som inneholder informasjon om den originale filen. Dette inkluderte filens navn, størrelse og tidsstempel , som ble plassert i en vanlig 128 byte XMODEM -blokk. Mens en normal XMODEM -overføring ville begynne med at avsenderen sendte "blokk 1" med en <SOH> overskrift, ble TeLink -overskriftspakken merket "blokk 0" og begynte med en <SYN> . Pakken inneholdt dato og klokkeslett for opprettelse av fil, filnavn på opptil 16 tegn, filstørrelsen som en 4-byte-verdi og navnet på programmet som sender filen.

En normal XMODEM -implementering ville ganske enkelt kaste pakken, forutsatt at pakkenummeret var ødelagt. Men dette førte til en potensiell tidsforsinkelse hvis pakken ble kastet, ettersom avsenderen ikke kunne fortelle om mottakeren hadde svart med <NAK> fordi den ikke forsto nullpakken eller fordi det var en overføringsfeil. Ettersom TeLink vanligvis bare ble brukt av FidoNet- programvare, som krevde det som en del av FidoNet-standardene, ga dette ikke et reelt problem da begge ender alltid ville støtte denne standarden.

Det grunnleggende "blokk 0" -systemet ble en standard i FidoNet-samfunnet, og ble gjenbrukt av en rekke fremtidige protokoller som SEAlink og YMODEM .

XMODEM-CRC

Kontrollsummen som ble brukt i den opprinnelige protokollen var ekstremt enkel, og feil i pakken kunne gå upåaktet hen. Dette førte til introduksjonen av XMODEM-CRC av John Byrns, som brukte en 16-biters CRC i stedet for 8-biters kontrollsum. CRC koder ikke bare dataene i pakken, men også plasseringen, slik at den kan legge merke til bitbyttefeilene som en kontrollsum ville savne. Statistisk sett gjorde dette sjansen for å oppdage en feil som var mindre enn 16 bits lang 99,9969%, og enda høyere for lengre feilbitstrenger.

XMODEM-CRC ble designet for å være bakoverkompatibel med XMODEM. For å gjøre dette sendte mottakeren et C(stort C) tegn i stedet for a for <NAK>å starte overføringen. Hvis avsenderen svarte med å sende en pakke, ble det antatt at avsenderen "kjente" XMODEM-CRC, og mottakeren fortsatte å sende Cden. Hvis det ikke var noen pakke, antok mottakeren at avsenderen ikke kjente protokollen, og sendte en for <NAK>å starte en "tradisjonell" XMODEM -overføring.

Dessverre hadde dette forsøket på bakoverkompatibilitet en ulempe. Siden det var mulig at det opprinnelige Ctegnet ville gå tapt eller ødelagt, kunne det ikke antas at mottakeren ikke støttet XMODEM-CRC hvis det første forsøket på å utløse overføringen mislyktes. Mottakeren prøvde dermed å starte overføringen tre ganger med å Cvente tre sekunder mellom hvert forsøk. Dette betydde at hvis brukeren valgte XMODEM-CRC mens han forsøkte å snakke med en XMODEM, slik den var tiltenkt, var det en potensiell forsinkelse på 10 sekunder før overføringen startet.

For å unngå forsinkelsen vil avsender og mottaker vanligvis oppgi XMODEM-CRC separat fra XMODEM, slik at brukeren kan velge "grunnleggende" XMODEM hvis avsenderen ikke eksplisitt lister det. For den gjennomsnittlige brukeren var XMODEM-CRC egentlig en "andre protokoll", og ble behandlet som sådan. Dette var imidlertid ikke sant for FidoNet -postere, der CRC ble definert som standarden for alle TeLink -overføringer.

Høyere gjennomstrømning

Siden XMODEM -protokollen krevde at avsenderen stoppet og ventet på en <ACK>eller <NAK>melding fra mottakeren, pleide den å være ganske treg. I en tid med 300 bit / s modemer krevde hele 132-byte-pakken litt over 3,5 sekunder for å sende (132 byte * (8 bits per byte + 1 startbit + 1 stoppbit) / 300 bits per sekund). Forutsatt at det tar 0,2 sekunder for mottakeren <ACK>å komme tilbake til avsenderen og den neste pakken begynner å treffe mottakeren (0,1 sekunder i begge retninger), vil den totale tiden for en pakke være 3,7 sekunder, litt over 92% gjennomstrømning.

Etter hvert som modemhastighetene økte, ble den faste forsinkelsen som trengs for å sende <ACK>/ <NAK>vokst i forhold til tiden som var nødvendig for å sende pakken. For eksempel, ved 2400 bit / s tok pakkene bare 0,44 sekunder å sende, så hvis <ACK>/ <NAK>fortsatt tok 0,2 sekunder å komme tilbake (dette er latens i nettverket, ikke gjennomstrømning), har gjennomstrømningen falt til under 60%. Med 9600 bit/s er det under 30% - mer tid brukes på å vente på svaret enn det som er nødvendig for å sende pakken.

En rekke nye versjoner av XMODEM ble introdusert for å løse disse problemene. Som tidligere utvidelser, hadde disse versjonene en tendens til å være bakoverkompatibel med den originale XMODEM, og i likhet med disse utvidelsene førte dette til en ytterligere brudd på XMODEM-landskapet i brukerens terminalemulator. Til slutt dukket det opp dusinvis av versjoner av XMODEM.

WXModem

WXmodem , forkortelse for "Windowed Xmodem", er en variant av XMODEM utviklet av Peter Boswell i 1986 for bruk på linjer med høy latens, spesielt offentlige X.25- systemer og PC Pursuit . Disse har forsinkelser som er langt høyere enn den vanlige gamle telefontjenesten , noe som fører til svært dårlig effektivitet i XMODEM. I tillegg bruker disse nettverkene ofte kontrolltegn for flytkontroll og andre oppgaver, spesielt vil XON/XOFF stoppe dataflyten. Til slutt var det noen ganger vanskelig å vite om en SOH var en pakkeindikator eller mer støy hvis det oppstod en feil som krevde et nytt forsøk . WXmodem tilpasset XMODEM-CRC for å løse disse problemene.

En endring var å unnslippe et lite sett med kontrollkarakterer, DLE , XON , XOFF og SYN . Disse ble sluppet unna ved å sette inn en DLE foran dem, og deretter endre karakteren ved å XORere den med 64. I teorien betydde dette at pakken kunne være så lang som 264 byte hvis den opprinnelig besto helt av tegn som krevde rømning. Disse innsatte og modifiserte tegnene er ikke en del av CRC -beregningen, de fjernes og konverteres i mottakerenden før CRC beregnes.

I tillegg hadde alle pakker et prefiks med et SYN- tegn, noe som betydde at pakkeinnledningen var SYN SOH , noe som reduserte sjansen for at en villkommen SOH ville bli forvirret for en pakkeoverskrift i forskjellige feiltilfeller. En SYN som ikke ble funnet utenom kroppen i en pakke var en feil.

Den største endringen i WXMODEM er bruken av et skyvevindu for å forbedre gjennomstrømningen på lenker med høy latens. For å gjøre dette ble ACK -meldingene fulgt av pakkenummeret de ACK eller NAK ing. Mottakeren trenger ikke ACK hver pakke, det er lov å ACK et hvilket som helst nummer mellom en og fire pakker. En ACK med det fjerde pakkesekvensnummer antas å ACK alle fire pakkene. En feil fører til at en NAK sendes umiddelbart, med alle pakker fra dette nummeret og etter at de er sendt på nytt.

Ved å kreve en ACK hver fjerde pakke får systemet til å fungere som om det har en pakkestørrelse på 512 byte, men i tilfelle en feil krever det vanligvis bare 128 byte for å bli sendt på nytt. Videre reduserer det datamengden som flyter i motsatt retning med fire ganger. Dette er av liten interesse for det typiske modemets full dupleksdrift , men er viktig i halv duplekssystemer som Telebit -modeller som har 19 kB hastighet i en retning og 75 bits/s i returkanalen.

SEAlink

En av de første tredjepartsforsenderne for FidoNet- systemet var SEAdog , skrevet av samme forfatter som det da populære .arc -datakomprimeringsformatet . SEAdog inkluderte en rekke forbedringer, inkludert SEAlink , en forbedret overføringsprotokoll basert på det samme skyvevinduskonseptet som WXmodem. Det skilte seg fra WXmodem hovedsakelig i detaljer.

En forskjell er at SEAlink støttet "nullpakken" introdusert av TeLink, som er nødvendig for å fungere som en drop-in-erstatning for TeLink i FidoNet-systemer der overskriften var forventet. ACKs og NAKs ble utvidet til tre-byte "pakker", med ACK eller NAK , deretter pakkenummeret, deretter komplementet til pakkenummeret, på samme måte som det originale XMODEM-pakkehodet. Vindusstørrelsen var normalt satt til seks pakker.

SEAlink var ikke forventet å operere over X.25 eller lignende lenker, og utførte dermed ikke rømning. Dette var også nødvendig for at nullpakken skulle fungere skikkelig, da denne standarden brukte SYN- tegnet som WXmodem hadde planlagt på nytt. I tillegg til disse endringene, la den til en "Overdrive" -modus for halv duplekslenker. Dette undertrykte ACK -er for pakker som ble overført, og gjorde vinduet uendelig stort. Denne modusen ble indikert med et flagg i nullblokken.

SEAlink la senere til en rekke andre forbedringer og var en nyttig generell protokoll. Imidlertid forble den sjelden utenfor FidoNet-verdenen, og ble sjelden sett i brukervendt programvare.

XMODEM-1K

En annen måte å løse gjennomstrømningsproblemet på er å øke pakkestørrelsen. Selv om det grunnleggende problemet med latens forblir, er hastigheten det blir et problem med høyere. XMODEM-1K med 1024-byte pakker var den mest populære slike løsningen. I dette tilfellet er gjennomstrømningen ved 9600 bit/s 81%, gitt de samme forutsetningene som ovenfor.

XMODEM-1K var en utvidet versjon av XMODEM-CRC, som indikerte lengre blokkstørrelse i avsenderen ved å starte en pakke med <STX>tegnet i stedet for <SOH>. Som andre bakoverkompatible XMODEM -utvidelser, var det meningen at en -1K overføring kunne startes med enhver implementering av XMODEM i den andre enden, og sikkerhetskopierer funksjoner etter behov.

XMODEM-1K var opprinnelig en av de mange forbedringene av XMODEM introdusert av Chuck Forsberg i sin YMODEM- protokoll. Forsberg antydet at de forskjellige forbedringene var valgfrie, og forventet at programvareforfattere skulle implementere så mange av dem som mulig. I stedet implementerte de generelt et minimum, noe som førte til et vell av halvkompatible implementeringer, og til slutt splittelse av navnet "YMODEM" til "XMODEM-1K" og en rekke YMODEM-er. Dermed etterlater XMODEM-1K faktisk YMODEM, men forble ganske vanlig uansett.

NMODEM

NMODEM er en filoverføringsprotokoll utviklet av LB Neal, som ga den ut i 1990. NMODEM er egentlig en versjon av XMODEM-CRC som bruker større 2048 byte blokker, i motsetning til XMODEMs 128 byte blokker. NMODEM ble implementert som et eget program, skrevet i Turbo Pascal 5.0 for IBM PC -kompatible datamaskiner. Blokkestørrelsen ble valgt for å matche den vanlige klyngestørrelsen til MS-DOS FAT- filsystemet på moderne harddisker , noe som gjør bufferdata for skriving enklere.

Protokollforfalskning

Over pålitelige (feilfrie) tilkoblinger er det mulig å eliminere ventetid ved å "forhåndsgjenkjenne" pakkene, en teknikk mer generelt kjent som " protokollspoofing ". Dette oppnås normalt i lenke -maskinvaren, spesielt Telebit -modemer. Modemene, når alternativet ble slått på, ville legge merke til XMODEM -overskriften og umiddelbart sende en ACK . Dette vil føre til at XMODEM-programmet sender den neste pakken umiddelbart, noe som gjør overføringen kontinuerlig, som et vindu i uendelig størrelse. Modemene undertrykker også ACK som sendes av XMODEM-programvaren ytterst, og frigjør derved lavhastighetskanalen.

Systemet kan også implementeres i selve protokollen, og variasjoner av XMODEM tilbød denne funksjonen. I disse tilfellene ville mottakeren sende ACK -en så snart pakken startet, på samme måte som Telebit -modemene. Siden denne funksjonen bare er en endring av mottakerens oppførsel, krever den ingen endringer i protokollen på avsenders side. YMODEM formaliserte dette systemet.

Dette konseptet bør stå i kontrast med det som ble brukt i SEAlink, som endrer oppførselen på begge sider av koblingen. I SEAlink slutter mottakeren å sende ACK helt, og avsenderen endrer sin oppførsel for ikke å forvente dem.

Se også

Referanser

Sitater

Bibliografi

Eksterne linker