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 zadaptować 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."
Autor: Olaf Barthel
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.