Janus (protokół)
| Protokół komunikacyjny | |
| Zamiar | Protokół Przesyłania Plików |
|---|---|
| Deweloperzy | Ricka Huebnera |
| Wstęp | grudzień 1987 |
| Oparte na | ZMODEM |
| Sprzęt komputerowy | modemy |
Janus to protokół przesyłania plików do użytku w systemach tablic ogłoszeń (BBS). Ma stosunkowo rzadką cechę, że jest w pełni dwukierunkowy, umożliwiając protokołowi jednoczesne przesyłanie i pobieranie plików. Został napisany przez Ricka Huebnera w 1987 roku; Huebner wcześniej napisał ZMODEM dla systemu Opus-CBBS.
Korzystając z Janus, systemy Opus BBS mogą zaoszczędzić czas, wymieniając pliki, takie jak pakiety wiadomości FidoNet w obu kierunkach w tym samym czasie, co Huebner opisał jako wysyłanie krótszego pliku za darmo. W większości przypadków dany system w sieci Fido pobierałby więcej wiadomości niż odsyłał, więc w praktyce efekt był taki, że strumień odpowiedzi był bezkosztowy.
Janus był przydatny w ustawieniach, w których łącza upstream i downstream miały podobną wydajność, co było prawdą w połowie lat 80., kiedy większość szybkich modemów działała z szybkością 2400 bps w obu kierunkach. Jednak protokół został wprowadzony prawie w tym samym czasie, co szybka popularyzacja USRobotics HST z szybkością pobierania 9600 bps i wysyłania tylko 300 bps, w przypadku której Janus oferował niewielką lub żadną przewagę. Kiedy pojawiły się szybsze modemy dwukierunkowe, takie jak v.32bis , Janus już w dużej mierze zniknął.
Detale
Janus to protokół zorientowany na pakiety, taki jak XMODEM i podobne systemy. W tych protokołach plik jest przesyłany w „pakietach” lub „blokach”, czyli małych częściach pliku jako całości. Po odebraniu każdego pakietu jest sprawdzany pod kątem błędów, a jeśli zostanie znaleziony błąd, komunikat o błędzie jest wysyłany z powrotem do nadawcy. Następnie nadawca wysyła pakiet ponownie, dopóki się nie powiedzie lub transfer nie zostanie anulowany po określonej liczbie błędów.
Janus jest typowym protokołem późnych lat 80., który próbuje lepiej wykorzystać rosnące prędkości modemu . XMODEM przesyłał tylko 128 bajtów danych na pakiet, a następnie czekał na odpowiedź od odbiornika przed wysłaniem kolejnego pakietu. Ze względu na opóźnienie sieci telefonicznej minimalny możliwy czas na otrzymanie tego potwierdzenia stanowił znaczny procent czasu potrzebnego na wysłanie następnego pakietu, co prowadziło do stosunkowo niskiego wykorzystania kanału na szybszych modemach.
Rozwiązaniem tego problemu zastosowanym w Janusie było umożliwienie zmiany rozmiaru pakietu, od 0 do 2052 bajtów na pakiet. W przypadku większych pakietów opóźnienie sieci stanowi znacznie mniejszą część czasu potrzebnego do wysłania pakietu. Dodatkowo Janus nie zatrzymywał się i nie czekał, aż odbiorca potwierdzi odbiór pakietu, po prostu zakładał, że został on prawidłowo odebrany i od razu rozpoczynał wysyłanie kolejnego pakietu. Jeśli wystąpił błąd, odbiornik zasygnalizowałby to z powrotem do nadawcy, a następnie zły pakiet zostałby ponownie wysłany, gdy tylko bieżący pakiet został ukończony.
Podstawowa struktura pakietu Janus składała się z następującego wzorca:
PKTSTRT, dane, PKTYPE, PKTEND, CRC
PKTSTRT i PKTEND były unikalnymi sekwencjami znaków, które pozwalały protokołowi zidentyfikować początek i koniec sekcji danych. Sekcja danych zawierała od 0 do 2052 bajtów danych, w zależności od PKTYPE. CRC była 16-bitową cykliczną kontrolą redundancji , to samo dotyczy XMODEM-CRC (i jego odmian). Było kilka różnych PKTYPE, które reprezentowały pakiety danych, potwierdzenia, naki i inne szczegóły transferu, a także FNAMEPKT, który wysyłał metadane pliku (nazwa, rozmiar itp.), Które inne protokoły obsługiwały w „pakiecie zero”. W przeciwieństwie do większości innych protokołów, Janus używał 32-bitowego przesunięcia w pliku do identyfikacji pakietów, w przeciwieństwie do protokołów pochodzących z XMODEM, które wykorzystywały wewnętrzny numer pakietu, który zwykle był monotonicznie rosnącą liczbą całkowitą.
Błąd w Janusie spowodowałby, że odbiornik wysłałby pakiet BADPKT z odesłanym offsetem pliku, umożliwiając systemowi wysłanie dowolnego pakietu poza kolejnością w dowolnym momencie. Dużą liczbę błędów można było rozwiązać wysyłając pakiet RPOSPKT, który „przewijał” transfer pod zadany 32-bitowy adres. W przeciwieństwie do innych protokołów, Janus nie miał z góry zdefiniowanych limitów liczby niepowodzeń, które spowodowałyby niepowodzenie transferu, transfery kończyły się tylko wtedy, gdy jedna lub druga strona jawnie wysłała HALTPKT.
Rozmiar pakietu w Janusie był dobierany dynamicznie na podstawie liczby błędów transmisji oraz czasu wysłania pakietu. Był to ten sam algorytm, który Huebner opracował dla swojej wersji ZMODEM używanej w systemie Opus BBS. Algorytm ten został później przeniesiony z powrotem do standardu ZMODEM przez Chucka Foresberga.
Cytaty
Bibliografia
- Huebner, Rick (16 grudnia 1987). Wprowadzenie do protokołu przesyłania plików w pełnym dupleksie Opus Janus (raport techniczny).