UUCP — UUCP

UUCP
Pierwotny autor (autorzy) Mike Lesk
Deweloper(zy) AT&T Bell Laboratories
Pierwsze wydanie 1979 ; 42 lata temu ( 1979 )
System operacyjny Unix i Unix-like , DOS , OS/2 , OpenVMS , AmigaOS , klasyczny Mac OS , CP/M
Rodzaj Komenda

UUCP to akronim od Unix-to-Unix Copy . Termin ten ogólnie odnosi się do zestawu programów komputerowych i protokołów umożliwiających zdalne wykonywanie poleceń oraz przesyłanie plików , wiadomości e - mail i wiadomości sieciowych między komputerami .

Polecenie o nazwie uucpjest jednym z programów w pakiecie; udostępnia interfejs użytkownika do żądania operacji kopiowania plików. Pakiet UUCP obejmuje również uux(interfejs użytkownika do zdalnego wykonywania poleceń), uucico(program komunikacyjny, który wykonuje transfer plików), uustat(raportuje statystyki ostatniej aktywności), uuxqt(wykonuje polecenia wysyłane ze zdalnych maszyn) i uuname(raportuje nazwę UUCP system lokalny). Niektóre wersje pakietu zawierają uuencode/ uudecode(konwertowanie 8-bitowych plików binarnych na 7-bitowy format tekstowy i odwrotnie).

Chociaż UUCP został pierwotnie opracowany na Unix w latach 70. i 80. i jest najbardziej związany z systemami uniksopodobnymi, implementacje UUCP istnieją dla kilku nieuniksopodobnych systemów operacyjnych, w tym DOS , OS/2 , OpenVMS (tylko dla sprzętu VAX ), AmigaOS , klasyczny Mac OS , a nawet CP/M .

Historia

UUCP został pierwotnie napisany w AT&T Bell Laboratories przez Mike'a Leska . Do 1978 był używany na 82 maszynach UNIX w systemie Bell, głównie do dystrybucji oprogramowania. Został wydany w 1979 roku jako część wersji 7 Unix . Oryginalny UUCP został przepisany przez badaczy AT&T Petera Honeymana, Davida A. Nowitza i Briana E. Redmana około 1983 roku. Przepisanie jest określane jako HDB lub HoneyDanBer uucp, które później zostało ulepszone, naprawione i przepakowane jako BNU UUCP (" Podstawowe narzędzia sieciowe”).

Każda z tych wersji była rozpowszechniana jako oprogramowanie zastrzeżone, co zainspirowało Iana Lance'a Taylora do napisania nowej wersji wolnego oprogramowania od podstaw w 1991 roku. Taylor UUCP został wydany na Powszechnej Licencji Publicznej GNU . Taylor UUCP rozwiązał luki w zabezpieczeniach, które umożliwiły niektórym oryginalnym robakom sieciowym zdalne wykonywanie nieoczekiwanych poleceń powłoki. Taylor UUCP zawierał również cechy wszystkich poprzednich wersji UUCP, pozwalając mu komunikować się z każdą inną wersją, a nawet używać podobnych formatów plików konfiguracyjnych z innych wersji.

UUCP został również zaimplementowany dla systemów operacyjnych innych niż UNIX , w szczególności systemów DOS . Pakiety takie jak UUSLAVE/GNUUCP ( John Gilmore , Garry Paxinos, Tim Pozar), UUPC/extended (Drew Derbyshire z Kendra Electronic Wonderworks) i FSUUCP (Christopher Ambler z IODesign), przyniosły wczesną łączność internetową z komputerami osobistymi, rozszerzając sieć poza połączone systemy uniwersyteckie. FSUUCP stanowiły podstawę dla wielu Bulletin Board System (BBS) pakietów, takich jak Galacticomm za majora BBS i Mustang Software „s Wildcat! BBS do łączenia się z siecią UUCP i wymiany poczty e-mail i ruchu Usenet . Na przykład UFGATE (John Galvin, Garry Paxinos, Tim Pozar) był pakietem, który zapewniał bramę między sieciami z protokołami Fidonet i UUCP.

FSUUCP była jedyną inną implementacją rozszerzonego protokołu „i” Taylora, co było znaczącym ulepszeniem w stosunku do standardowego protokołu „g” używanego przez większość implementacji UUCP.

Technologia

Przed powszechnym dostępem do Internetu komputery były połączone jedynie mniejszymi sieciami lokalnymi w obrębie firmy lub organizacji. Były one również często wyposażone w modemy, dzięki czemu można było z nich korzystać zdalnie z terminali znakowych za pośrednictwem wdzwanianych linii telefonicznych . UUCP wykorzystywał modemy komputerów do łączenia się z innymi komputerami, ustanawiając między nimi tymczasowe łącza punkt-punkt. Każdy system w sieci UUCP ma listę sąsiednich systemów, z numerami telefonów, nazwami logowania i hasłami itp. Gdy praca (żądanie transferu plików lub wykonania polecenia) jest kolejkowana do sąsiedniego systemu, uucicoprogram zazwyczaj wywołuje ten system w celu przetworzenia praca. uucicoProgram może również sondować sąsiadów okresowo w celu sprawdzenia pracy kolejce po ich stronie; pozwala to na uczestnictwo sąsiadów bez możliwości wybierania numeru.

Z biegiem czasu łącza dial-up zostały zastąpione połączeniami internetowymi, a UUCP dodał szereg nowych protokołów warstwy łącza. Te nowsze połączenia w ogóle zmniejszyły również zapotrzebowanie na UUCP, ponieważ opracowano nowsze protokoły aplikacji, aby wykorzystać zalety nowych sieci. Obecnie UUCP jest rzadko używany przez łącza dial-up, ale czasami jest używany przez TCP/IP . Liczba zaangażowanych systemów na początku 2006 r. obejmowała od 1500 do 2000 witryn w 60 przedsiębiorstwach. Długowieczność UUCP można przypisać niskiemu kosztowi, obszernemu rejestrowaniu, natywnemu przełączaniu awaryjnemu na połączenia telefoniczne i trwałemu zarządzaniu kolejkami.

Sesje

UUCP jest zwykle uruchamiany przez zalogowanie się użytkownika do systemu docelowego, a następnie uruchomienie programu UUCP. W większości przypadków odbywa się to automatycznie poprzez zalogowanie się na znane konto użytkownika używane do przelewów, którego powłoka konta została ustawiona na uucico. Dlatego w przypadku przelewów automatycznych inna maszyna musi po prostu otworzyć połączenie modemowe z wywoływaną maszyną i zalogować się na znane konto.

Po uruchomieniu uucico będzie oczekiwać odebrania poleceń z innego programu UUCP na komputerze wywołującego i rozpoczęcia sesji. Sesja składa się z trzech odrębnych etapów:

  1. Początkowy uścisk dłoni
  2. Żądania plików
  3. Ostateczny uścisk dłoni

Początkowy uścisk dłoni

Na początku uucico odpowie wysyłając łańcuch identyfikacyjny, , gdzie \20 jest znakiem control-P, a \0 jest końcowym znakiem null. UUCP wywołującego odpowiada za pomocą , gdzie options jest łańcuchem zawierającym zero lub więcej przełączników opcji podobnych do Uniksa. Mogą to być rozmiary pakietów i okien, maksymalny obsługiwany rozmiar pliku, opcje debugowania i inne. \20Shere=hostname\0\20Scallername options\0

W zależności od konfiguracji dwóch systemów, połączenie może się tutaj zakończyć. Na przykład, gdy dzwoniący odpowiada nazwą swojego systemu, wywoływany system może opcjonalnie rozłączyć się, jeśli nie rozpoznaje dzwoniącego, wysyłając RYou are unknown to me\0ciąg odpowiedzi, a następnie rozłączając się.

Żądania plików

Jeśli dwa systemy pomyślnie uzgadniają, dzwoniący zacznie teraz wysyłać serię żądań plików. Istnieją cztery rodzaje:

S powoduje wysłanie pliku od wywołującego do wywoływanego systemu (upload). Dostępne są nazwy od i do, co pozwala na zmianę nazwy pliku w odbiorniku. Gdy polecenie S zostanie odebrane w wywoływanym systemie, odpowiada on SY, jeśli się powiedzie i jest gotowy do zaakceptowania pliku, lub SNx, jeśli się nie powiodło, gdzie x jest przyczyną niepowodzenia. Jeśli SY zostanie odebrane przez dzwoniącego, rozpoczyna się ładowanie pliku przy użyciu protokołu wybranego podczas początkowego uzgadniania (patrz poniżej). Po zakończeniu przesyłania wywoływany system odpowiada CY, jeśli pomyślnie odebrał plik, lub CN5, jeśli się nie udało.
R jest Żądaniem dla wywoływanego systemu wysłania pliku do dzwoniącego (pobranie). W przeciwnym razie jest podobny do S, używając RY i RN do wskazania, że ​​polecenie zostało zaakceptowane i zacznie wysyłać dane lub ma problem, i oczekuje CY i CN5 od wywołującego na końcu transferu.
X wgrywa polecenia do wykonania w wywoływanym systemie. Można to wykorzystać do wywołania przez system innego i dostarczenia do niego plików. Wywoływany system odpowiada XY, jeśli się powiodło, lub XN, jeśli się nie udało.
H , dla Hangup, oznacza zakończenie połączenia. Wywoływany system odpowiada HY, jeśli się powiodło, lub HN, jeśli się nie powiodło.

Ostateczny uścisk dłoni

Po wysłaniu komendy H, system wywołujący wysyła końcowy pakiet \20OOOOOO\0(control-P, sześć ohs, terminator zerowy), a wywoływany system odpowiada \20OOOOOO\0(control-P, siedem ohs, terminator zerowy). Niektóre systemy po prostu rozłączą się po pomyślnym odebraniu polecenia H i nie zawracają sobie głowy ostatnim uściskiem dłoni.

protokół gpro

W zestawie protokołów w UUCP, podstawowy protokół g jest odpowiedzialny za przesyłanie informacji w bezbłędnej formie. Protokół powstał jako system ogólnego przeznaczenia do dostarczania pakietów, a zatem oferuje szereg funkcji, które nie są wykorzystywane przez pakiet UUCP jako całość. Obejmują one dodatkowy kanał, który może wysyłać dane poleceń przeplatane transferem plików, oraz możliwość renegocjacji wielkości pakietów i okien podczas transmisji. Te dodatkowe funkcje mogą nie być dostępne w niektórych implementacjach stosu UUCP.

Format pakietu składał się z 6-bajtowego nagłówka, a następnie od zera do 4096 bajtów w ładunku. Pakiet zaczyna się od pojedynczego \020 (control-P). Po nim następuje pojedynczy bajt, znany jako „K”, zawierający wartość od 1 do 8, wskazujący rozmiar pakietu od 32 do 4096 bajtów, lub 9 oznaczający pakiet kontrolny. Wiele systemów obsługiwało tylko K=2, co oznacza 64 bajty. Następne dwa bajty to 16-bitowa suma kontrolna ładunku, bez nagłówka. Następny bajt to typ danych, a ostatni bajt to XOR nagłówka, co pozwala na sprawdzenie go oddzielnie od ładunku.

Bajt kontrolny składa się z trzech pól bitowych w formacie TTXXXYYY. TT to typ pakietu, 0 dla pakietów kontrolnych (które również wymaga K=9 do poprawnego działania), 1 dla alternatywnych danych (nieużywanych w UUCP), 2 dla danych, a 3 oznacza krótki pakiet, który na nowo definiuje znaczenie K. W pakiecie danych XXX to numer pakietu dla tego pakietu od 0 do 7, a YYY to ostatni, który został poprawnie odebrany. Zapewnia to do 8 pakietów w oknie. W pakiecie kontrolnym XXX wskazuje polecenie, a YYY jest używane dla różnych parametrów. Na przykład, transfery są rozpoczynane przez wysłanie krótkiego pakietu kontrolnego z TT=0 (kontrola), XXX=7 i YYY liczbą pakietów w oknie, a następnie wysłanie kolejnego pakietu z XXX=6 i YYY jako długością pakietu (zakodowane jako byłoby to w K), a następnie trzeci pakiet, który jest identyczny z pierwszym, ale XXX=5.

g-protocol wykorzystuje prosty system okien przesuwnych , aby poradzić sobie z potencjalnie długimi opóźnieniami między punktami końcowymi. Protokół zezwala na pakiety o rozmiarze od 64 do 4096 8-bitowych bajtów oraz okna zawierające od 1 do 7 pakietów. Teoretycznie system wykorzystujący pakiety 4k i 7 okien pakietów (4096x7) oferowałby dopasowanie wydajności lub pokonanie najlepszych protokołów przesyłania plików, takich jak ZMODEM . W praktyce wiele implementacji obsługiwało tylko jedno ustawienie 64x3. W rezultacie protokół g ma niezasłużoną reputację słabej wydajności. Zamieszanie dotyczące rozmiaru pakietów i okien doprowadziło do powstania protokołu G, różniącego się tylko tym, że zawsze używał 4096x3. Taylor UUCP nie obsługiwał G, ale obsługiwał każde prawidłowe żądane okno lub rozmiar pakietu, więc zdalne systemy uruchamiające G działałyby dobrze z g Taylora, podczas gdy dwa systemy Taylora mogły negocjować jeszcze szybsze połączenia.

Modemy Telebit wykorzystywały fałszowanie protokołu w celu poprawy wydajności transferów g-protocol poprzez zauważanie znaczników końca pakietu wysyłanych do zdalnego systemu i natychmiastowe wysyłanie odpowiedzi ACKdo lokalnego hosta, udając, że zdalny system już odebrał i zdekodował pakiet to poprawnie. To spowodowało, że stos oprogramowania wysłał następny pakiet tak szybko, że transfer stał się prawie ciągły. Dane między dwoma modemami zostały skorygowane przy użyciu zastrzeżonego protokołu opartego na MNP, który działał przez połączenia half-duplex Telebit znacznie lepiej niż normalnie g-protocol, ponieważ w typowym przypadku 64x3 zdalny system wysyłałby stały strumień ACKs, które przepełniłyby kanał powrotny o niskiej prędkości. W połączeniu z naturalnie wyższymi szybkościami transmisji danych modemu, znacznie poprawiły one ogólną przepustowość i ogólnie działały około siedmiokrotnie szybciej niż modem 2400 bps. Były powszechnie używane na hostach UUCP, ponieważ mogły szybko spłacić się dzięki obniżonym opłatom za połączenia międzymiastowe.

Inne protokoły

Implementacje UUCP obejmują również inne protokoły przesyłania do użytku przez niektóre łącza.

f-protocol jest zaprojektowany do uruchamiania przez 7-bitowe łącza z korekcją błędów. Pierwotnie był przeznaczony do użytku z łączami X.25 , które były popularne przez pewien czas w latach 80. XX wieku. Nie pakietuje danych, zamiast tego cały plik jest wysyłany jako pojedynczy długi ciąg, po którym następuje suma kontrolna całego pliku. Podobny protokół x wydaje się być mało przydatny lub wcale. d-protocol był podobny do x, ale przeznaczony do użytku w sieciach Datakit , które łączyły wiele biur Bell Labs .

t-protocol wywodzi się z wersji BSD UUCP i jest przeznaczony do uruchamiania przez 8-bitowe wolne od błędów łącza TCP/IP . W ogóle nie ma korekcji błędów, a protokół składa się po prostu z dzielenia danych poleceń i plików na 512 lub 1024-bajtowe pakiety, aby łatwo zmieścić się w typowych ramkach TCP. Rzadziej używany e-protokół , który pochodzi z wersji HoneyDanBer w przeciwieństwie do t z BSD, różni się tylko tym, że polecenia nie są pakietowane i są zamiast tego wysyłane jako normalne ciągi, podczas gdy pliki są dopełniane do najbliższych 20 bajtów.

Routing poczty

Wizytówka z adresem e-mail UUCP

Możliwości uucpi uuxqtmogą być wykorzystywane do wysyłania wiadomości e-mail między komputerami, z odpowiednimi interfejsami użytkownika poczty i programami agentów dostarczania. Prosty adres pocztowy UUCP został utworzony z nazwy sąsiedniej maszyny, znaku wykrzyknika (często wymawianego bang ), po którym następowała nazwa użytkownika na sąsiednim komputerze. Na przykład, adres barbox!user odwołuje się do użytkownika user na sąsiednim komputerze barbox .

Poczta mogłaby ponadto być kierowana przez sieć, przechodząc przez dowolną liczbę węzłów pośrednich przed dotarciem do miejsca przeznaczenia. Początkowo należało to zrobić, określając pełną ścieżkę, z listą nazw hostów pośrednich oddzielonych grzywką. Na przykład, jeśli machine barbox nie jest podłączony do lokalnej maszyny, ale wiadomo, że barbox jest połączony z maszyną foovax, która komunikuje się z lokalną maszyną, odpowiednim adresem do wysłania poczty będzie foovax!barbox!user .

Użytkownik barbox!user zwykle publikowałby swój adres e-mail UUCP w postaci …!bigsite!foovax!barbox!user . To kieruje ludzi do przekierowania swojej poczty do maszyny bigsite (przypuszczalnie dobrze znanej i dobrze połączonej maszyny dostępnej dla wszystkich), a stamtąd przez maszynę foovax do konta użytkownika użytkownika na barbox . Opublikowanie pełnej ścieżki byłoby bezcelowe, ponieważ byłoby różne, w zależności od tego, gdzie był nadawca. (np. Ann w jednym miejscu może być zmuszona do wysłania ścieżką gway!tcol!canty!uoh!bigsite!foovax!barbox!user , podczas gdy z innego miejsca Bill musi wysłać ścieżką pdp10!router22!bigsite!foovax!barbox! użytkownik ). Wielu użytkowników sugerowałoby wiele tras z różnych dużych znanych witryn, zapewniając jeszcze lepszą i być może szybszą usługę połączenia od nadawcy poczty.

Ścieżka uderzenia

Adres e-mail tego formularza był znany jako ścieżka wybuchu . Ścieżki uderzenia od ośmiu do dziesięciu maszyn (lub przeskoków ) nie były rzadkością w 1981 r., a późne łącza dial-up UUCP mogły powodować tygodniowe czasy transmisji. Ścieżki uderzenia były często wybierane zarówno na podstawie czasu transmisji, jak i niezawodności, ponieważ wiadomości często ginęły. Niektóre hosty posunęły się tak daleko, że próbowały „ przepisać ” ścieżkę, wysyłając pocztę „szybszymi” trasami — ta praktyka była zwykle niemile widziana.

Końcówka „pseudodomeny” .uucp była czasami używana do oznaczenia nazwy hosta jako osiągalnej przez sieć UUCP, chociaż nigdy nie została ona formalnie zarejestrowana w systemie nazw domen (DNS) jako domena najwyższego poziomu . Społeczność uucp administrowała się sama i nie pasowała do metod administracji i przepisów regulujących DNS; .uucp działa tam, gdzie trzeba; niektóre hosty wysyłają pocztę z kolejki SMTP do kolejek uucp na maszynach będących bramkami, jeśli adres .uucp jest rozpoznawany w przychodzącym połączeniu SMTP.

Ruch Usenetu był pierwotnie przesyłany przez protokół UUCP przy użyciu ścieżek bang. Są one nadal używane w liniach nagłówka ścieżki formatu wiadomości Usenet . Mają teraz tylko cel informacyjny i nie są używane do routingu, chociaż mogą być używane do zapewnienia, że ​​nie wystąpią pętle.

Ogólnie rzecz biorąc, podobnie jak inne starsze formaty adresów e-mail , ścieżki bang zostały zastąpione przez „ notację @ ”, nawet przez witryny nadal korzystające z UUCP. Witryna korzystająca wyłącznie z UUCP może zarejestrować nazwę domeny DNS, a serwer DNS, który obsługuje tę domenę, dostarcza rekordy MX, które powodują dostarczanie poczty internetowej do tej witryny do hosta UUCP w Internecie, który może następnie dostarczać pocztę do UUCP teren.

UUCPNET i mapowanie

UUCPNET to nazwa całej sieci komputerów połączonych poprzez UUCP. Sieć ta była bardzo nieformalna, utrzymywana w duchu wzajemnej współpracy pomiędzy systemami będącymi własnością tysięcy prywatnych firm, uczelni i tak dalej. Często, szczególnie w sektorze prywatnym, powiązania UUCP były ustanawiane bez oficjalnej zgody kierownictwa wyższego szczebla firm. Sieć UUCP stale się zmieniała, ponieważ dodawano nowe systemy i łącza dial-up, inne usuwano itp.

Projekt mapowania UUCP był ochotnikiem, w dużej mierze udanym wysiłkiem zbudowania mapy połączeń między maszynami, które były otwartymi przekaźnikami poczty i ustanowienia zarządzanej przestrzeni nazw. Każdy administrator systemu przesyłał pocztą elektroniczną listę systemów, z którymi miałby się łączyć, wraz z rankingiem każdego takiego połączenia. Te przesłane wpisy map zostały przetworzone przez automatyczny program, który połączył je w jeden zestaw plików opisujących wszystkie połączenia w sieci. Pliki te były następnie publikowane co miesiąc w specjalnie do tego celu przeznaczonej grupie dyskusyjnej . Pliki map UUCP mogą być następnie wykorzystywane przez oprogramowanie, takie jak „pathalias”, do obliczania najlepszej ścieżki trasy z jednego komputera do drugiego dla poczty i automatycznego dostarczania tej trasy. Mapy UUCP zawierały również informacje kontaktowe dla stron, dzięki czemu strony pragnące dołączyć do UUCPNET miały łatwy sposób na znalezienie potencjalnych sąsiadów.

Połączenia z Internetem

Wiele hostów UUCP, szczególnie tych na uniwersytetach, było również podłączonych do Internetu we wczesnych latach, i opracowano bramki poczty e-mail między pocztą internetową opartą na protokole SMTP a pocztą UUCP. Użytkownik w systemie z połączeniami UUCP może w ten sposób wymieniać pocztę z użytkownikami Internetu, a łącza internetowe mogą być wykorzystywane do omijania dużych fragmentów wolnej sieci UUCP. „Strefa UUCP” została zdefiniowana w przestrzeni nazw domen internetowych w celu ułatwienia tych interfejsów.

Dzięki tej infrastrukturze mocną stroną UUCP było to, że umożliwiało witrynie uzyskanie dostępu do internetowej poczty e-mail i sieci Usenet przy użyciu jedynie łącza modemowego wdzwanianego do innego współpracującego komputera. Działo się to w czasie, gdy prawdziwy dostęp do Internetu wymagał dzierżawionej linii danych zapewniającej połączenie z Internetowym Punktem Obecności , co było kosztowne i trudne do zorganizowania. W przeciwieństwie do tego, połączenie z siecią UUCP można zwykle ustanowić za pomocą kilku telefonów do administratorów potencjalnych sąsiednich systemów. Sąsiednie systemy często znajdowały się na tyle blisko, aby uniknąć wszystkich opłat za rozmowy telefoniczne poza podstawowymi.

Polecenia zdalne

uux to zdalne wykonywanie poleceń przez UUCP. Polecenie uux służy do wykonania polecenia w systemie zdalnym lub do wykonania polecenia w systemie lokalnym przy użyciu plików z systemów zdalnych. Polecenie jest uruchamiane przez uucicodemona, który obsługuje żądania zdalnego wykonania jako po prostu inny rodzaj pliku do wysłania wsadowego do zdalnego systemu, gdy tylko dostępny jest węzeł następnego przeskoku. Zdalny system wykona następnie żądane polecenie i zwróci wynik, gdy oryginalny system będzie dostępny. Oba te transfery mogą być pośrednie, poprzez ścieżki wieloskokowe, z dowolnymi oknami dostępności. Nawet podczas wykonywania polecenia na zawsze dostępnym sąsiedzie, uux nie jest natychmiastowe.

Upadek

Wykorzystanie UUCP zaczęło wygasać wraz z pojawieniem się dostawców usług internetowych oferujących niedrogie usługi SLIP i PPP . Projekt mapowania UUCP został formalnie zamknięty pod koniec 2000 roku.

Protokół UUCP został obecnie w większości zastąpiony protokołami internetowymi opartymi na TCP/IP: SMTP dla poczty i NNTP dla grup Usenet.

W lipcu 2012 r. holenderski dostawca Internetu XS4ALL zamknął swoją usługę UUCP, twierdząc, że jest „prawdopodobnie jednym z ostatnich dostawców na świecie, który nadal ją oferuje”; w tym czasie miał tylko 13 użytkowników (jednak przed zamknięciem przez kilka lat odrzucał żądania nowych użytkowników).

Obecne zastosowania i dziedzictwo

Jedną z zachowanych cech UUCP jest format pliku czatu, w dużej mierze odziedziczony przez pakiet oprogramowania Expect .

UUCP był używany przez drogie łącza specjalnego przeznaczenia (np. morskie łącza satelitarne) długo po jego zniknięciu gdzie indziej i nadal pozostaje w użyciu. Oprócz tradycyjnego użytkowania, w 2021 r. rosną nowe i innowacyjne zastosowania UUCP, zwłaszcza w telekomunikacji w paśmie HF , na przykład dla społeczności w lasach deszczowych Amazonii do wymiany e-maili i innych zastosowań. Łatka do UUCP Iana została dodana do pakietu UUCP Debian Linux w celu dostosowania do projektu HERMES (High-Frequency Emergency and Rural Multimedia Exchange System), który zapewnia łączność UUCP HF.

W połowie 2000 roku zaproponowano użycie UUCP przez TCP/IP (często szyfrowane przy użyciu protokołu SSH ), gdy komputer nie ma żadnych stałych adresów IP, ale nadal jest gotowy do uruchomienia standardowego agenta przesyłania poczty (MTA), takiego jak Sendmail lub Postfiks .

Ścieżki podobne do Bang są nadal używane w sieci Usenet , ale nie do routingu; są one używane do zapisywania w nagłówku wiadomości węzłów, przez które ta wiadomość przeszła, a nie do wskazywania miejsca, w którym przejdzie dalej. „Bang path” jest również używany jako wyrażenie dla dowolnej wyraźnie określonej ścieżki routingu między hostami sieciowymi. Takie użycie niekoniecznie ogranicza się do UUCP, routingu IP, wiadomości e-mail lub Usenetu.

Koncepcja protokołów sieciowych odpornych na opóźnienia została ponownie przyjęta na początku XXI wieku. Podobne techniki, jak te stosowane przez UUCP, mogą mieć zastosowanie do innych sieci, w których występują opóźnienia lub znaczące zakłócenia.

Zobacz też

Bibliografia

Linki zewnętrzne