Główne założenia projektowe

Zakładamy, że głównym zastosowaniem aplikacji PROTONET jest wizualizacja działania protokołów sieciowych rodziny TCP/IP w celach edukacyjnych. Główne zadania postawione przed naszą aplikacją to:

• dostarczenie wygodnego mechanizmu do budowy topologii i konfiguracji sieci,
• ukazanie mechanizmów działania zaimplementowanych protokołów,
• ukazanie związków przyczynowo-skutkowych zdarzeń zachodzących w systemie w trakcie komunikacji sieciowej,
• pokazanie struktury i zawartości krążących w sieci pakietów,
• zbieranie i udostępnianie statystyk dotyczących symulacji,
• informowanie o działaniu algorytmów zaimplementowanych w oprogramowaniu protokołów i na poziomie sieci fizycznej,
• rejestrowanie wydarzeń interesujących użytkownika, w formie pozwalającej na późniejszą analizę.

Znając cele, które chcemy osiągnąć ustaliliśmy pewne założenia i ograniczenia.

Ograniczenie architektury sieci

W naszej aplikacji ograniczamy się do sieci fizycznej typu Ethernet -- jest to najbardziej dostępna a przez to najpopularniejsza w tej chwili architektura sieciowa. Implementujemy typowe dla tej sieci cechy:

• bezpołączeniowy tryb pracy,
• niepewność dostarczenia pakietów,
• konieczność wykrywania i reagowania na kolizje w czasie transmisji.

Ponadto, zakładamy, że:

• stworzony przez nas symulator nie będzie służył do badania fizycznych parametrów zaprojektowanych topologii sieciowych (przepustowości, obciążeń poszczególnych elementów, wyszukiwaniu wąskich gardeł, itp.),
• będzie go można łatwo rozbudowywać poprzez implementację kolejnych protokołów oraz bazujących na nich aplikacji.

Idealizacja sieci

Za zaniedbywalne uważamy parametry fizyczne kabla typu długość, tłumienność itp. Nie uwzględniamy np. konieczności stosowania wzmacniaka (ang. repeater) w momencie przekroczenia pewnej granicznej długości kabla. Pozwalamy sobie na to, gdyż wzmacniak, jako urządzenie zupełnie pasywne nie wnosi nic znaczącego (z punktu widzenia przeznaczenia naszej aplikacji) do logiki zachowania sieci. Zdecydowaliśmy się jednak zaimplementować fizyczną niedoskonałość sieci -- dla kabla można zdefiniować parametry określające w promilach prawdopodobieństwo zagubienia i przekłamania pakietu. Właściwości te mogą być użyteczne w celu pokazania reakcji protokołów transportowych zapewniających niezawodność dostarczania, na wystąpienie powyższych błędów transmisji danych.

Pewien stopień idealizacji czasu w systemie

Zdarzenia zachodzące w systemie są umiejscowione w czasie. Jako jednostkę czasu przyjmujemy umownie jedną milisekundę. W momencie startu symulacji czas w systemie jest ustawiany na zero i iteracyjnie jest przestawiany do najbliższego momentu, w którym ma się wydarzyć najbliższe zdarzenie. Czasy przetwarzania na poszczególnych elementach systemu sieciowego są w pewnym stopniu idealizowane:

• czas przetwarzania ramki ethernetowej przez kabel sieciowy jest określany przez użytkownika i nie zależy od wielkości ramki,
• czas przetwarzania ramki ethernetowej przez interfejs sieciowy, podobnie jak poprzedni czas, jest określany przez użytkownika i nie zależy od ilości danych w ramce,
• czasy przetwarzania pozostałych elementów (protokołów, aplikacji) jako nieistotny ustala się na zero.

Rozróżnienie ruterów i komputerów

W systemie PROTONET rutery i komputery stanowią oddzielne klasy obiektów. W momencie dodawania maszyny do projektu decydujemy czy ma ona być ruterem, czy komputerem. Przyjęto założenie, że komputer może być podłączony do sieci tylko jednym interfejsem sieciowym, zaś ruter takich podłączeń może mieć maksymalnie osiem.

Model implementacji protokołów

Naszą implementację protokołów, postanowiliśmy w pewnym stopniu oprzeć na jednej z istniejących, dobrze opisanych implementacji. Jako modelową implementację wybraliśmy realizację zaprezentowaną w książce [Comer 1997]. Implementacja ta jest częścią systemu operacyjnego Xinu^3.1. Argumenty uzasadniające ten wybór przytoczymy za autorem:

• kod programu jest dobrze udokumentowany, omówiony w kilku książkach;
• w programie nie zaimplementowano mechanizmów naliczania kosztów ani innych podobnych mechanizmów administracyjnych, dzięki czemu kod jest wolny od zbędnych szczegółów, a zatem łatwiejszy do zrozumienia;
• oprogramowanie to jest dostępne powszechnie i bezpłatnie, nie przysparza problemów licencyjnych;
• oprogramowanie Xinu powstało w ramach projektu badawczego i w niektórych przypadkach zawiera rozwiązania bardziej funkcjonalne niż zastosowane w odpowiednikach komercyjnych.

Model aplikacji

Aby zrealizować powyższy postulat zdecydowaliśmy się na warstwową implementację aplikacji. Naturalną platformą ułatwiającą implementację powyższego założenia jest język obiektowy. Wybieraliśmy pomiędzy C++ oraz Javą, ostatecznie zdecydowaliśmy się na C++. Rozróżniliśmy siedem warstw projektowych. Dokładne omówienie realizacji warstwowości aplikacji PROTONET znajduje się w następnym rozdziale opisującym implementację.