UUCP - UUCP

UUCP
Původní autoři Mike Lesk
Vývojáři AT&T Bell Laboratories
První vydání 1979 ; Před 42 lety ( 1979 )
Operační systém Unix a podobné Unix , DOS , OS / 2 , OpenVMS , AmigaOS , klasický Mac OS , CP / M
Typ Příkaz

UUCP je zkratka z Unix-to-Unix Copy . Termín obecně se odkazuje na sadu počítačových programů a protokolů , které umožňují vzdálené spuštění příkazů a přenos souborů , e-mailu a NetNews mezi počítači .

Příkaz s názvem uucpje jedním z programů v sadě; poskytuje uživatelské rozhraní pro vyžádání operací kopírování souborů. Sada UUCP také zahrnuje uux(uživatelské rozhraní pro vzdálené provádění příkazů), uucico(komunikační program, který provádí přenosy souborů), uustat(hlásí statistiku o nedávné aktivitě), uuxqt(provádí příkazy odeslané ze vzdálených počítačů) a uuname(hlásí název UUCP místní systém). Některé verze sady obsahují uuencode/ uudecode(převádějí 8bitové binární soubory do 7bitového textového formátu a naopak).

Ačkoli UUCP byl původně vyvinut na Unixu v 70. a 80. letech a je nejtěsněji spojen se systémy podobnými Unixu , existují implementace UUCP pro několik jiných operačních systémů než Unix, včetně DOS , OS / 2 , OpenVMS (pouze pro hardware VAX) ), AmigaOS , klasický Mac OS a dokonce CP / M .

Dějiny

UUCP byl původně napsán na AT & T Bell Laboratories podle Mike Lesk . V roce 1978 byl používán na 82 UNIX strojích uvnitř systému Bell, primárně pro distribuci softwaru. To bylo vydáno v roce 1979 jako součást verze 7 Unix . Původní UUCP přepsali vědci AT&T Peter Honeyman, David A. Nowitz a Brian E. Redman kolem roku 1983. Přepis se označuje jako HDB nebo HoneyDanBer uucp, který byl později vylepšen, opraven a znovu zabalen jako BNU UUCP (" Základní síťové nástroje ").

Každá z těchto verzí byla distribuována jako proprietární software, což inspirovalo Iana Lancea Taylora k napsání nové bezplatné verze softwaru v roce 1991. Taylor UUCP byl vydán pod GNU General Public License . Taylor UUCP řešil bezpečnostní díry, které umožňovaly některým původním síťovým červům vzdáleně provádět neočekávané příkazy prostředí. Taylor UUCP také začlenil funkce všech předchozích verzí UUCP, což mu umožnilo komunikovat s jakoukoli jinou verzí a dokonce používat podobné formáty konfiguračních souborů z jiných verzí.

UUCP byl také implementován pro operační systémy jiné než UNIX , zejména systémy DOS . Balíčky jako UUSLAVE / GNUUCP ( John Gilmore , Garry Paxinos, Tim Pozar), UUPC / extended (Drew Derbyshire z Kendra Electronic Wonderworks) a FSUUCP (Christopher Ambler z IODesign) přinesly časnou internetovou konektivitu k osobním počítačům a rozšířily síť za hranice vzájemně propojené univerzitní systémy. FSUUCP tvořil základ pro mnoho balíčků systému BBS ( Bullet Board System ), jako je Galacticomm's Major BBS a Mustang Software 's Wildcat! BBS pro připojení k síti UUCP a výměnu e-mailového a Usenet provozu. Například UFGATE (John Galvin, Garry Paxinos, Tim Pozar) byl balíček, který poskytoval bránu mezi sítěmi provozujícími protokoly Fidonet a UUCP.

FSUUCP byla jedinou další implementací Taylorova vylepšeného protokolu „i“, což je významné zlepšení oproti standardnímu protokolu „g“ používanému většinou implementací UUCP.

Technologie

Před širokou dostupností přístupu na internet byly počítače připojeny pouze menšími lokálními sítěmi v rámci společnosti nebo organizace. Oni byli také často vybaveny modemy , aby mohly být použity vzdáleně z znak režimu terminálů přes dial-up telefonní linky . UUCP používal modemy počítačů k vytáčení do jiných počítačů a navazoval mezi nimi dočasné spojení point-to-point. Každý systém v síti UUCP má seznam sousedních systémů s telefonními čísly, přihlašovacími jmény a hesly atd. Když je pro sousední systém zařazena práce (požadavky na přenos souborů nebo provádění příkazů), uucicoprogram obvykle volá tento systém ke zpracování práce. uucicoProgram může také hlasování svým sousedům pravidelně kontrolovat práci ve frontě na jejich straně; to umožňuje sousedům bez možnosti vytáčeného připojení k účasti.

V průběhu času byly vytáčené odkazy nahrazeny internetovými připojeními a UUCP přidal řadu nových protokolů vrstvy spojení . Tato novější připojení také vůbec snížila potřebu UUCP, protože se vyvíjely novější aplikační protokoly, aby využívaly výhod nových sítí. Dnes se UUCP zřídka používá přes vytáčené odkazy, ale občas se používá přes TCP / IP . Na začátku roku 2006 se počet zapojených systémů pohyboval mezi 1 500 a 2 000 pracovišti v 60 podnicích. Životnost UUCP lze přičíst jeho nízkým nákladům, rozsáhlému protokolování, nativnímu převzetí služeb při selhání dial-upu a trvalé správě front.

Session

UUCP se obvykle spouští přihlášením uživatele do cílového systému a následným spuštěním programu UUCP. Ve většině případů se to automatizuje přihlášením do známého uživatelského účtu používaného pro převody, jehož shell účtu byl nastaven na uucico. U automatických přenosů tedy musí jiný stroj jednoduše otevřít modemové spojení s volaným strojem a přihlásit se ke známému účtu.

Po spuštění uucico bude očekávat příjem příkazů z jiného programu UUCP na počítači volajícího a zahájení relace. Relace má tři odlišné fáze:

  1. Počáteční potřesení rukou
  2. Žádosti o soubory
  3. Konečné podání ruky

Počáteční potřesení rukou

Při spuštění uucico odpoví odesláním identifikačního řetězce, kde \ 20 je znak control-P a \ 0 je koncová null. UUCP volajícího reaguje s , kde options je řetězec obsahující nula nebo více Unixových přepínačů možností. Mohou zahrnovat velikosti paketů a oken, maximální podporovanou velikost souboru, možnosti ladění a další. \20Shere=hostname\0\20Scallername options\0

V závislosti na nastavení těchto dvou systémů může hovor zde skončit. Například když volající odpoví svým jménem systému, může volaný systém volitelně zavěsit, pokud volajícího nerozpozná, odeslat RYou are unknown to me\0řetězec odpovědi a poté se odpojit.

Žádosti o soubory

Pokud dva systémy úspěšně předají handshake, volající nyní začne posílat řadu požadavků na soubory. Existují čtyři typy:

S způsobí odeslání souboru z volajícího do volaného systému (upload). Názvy od a do jsou k dispozici, což umožňuje změnu názvu souboru na přijímači. Když je příkaz S přijat na volaném systému, reaguje SY, pokud byl úspěšný, a je připraven přijmout soubor, nebo SNx, pokud selhal, kde x je důvod selhání. Pokud volající přijme SY, začne nahrávat soubor pomocí protokolu vybraného během počátečního podání ruky (viz níže). Po dokončení přenosu volaný systém odpoví CY, pokud úspěšně přijal soubor, nebo CN5, pokud selhal.
R je Žádost volaného systému o odeslání souboru volajícímu (stažení). Jinak je to podobné jako S, použití RY a RN k označení, že příkaz byl přijat, a začne posílat data nebo měl problém, a na konci přenosu očekává volajícího CY a CN5.
X nahraje příkazy, které mají být provedeny na volaném systému. To lze použít k tomu, aby tento systém zavolal jiného a doručil do něj soubory. Volaný systém reaguje XY, pokud uspěl, nebo XN, pokud selhal.
H pro Hangup označuje, že volající je hotový. Volaný systém reaguje HY, pokud uspěl, nebo HN, pokud selhal.

Konečné podání ruky

Po odeslání příkazu H volající systém odešle finální paket \20OOOOOO\0(control-P, šest ohů, nulový terminátor) a volaný systém odpoví \20OOOOOO\0(ovládání-P, sedm ohů, nulový terminátor). Některé systémy jednoduše zavěsí na úspěšný příjem příkazu H a nebudou se obtěžovat konečným podáním ruky.

g-protokol

V rámci sady protokolů v UUCP je za přenos informací v bezchybné formě zodpovědný základní g-protokol. Protokol vznikl jako univerzální systém pro doručování paketů, a tak nabízí řadu funkcí, které balíček UUCP jako celek nepoužívá. Patří mezi ně sekundární kanál, který může odesílat příkazová data proložená přenosem souboru, a schopnost znovu vyjednat velikost paketu a okna během přenosu. Tyto funkce navíc nemusí být k dispozici v některých implementacích zásobníku UUCP.

Formát paketu sestával ze 6bajtového záhlaví a poté mezi nulou a 4096 bajty v užitečném zatížení. Paket začíná jedním \ 020 (control-P). Poté následuje jeden bajt, známý jako „K“, obsahující hodnotu 1 až 8 označující velikost paketu od 32 do 4096 bajtů, nebo 9 označující kontrolní paket. Mnoho systémů podporovalo pouze K = 2, což znamená 64 bytů. Další dva bajty byly 16bitovým kontrolním součtem užitečného zatížení, bez hlavičky. Další bajt je datový typ a nakonec poslední bajt je XOR záhlaví, což umožňuje jeho samostatnou kontrolu od užitečného zatížení.

Řídicí bajt se skládá ze tří bitových polí ve formátu TTXXXYYY. TT je typ paketu, 0 pro kontrolní pakety (což také vyžaduje platnost K = 9), 1 pro alternativní data (nepoužívá se v UUCP), 2 pro data a 3 označuje krátký paket, který znovu definuje význam K. V datovém paketu je XXX číslo paketu pro tento paket od 0 do 7 a YYY je poslední, který byl přijat správně. To poskytuje až 8 paketů v okně. V kontrolním paketu XXX označuje příkaz a YYY se používá pro různé parametry. Například přenosy jsou zahájeny odesláním krátkého kontrolního paketu s TT = 0 (kontrola), XXX = 7 a RRRR počet paketů v okně, poté odesláním dalšího paketu s XXX = 6 a RRRR jako délkou paketu (kódováno jako bylo by to v K) a pak třetí paket, který je identický s prvním, ale XXX = 5.

g-protokol používá jednoduchý systém posuvných oken k řešení potenciálně dlouhých latencí mezi koncovými body. Protokol umožňuje velikost paketů od 64 do 4096 8bitových bajtů a okna, která obsahují 1 až 7 paketů. Teoreticky by systém využívající 4k pakety a 7 paketových oken (4096x7) nabízel porovnávání výkonu nebo překonávání nejlepších protokolů pro přenos souborů, jako je ZMODEM . V praxi mnoho implementací podporovalo pouze jedno nastavení 64x3. Výsledkem je, že protokol g má nezaslouženou pověst špatného výkonu. Zmatek nad velikostí paketů a oken vedl k protokolu G, který se lišil pouze tím, že vždy používal 4096x3. Taylor UUCP nepodporoval G, ale podporoval jakékoli platné požadované okno nebo velikost paketu, takže vzdálené systémy začínající G by fungovaly dobře s Taylorovým g, zatímco dva Taylor systémy dokázaly vyjednat ještě rychlejší připojení.

Telebitové modemy používaly spoofing protokolu ke zlepšení výkonu přenosů g-protokolu tím, že si všimly, že se do vzdáleného systému odesílají značky konce paketu a okamžitě posílají ACKzpět místnímu hostiteli, předstírají, že vzdálený systém již přijal paket a dekódoval správně. To vyvolalo softwarový zásobník odeslat další paket tak rychle, že přenos se stal téměř nepřetržitým. Data mezi těmito dvěma modemy byla opravena chybou pomocí proprietárního protokolu založeného na MNP, který běžel přes poloviční duplexní spojení Telebit mnohem lépe, než by normálně používal protokol g, protože v běžném případě 64x3 by vzdálený systém odesílal konstantní proud ACKkteré by přetekly zpětným kanálem s nízkou rychlostí. V kombinaci s přirozeně vyššími datovými rychlostmi modemu výrazně zlepšily celkovou propustnost a obecně dosahovaly zhruba sedmkrát vyšší rychlosti než modem s rychlostí 2 400 b / s. Byly široce používány na hostitelích UUCP, protože se mohli rychle platit za snížené poplatky na dálku.

Další protokoly

Implementace UUCP zahrnují také další přenosové protokoly pro použití přes určité odkazy.

f-protokol je navržen tak, aby běžel přes 7-bitové chyby opravené odkazy. Toto bylo původně zamýšleno pro použití na odkazech X.25 , které byly v 80. letech po určitou dobu populární. Nebaletizuje data, místo toho je celý soubor odeslán jako jeden dlouhý řetězec následovaný kontrolním součtem celého souboru. Zdá se, že podobný protokol x zaznamenal malé nebo žádné použití. d-protokol byl podobný x, ale byl určen pro použití v sítích Datakit, které spojovaly mnoho kanceláří Bell Labs .

Protokol t pochází z BSD verzí UUCP a je navržen pro běh přes 8bitové bezchybné odkazy TCP / IP . Nemá vůbec žádnou korekci chyb a protokol se skládá jednoduše z rozdělení dat příkazů a souborů do 512 nebo 1024 bajtových paketů, aby se snadno vešly do typických rámců TCP. Méně používaný e-protokol , který vytvořil verze HoneyDanBer na rozdíl od t z BSD, se liší pouze v tom, že příkazy nejsou zabaleny a místo toho jsou odesílány jako normální řetězce, zatímco soubory jsou vyplněny na nejbližších 20 bajtů.

Směrování pošty

Vizitka s e-mailovou adresou UUCP

Funkce uucpa uuxqtlze použít k odesílání e-mailů mezi stroji s vhodnými uživatelskými rozhraními pošty a programy doručovacího agenta. Jednoduchá e-mailová adresa UUCP byla vytvořena z názvu sousedního počítače, vykřičníku (často vyslovovaného třesku ), následovaného uživatelským jménem na sousedním počítači. Například adresa barbox! Uživatel by odkazoval na uživatele uživatele na sousední barbox stroje .

Mail mohl být dále směrován přes síť a procházet libovolným počtem mezilehlých uzlů před příjezdem na místo určení. Zpočátku to bylo nutné provést zadáním úplné cesty se seznamem mezilehlých názvů hostitelů oddělených třesky. Například, pokud přístroj barbox není připojen k místnímu počítači, ale je známo, že barbox je spojen s strojem foovax která se komunikovat s místním počítači, na příslušnou adresu odeslat poštu by foovax! Barbox! Uživatel .

Uživatel barbox! Uživatel by obecně zveřejnil svou e-mailovou adresu UUCP ve formě, jako je ...! Bigsite! Foovax! Barbox! User . To směruje lidi, aby směrovali svou poštu na strojovou bigsite (pravděpodobně známý a dobře propojený stroj přístupný všem) a odtamtud přes stroj foovax na účet uživatele uživatele na barboxu . Publikování úplné cesty by bylo zbytečné, protože by se lišilo podle toho, kde byl odesílatel. (např. Ann na jednom místě možná bude muset poslat cestou path gway! tcol! canty! uoh! bigsite! foovax! barbox! uživatel , zatímco odjinud musí Bill poslat cestou pdp10! router22! bigsite! foovax! barbox! uživatel ). Mnoho uživatelů by navrhlo více tras z různých velkých známých webů, což by poskytovalo ještě lepší a možná rychlejší službu připojení od odesílatele pošty.

Bang cesta

E-mailová adresa tohoto formuláře byla známá jako cesta třesku . Trasy osmi až deseti strojů (nebo chmele ) nebyly v roce 1981 neobvyklé a pozdní noční vytáčené UUCP odkazy mohly způsobit týdenní přenosové časy. Cesty Bang byly často vybrány jak časem přenosu, tak spolehlivostí, protože zprávy se často ztratily. Někteří hostitelé zašli tak daleko, že se pokusili cestu „ přepsat “ a posílat poštu „rychlejšími“ cestami - na tuto praxi se zvyklo mračit.

Koncovka .uucp typu „pseudo-doména“ končící někdy byla použita k označení názvu hostitele, který je dosažitelný prostřednictvím sítí UUCP, ačkoli tento název nebyl nikdy formálně zaregistrován v systému názvů domén (DNS) jako doména nejvyšší úrovně . Komunita uucp se spravovala sama a neseděla dobře s metodami a předpisy pro správu DNS; .uucp funguje tam, kde to potřebuje; někteří hostitelé puntují poštu z fronty SMTP do front uucp na strojích brány, pokud je na příchozím připojení SMTP rozpoznána adresa .uucp.

Provoz na síti Usenet byl původně přenášen přes protokol UUCP pomocí cest třesku. Ty se stále používají v řádcích záhlaví cesty ve formátu zprávy sítě Usenet . Nyní mají pouze informační účel a nepoužívají se pro směrování, i když je lze použít k zajištění toho, aby nedocházelo ke smyčkám.

Obecně, stejně jako jiné starší formáty e-mailových adres , byly cesty trasování nahrazeny znakem „ @ notace “, a to i u webů, které stále používají UUCP. Web pouze pro UUCP může zaregistrovat název domény DNS a nechat server DNS, který tuto doménu zpracovává, poskytovat záznamy MX, které způsobí, že internetová pošta na tento web bude doručena hostiteli UUCP na internetu, který pak může doručit poštu na UUCP stránky.

UUCPNET a mapování

UUCPNET byl název pro celkovou síť počítačů připojených přes UUCP. Tato síť byla velmi neformální a byla udržována v duchu vzájemné spolupráce mezi systémy ve vlastnictví tisíců soukromých společností, univerzit atd. Často, zejména v soukromém sektoru, byla spojení UUCP navazována bez oficiálního souhlasu vrchního vedení společností. Síť UUCP se neustále měnila, protože byly přidávány nové systémy a vytáčené odkazy, ostatní byly odstraněny atd.

Projekt mapování UUCP byl dobrovolníkem, převážně úspěšným úsilím o vytvoření mapy spojení mezi stroji, která byla otevřenými poštovními relé, a vytvoření spravovaného jmenného prostoru. Každý správce systému zašle e-mailem seznam systémů, ke kterým se připojí, spolu s hodnocením každého takového připojení. Tyto odeslané položky mapy byly zpracovány automatickým programem, který je spojil do jedné sady souborů popisujících všechna připojení v síti. Tyto soubory byly poté každý měsíc publikovány v diskusní skupině věnované tomuto účelu. Mapové soubory UUCP by pak mohl software, jako je „pathalias“, použít k výpočtu nejlepší cesty trasy z jednoho počítače do druhého pro poštu a k automatickému dodání této trasy. Mapy UUCP také uváděly kontaktní informace pro weby, a tak poskytly webům, které se snaží připojit k UUCPNET, snadný způsob, jak najít potenciální sousedy.

Připojení k internetu

Mnoho hostitelů UUCP, zejména na univerzitách, bylo také v počátečních letech připojeno k internetu a byly vyvinuty e-mailové brány mezi poštou založenou na internetovém SMTP a poštou UUCP. Uživatel v systému s připojeními UUCP by si tak mohl vyměňovat poštu s uživateli internetu a internetové odkazy by mohly být použity k obejití velkých částí pomalé sítě UUCP. Pro usnadnění těchto rozhraní byla v oboru názvů internetových domén definována „zóna UUCP“.

Díky této infrastruktuře byla síla UUCP v tom, že umožňovala webu získávat internetové e-maily a připojení k síti Usenet pouze pomocí vytáčeného modemového spojení s jiným spolupracujícím počítačem. Bylo to v době, kdy skutečný přístup k internetu vyžadoval pronajatou datovou linku poskytující připojení k internetovému bodu přítomnosti , což bylo nákladné a obtížně uspořádatelné. Naproti tomu propojení na síť UUCP lze obvykle navázat několika telefonními hovory správcům potenciálních sousedních systémů. Sousední systémy byly často dostatečně blízko, aby se vyhnuly všem, kromě nejzákladnějších poplatků za telefonní hovory.

Vzdálené příkazy

uux je vzdálené provádění příkazů přes UUCP. Příkaz uux se používá k provedení příkazu ve vzdáleném systému nebo k provedení příkazu v místním systému pomocí souborů ze vzdálených systémů. Příkaz spouští uucicodémon, který zpracovává požadavky na vzdálené spuštění jako jednoduše jiný druh souboru pro dávkové odeslání do vzdáleného systému, kdykoli je k dispozici uzel dalšího hopu. Vzdálený systém poté provede požadovaný příkaz a vrátí výsledek, jakmile bude k dispozici původní systém. Oba tyto převody mohou být nepřímé, prostřednictvím vícecestných cest, s libovolnými okny dostupnosti. I když provádíte příkaz na vždy dostupném sousedovi, uux není okamžitý.

Pokles

Využití UUCP začalo vymírat s nárůstem poskytovatelů internetových služeb nabízejících levné SLIP a PPP služby. Projekt mapování UUCP byl formálně ukončen koncem roku 2000.

Protokol UUCP byl nyní většinou nahrazen internetovými protokoly založenými na TCP / IP SMTP pro poštu a NNTP pro novinky Usenet.

V červenci 2012 nizozemský poskytovatel internetu XS4ALL ukončil svou službu UUCP a prohlásil, že je „pravděpodobně jedním z posledních poskytovatelů na světě, který ji stále nabízí“; v té době měl pouze 13 uživatelů (před ukončením provozu však několik let odmítal žádosti nových uživatelů).

Současné použití a dědictví

Jednou z přežívajících funkcí UUCP je formát souboru chatu, který z velké části zdědil softwarový balíček Expect .

UUCP se používal přes speciální účelové spoje s vysokými náklady (např. Námořní satelitní spojení) dlouho po jeho zmizení jinde a stále se používá v původním použití. Kromě dosavadního používání v roce 2021 rostou nová a inovativní použití UUCP, zejména pro telekomunikace v pásmu HF , například pro komunity v amazonském deštném pralese pro výměnu e-mailů a další využití. Oprava Ianova UUCP byla přidána do balíčku UUCP Debian Linux, aby se přizpůsobil projektu HERMES (High-Frequency Emergency and Rural Multimedia Exchange System), který poskytuje UUCP HF konektivitu.

V polovině 2000s, UUCP přes TCP / IP (často šifrované, pomocí protokolu SSH ) byl navržen pro použití, když počítač nemá žádné pevné IP adresy, ale je stále ochoten spustit standardního agenta pro přenos pošty (MTA), jako je Sendmail nebo Postfix .

Cesty podobné Bangu se v síti Usenet stále používají , i když ne pro směrování; používají se k zaznamenávání uzlů, kterými tato zpráva prošla, do záhlaví zprávy, spíše než k přímému směrování, kam půjde dál. „Cesta Bang“ se také používá jako výraz pro jakoukoli výslovně určenou směrovací cestu mezi hostiteli sítě. Toto použití není nutně omezeno na UUCP, směrování IP, e-mailové zprávy nebo Usenet.

Koncept síťových protokolů tolerujících zpoždění byl znovu navštíven počátkem roku 2000. Podobné techniky jako ty, které používá UUCP, lze použít v jiných sítích, u kterých dochází ke zpoždění nebo významnému narušení.

Viz také

Reference

externí odkazy