• CAM 9 - Roadshow, stos TCP/IP

18.02.2005 23:01, autor artykułu: Olaf Barthel
odsłon: 7430, powiększ obrazki, wersja do wydruku,

Oto "Roadshow" - nowy stos TCP/IP dla AmigaOS - autor: Olaf Barthel

1. Wprowadzenie

1.1 Boże narodzenie 2000

Co robiliście podczas tych dłużących się dni między wigilią a pierwszym dniem nowego, 2001 roku? Ja czytałem książkę Petera Bogdanovicha "This is Orson Welles" i zaczynałem pracę nad portowaniem stosu TCP/IP dla Amigi. Dlaczego? Jak zapewne pamiętacie, AmigaOS3.5 dostarczany był ze specjalną, ograniczoną wersją programu Holgera Kruse - Miami, posiadającego zintegrowany stos TCP/IP. Pełen stos TCP/IP został dołączony w AmigaOS3.9 pod postacią "AmiTCP Genesis". Jednakże, kwestia tego kto właściwie był właścicielem "AmiTCP" i czy mógł on zostać legalnie dołączony do AmigaOS3.9, doprowadziła do wielu komplikacji. W czasie, gdy zacząłem pracę nad moim małym projektem, trudno było powiedzieć czy jakikolwiek amigowy stos TCP/IP jest nadal dostępny do kupienia i/lub nadal jest rozwijany. Zaciekawiło mnie, jak trudne będzie przeportowanie stosu TCP/IP na Amigę.

1.2 Krótka historia amigowego sieciowania

Po raz piewszy o stosie TCP/IP dla Amigi usłyszałem w roku 1990 podczas mojej rozmowy z miejscowym sprzedawcą Amig. Dostępny był wówczas w sklepach nowy produkt Commodore zwany A225, który reklamowano jako implementację stosu TCP/IP dla Amigi przy wykorzystaniu kart ethernetowych produkowanych przez Ameristar (które Commodore adaptowało jako kartę ethernetową A2065). Później dowiedziałem się, że ze strony Commodore była to próba wypełnienia luki wynikającej z potrzeb: karty ethernetowe były dostępne w sprzedaży przed pojawieniem się właściwego dla nich oprogramowania.

Pierwszym oficjalnym, amigowym stosem TCP/IP był port kernela BSD UNIX wraz z zestawem narzędzi i nawet klientem systemu plików dla Sunowskiego NFS-a (Networked File System). Niemniej jednak oprogramowanie było bardzo "surowe". Pamiętam, że tylko kilka aplikacji wykorzystywało ten stos, a wśród nich była gra firmy Maxis, Inc. "Robosport". W grze kilku graczy mogło konkurować w rozgrywce po sieci. Celem było zniszczenie robotów przeciwnika. Przy wykorzystaniu opcji null modem można było grać "po sieci" przez kartę ethernetową A2065/Ameristar.

To czego brakowało wówczas Amidze to standardowy sterownik, który mógł zostać wykorzystany do podłączenia dowolnego sprzętu "sieciowego". Sterownik ten przybył pod nazwą SANA (Standard Amiga Network Architecture). Będąc bardziej dokładnym, była to druga edycja tego standardu, znanego obecnie jako SANA-II. Premierę swoją miał w roku 1991, ale zajęło trochę czasu zanim przyjął się na dobre. Dla przykładu, w roku 1992 firma Oxxi wydała pakiet oprogramowania umożliwiający Amidze zintegrować się z sieciami Novellowymi. Amigowy klient tego oprogramowania pojawił się po opublikowaniu specyfikacji standardu SANA-II, jednak nie zawierał obsługi tego standardu i wymagał do pracy odrębnym sterowników.

Wśród pierwszych produktów obsługujących standard SANA-II znajdował się Commodorowski "Envoy" - program z rodziny peer-to-peer i do obsługi drukarek sieciowych zarazem. Nadal nie istniał jednak stos TCP/IP, który obsługiwałby standard SANA-II. Ludzie pracujący nad Envoy'em, pracowali również nad ulepszoną wersją swojego oryginalnego portu stosu TCP/IP. Nazwali go "AS225R2" (można domniemywać, że S to skrót od "shared library" - współdzielona biblioteka). Nowy stos zaprojektowany był na podobieństwo współdzielonej biblioteki zwanej "socket.library", w której zaimplementowano API BSD UNIX (wówczas będące standardem).

Niestety Commodore zdecydowało, że projekt rozwoju tego elementu zostaje zamknięty, a osoby nad nim pracujące zostały przeniesione do pracy nad innymi zadaniami. To zatrzymało rozwój zarówno Envoy jak i AS225R2. Ta decyzja sprawiła, że Amiga pozostała bez adekwatnego stosu TCP/IP.

Sprawy nabrały innego obrotu w roku 1993 gdy pewien student z Uniwersytetu w Helsinkach stworzył pierwszy stos TCP/IP dla Amigi, który bił na głowę AS225R2. Narodził się AmiTCP. Podobnie jak AS225R2, korzystał z kernela BSD UNIX i z nim powiązanych narzędzi. Jednakże interfejs był zgoła odmienny. Oprogramowanie musiało być specjalnie zaadoptowane, aby mogło być obsługiwane lub móc obsługiwać AmiTCP. Zdecydowanie nie był to zamiennik AS225R2.

Przez lata rosła konkurencja dla AS225R2 i AmiTCP. AS225R2 odrodziło się jako komercyjny produkt wydany przez Interworks. INet-225 i AmiTCP połączono i wydano pod nazwą jednego, komercyjnego produktu AmiTCP 4.0. Niektóre aplikacje obsługiwały interfejsy zarówno AS225R2 jak i AmiTCP, lecz w miarę upływu czasu coraz więcej oprogramowania obsługiwało tylko AmiTCP.

W roku 1996 dwa kolejne stosy TCP/IP stały się dostępne dla Amigi: "TermiteTCP" spod szyldu Oregon Research oraz "Miami" autorstwa Holgera Kruse. Obydwa były kompatybilne z AmiTCP. Wkrótce Miami, a później MiamiDeluxe stały się standardowym interfejsem obsługi stosu TCP/IP.

1.3 Obecna sytuacja

Podobnie jak kiedyś było ważnym i trudnym do osiągnięcia, aby Amiga posiadała dostęp do internetu, tak obecnie ważnym i niemożliwym do osiągnięcia jest kupno stosu TCP/IP, jak i karty ethernetowej przystosowanej do Amigi. AmiTCP nie można obecnie kupić, a autor Miami nie akceptuje nowych użytkowników zainteresowanych rejestracją ograniczonej wersji jego produktu.

2. Portowanie stosu TCP/IP dla Amigi

2.1 Ciekawość

Byłem bardzo ciekawy jak trudnym byłoby przeportowanie stosu TCP/IP dla Amigi. Gdy zacząłem badać ten temat, mogłem przyjrzeć się ostatniej dostępnej za darmo wersji AmiTCP, tj. 3.0. Zanim stała się produktem komercyjnym, wypuszczono jej kod źródłowy na zasadach licencji GPL. To umocniło mnie w przekonaniu, że będzie to dobry punkt zaczepienia, gdyż wyjaśniało jak "od środka" działa interfejs. Niemniej jednak i tak musiałem zaczynać od szczątków. Kod AmiTCP oparty jest na BSD UNIX Net/2 z wykorzystaniem kernelu MACH, w który był zintegrowany. W 2000 roku kod ten liczył już sobie 10 lat. Pomyślałem, że można się lepiej postarać. Nie uznałem również za lojalne stworzenie komercyjnego produktu na bazie adaptacji kodu objętego licencją GPL.

Wziąłem na warsztat ostatnią wersję 4.4BSD Unix i zacząłem wyciągać z tego kod. W projekcie AmiTCP można znaleźć zarówno funkcjonalność centralnego socketa I/O jak i funkcje dostępu do bazy danych (dla nazw usług i nazw domen). Musiałem to wyciągnać z kernela i współdzielonych bibliotek. Oddzielenie właściwego kodu było pierwszym krokiem przy portowaniu.

2.2 Pamięć i przerwania

System operacyjny Amigi i typowy kernel Unixa nie mają nic wspólnego. AmigaOS możemy nazwać "mikrokernelem", w którym usługi takie jak przekazywanie wiadomości i dostarczenie sygnału łączą aplikacje i system operacyjny. W kernelu Unixa istnieje specjalny protokół dla aplikacji, który uzyskuje usługi kernela poprzez wymuszenie funkcji sieciowych. Wewnątrz kernela przerwania (kontrolowane przez warunki sprzętowe i programowe) kierują przetwarzaniem danych przychodzących i wychodzących.

Portując stos TCP/IP oparty na Unixie należy zaadaptować kod kernela w architekturę AmigaOS. Dla przykładu, jeśli pakiet danych przybywa z sieci, na systemie Unixowym przerwania przejmują kontrolę powodując rozpoczęcie procesu przyjmowania danych. Na Amidze pakiet przybywa w formie wiadomości, która musi zostać przetworzona.

W kernelu BSD UNIX, który próbowałem przeportować, można zauważyć, że hierarchia poziomu przerwań zarządza przetwarzaniem danych przychodzących i wychodzących. Ta poziomowa hierarchia działa niczym mechanizm arbitralny: jeśli ustawimy wyższy poziom przerwań, przerwania na niższych poziomach są blokowane do czasu gdy nie przestawimy ich na obsługę poziomu niższego. Mechanizm oddziela np. transmisję pakietów danych przychodzących/wychodzących od przetwarzania danych, które te pakiety zawierają. Cecha arbitrażowa jest podobna do funkcji Forbid/Permit z systemu operacyjnego Amigi, które są typowymi dla współdzielonych systemów operacyjnych lub Task resources. W rzeczywistości AmiTCP wykorzystuje Forbid/Permit do emulacji wielopoziomowej hierarchi przerwań kernela Unixowego.

Kolejną własnością kernela BSD UNIX jest jego system zarządzania pamięcią. Dane TCP mogą zostać pofragmentowane, wysłane i otrzymane poza ustalonym porządkiem, z pominięciem niektórych sekcji, powielone lub ponownie wysłane. Musi być możliwe powtórne złożenie tych danych do ich oryginalnej postaci i właśnie tutaj do pracy przystępuje system zarządzania pamięcią. Prostym jest tasowanie i łączenie pofragmentowanych danych. Jednakże, aby zarządzać efektywnie pofragmentowaną pamięcią i aby możliwym było zwolnienie niewykorzystywanej pamięci w tym samym czasie należy wykorzystać element alokacji pamięci kernela Unixowego. Działa on na zasadzie alokowania bloków pamięci w "strony", które są przypisywane określonym adresom pamięci. Ta cecha nie istnieje w systemie operacyjnym Amigi i musi być emulowana.

2.3 Próba ognia

Nad pierwszą wersją portu stosu TCP/IP pracowałem prawie dwa tygodnie. Polepszałem go pod względem prędkości i stabilności, lecz nadal występowały tajemnicze zawieszenia, których nie potrafiłem wyjaśnić. Zdarzało mu się jednak działać raczej stabilnie przez dłuższe okresy czasu, więc zdecydowałem się zabrać ten prototyp na coroczne spotkanie MeKa na uniwersytecie w Karlsruhe, które odbyło się na początku stycznia 2001 roku.

Przywiozłem ze sobą moją A3000UX i monitor A2024. Żadnej karty graficznej ani monitora VGA. Fakt, wykorzystania tylko tego co posiada w sobie Amiga (układy specjalizowane) okazał się bardzo pomocny. Gdy testowałem prototyp stosu TCP/IP zauważyłem dziwne wzorki tworzące się na ekranie. Coś niczym wędrujące mrówki. Badając problem, którego wcześniej nie widziałem pracując na Picasso IV, zauważyłem, że system zarządzania pamięcią, który napisałem był błędny i powodował zaśmiecanie pamięci chip. Zajęło mi trochę czasu naprawienie tego problemu, lecz wydarzyło się wtedy coś, co stało się momentem zwrotnym tego małego projektu: ogólna stabilność wzrosła znacząco, a efektywność dosłownie osiągnęła swój szczyt. Niecały tydzień później mój port stosu TCP/IP przebił zarówno "AmiTCP Genesis" jak i "MiamiDeluxe". Przeszedł bojowe testy w mojej lokalnej sieci. Nadszedł czas, aby poważnie pomyśleć o przemianie tego stosu w komercyjny produkt.

3. Mówiąc poważnie

3.1 Zestaw cech

MiamiDeluxe autorstwa Holgera Kruse ustanowiło standard funkcjonalności amigowego stosu TCP/IP. Stos TCP/IP musiał obsługiwać automatyczną konfigurację sieci przez DHCP (Dynamic Host Configuration Protocol), musiały istnieć sterowniki do połączenia dial-up (PPP) oraz do szerokopasmowego dostępu do internetu (PPPoE), firewall, filtr pakietów IP i obsługa NAT (Network Address Translation), obsługa lokalnych serwerów, zoptymalizowana implementacja protokołu SSL (Secure Socket Layer), a wszystko to musiało być osiągalne przez graficzny interfejs użytkownika.

To bardzo dużo i wydaje mi się, że tylko MiamiDeluxe posiadało obsługę wszystkiego w jednym pakiecie. Siła przychodzi jednak z ceną: MiamiDeluxe to szczelny zintegrowany program, rozmiaru rzędu 500 kB plus dodatkowe narzędzia i sterowniki.

Odkąd na mojej liście zadań do wykonania było kilka innych projektów, zdecydowałem się podejść do stosu TCP/IP w trochę mniejszym zakresie. Chciałem spróbować zapewnić obsługę tego co stanowi esencję amigowego stosu TCP/IP przy wykorzystaniu koncepcji modułowej. Chciałem również skoncentrować się na jądrze stosu i zostawić innym pracę nad projektowaniem graficznego interfejsu użytkownika. Od momentu gdy niektóre elementy zintegrowane w MiamiDeluxe stały się dostępne w osobnych pakietach (np. klient telnet/ssh, secure socket layer) napisanych przez tzw. third parties, postanowiłem, że nie będę ich sam pisał od nowa.

Cechy, które narodziły się podczas etapu planowania, są następujące:

  • kompatybilność z API "AmiTCP" 4.0
  • typowo amigowe narzędzia konfiguracji w odróżnieniu od trudnych w opanowaniu narzędzi Unixowych
  • stos TCP/IP powinien być raczej pojedynczą współdzieloną biblioteką
  • konfiguracja DHCP dla urządzeń ethernetowych; obsługa Zeroconf dla alokacji adresów
  • Obsługa sterowników ethernet i PPP
  • Pełna obsługa standardu SANA-IIR3, włącznie z dostępem DMA
  • Obsługa Berkeley Packet Filter
  • Filtr pakietu IP i obsługa (NAT)
  • obsługa urządzenia "TCP:"
  • Rozszerzone API umożliwiające programistom posiadanie większej kontroli nad stosem TCP/IP, włącznie z możliwością monitorowania i filtrowania pakietów
  • Integracja z systemem AmigaOS na etapie instalacji; pliki konfiguracyjne wędrują do DEVS:, nie wymagane jest przypisanie urządzenia "Roadshow:"
  • "Prosta" konfiguracja: jedna, prosta komenda shell powoduje uruchomienie sieci; nie wymagane skomplikowane narzędzia konfiguracyjne
  • Konfiguracja sterownika podobna do plików mountujących urządzenia występuje w Startup-Sequence.
  • Rozszerzony i ulepszony zestaw oprogramowania dla programistów, która zawiera pełen kod źródłowy wszystkich narzędzi konfiguracyjnych i przykładowych programów.
  • Zmiany w plikach konfiguracji globalnej są śledzone; uaktualnienia nastają zaraz po wykryciu zaistnienia modyfikacji
  • Obsługa lokalnych serwerów
  • Obsługa Multicast
  • Pełna lokalizacja wszystkich narzędzi i komunikatów błędów
  • Portowalność, umożliwiająca przebudowę na użytek pod PowerPC

Mniej więcej z takim zestawem cech rozpocząłem pracę i w obecnej wersji nie brakuje żadnej z nich. Jako programista wiedziałem, że zestaw oprogramowania dla programistów i kontrola jaką ci powinni mieć nad wewnętrzną zasadą działania stosu powinna być najważniejsza. Produkty amigowe były w przeszłości bardzo użyteczne, właśnie przez to, że umożliwiały programistom ich rozbudowę na podstawie funkcjonalności jaką oferowały, a także pozwalały tworzyć nowe aplikacje o jakich oryginalni projektanci nawet nie śnili. Dla przykładu, rozszerzone API umożliwia napisanie własnego firewalla (jeżeli nie chcemy korzystać z tego wbudowanego).

3.2 Połączenie dial-up

W miarę postępu prac nad stosem TCP/IP, który stawał się z dnia na dzień coraz bardziej użytecznym, zauważyłem, że było coś czego w nim brakowało. Modułowy stos TCP/IP nie zawierał wbudowanego sterownika dla połączeń przez protokół PPP. Wówczas istniały tylko trzy takie sterowniki dla Amigi: AmiPPP autorstwa Thomasa Bickela i dwie różne implementacje ppp.device autorstwa Holgera Kruse i Emmanuela Lesueur. Do żadnego z nich nie posiadałem praw na ich wykorzystanie.

Z całą pewnością alternatywą było napisanie od podstaw własnego sterownika PPP. Okazało się to dla mnie wielkim wyzwaniem, biorąc pod uwagę fakt, że wszyscy próbowali adaptować lub portować istniejący Australian National University PPP daemon. Kod rozwijany był pod Unixem a środowisko amigowe niekoniecznie jest do niego adekwatne.

Napisanie sterownika i przetestowanie go zajęło mi większość roku 2001. Gdy postanowiłem do mojego nowego mieszkania dociągnąć łącze ADSL, do projektu włączyłem również obsługę protokołu PPPoE, który jest usługą umożliwiającą zwijanie danych PPP do pakietów ethernetowych. Są również inne protokoły umożliwiające powyższe (np. PPPoA, PPTP i L2TP), ale trudno było mi je zaimplementować z powodu braku odpowiedniego sprzętu. Dużą przeszkodą było również skomplikowanie tych protokołów, w szczególności L2TP.

Podczas prac nad sterownikiem PPP zauważyłem, że specyfikacja SANA-II nie zbyt dobrze precyzowała obsługę sterownika do połączeń dial-up. Gdy opracowywano specyfikację ten standard nie był jeszcze tak ważny. Typowy dostęp do sieci zapewniany był przez ethernet lub ArcNet, przy pomocy stałej konfiguracji. Dynamiczne adresy konfiguracji dokonywane przez sterowniki dial-up (PPP lub SLIP) były poza obszarem zainteresowań oryginalnego projektu. Istniejące sterowniki stosowały różne dziwne sposoby na konfigurację parametrów, jak i na komunikowanie się z aplikacjami. Dla przykładu, powszechne w użyciu było przechowywanie parametrów w zmiennych środowiskowych, które były odczytywane przez plik skryptowy. Plik skryptowy wykorzystywał narzędzia konfiguracji stosu TCP/IP do przetłumaczenia zawartości tych zmiennych na parametry interfejsu sieciowego.

W tym momencie narodziła się czwarta edycja standardu SANA-II, który obsługują zarówno Roadshow jak i sterowniki PPP.

Z uwagi na to, w jaki sposób sterownik PPP ewoluował, stosunkowo prostym było zaimplementowanie obsługi protokołu PPPoE. Jako dodatek, implementacja stała o jeden poziom wyżej od obecnie istniejących projektów. Podczas gdy niektóre sterowniki musiały odebrać i przepakować czyste pakiety PPP w formę PPPoE, mój sterownik PPPoE generuje i przetwarza pakiety PPPoE w locie, bez potrzeby przeprowadzania dodatkowej konwersji.

Sterowniki PPP i PPPoE zostały zaprojektowane tak, aby współgrać z programem-wrapperem. Ten program wykonuje operacje połączenia i dokonuje konfiguracji sterownika, zespalając wszystko ze stosem TCP/IP.

Podstawową cechą zestawu sterowników PPP jest porównywalność z innymi dostępnymi rozwiązaniami. Dla przykładu obsługiwana jest kompresja nagłówków Van Jacobsona jak również uwierzytelnienie MS-CHAPv1. Kompresja danych nie jest jednak wykonywana z powodów prawnych i ogólnej dostępności tejże cechy. Podobnie jak stos TCP/IP, sterowniki są portowalne, aby można je było przebudować na potrzeby PowerPC.

3.3 Składając wszystko razem

Rdzeń pakietu składa się z następujących elementów:

  • dwie współdzielone biblioteki (bsdsocket.library i usergroup.library)
  • pliki konfiguracji dla potrzeb: routing, name resolution, usług internetowych i inetd-style superserver
  • narzędzia konfiguracyjne i administracyjne stosu TCP/IP
  • narzędzia konfiguracyjne i administracyjne filtru pakietów IP i NAT-u
  • dwa sterowniki PPP (ppp-serial.device i ppp-ethernet.device)
  • narzędzia do wykonywania połączeń i operacji uwierzytelniających niezbędnych to połączenia przy pomocy sterowników PPP

To są podstawowe funkcjonalności objęte licencją. Napisano jednak dla AmigaOS4 wiele innych apliacji, które w znacznym stopniu rozszerzają podstawowe możliwości dostępne w głównym pakiecie. Dołączono również edytor ustawień stosu TCP/IP obejmujący kilka przykładowych plików konfiguracyjnych. Wersja podstawowego pakietu dla AmigaOS4 została przepisana pod PowerPC z bibliotekami i sterownikami pracującymi natywnie pod tym procesorem.

3.4 Jak to działa?

Wyjątkowość Roadshow polega na tym, że próbuje wyłamać się z ustalonego tradycyjnego podejścia jakie zapewniało AmiTCP, polegającego na złożeniu całego stosu TCP/IP w jeden program, który konstruował centralną "bsdsocket.library" w pamięci. W rzeczywistości koniecznym było uruchomienie programu do możliwości pracy ze stosem TCP/IP. Stos był aktywny tak długo, jak długo działał program. W mojej implementacji zastosowałem sztuczkę wykorzystaną w AS225R2 i umieściłem wszystko w standardowych współdzielonych bibliotekach.

Jak wejść "na sieć"? Dla pakietów takich jak Miami jest to stosunkowo proste: wybierasz właściwy interfejs sieci i wciskasz odpowiedni przycisk, który łączy się z właściwymi komponentami sieci, których nazwy i ich szczególne informacje przechowywane są w pliku konfiguracyjnym. W tradycyjnym podejściu Unixowym, musisz wywołać zestaw komend z poziomu shella, które konfigurują interfejs sieci i mogą wywołać inne programy, które negocjują adresy IP i przeprowadzają operacje uwierzytelniające. Kolejny program zostaje uruchomiony i stabilizuje połączenie i wszystkie ścieżki. AmiTCP wykorzystuje takie właśnie podejście.

Roadshow to połączenie obu tych sposobów. Na początek trzeba poinformować stos TCP/IP o interfejsie sieci, a następnie możemy go ręcznie skonfigurować lub nakazać konfigurację automatyczną. Zasadniczo działa to podobnie do mountlist, które znajdują się w "DEVS:DOSDrivers" - zamiast plików konfigurujących systemy plików mamy pliki konfiguracyjne interfejsów sieci, których obecność wyłapywana jest w Startup-Sequence. Dla sterowników ethernetowych, interfejsy mogą być już skonfigurowane zaraz po ich zamountowaniu. Interfejs może wykorzystywać statyczne adresy lub może wykorzystać wbudowane DHCP, aby te adresy ustalić, znaleźć nazwę domeny serwera i ustabilizować połączenie (alternatywnie, lokalny adres IP może zostać przypisany przez protokół Zeroconf). Domyślne informacje na temat połączenia i nazwa domeny serwerów mogą być zmieniane w dwóch lokalnych plikach konfiguracyjnych (w przypadku gdy nie wybierzesz konfiguracji DHCP). Roadshow śledzi zmiany w tych plikach, tak więc możliwe jest przekonfigurowanie sieci w locie.

Wszystko to dzieje się w momencie gdy system się uruchamia. Jedna linia w Startup-Sequence sprawi, że Amiga będzie w sieci. Tak właśnie z tego korzystam w pracy i w domu. Włączam Amigę, czekam na moment gdy pojawia się Workbench i już jestem w sieci, bez potrzeby uruchamiania innego programu czy wciskania jakichś przycisków.

3.5 Firewall

Na potrzeby Roadshow zaadoptowałem pakiet "IP filter" autorstwa Darrena Reeda, który idealnie wpasował się w kod istniejącego stosu TCP/IP. Pakiet obsługuje zarówno podstawowe zasady filtrowania, maskaradę jak i tłumaczenie adresów sieciowych. Konfiguracja jest trochę skomplikowana, ale wszystko działa jak należy. Można wykorzystać Amigę jako firewall lub pozwolić jej na dzielenie połączenia PPP z innym komputerem w tej samej sieci. W rzeczywistości tak właśnie robiłem w domu, do czasu gdy nie założono u mnie połączenia ADSL.

Roadshow posiada wbudowaną funkcjonalność umożliwiającą pisanie kodu, który będzie dokonywał filtrowania i przepisywał pakiety IP. Aby stworzyć własnego firewalla można wykorzystać te same punkty wejścia jak te we wbudowanych filtrze IP. Obsługiwane są również hooki odpowiedzialne za monitorowanie aplikacji, które próbują ustabilizować połączenia zewnętrzne. Monitorowane są również połączenia wewnętrzne.

4. Przyszłość

Roadshow to moja pierwsza próba przeportowania stosu TCP/IP i napisania sterowników PPP. Było to bardzo cenne doświadczenie, które zrodziło coś pożytecznego: rozwiązanie na bazie którego można tworzyć aplikacje. Z całą pewnością stanowi kontrast do zintegrowanych pakietów stosu TCP/IP takich jak Miami, które są popularne do dzisiaj.

Mówiąc prawdę, podczas gdy sterowniki PPP, obsługa DHCP i protokołu Zeroconf były pisane od początku, stos TCP/IP nie był. Pracę rozpocząłem na kodzie kernela BSD UNIX, który jest stosunkowo nowy w porównaniu do tego na bazie którego powstało AmiTCP. Jest jednak starszy od tego wykorzystywanego w nowoczesnych systemach operacyjnych BSD UNIX takich jak OpenBSD, NetBSD czy FreeBSD. Oznacza to na przykład, że IPv6 nie jest obsługiwane.

Brak obsługi IPv6 to jedna z wad, którą mam nadzieję szybko usunąć przez przeportowanie bardziej nowoczesnego stosu TCP/IP. OpenBSD zdaje się być bardzo trafnym wyborem. Biorąc jednak pod uwagę, że zajęło mi prawie dwa lata przeportowanie kernela 4.4BSD-Lite2, nie mogę wiele obiecać, że pracę rozpoczną się niebawem.

W międzyczasie mam nadzieję, że Roadshow spełni wasze oczekiwania. Dużo ciężkiej pracy zostało w niego włożone.

P.S.: Skąd wzięła się dziwna nazwa "Roadshow"? Bezpośrednio z książki "This is Orson Welles", gdzie Welles stale powtarza, że "he would enjoy going on a roadshow again."



Tłumaczenie na podstawie Club Amiga Monthly - Sebastian Rosa.

Translated and reproduced by kind permission of Amiga Inc. Not for distribution beyond this site.

Przetłumaczone i opracowane za zgodą Amiga.Inc. Dystrybucja wyłącznie na stronach PPA.

Club Amiga logo concept and artwork by Mark Rickan & Mohamed Moujami, winners of the Club Amiga Logo Contest.
Submitted text and images reproduced in Club Amiga Monthly are copyright by their respective authors.
All other text and images reproduced in Club Amiga Monthly are copyright 2003 Amiga Inc.
Content may not be reprinted or reproduced in part or in whole without express written consent of Amiga Inc.

 głosów: 2   
dodaj komentarz
Na stronie www.PPA.pl, podobnie jak na wielu innych stronach internetowych, wykorzystywane są tzw. cookies (ciasteczka). Służą ona m.in. do tego, aby zalogować się na swoje konto, czy brać udział w ankietach. Ze względu na nowe regulacje prawne jesteśmy zobowiązani do poinformowania Cię o tym w wyraźniejszy niż dotychczas sposób. Dalsze korzystanie z naszej strony bez zmiany ustawień przeglądarki internetowej będzie oznaczać, że zgadzasz się na ich wykorzystywanie.
OK, rozumiem