Spis rzeczy Dalej: Rozszerzenie funkcjonalności programu Wstecz: Wstęp

Rozdział 3

Opis programu

3.1 Przyjęty model symulacji
3.1.1 Model warstwy łącza
3.1.2 Model ARP
3.1.3 Model IP
3.1.4 Model ICMP
3.2 Implementacja
3.2.1 Konstrukcja programu
3.2.2 Symulacja
3.2.3 Interfejs użytkownika
3.3 Otoczenie dydaktyczne

Niniejszy rozdział opisuje model symulowanej sieci, funkcje realizowane przez program oraz środowisko dydaktyczne z zestawem zadań, w którym jest on wykorzystywany. Najważniejszym celem programu jest umożliwienie przyszłemu użytkownikowi samodzielnej konfiguracji parametrów sztucznej intersieci oraz sprawdzenia, czy wprowadzone ustawienia są prawidłowe. Dlatego największy nacisk położono na symulowanie tych mechanizmów zestawu protokołów TCP/IP, na które człowiek ma bezpośredni wpływ.

Z praktyki autora wynika, że parametrami, które każdy administrator sieci musi umieć prawidłowo ustalać, są adres i maska IP oraz tablica tras. Są to parametry IP odpowiadające za poprawne przekazywanie pakietów i wzajemną osiągalność węzłów sieci. Pozostałe protokoły (TCP, UDP, ICMP, ARP), tworzące zrąb TCP/IP są bezobsługowe i nie wymagają zazwyczaj ingerencji człowieka. Postanowiono więc implementować tylko te z nich, które są niezbędne do prawidłowego działania IP. Z tego względu zaimplementowano ICMP, który jest blisko związany z IP, tym bardziej, że umożliwia on implementację testu ping. Innym protokołem, całkowicie bezobsługowym, który został włączony do symulacji, jest ARP. Decyzję taką podjęto, gdyż ARP jest niezbędny do działania IP w sieciach lokalnych będących obecnie najpopularniejszą technologią sieci komputerowych. Aby ułatwić konfigurację i diagnostykę sieci, program umożliwia śledzenie działania elementów sieci oraz przepływu pakietu, a także tworzenie zestawień: tabel adresów IP, tras i powiązań adresów (ARP). Pominięto całkowicie urządzenia pracujące w warstwie łącza. Symulowanie ich działania, a w konsekwencji umieszczenie ich na mapie, spowodowałoby znaczną jej komplikację. Dlatego program modeluje działanie protokołów łącza w możliwie prosty sposób.

Podczas projektowania starano się, by program był intuicyjny i łatwy w obsłudze. Dlatego zdecydowano się na realizację graficznego interfejsu użytkownika wraz z mapą przedstawiającą topologię sieci. Umożliwia ona wybranie elementu sieci i skonfigurowanie go, a także animuje przepływ pakietów. Obsługa interfejsu jest realizowana przez standardowe mechanizmy Javy w wersji 1.0.2. Posiadają one pewne ograniczenia, szerzej omówione wewnątrz rozdziału. Wybranie języka Java do implementacji programu było, mimo pewnych problemów z interfejsem graficznym, właściwym krokiem. Dzięki temu program nie jest dedykowany do konkretnej platformy sprzętowej. Zaletami Javy ułatwiającymi implementację były obiektowy charakter języka oraz wbudowane mechanizmy zarządzania i synchronizacji wątków. Należy pamiętać, że do pracy z programem potrzebna jest przeglądarka obsługująca wirtualną maszynę Javy. Wymaganie to spełnia MS Internet Explorer lub Netscape Navigator w wersji 3.0 lub późniejszej oraz Sun HotJava.

Aby zapewnić użytkownikowi możliwość samokształcenia, stworzono scenariusz pięciu ćwiczeń -- dokumentów HTML -- wprowadzający czytelnika w kolejne zagadnienia związane z symulowanymi mechanizmami IP. Ćwiczenie składa się z zadania praktycznego oraz informacji teoretycznych niezbędnych do jego wykonania. Zadanie polega na skonfigurowaniu sieci symulowanej przez wbudowany w stronę aplet. Kolejne zadania są coraz trudniejsze i posiadają coraz bardziej rozbudowane mapy sieci, zaś ostatnie jest rodzajem egzaminu - student musi wykryć kilka błędów w konfiguracji sieci i je naprawić.

Spis rzeczy  Początek rozdziału

3.1 Przyjęty model symulacji

Każda symulacja opiera się na określonym modelu upraszczającym rzeczywisty świat. Uwzględnia on jedynie ważne dla danego zastosowania aspekty rzeczywistości, pozostałe zaś pomija, by zredukować stopień skomplikowania zadania. Opisywany program również opiera się na modelu upraszczającym rzeczywiste działanie sieci komputerowej. Jak wspomniano powyżej, pominięto przede wszystkim te cechy, na które administrator nie ma większego wpływu, i które nie są kluczowe dla zapewnienia osiągalności, choć są ważne dla funkcjonowania realnej sieci -- na przykład fragmentację, czy sposób przydziału prawa do nadawania we współdzielonym medium sieci ethernet. Poniżej omówiono dokładnie implementowany przez program model sieci.

Spis rzeczy  Początek rozdziału

3.1.1 Model warstwy łącza

Program modeluje dwa rodzaje sieci w warstwie łącza danych: linie szeregowe i ethernet. Taka dualność mechanizmów warstwy łącza podkreśla elastyczność IP i zaznajamia użytkownika z rzeczywistą strukturą intersieci. Z linii szeregowych tworzone są sieci rozległe, umożliwiające łączenie oddalonych od siebie sieci lokalnych, wśród których ethernet jest najbardziej popularną technologią. Za wyborem ethernetu przemawiał także fakt, że jego działanie jest łatwiejsze do wizualizacji niż sieci pierścieniowych, takich jak FDDI czy Token Ring posługujących się znacznikiem.

W modelu linii szeregowych przyjęto następujące uproszczenia:

Oczywiście model ethernetu także zawiera pewne uproszczenia: Oprócz wymienionych powyżej, oba modele sieci warstwy łącza posiadają jeszcze następujące cechy: Spis rzeczy  Początek rozdziału

3.1.2 Model ARP

Program realizuje tłumaczenie adresów IP na adresy MAC za pomocą modelu protokołu ARP. Jedynym wprowadzonym uproszczeniem w stosunku do rzeczywistego protokołu była rezygnacja z pól określających długość i typ adresu w strukturze pakietu, a przez to zawężenie protokołu do tłumaczenia jedynie symulowanych typów adresów: IP i MAC. Z punktu widzenia symulacji IP uniwersalność ARP jest całkowicie zbędna, gdyż nie obsługuje ona innych protokołów warstwy łącza i sieci. Program realizuje następujące funkcje ARP wymagane przez RFC 1122: Spis rzeczy  Początek rozdziału

3.1.3 Model IP

Model symuluje IP w wersji 4 z następującymi ograniczeniami: Warto zauważyć, że oprogramowanie każdego węzła jest identyczne. Nie ma zatem potrzeby obsługi błędnych, lub zawierających dodatkowe opcje pakietów, gdyż symulator nie potrafi ich generować. Z tego względu nie odnosi się do niego zdecydowana większość pozycji z długiej listy wymagań RFC 1122 dla warstwy intersieci. Te, które model spełnia to: Spis rzeczy  Początek rozdziału

3.1.4 Model ICMP

Protokół ICMP został ograniczony do następujących typów komunikatów: Zaniechano implementacji - ze względu na rzadkie zastosowanie - pozostałych typów komunikatów, nie są one zresztą obligatoryjne.

Zgodnie z RFC1122 nie jest wysyłany pakiet ICMP w przypadku błędu spowodowanego przez komunikat ICMP o błędzie lub datagram rozgłoszeniowy. Węzły zawsze odpowiadają na komunikat echo. Komunikat przekierowanie wysyłają tylko rutery, a węzeł do którego został wysłany wprowadza odpowiednie zmiany do swojej tablicy tras.

Spis rzeczy  Początek rozdziału

3.2 Implementacja

Projektowanie i wstępne prace nad programem rozpoczęły się latem 1997 roku. Autor początkowo zamierzał nieco inaczej zaprojektować interfejs użytkownika, w szczególności wywoływanie akcji. W założeniu mapa miała być integralną częścią strony WWW, zaś akcje na obiektach mapy miały być wykonywane za pomocą rozwijanego (ang. pop-up) menu pojawiającego się po naciśnięciu klawisza myszy na wybranym obiekcie. Zawartość menu byłaby uzależniona od rodzaju obiektu.

Niestety, rok temu w powszechnym użyciu był JDK (Java Development Kit) w wersji 1.0.2, który nie obsługiwał rozwijanego menu. Autor musiał więc zmienić koncepcję interfejsu użytkownika i zrealizował technikę ,,zaznacz i wykonaj'': najpierw zaznacza się obiekt na mapie, a następnie wybiera dla niego polecenia z menu. W tym celu został zaprojektowany uniwersalny pasek menu, którego pozycje uaktywniają się w zależności od właściwości zaznaczonego obiektu. Konsekwencją stosowania menu w formie paska było stworzenie oddzielnego okna, gdyż w środowisku JDK 1.0.2 jedynie obiekty klasy Frame, czyli samodzielne okna mogą posiadać menu. Aplet widoczny jest więc na stronie HTML jako przycisk, naciśnięcie którego powoduje otworzenie głównego okna symulatora.

Autor nie zdecydował sie na zmianę podejścia po udostępnieniu przez Sun JDK 1.1.3 z powodu wprowadzonych w tej wersji licznych zmian w bibliotekach obsługujących interfejs użytkownika. Poza tym realizacja symulatora w wersji 1.0.2 pozwala uruchamiać program za pomocą starszych przeglądarek.

Napisanie symulacji protokołu IP w języku obiektowym pozwoliło na uproszczenie konstrukcji programu w porównaniu z kodem obsługującym rzeczywisty protokół. Oto przykłady:

Spis rzeczy  Początek rozdziału

3.2.1 Konstrukcja programu

Program składa się z 48 klas zgrupowanych w pakiet o nazwie ips oraz dodatkowej klasy definiującej wygląd mapy. Pakiet ips jest uniwersalny -- pozwala na skonfigurowanie topologii symulowanej sieci przez użytkownika za pomocą stworzonych w tym celu metod. Sposób konstrukcji własnej mapy jest opisany w rozdz. 4.1.

Klasy należące do pakietu ips definiują następujące rodzaje obiektów:

Szkieletem, który integruje ze sobą całość programu jest obiekt klasy Framework, dziedziczący po klasie java.applet.Applet. To on tworzy okno symulacji, mapę i elementy sieci, uruchamia wątki oraz realizuje funkcje demona zegarowego. W jego klasie są też zdefiniowane metody służące do konstrukcji mapy.

Program jest napisany wielowątkowo. Poszczególne wątki realizują następujące zadania:

Należy jeszcze wspomnieć o zdarzeniach generowanych przez użytkownika, obsługiwanych przez oddzielny wątek. Dostęp do wspólnych struktur danych (tablice tras, ARP, kolejki pakietów) jest synchronizowany za pomocą wbudowanych mechanizmów maszyny wirtualnej Javy. Klasy RoutingTable, PacketBuffer, EthernetPort pełnią funkcję monitorów chroniących swoje zasoby za pomocą synchronizowanych metod.

Spis rzeczy  Początek rozdziału

3.2.2 Symulacja

Istnieją trzy podstawowe rodzaje elementów, z których złożona jest sieć: Podczas projektowania przyjęto rozwiązanie naśladujące rzeczywisty świat: każdy węzeł jest niezależnym wątkiem mogącym generować, przesyłać i odbierać pakiety. Z uwagi na potrzebę wizualizacji przepływu pakietów przez sieć, konieczne było również stworzenie wątków sterujących poruszaniem się pakietów po poszczególnych łączach. Wątki działają więc w kontekście każdego węzła i każdej sieci. Oba rodzaje obiektów posiadają kolejkę wejściową. Pobierają z niej kolejno pakiety, wykonują pewne czynności (węzeł znajduje drogę w tablicy tras, sieć steruje przebiegiem animacji) i przesyłają pakiet do określonego portu. Za jego pośrednictwem pakiet jest wstawiany do kolejki wejściowej innego wątku. Kolejki są realizowane jako bufory cykliczne (klasa PacketBuffer). Wykorzystują one mechanizmy synchronizacji procesów dostarczane przez Javę. W przypadku przepełnienia bufora jest generowany wyjątek klasy NoSpaceException, którego obsługa polega na zignorowaniu danego pakietu. Układ pracuje w schemacie producent-konsument z wieloma producentami i jednym konsumentem. Przekazywanie pakietów w programie zostało przedstawione na rys. 3.1. Odcień szarości strzałek zależy on od wątku, który steruje danym przepływem (przepływy inicjowane przez węzeł są jasno szare, sieć -- ciemno szare, a przez demona zegarowego -- czarne).
Rysunek 3.1: Przepływ pakietów między wątkami programu

Z uwagi na to, że działanie sieci szeregowych i rozgłoszeniowych znacznie się różni, konieczne stało się rozdzielenie portów i sieci na dwa rodzaje: linie szeregowe (klasa SerialLine) posiadają dowiązania do dwu portów -- końców łącza. Po pobraniu pakietu z kolejki sprawdzają z którego portu został wysłany, by określić kierunek przepływu na mapie. Po zakończeniu ,,przesyłania'' czyli obsługi wizualizacji przekazują pakiet do drugiego portu. Inaczej działają sieci rozgłoszeniowe (klasa EtherNet). Z założenia można do nich dołączyć wiele interfejsów. Po pobraniu pakietu z kolejki jest identyfikowany jego nadawca, aby określić, z którego punktu na szynie ma się ,,rozchodzić'' pakiet. Gdy pakiet już ,,zniknie'' z sieci, każdy port, włącznie z nadawcą, otrzymuje jego duplikat.

Podobnie interfejsy -- dołączone do linii szeregowych (klasa SerialPort) mają bardzo prostą konstrukcję. Jedynym ich zadaniem jest wstawienie pakietu do odpowiedniej kolejki i w razie potrzeby wstawienie własnego adresu w pole nadawcy. Zupełnie inaczej jest z portami klasy EthernetPort. Obsługują one protokół ARP. Poza tą klasą żaden obiekt nie ma bezpośredniego dostępu do struktur danych związanych z tłumaczeniem adresów. W większości implementacji tablica ARP jest wspólna dla wszystkich portów systemu, a każdy jej wiersz posiada kolumnę wskazującą, którego portu dotyczy [#!COMER2!#]. Ze względu na obiektowy język autor przyjął inne rozwiązanie: każdy port ethernetowy posiada własną tablicę bez wspomnianej kolumny. Dzięki temu można było ograniczyć dostęp do tablicy i zmniejszyć liczbę wątków sięgającą do danej instancji. Ostatnim rodzajem interfejsu jest port lokalny (klasa LocalPort) mający za zadanie obsługę pakietów zaadresowanych do węzła, z którym jest związany.

Działanie wątku węzła nie zależy od rodzaju posiadanych portów i podłączonych do nich sieci. Obsługuje on bowiem tylko pakiety IP i ICMP. Każdy węzeł po pobraniu pakietu z kolejki analizuje jego zawartość, szuka odpowiedniej pozycji w tablicy tras i przesyła pakiet zgodnie ze znalezioną drogą do jednego ze swoich portów.

Wszystkie omawiane klasy mają jedną nadklasę NetEntity, która realizuje zadania wspólne dla wszystkich elementów sieci: komunikację z interfejsem użytkownika, a dokładniej -- obsługę tworzenia raportów i zgłaszania komunikatów.

Spis rzeczy  Początek rozdziału

3.2.3 Interfejs użytkownika

Interfejs użytkownika to przede wszystkim okno główne (klasa MainWindow) zawierające mapę -- graficzną reprezentację topologii sieci, menu ze wszystkimi dostępnymi użytkownikowi funkcjami programu oraz pasek przy swojej dolnej krawędzi, na którym ukazuje się opis aktywnego w danej chwili elementu mapy. Metody głównego okna determinują reakcję na wybranie przez użytkownika pozycji z menu.

Menu

Menu jest podzielone na następujące sekcje: Pozycje w sekcjach Edycja, Widok i Akcje są uaktywniane w zależności od rodzaju aktywnego obiektu. Jeśli zaznaczony jest węzeł sieci, to można dodać pozycję do jego tablicy tras, otworzyć bądź zamknąć okno podglądu (pozycja Podgląd), obejrzeć tablicę tras i adresy wszystkich portów oraz wysłać pakiet ICMP echo pod wskazany adres. Jeśli zaznaczony został port, to można nadać lub zmienić jego adres IP, otworzyć bądź zamknąć okno podglądu, a także, jeśli jest to port dołączony do ethernetu, obejrzeć jego tablicę ARP. W przypadku zaznaczenia sieci jest również dostępna pozycja okna śledzenia, a także można -- co jest dużym ułatwieniem przy diagnozowaniu problemów -- obejrzeć wszystkie adresy portów dołączonych do sieci zestawione w jednej tabeli.

Spis rzeczy  Początek rozdziału

Mapa

Mapa jest najbardziej skomplikowanym elementem interfejsu graficznego. Pokazuje ona topologię symulowanej sieci, przedstawia poruszające się po sieci pakiety, a przede wszystkim umożliwia wybór elementów symulacji przez użytkownika. Mapa odzwierciedla symulowane obiekty i ich powiązania. Z uwagi na specyficzny charakter stworzono hierarchię obiektów -- elementów mapy. Są to: Ostatnia klasa ma wiele podklas z uwagi na skomplikowanie i duże różnice w realizacji wizualizacji przepływu pakietów.

Elementy mapy mogą być w jednym z następujących stanów:

wolny
-- element jest płaski i szary,
aktywny
-- element jest wypukły, jego opis pojawia się pod mapą,
aktywny i wybrany
-- element zmienia kolor na czerwony,
wybrany
-- element pozostaje czerwony, lecz staje się płaski.
Bycie aktywnym jest związane z położeniem wskaźnika względem elementu i symbolizowane ,,wypukłością'' elementu, który sygnalizuje w ten sposób, że jest samodzielną częścią mapy i może być wykonana na nim pewna akcja. Bycie wybranym związane jest ze zdarzeniem zwolnienia klawisza myszy w obrębie elementu podczas gdy jest aktywny i symbolizowane zmianą barwy. W tym stanie może być wybrana dla elementu akcja z menu. Jeśli żaden inny element nie jest w danej chwili aktywny, to pod mapą znajduje się opis elementu wybranego. Diagram zmiany stanów jest pokazany na rys. 3.2. Umieszczono na nim tylko te zdarzenia, które są istotne dla zmiany stanu elementu (naciśnięcie klawisza myszy nie zmienia go).
Rysunek 3.2: Diagram zmiany stanów elementów mapy

Realizacja animacji wymaga cyklicznego odrysowywania mapy. Należy zauważyć, że w danej chwili może przepływać przez symulowana intersieć wiele pakietów, a przepływ każdego z nich będzie kontrolowany przez inny wątek sieci. W związku z tym zdecydowano się na rozdzielenie funkcji animacji (a dokładniej modyfikacji położenia pakietów) od rysowania. Zadanie odświeżania mapy powierzono wątkowi działającemu w kontekście obiektu klasy Map, który posiada dowiązania do wszystkich elementów mapy. Wątek bada co kilkadziesiąt milisekund, czy zmienił się chociaż jeden element mapy. Jeśli tak -- to odrysowuje poprzez bufor nowy obraz i wyświetla go na ekranie.

Spis rzeczy  Początek rozdziału

Okna dialogowe

Konfiguracja symulacji odbywa się za pomocą okien dialogowych. Każdy dialog jest zdefiniowany w osobnej klasie: Klasy weryfikują poprawność parametrów wprowadzonych przez użytkownika oraz wywołują odpowiednią metodę wybranego obiektu symulacji. Oprócz wymienionych dialogów istnieją jeszcze dwa rodzaje okien służące do prezentacji konfiguracji i działania symulowanej sieci. Ukazują się one po wybraniu jednej z pozycji menu Widok.

Okna podglądu powstały by możliwić śledzenie zdarzeń generowanych przez obiekty symulacji. Zbieranie komunikatów realizują obiekty klasy Audit. Każdy obiekt dziedziczący po klasie NetEntity przesyła komunikaty własnemu obiektowi śledzącemu. Komunikaty są wypisywane do okna dialogowego zdefiniowanego w klasie AuditWindow. Posiada ono przycisk Wstrzymaj pozwalający zatrzymać wypisywanie komunikatów na ekran. Dzięki temu można je przeanalizować w sytuacji, gdy program szybko generuje dużą ich ilość. Klasy służące do wypisywania zdarzeń wykorzystywane są także do obsługi komunikatów testu ping.

Program umożliwia obejrzenie następujących raportów:

Zaprojektowano osobną klasę obiektów Report służących do reprezentacji raportów i zawierającą dwuwymiarową tablicę napisów oraz klasę DialogReport obsługującą okienko dialogowe. Aby umożliwić odświeżanie wyświetlanych raportów przyjęto, że obiekt klasy DialogReport przechowuje dowiązanie do obiektu NetEntity, którego raport dotyczy, ten zaś posiada uniwersalną metodę getReport() do tworzenia raportów określonego typu.

Podsystem pomocy

Wiadomości o funkcjach programu można uzyskać za pomocą podsystemu pomocy. Ma on charakter kontekstowy: każde okno dialogowe jest zaopatrzone w przycisk Help umożliwiający uzyskanie informacji dotyczących pól okna. Po naciśnięciu przycisku pojawia się nowe okno przeglądarki WWW z odpowiednią sekcją strony HTML. Wszystkie informacje podsystemu pomocy są bowiem umieszczone w jednym dokumencie o domyślnej nazwie help.html.

Spis rzeczy  Początek rozdziału

3.3 Otoczenie dydaktyczne

Jednym z celów niniejszej pracy było stworzenie studentom warunków do samodzielnej nauki zasad działania sieci IP. W tym celu został przygotowany program szkolenia składający się z pięciu części -- dokumentów napisanych w HTML. Każdy z nich zawiera program (aplet Javy) z określoną topologią i konfiguracją sieci, opis zadania do przeprowadzenia z programem oraz podstawowe informacje niezbędne do wykonania zadania.

Część 1 -- zapoznanie z programem

Program pierwszej części ma na celu nauczenie użytkownika korzystania z programu. Wszystkie węzły wchodzące w skład sieci są poprawnie skonfigurowane, a zadaniem studenta jest: Mapa sieci dołączona do tej części pokazuje dwie sieci lokalne połączone ruterem.

Część 2 -- podstawy IP, ICMP i ARP

Druga część scenariusza zawiera podstawowe informacje na temat protokołów IP, ICMP i ARP. W tej części student: Mapa w tej części pokazuje pojedynczą sieć lokalną. Student musi wybrać zestaw zawierający poprawne adresy IP, przypisać je węzłom i sprawdzić pingiem osiągalność. Jednocześnie sprawdzane jest działanie protokołu ARP i zawartość jego tablic.

Część 3 -- konfiguracja tablicy tras

Trzecia część jest poświęcona jest problematyce trasowania. Omawia się rolę i budowę tablicy tras. Poruszone są przyczyny powstawania komunikatów ICMP odbiorca nieosiągalny, przekroczony czas i przekierowanie oraz ich skutki. Mapa zadania przedstawia typową sieć komputerową organizacji posiadającej odległe oddziały. Węzły sieci mają nadane adresy, a zadaniem studenta jest konfiguracja ich tablic tras oraz wykonanie testów ping w różnych relacjach. Testy pozwalają sprawdzić poprawność dokonanych ustawień oraz zobrazować pewne sytuacje typowe dla działania IP.

Część 4 -- podsieci IP

Część czwarta omawia dzielenie przestrzeni adresowej na podsieci. Przedstawione są zasady stosowania masek adresowych. Zadanie wymaga przydziału adresów należących do jednej sieci klasy C węzłom należącym do sześciu różnej wielkości sieci lokalnych. Ponieważ intersieć tworzy pętlę, więc dodatkowo należy tak skonfigurować tablice tras ruterów, by pakiety podążały zawsze najkrótszą drogą.

Część 5 -- sprawdzian

Ostatnia, piąta część jest pewnego rodzaju egzaminem sprawdzającym nabytą wiedzę. Sprawdzian wymaga znalezienia błędów w konfiguracji pewnej sieci, a także zaprojektowania dla niej własnej adresacji i trasowania.

Zagadnienia omówione w poszczególnych częściach nie wyczerpują oczywiście całości problematyki związanej z sieciami IP. Zawierają jedynie podstawowe informacje, niebędne do pracy z symulatora i pomocne w zrozumieniu działania IP.

Spis rzeczy   Wstecz: Początek rozdziału Dalej: Rozszerzenie funkcjonalności programu