UUCP - UUCP

UUCP
Eredeti szerző (k) Mike Lesk
Fejlesztő (k) AT&T Bell Laboratories
Első kiadás 1979 ; 42 évvel ezelőtt ( 1979 )
Operációs rendszer Unix és Unix-szerű , DOS , OS / 2 , OpenVMS , AmigaOS , klasszikus Mac OS , CP / M
típus Parancs

UUCP egy mozaikszó a Unix-to-Unix Copy . A kifejezés általában olyan számítógépes programok és protokollok csoportjára utal, amelyek lehetővé teszik a parancsok távoli végrehajtását, valamint fájlok , e-mailek és hálózatok számítógépek közötti átvitelét .

A megnevezett parancs uucpa program egyik programja; felhasználói felületet biztosít a fájlmásolási műveletek kérésére. Az UUCP csomag tartalmaz még uux(felhasználói felület a távoli parancsfuttatáshoz), uucico(a fájlátviteleket végrehajtó kommunikációs programot), uustat(statisztikákat készít a legutóbbi tevékenységekről), uuxqt(végrehajtja a távoli gépekről küldött parancsokat), és uuname(beszámolja a fájl UUCP nevét). helyi rendszer). Néhány változatban a programcsomag uuencode/ uudecode(convert 8 bites bináris fájlok 7-bites szöveges formátumban, és fordítva).

Bár az UUCP-t eredetileg az 1970-es és 1980-as években fejlesztették ki a Unix- on , és a legszorosabban kapcsolódik a Unix-szerű rendszerekhez, az UUCP-implementációk számos nem Unix-szerű operációs rendszerhez léteznek, beleértve a DOS-t , az OS / 2-t , az OpenVMS-t (csak a VAX hardverekhez) ), Az AmigaOS , a klasszikus Mac OS és még a CP / M is .

Történelem

Az UUCP-t eredetileg az AT&T Bell Laboratories-ban írta Mike Lesk . 1978-ig 82 UNIX gépen használták a Bell rendszeren belül, elsősorban szoftverterjesztés céljából. 1979-ben jelent meg a Unix 7-es verziójának részeként . Az eredeti UUCP ben újraírta az AT & T kutatók Peter Honeyman, David A. Nowitz és Brian E. Redman körül 1983 átíró nevezik MFB vagy HoneyDanBer uucp, amelyet később megerősített, hiba javítása, és újracsomagolhatók BNU UUCP (” Alapvető hálózati segédprogramok ").

Ezeket a verziókat saját szoftverként terjesztették, és ez inspirálta Ian Lance Taylort arra, hogy 1991-ben egy új ingyenes szoftver verziót írjon a semmiből. A Taylor UUCP a GNU General Public License alatt jelent meg . Taylor UUCP olyan biztonsági lyukakkal foglalkozott, amelyek lehetővé tették az eredeti hálózati férgek számára, hogy távolról hajtsanak végre váratlan shell parancsokat. A Taylor UUCP beépítette az UUCP összes korábbi verziójának jellemzőit, lehetővé téve a kommunikációt bármely más verzióval, és akár más konfigurációs fájlformátumok használatát is.

Az UUCP-t nem UNIX operációs rendszereknél is megvalósították , nevezetesen a DOS rendszereket. Az olyan csomagok, mint az UUSLAVE / GNUUCP ( John Gilmore , Garry Paxinos, Tim Pozar), az UUPC / Extended (Drew Derbyshire of Kendra Electronic Wonderworks) és az FSUUCP (Christopher Ambler, IODesign) korai internetkapcsolatot hoztak a személyi számítógépekhez, a hálózatot kibővítve összekapcsolt egyetemi rendszerek. FSUUCP képezte az alapját a sok hirdetőtábla rendszer (BBS) csomagokat, mint Galacticomm a Major BBS és Mustang Software „s Wildcat! BBS az UUCP hálózathoz való csatlakozáshoz, valamint e-mail és Usenet forgalom cseréjéhez . Például az UFGATE (John Galvin, Garry Paxinos, Tim Pozar) egy olyan csomag volt, amely átjárót biztosított a Fidonet és az UUCP protokollt futtató hálózatok között .

Az FSUUCP volt a Taylor továbbfejlesztett „i” protokolljának egyetlen másik megvalósítása, ami jelentős javulást jelent a legtöbb „UUCP” implementáció által használt standard „g” protokollhoz képest.

Technológia

Az internet-hozzáférés széles körű elérhetősége előtt a számítógépeket csak kisebb helyi hálózatok csatlakoztatták egy vállalaton vagy szervezeten belül. Ők is gyakran ellátott modemek így lehetne használni távolról karakteres módú terminálok keresztül dial-up telefonvonalon . Az UUCP a számítógépek modemeivel tárcsázta más számítógépeket, ideiglenes, pont-pont kapcsolatokat létesítve közöttük. Az UUCP-hálózat minden rendszerének van egy listája a szomszédos rendszerekről, telefonszámokkal, bejelentkezési nevekkel és jelszavakkal, stb. Amikor a munka (fájlátviteli vagy parancsfuttatási kérelmek) várakozási sorba kerülnek egy szomszédos rendszerben, a uucicoprogram általában felhívja ezt a rendszert a munka. A uucicoprogram időközönként felmérheti a szomszédait is, hogy ellenőrizze, van-e sorban állás az oldalukon; ez lehetővé teszi a szomszédok számára, hogy ne tudjanak részt venni.

Idővel, dial-up kapcsolatok váltották Internet kapcsolat, és UUCP hozzáadott számos új kapcsolati réteg protokollok. Ezek az újabb kapcsolatok egyáltalán csökkentették az UUCP szükségességét, mivel újabb alkalmazásprotokollok alakultak ki az új hálózatok előnyeinek kihasználására. Ma az UUCP-t ritkán használják telefonos kapcsolaton keresztül, de alkalmanként TCP / IP-n keresztül . Az érintett rendszerek száma 2006 eleje óta 1500 és 2000 telephely között működött 60 vállalkozásban. Az UUCP hosszú élettartama annak köszönhető, hogy alacsony az ára, kiterjedt naplózása, a natív feladatátváltás a dialuphoz és a tartós sorkezelés.

Munkamenetek

Az UUCP rendszerint úgy kezdődik, hogy a felhasználó bejelentkezik a célrendszerbe, majd futtatja az UUCP programot. A legtöbb esetben ezt úgy automatizálják, hogy bejelentkeznek egy ismert, átutalásokhoz használt felhasználói fiókba, amelynek fiókjának shellje értéke uucico. Így az automatizált átvitelhez egy másik gépnek egyszerűen meg kell nyitnia egy modemkapcsolatot a hívott géppel, és be kell jelentkeznie az ismert fiókba.

Amikor az uucico fut, elvárja, hogy parancsokat kapjon egy másik UUCP programtól a hívó gépén, és elkezdjen egy munkamenetet. A munkamenetnek három külön szakasza van:

  1. Kezdeti kézfogás
  2. Fájlkérés (ek)
  3. Végső kézfogás

Kezdeti kézfogás

Indításkor az uucico egy azonosító karakterlánc küldésével válaszol , ahol \ 20 a control-P karakter, a \ 0 pedig egy null. A hívó fél UUCP-je azzal válaszol , ahol az opciók egy karakterlánc, amely nulla vagy több Unix-szerű opció kapcsolót tartalmaz. Ide tartozhatnak a csomag- és ablakméretek, a maximálisan támogatott fájlméret, a hibakeresési lehetőségek és mások. \20Shere=hostname\0\20Scallername options\0

A két rendszer beállításától függően a hívás itt érhet véget. Például, amikor a hívó a rendszer nevével válaszol, a hívott rendszer opcionálisan leteszi a kapcsolatot, ha nem ismeri fel a hívót, elküldi a RYou are unknown to me\0válaszláncot, majd leválik.

Fájlkérések

Ha a két rendszer sikeresen kézfog, a hívó mostantól fájlkérések sorozatát kezdi el küldeni. Négy típus létezik:

S okozza a fájl elküldését a hívó féltől a hívott rendszerhez (feltöltés). A és a nevek meg vannak adva, lehetővé téve a fájlnév megváltoztatását a vevőn. Amikor az S parancs megkapja a hívott rendszert, akkor SY-vel válaszol, ha ez sikerült, és kész elfogadni a fájlt, vagy ha nem sikerült, akkor az SNx-et, ahol az x hiba oka. Ha egy SY-t kap a hívó, akkor megkezdi a fájl feltöltését a kezdeti kézfogás során kiválasztott protokoll segítségével (lásd alább). Amikor az átvitel befejeződött, a hívott rendszer CY-vel válaszol, ha sikeresen megkapta a fájlt, vagy CN5-el, ha nem sikerült.
R egy kérés, hogy a hívott rendszer fájlokat küldjön a hívónak (letöltés). Egyébként hasonló az S-hez, az RY és az RN használatával jelzi a parancs elfogadását, és elkezdi az adatok küldését vagy problémát, és az átvitel végén CY-t és CN5-t vár a hívótól.
X feltölti a meghívott rendszeren végrehajtandó parancsokat. Ezzel fel lehet hívni a rendszert egy másikra és fájlokat szállítani rá. A hívott rendszer XY-vel válaszol, ha sikerült, vagy XN-nel, ha nem sikerült.
H a Hangup esetében azt jelzi, hogy a hívó fél kész. A hívott rendszer HY-vel válaszol, ha ez sikerült, vagy HN-nel, ha nem sikerült.

Végső kézfogás

H parancs elküldése után a hívó rendszer elküld egy végső csomagot \20OOOOOO\0(vezérlő-P, hat oh, null-terminátor), és a hívott rendszer válaszol \20OOOOOO\0(control-P, hét oh, null-terminátor). Egyes rendszerek egyszerűen leteszik a H parancs sikeres fogadását, és nem zavarják a végső kézfogást.

g-protokoll

Az UUCP protokollcsomagjában az alapul szolgáló g-protokoll felelős az információk hibamentes továbbításáért. A protokoll általános célú csomagküldési rendszerként jött létre, és ezért számos olyan szolgáltatást kínál, amelyeket az UUCP csomag nem használ fel egészében. Ide tartozik egy másodlagos csatorna, amely fájlparaméterekkel küldött parancsadatokat küldhet, valamint az átviteli folyamat során a csomag- és ablakméretek újratárgyalásának lehetősége. Lehetséges, hogy ezek az extra szolgáltatások nem állnak rendelkezésre az UUCP-verem egyes megvalósításaiban.

A csomagformátum 6 bájtos fejlécből állt, majd nulla és 4096 bájt között volt a hasznos teherben. A csomag egyetlen \ 020-mal kezdődik (kontroll-P). Ezt követi egyetlen bájt, az úgynevezett "K", amely 1 és 8 közötti értéket mutat, jelezve a 32 és 4096 bájt közötti csomagméretet, vagy egy 9-et, amely egy vezérlő csomagot jelöl. Sok rendszer csak a K = 2 értéket támogatta, vagyis 64 bájtot jelent. A következő két bájt a hasznos terhelés 16 bites ellenőrző összege volt, a fejléc nélkül. A következő bájt az adattípus, végül az utolsó bájt a fejléc XOR-ja, amely lehetővé teszi, hogy a terheléstől külön ellenőrizhető legyen.

A vezérlő bájt három bitmezőből áll, TTXXXYYY formátumban. A TT a csomag típusa, 0 a vezérlőcsomagoknál (amihez a K = 9 érvényességéhez is szükség van), 1 az alternatív adatokhoz (nem használják az UUCP-ben), 2 az adatokhoz és 3 egy rövid csomagot jelöl, amely újra meghatározza a K. Egy adatcsomagban az XXX a csomag csomagszáma 0 és 7 között, az YYY pedig az utolsó, amelyet helyesen fogadott. Ez legfeljebb 8 csomagot tartalmaz egy ablakban. Egy vezérlőcsomagban az XXX jelzi a parancsot, az YYY pedig a különböző paraméterekhez használható. Például az átvitelt egy rövid vezérlőcsomag elküldésével kezdjük, amelynek TT = 0 (vezérlés), XXX = 7 és YYY a csomagok számát egy ablakban, majd elküldünk egy másik csomagot, amelynek csomagja hossza XXX = 6 és YYY (kódolva: ez K-ben van), majd egy harmadik csomag, amely megegyezik az elsővel, de XXX = 5.

A g-protokoll egyszerű csúszóablakos rendszert használ a végpontok közötti potenciálisan hosszú késések kezelésére. A protokoll lehetővé teszi a csomagok méretét 64 és 4096 között, 8 bites bájtokat, és az ablakokat, amelyek 1-7 csomagot tartalmaznak. Elméletben a rendszer segítségével 4k csomagokat, és 7 csomag windows (4096x7) adna teljesítménye megfelelő, vagy verte a legjobb fájl átviteli protokoll hasonló Zmodem . A gyakorlatban sok megvalósítás csak egyetlen 64x3-as beállítást támogatott. Ennek eredményeként a g-protokoll méltatlan hírnevet mutat a gyenge teljesítmény miatt. A csomag- és ablakméretek zavara a G-protokollhoz vezetett, csak abban különbözött, hogy mindig 4096x3-at használt. A Taylor UUCP nem támogatta a G-t, de támogatott minden érvényes kért ablakot vagy csomagméretet, így a G-t indító távoli rendszerek jól működnek Taylor g-jével, míg két Taylor-rendszer még gyorsabb kapcsolatokról tudna tárgyalni.

A Telebit modemek protokollhamisítást használtak a g-protokoll átviteli teljesítményének javítására azáltal, hogy észrevették a távoli rendszerbe küldött csomagvégi jelölőket, és azonnal visszaküldtek ACKa helyi állomásnak, úgy tettek, mintha a távoli rendszer már megkapta volna a csomagot és dekódolták volna. helyesen. Ez elindította a szoftverköteget a következő csomag küldésére, olyan gyorsan, hogy az átvitel szinte folyamatos lett. A két modem közötti adatokat hibajavítással az MNP-n alapuló, saját tulajdonú protokoll segítségével javítottuk , amely a Telebit fél-duplex kapcsolatait futtatta sokkal jobban, mint általában a g-protokoll, mert a 64x3 általános esetben a távoli rendszer állandó adatfolyamot küld ACKs amelyek túlcsordítanák az alacsony sebességű visszatérő csatornát. A természetesen nagyobb adatsebességgel kombinálva jelentősen javították az átviteli sebességet, és általában a 2400 bps sebességű modem sebességének hétszeresét teljesítették. Széles körben használták őket az UUCP gazdagépein, mivel gyorsan csökkentett távolsági díjakkal tudtak fizetni.

Egyéb protokollok

Az UUCP megvalósításai más átviteli protokollokat is tartalmaznak bizonyos linkeken keresztül történő használatra.

Az f-protokollt 7 bites hibajavított linkek futtatására tervezték. Ezt eredetileg az 1980-as években egy ideig népszerű X.25-ös linkeken használták. Nem csomagolja az adatokat, ehelyett a teljes fájlt egyetlen hosszú karakterláncként küldi, amelyet egy egész fájl ellenőrző összeg követ. Úgy tűnik, hogy a hasonló x-protokollt alig vagy egyáltalán nem használták. A d-protokoll hasonló volt az x-hez, de Datakit hálózatokon való felhasználásra szánták , amelyek számos Bell Labs irodát összeköttek .

A t-protokoll az UUCP BSD verzióiból származik, és úgy tervezték, hogy 8 bites hibamentes TCP / IP kapcsolatokon futtasson . Egyáltalán nincs hibajavítása, és a protokoll egyszerűen abból áll, hogy a parancs- és fájladatokat 512 vagy 1024 bájtos csomagokra bontja, hogy könnyen illeszkedjenek a tipikus TCP keretek közé. A kevésbé használt e-protokoll , amely a HoneyDanBer változatokat a t-vel ellentétben a BSD-ből állította elő, csak annyiban különbözik, hogy a parancsok nincsenek csomagolva, és normál karakterláncként kerülnek elküldésre, míg a fájlok a legközelebbi 20 bájtra vannak kitöltve.

Levelezés továbbítása

Névjegykártya UUCP e-mail címmel

A uucpés uuxqtképességek felhasználhatók e-mail küldésre a gépek között, megfelelő levelezési felhasználói felületekkel és kézbesítési ügynök programokkal. Egy egyszerű UUCP-mail címet alakítottak ki a szomszédos gépnévből, egy felkiáltójelből (gyakran kiejtve bumm ), amelyet a szomszédos gépen a felhasználói név követett. Például a barbox! User cím a szomszédos gép barbox felhasználói felhasználójára utal .

A levél tovább továbbítható a hálózaton keresztül, tetszőleges számú köztes csomóponton áthaladva, mielőtt megérkezne a rendeltetési helyre. Kezdetben ezt a teljes elérési út megadásával kellett megtenni, a közbenső hosztnevek listájával, frufruokkal elválasztva. Például, ha a gépi barbox nincs csatlakoztatva a helyi géphez, de ismert, hogy a barbox olyan gépi foovax- hoz van csatlakoztatva, amely kommunikál a helyi géppel, akkor a megfelelő cím, ahová e- mailt küldhet, a foovax! Barbox! Felhasználó lesz .

A barbox! Felhasználó általában közzéteszi UUCP e-mail címét olyan formában, mint …! Bigsite! Foovax! Barbox! Felhasználó . Ez irányítja az embereket útvonalon levelüket a gép bigsite (feltehetően egy jól ismert és jól csatlakoztatott gép mindenki számára elérhető), és onnan a gép foovax számlájára felhasználó felhasználói szóló barbox . Teljes út közzététele értelmetlen lenne, mert más lenne, attól függően, hogy hol volt a feladó. (Pl . Annnak az egyik helyszínen előfordulhat, hogy a gway! tcol! canty! uoh! bigsite! foovax! barbox! felhasználó útján kell elküldenie, míg máshonnan Billnek a pdp10! router22! bigsite! foovax! barbox! felhasználó ). Sok felhasználó több útvonalat javasolna különféle nagy, jól ismert webhelyekről, még jobb és talán gyorsabb csatlakozási szolgáltatást nyújtva a levelek feladójától.

Bang út

Az ilyen űrlapú e-mail címet úgy hívták, hogy egy csattanás . Nyolc-tíz gép (vagy komló ) ütési útja nem volt ritka 1981-ben, és a késő esti telefonos UUCP-kapcsolatok egy hétig terjedő átviteli időket okozhattak. A robbanás utakat gyakran az átviteli idő és a megbízhatóság egyaránt választotta, mivel az üzenetek gyakran elvesznek. Néhány házigazda odáig ment, hogy megpróbálta " átírni " az utat, "gyorsabb" útvonalakon küldött levelet - ez a gyakorlat általában rosszalló volt.

Az "ál-domain" végződésű .uucp- t néha arra használták, hogy az állomásnevet elérhetővé tegyék az UUCP hálózata által, bár ezt hivatalosan soha nem regisztrálták a domain névrendszerben (DNS) felső szintű tartományként . Az uucp közösség adminisztrálta magát, és nem állt jól össze a DNS-t szabályozó adminisztrációs módszerekkel és előírásokkal; .uucp ott működik, ahol kell; egyes gazdagépek az SMTP-sorból kifelé küldik az e-maileket az átjáró gépek uucp-soraiba, ha a bejövő SMTP-kapcsolaton .uucp-címet ismerünk fel.

A Usenet- forgalmat eredetileg az UUCP protokollon keresztül továbbították bumm útvonalak segítségével. Ezeket továbbra is használják a Usenet üzenetformátumú Path fejléc sorai. Most már csak információs céljuk van, és nem használják útválasztáshoz, bár felhasználhatók arra, hogy a hurkok ne forduljanak elő.

Általánosságban, a többi régebbi e-mail cím formátumhoz hasonlóan, a böngészési utakat is felváltotta a " @ jelölés ", még az UUCP-t továbbra is használó webhelyek is. A csak UUCP-webhelyek regisztrálhatnak egy DNS-tartománynevet, és a domain kezelését végző DNS-kiszolgáló MX-rekordokat adhat, amelyek miatt az adott webhelyhez tartozó internetes leveleket egy UUCP-állomáshoz juttatják el az interneten, amely azután el tudja juttatni a levelet az UUCP-nak. webhely.

UUCPNET és leképezés

Az UUCPNET volt a neve az UUCP-n keresztül összekapcsolt számítógépek hálózatának. Ez a hálózat nagyon informális volt, fenntartva a több ezer magánvállalat, egyetem stb. Tulajdonában lévő rendszerek közötti kölcsönös együttműködés szellemében. Gyakran, különösen a magánszektorban, az UUCP kapcsolatokat a vállalatok felső vezetésének hivatalos jóváhagyása nélkül hozták létre. Az UUCP hálózata folyamatosan változott, mivel új rendszereket és telefonos linkeket adtak hozzá, másokat eltávolítottak stb.

Az UUCP Mapping Project önkéntes, nagyrészt sikeres erőfeszítés volt, hogy térképet készítsen a nyitott levelező-továbbító gépek közötti kapcsolatokról és egy felügyelt névtér létrehozásáról. Minden rendszergazda e-mailben elküldi azoknak a rendszereknek a listáját, amelyekhez csatlakoznak, valamint az egyes kapcsolatok rangsorát. Ezeket a beküldött térképbejegyzéseket egy automatikus program dolgozta fel, amely egyetlen fájlkészletbe egyesítette a hálózat összes kapcsolatát. Ezeket a fájlokat ezután havonta tették közzé egy erre a célra szánt hírcsoportban . Az UUCP térképfájlokat ezután olyan szoftverek használhatják, mint a "pathalias", hogy kiszámítsák a legjobb útvonalat az egyik géptől a másikig a levelek számára, és ezt az útvonalat automatikusan biztosítsák. Az UUCP térképek felsorolták a webhelyek elérhetőségeit, és így az UUCPNET-hez csatlakozni kívánó webhelyeknek egyszerű módot adtak a leendő szomszédok megtalálásához.

Internetkapcsolatok

Számos UUCP-gazdagép, különösen az egyetemeken dolgozó, szintén korai éveiben csatlakozott az internethez , és kifejlesztették az e-mail átjárókat az internetes SMTP- alapú levelek és az UUCP-levelek között. Az UUCP-kapcsolattal rendelkező rendszer felhasználói tehát leveleket cserélhetnek az internet-felhasználókkal, és az internetes linkeket fel lehet használni a lassú UUCP-hálózat nagy részeinek megkerülésére. Ezen interfészek megkönnyítése érdekében egy "UUCP zónát" határoztak meg az internetes domain névtérben.

Ennek az infrastruktúrának a használatával az UUCP erőssége az volt, hogy lehetővé tette egy webhely számára, hogy internetes e-maileket és Usenet-kapcsolatokat szerezzen, csak egy betárcsázós modem hivatkozással egy másik együttműködő számítógépre. Ez abban az időben történt, amikor a valódi internethozzáféréshez bérelt adatvezetékre volt szükség, amely kapcsolatot biztosított egy internetes jelenléti ponttal , mindkettőt drága és nehéz volt megszervezni. Ezzel szemben az UUCP-hálózathoz való kapcsolat általában létrejöhet néhány telefonhívással a leendő szomszédos rendszerek rendszergazdáihoz. A szomszédos rendszerek gyakran elég közel voltak ahhoz, hogy elkerüljék a telefonhívások minden díját, kivéve a legalapvetőbb díjakat.

Távoli parancsok

az uux távoli parancsfuttatás az UUCP-n keresztül. A uux parancs végrehajtására használjuk a parancsot egy távoli rendszer , vagy egy parancs végrehajtása a helyi rendszer segítségével fájlokat távoli rendszerek. A parancsot a uucicodémon futtatja , amely a távoli végrehajtási kérelmeket egyszerűen egy másik típusú fájlként kezeli, amelyet kötegelt küldésként el kell küldeni a távoli rendszernek, amikor rendelkezésre áll egy következő ugrási csomópont. A távoli rendszer ekkor végrehajtja a kért parancsot, és visszaadja az eredményt, amikor az eredeti rendszer rendelkezésre áll. Mindkét transzfer lehet közvetett, multi-hop útvonalakon keresztül, tetszőleges elérhetőségi ablakokkal. Még akkor sem, ha a parancsot mindig elérhető szomszédon hajtja végre, az uux nem azonnali.

Hanyatlás

Az UUCP használata az olcsó SLIP és PPP szolgáltatásokat kínáló internetszolgáltatók térnyerésével kezdett kihalni . Az UUCP Mapping Project hivatalosan 2000 végén leállt.

Az UUCP protokollt mára többnyire az internet TCP / IP alapú SMTP protokollja váltotta fel a levelek számára és az NNTP az Usenet hírek számára.

2012 júliusában az XS4ALL holland internetszolgáltató bezárta UUCP szolgáltatását, azt állítva, hogy "valószínűleg a világ egyik utolsó szolgáltatója kínálta még"; akkor csak 13 felhasználója volt (a leállítása előtt azonban több évig elutasította az új felhasználók kéréseit).

Jelenlegi felhasználás és örökség

Az UUCP egyik megmaradt jellemzője a chat fájlformátum, amelyet nagyrészt az Expect szoftvercsomag örököl .

Az UUCP speciális célú, magas költségű összeköttetéseken (pl. Tengeri műholdas összeköttetéseken) volt használatban jóval azután, hogy másutt eltűnt, és továbbra is örökölt. A régi használat mellett 2021-ben egyre növekszik az UUCP új és innovatív felhasználása, különösen a telekommunikáció számára a HF sávban, például az amazóniai esőerdők közösségei számára e-mailek cseréjére és egyéb felhasználásra. Az Ian UUCP-jének javítását az UUCP Debian Linux csomagjához adták hozzá, hogy alkalmazkodjon a HERMES (High-Frequency Emergency and Rural Multimedia Exchange System) projekthez, amely UUCP HF-kapcsolatot biztosít.

A 2000-es évek közepén javasolták az UUCP TCP / IP-n keresztül (gyakran titkosítva, az SSH protokoll használatával) használatát, amikor a számítógépnek nincs rögzített IP-címe, de továbbra is hajlandó futtatni egy szabványos levélátviteli ügynököt (MTA), mint például a Sendmail vagy Postfix .

Bummszerű utak továbbra is használatosak a Usenet hálózaton belül , bár nem útválasztáshoz; arra használják, hogy az üzenet fejlécében rögzítsék azokat a csomópontokat, amelyeken keresztül az üzenet átment, ahelyett, hogy irányítanák, hova fog tovább menni. A "Bang path" kifejezést használják a hálózati hosztok közötti bármely kifejezetten meghatározott útválasztási útvonal kifejezésére is . Ez a használat nem feltétlenül korlátozódik az UUCP-re, az IP-útválasztásra, az e-mail üzenetküldésre vagy a Usenetre.

A késleltetést elviselő hálózati protokollok fogalmát a 2000-es évek elején felülvizsgálták. Az UUCP által használtakhoz hasonló technikák alkalmazhatók más hálózatokon is, amelyek késést vagy jelentős zavarokat tapasztalnak.

Lásd még

Hivatkozások

Külső linkek