Główne mechanizmy aplikacji PROTONET

Aplikacja ma strukturę warstwową. Warstwy, które wyróżniliśmy w trakcie projektu to:

• warstwa zarządzania projektem,
• warstwa graficzna projektu sieci,
• warstwa fizyczno-logiczna,
• warstwy protokołów,
• warstwa aplikacji,
• warstwa zarządzania symulacją,
• warstwa prezentacji wyników symulacji.

Poniżej omawiamy wszystkie warstwy i podajemy informacje o implementacji.

Warstwa zarządzania projektem

W tej warstwie zaimplementowano globalne operacje na projekcie: zapis projektu do pliku, wczytanie projektu z pliku, tryby pracy nad projektem. Zdefiniowane jest tutaj także główne okno projektu wraz z przyciskami, menu, paskiem stanu, obszarem roboczym oraz panelem właściwości. Trzymane są tutaj również listy obiektów logicznych. Wszystkie operacje wykonywane na obiektach logicznych i graficznych wykonywane są w sposób pośredni, tzn. zaznaczenie obiektu w obszarze roboczym i wywołanie jakiegoś polecenia powoduje sprawdzenie wszystkich obiektów i ustalenie tego, którego położenie pokrywa się ze współrzędnymi zaznaczenia. Następnie wywoływana jest odpowiednia metoda obsługująca daną operację, zadeklarowana we wspólnej dla wszystkich nadklasie (L_Element -- dla elementów logicznych, G_Element -- dla elementów graficznych). Poprzez mechanizm dziedziczenia, w zależności od typu obiektu, realizowana jest właściwa obsługa polecenia.

Na przykład przy zapisie lub odczycie z pliku na rzecz każdego z elementów wywołuje się odpowiednią metodę zapisującą lub odczytującą wartości jego atrybutów z pliku.

Warstwa graficzna projektu sieci

Ta warstwa zawiera implementację elementów graficznych wchodzących w skład projektu topologii sieciowej. Każdy z obiektów posiada nadpisane podstawowe metody zdefiniowane we wspólnej nadklasie G_Element. Są to na przykład metody sprawdzające czy dane współrzędne znajdują się wewnątrz obiektu, metoda odrysowująca obiekt, metody przemieszczające obiekt itp. Podstawowe klasy graficzne zorganizowane są w następującą hierarchię:

• G_Element -- element graficzny, rozumiany w sposób ogólny:
  • G_Maszyna -- maszyna graficzna (element wyświetlany jako ikonka):
    • G_Komputer -- komputer graficzny,
    • G_Ruter -- ruter graficzny,
  • G_Kwadrat -- kwadrat graficzny (element wyświetlany jako pełny kwadrat):
    • G_Gniazdo -- graficzne gniazdo na kablu,
    • G_Interfejs -- graficzny element symbolizujący interfejs osadzony w maszynie,
  • G_Linia -- element graficzny wyświetlany jako linia:
    • G_Wtyczka -- element graficzny łączący interfejs graficzny z gniazdem na kablu,
    • G_Kabel -- kabel graficzny (element łączący gniazda).

W warstwie tej zaimplementowano także menu kontekstowe elementów graficznych, dostępne w trakcie trybu budowania i konfigurowania topologii sieciowej.

Warstwa fizyczno-logiczna

Zaimplementowane tutaj obiekty składają się z jednej strony na logiczną strukturę projektu (tzn. komputery i rutery podłączone za pomocą interfejsów do kabli), z drugiej strony zaimplementowana jest na nich także warstwa fizyczna sieci -- znajdują się tutaj metody odpowiedzialne za komunikację sieciową na najniższym poziomie. Na podstawie zbudowanej topologii sieci wiadomo jakie elementy logiczne muszą się ze sobą komunikować przy transmisji danych w sieci.

Struktura klas zdefiniowana na tym poziomie to:

• L_Element -- element logiczny:

  • L_Maszyna -- element logiczny typu maszyna:

    • L_Komputer -- komputer logiczny,
    • L_Ruter -- ruter logiczny,

  • L_Interfejs -- element logiczny typu interfejs,

    • IfLoop -- interfejs lokalny (ang. loopback),
    • IfEth -- interfejs sieciowy typu Ethernet,

  • L_Kabel -- kabel sieciowy.

Warstwy protokołów

W tych warstwach zdefiniowano klasy implementujące poszczególne protokoły oraz klasy definiujące struktury pakietów obsługiwanych przez te protokoły. Protokoły są osadzone na maszynach (komputerach i ruterach). Kolejne protokoły coraz wyższych rzędów tworzą kolejne warstwy. Budowa taka daje możliwość łatwej rozbudowy programu poprzez dodawanie kolejnych protokołów wykorzystujących jako podstawę działania protokoły już zaimplementowane.

W obecnej chwili zaimplementowane są następujące protokoły:

• IP,
• ARP,
• ICMP.

Warstwa aplikacji

W tej warstwie są zdefiniowane aplikacje działające na maszynach, wykorzystujące któryś z dostępnych protokołów jako podstawę do komunikacji. Dodatkowo dla każdej aplikacji zdefiniowany jest interfejs użytkownika, pozwalający na zadanie parametrów startowych dla aplikacji. Stałym parametrem startowym aplikacji jest opóźnienie jej startu względem czasu zero. Zaimplementowane aplikacje to:

• arp -- zadanie zapytania arp o dowolny adres IP; parametry własne to adres IP oraz określenie interfejsu, do którego zostanie wysłane to zapytanie. Aplikacja korzysta bezpośrednio z protokołu ARP;
• ip -- przesłanie pakietu IP do wybranej maszyny w sieci; parametry własne to docelowy adres IP oraz długość przesyłanego pakietu. Jest to aplikacja działająca bezpośrednio na bazie protokołu IP;
• ping -- standardowa aplikacja ping działająca na bazie protokołu ICMP; parametry to docelowy adres IP oraz liczba powtórzeń wysłania prośby o echo.

Aplikacje arp i ip nie mają odpowiedników wśród aplikacji w świecie rzeczywistym. Zostały one skonstruowane tylko po to, aby zademonstrować wybrane aspekty działania protokołów, na których są oparte.

Warstwa zarządzania symulacją

W warstwie tej zaimplementowano mechanizmy służące do przeprowadzenia symulacji. Symulacja w aplikacji PROTONET sterowana jest centralnie -- głównym obiektem nadzorującym symulację jest obiekt klasy Scheduler. Zajmuje się on rozdziałem sterowania pomiędzy inne obiekty. Obiekty innych klas zgłaszają zapotrzebowanie na sterowanie poprzez metody udostępnione przez klasę Scheduler:

• registerTimeOut (ScheduledObj* zgłaszający,int poJakimCzasie) -- zakolejkowanie informacji o żądaniu dostępu do sterowania (za poJakimCzasie milisekund) zgłoszonym przez obiekt zgłaszający. W odpowiednim momencie zostanie wywołana na rzecz obiektu zgłaszający metod runTimeOut;
• registerAction (ScheduledObj* zgłaszający, int poJakimCzasie) -- zakolejkowanie informacji o żądaniu dostępu do sterowania (za poJakimCzasie milisekund) zgłoszonym przez obiekt zgłaszający. W odpowiednim momencie zostaną wywołane na rzecz obiektu zgłaszającego metody runAction oraz runResource.

Metody te powodują zakolejkowanie żądań sterowania zgłaszanych przez obiekty w odpowiednich strukturach obiektu klasy Scheduler.

Aby dowolny obiekt mógł bezpośrednio otrzymać sterowanie, musi dziedziczyć po klasie ScheduledObj. W klasie tej zdefiniowano trzy wirtualne metody, które klasa dziedzicząca musi redefiniować:

• metoda runTimeOut przeznaczona do ustawiania zegarów dla obiektu zgłaszającego;
• metoda runAction wykonująca właściwą akcję, którą chciał wykonać obiekt w momencie zgłoszenia zapotrzebowania na sterowanie;
• metoda runResource wywoływana przed metodą runAction, służy do ewentualnej rezerwacji zasobów niezbędnych do wykonania akcji (w metodzie runAction w takim wypadku należy sprawdzić czy zasoby udało się zarezerwować). W przypadku, gdy rezerwacja zasobów nie jest niezbędna, metoda ta może być pusta.

Symulacja trwa dopóty, dopóki w którejkolwiek z kolejek znajdują się zlecone żądania sterowania lub do momentu jej przerwania na życzenie użytkownika. Najmniejszym krokiem symulacji jest obsłużenie wszystkich żądań zgłoszonych na jeden moment czasowy (w rozumieniu czasu naliczanego przez system PROTONET).

Warstwa prezentacji wyników symulacji

System PROTONET umożliwia śledzenie zdarzeń zachodzących w systemie w czasie symulacji. Prezentacja zdarzeń odbywa się w okienkach otwieranych na życzenie użytkownika. Okienko takie wyświetla informacje o zdarzeniach, pakietach, głównych procesach decyzyjnych zachodzących w jednym z elementów architektury sieciowej (możliwe jest podsłuchiwanie zdarzeń w komputerze, ruterze, kablu i dowolnym interfejsie -- w tym także lokalnym). Dodatkowo istnieje możliwość otwarcia okienka podglądu dla zdarzeń zachodzących w procesie zarządzającym przydziałem czasu. Informacje można filtrować ze względu na warstwę, w której zachodzą zdarzenia (warstwa fizyczna oraz poszczególne protokoły), a także ze względu na treść (może to być zawartość pakietów i/lub komunikaty o zdarzeniach i decyzjach podejmowanych przez oprogramowanie).

Poszczególne elementy systemu generują sygnały z komunikatami obudowanymi znacznikami języka QML, komunikaty te są przechwytywane i filtrowane (mechanizmem sygnałów i slotów) przez okienka podglądu zdarzeń. QML jest językiem znacznikowym zgodnym ze specyfikacją XML obsługiwanym przez klasy dostarczone wraz z biblioteką Qt. Język ten umożliwia kolorowanie, wybór krojów czcionki, stylów wyliczania itp. w stosunku do prezentowanego tekstu.

Rysunki , i obrazują budowę główych elementów aplikacji na tle jej struktury warstwowej.

Figure: Budowa interfejsu sieciowego

Figure: Budowa kabla sieciowego

Figure: Budowa komputera z uwzględnieniem warstwowości aplikacji