Rok akademicki 2011/2012
POLITECHNIKA WARSZAWSKA
WYDZIAŁ ELEKTRONIKI I TECHNIK INFORMACYJNYCH
INSTYTUT INFORMATYKI
PRACA DYPLOMOWA MAGISTERSKA
Kamil Kukołowicz
WYKORZYSTANIE NAGŁÓWKA HOP-BY-HOP
PROTOKOŁU IPV6 DO TRANSPORTU WIADOMOŚCI
KONTROLNYCH W BEZPRZEWODOWYCH
SIECIACH AD-HOC
Opiekun pracy
mgr inż. Paweł Radziszewski
Ocena ………………………
……………………………...
Podpis Przewodniczącego
Komisji Egzaminu Dyplomowego
STRESZCZENIE
Przedmiotem niniejszej pracy jest zbadanie możliwości wykorzystania nagłówka hop-by-hop
w sieciach IPv6 do przesyłania wiadomości sygnalizacyjnych i próba oceny przydatności
takiego rozwiązania. Przydatność jest oceniana z punktu widzenia wykorzystania
w środowisku bezprzewodowej sieci ad-hoc, do optymalizacji jej działania. Stworzono
środowisko testowe umożliwiające przesyłanie wiadomości w nagłówkach hop-by-hop
i przeprowadzono szereg testów. Przeprowadzony zbiór testów jest tylko małym krokiem do
zbadania rzeczywistej przydatności nagłówka hop-by-hop, jako sposobu przesyłania
wiadomości sygnalizacyjnych w bezprzewodowych sieciach ad-hoc.
Słowa kluczowe: IPv6, nagłówek rozszerzający, QoS, Linux, jądro
USAGE OF HOP-BY-HOP IPV6 HEADER FOR TRANSMISSION OF CONTROL
INFORMATION IN WIRELESS AD-HOC NETWORKS
SUMMARY
The scope of this thesis covers studies on usage of hop-by-hop header in IPv6 networks for
sending status information and evaluation of possible advantages of this type of
communication. A test environment that provides sending messages mechanism in hop-by-
hop header was created and several tests were proceeded. The results of tests are evaluated in
relation to ad-hoc wireless networks and network optimization in those networks. The group
of tests are only a small step to evaluate real advantages and disadvantages of using hop-by-
hop headers in ad-hoc networks.
Keywords: IPv6, Extension Headers, Quality of Service, QoS, Linux, kernel
ŻYCIORYS
Urodziłem się 04 lutego 1986 roku w Warszawie. W roku 2005 ukończyłem XIV
liceum ogólnokształcące w Warszawie i rozpocząłem studia na Wydziale Elektroniki
i Technik Informacyjnych, na kierunku Elektronika, Informatyka i Telekomunikacja, na
Politechnice Warszawskiej. W roku 2009 uzyskałem dyplom inżyniera specjalności
teleinformatyki i zarządzania w telekomunikacji, z wynikiem bardzo dobrym. W tym samym
roku rozpocząłem stacjonarne studia drugiego stopnia na kierunku Informatyka, na
specjalności Inżynieria Systemów Informatycznych. Od końca roku 2009 pracuję w dużej
firmie telekomunikacyjnej, wykonując pracę analityka systemów informatycznych.
Kamil Kukołowicz
SPIS TREŚCI
.............................................................................
.....................................................................................
.............................................................................................
..............................................................................
2.3 Bezstanowa konfiguracja adresu IPv6
.........................................................
2.4 Nagłówek hop-by-hop i inne nagłówki rozszerzające
...................................
3. Implementacja protokołu IPv6 w systemie Linux
..............................................
3.1 Obsługa pakietów przychodzących i wychodzących.
...................................
3.2 Bufor na pakiet – skb_buff
...........................................................................
3.3 Pakiety – obsługa w warstwie łącza danych
................................................
...........................................................................
............................................................................
4. Przegląd możliwych implementacji programu.
.................................................
..............................................................................
4.2 Implementacja z wykorzystaniem zaczepów
...............................................
4.3 Implementacja w przestrzeni użytkownika.
.................................................
............................................................................................
5. Środowisko stworzone do testownia wykorzystania nagłówka hop-by-hop, jako
kanału komunikacyjnego
......................................................................................
5.1 Wstęp do funkcjonalności stworzonego środowiska testowego.
5.2 Program warstwy transportowej.
.................................................................
......................................................................................
......................................................................................
...........................................................................................
......................................................................................
......................................................................................
5.4 Pomiar opóźnienia przesyłania wiadomości
.................................................
..........................................................................................
6.1 Schemat środowiska testowego
..................................................................
................................................................................................
.................................................................................................
6.4 Mechanizm kształtowania ruchu
..................................................................
..........................................................................................
.....................................................................................
7.2 Scenariusze testów akceptacyjnych.
...........................................................
4
8. Testy wydajności i opóźnienia
...........................................................................
...................................................................................
8.2 Test w. 2. Priorytet 4. Typ potwierdzenia 2.
..................................................
8.3 Test w. 3. Priorytet 4. Typ potwierdzenia 1.
..................................................
8.4. Test o. 1. Priorytet 2. Syg. constant.
...........................................................
8.5 Test o. 2. Priorytet 3. Syg. constant.
............................................................
8.6 Test o. 3. Priorytet 4. Syg. const.
.................................................................
8.7 Test o. 4. Priorytet 2. Syg. random.
.............................................................
8.8 Test o. 5. Priorytet 2. Sygnał snmp-like.
.......................................................
8.9 Podsumowanie testów wydajności i opóźnienia.
........................................
...............................................................................
9.1 Test p. 1. Priorytet 1. Scp. Syg. random.
....................................................
9.2 Test p. 2. Priorytet 1. Scp. Syg. random rzadki.
.........................................
9.3 Test p. 3. Priorytet 2. Scp. Syg. const. Kier. przeciwny.
..............................
9.4 Test p. 4. Priorytet 2. Scp. Syg. const. Kier. zgodny.
..................................
9.5 Test p. 5. Priorytet 2. Scp. Syg. const. Kier. zgodny. Tc duże opóźnienie.
9.6 Test p. 6. Priorytet 4. Scp. Syg. const. Kier. zgodny. Tc duże opóźnienie.
9.7 Test p. 7. Priorytet 4. Scp. Syg. const. Kier. zgodny. Tc małe opóźnienie.
9.8 Test p. 8. Priorytet 2. Vlc. Syg. const.
........................................................
9.9 Test p. 9. Priorytet 2 duży odstęp. Vlc. Syg. const.
....................................
9.10 Test p. 10. Priorytet 1. Vlc. Syg. const.
....................................................
9.11 Test p. 11. Priorytet 2. Vlc. Syg. snmp-like.
..............................................
9.12 Test p. 12. Priorytet 4. Vlc. Syg. snmp-like.
..............................................
9.13 Test p. 13. Priorytet 3. Vlc. Syg. snmp-like.
..............................................
9.14 Test p. 14. Priorytet 4. Vlc. Tc. Syg. snmp-like.
........................................
9.15 Test p. 15. Priorytet 3. Vlc. Tc. Syg. snmp-like.
........................................
9.16 Podsumowanie testów przesyłania danych
.............................................
...................................................................................
....................................................................................................
Załącznik A. Dokumentacja użytkowa programu testowego
...............................
Załącznik B. Zawartość płyty CD dołączonej do pracy.
.......................................
5
WYKAZ UŻYWANYCH SKRÓTÓW
IPSec – ang. Internet Protocol Security; protokół który umożliwia bezpieczną komunikację za
pomocą protokołu IP; Bezpieczeństwo oznacza możliwość szyfrowania wiadomości oraz
zapewnienie identyfikacji nadawcy
AH – ang. Authentication Header; składnik protokołu IPSec, zapewnia integralność
przesyłanych danych oraz uwierzytelnienie nadawcy wiadomości
ESP – ang. Encapsulating Security Payload; składnik protokołu IPSec, zapewnia integralność
i poufność przesyłanych danych oraz uwierzytelnienie nadawcy wiadomości
AODV – ang. Ad hoc On-Demand Distance Vector, protokół routingu typu reaktywnego,
stosowany w bezprzewodowych sieciach ad-hoc
CSMA/CD – ang. Carrier Sense Multiple Access with Collision Detection; sposób dostępu do
pasma transmisyjnego, realizowany na zasadzie wielodostępu z badaniem stanu kanału
i wykrywaniem kolizji
TLV – ang. Type-Length-Value; uniwersalny sposób kodowania wiadomości, który składa się
z identyfikator typu wiadomości, długości wiadomości i zawartości wiadomości,
wykorzystywany jest m. in. w protokole IPv6 w nagłówku typu hop-by-hop i ang. destination
options
CDMA – ang. Code Division Multiple Access, sposób dostępu do wspólnego pasma
radiowego nazywany wielodostępem z podziałem kodowym, w którym użytkownicy
korzystają z tego samego pasma częstotliwości, a ich ich transmisje odróżniane są za pomocą
specjalnie przyznawanych kodów, w standardzie wykorzystywane są zawansowane techniki
sterowania mocą, które zmniejszają interferencje między użytkownikami
UMTS – ang. Universal Mobile Telecommunications Systemstandard, standard telefonii
komórkowej trzeciej generacji, od standardu GSM różni się głównie innym sposobem
wielodostępu do kanału radiowego; w UMTS jest wykorzystywany wielodostęp CDMA
6
1. WSTĘP
W ostatnich latach sieć IP stała się coraz bardziej popularna w obszarach, w których nie
występowała powszechnie. Chodzi m. in. o wprowadzone na masową skalę bezprzewodowe
punkty dostępowe, do których łączą się komputery przenośne, a nawet aparaty telefonii
komórkowej i smartfony. Radiowy sposób przesyłania danych jest bardzo wygodny, gdyż nie
trzeba być podłączonym kablem do gniazdka, a także można zmieniać, w obszarze objętym
zasięgiem, swoje położenie. Oprócz klasycznych struktur bezprzewodowej sieci dostępowej,
z centralnie położonym routerem, tworzy się inne modele, które rezygnują z hierarchicznej
budowy. Taką strukturą jest sieć kratowa ang. ad-hoc, w której nie ma wyróżnionego jednego
punktu, zbierającego ruch od pozostałych członków. Pakiety przesyłane są między
sąsiadującymi komputerami, które są w odległości umożliwiającej transmisję pomiędzy nimi.
Przykładowym scenariuszem wykorzystania takiego sposobu funkcjonowania jest grupa
samochodów, stojących w korku, wyposażonych w urządzenia spełniające funkcję komputera
i wymieniających się miedzy sobą danymi. Zagadnieniem, które trzeba rozwiązać w sieciach
typu ang. ad-hoc, jest odpowiednie routowanie pakietów. Poszczególne komputery powinny
wiedzieć o swoim istnieniu i ścieżkach, po których są dla siebie osiągalne. Jeżeli
bezprzewodowa struktura ma połączenie z internetem, wtedy konieczna jest też wiedza,
w których miejscach sieci to połączenie zostało ustanowione. Należy pamiętać, że struktura
może ulec zmianie, spowodowanej wyłączeniem się któregoś komputera lub zerwaniem
połączenia, wynikającym ze zbyt dużej odległości między elementami. Jednym z protokołów
routingu stosowanym w sieciach typu ad-hoc jest ang. AODV. Charaketryzuje się on tym, że
poszukiwanie ścieżki prowadzącej do celu jest wykonywane dopiero w momencie pojawienia
się żądania przez jednen z komputerów. Oznacza to, że jeżeli pakiety nie są przesyłane
między sąsiednimi komputerami, wtedy nie są też wysyłane wiadomości tego protokołu.
Wiadomości routingowe są przesyłane najczęściej w postaci odrębnych pakietów IP.
W protokołach stosowanych w sieci internet, takich jak ang. OSPF, czy ang. RIP, informacje
są przesyłane w stałych odstępach czasu lub na żądanie. Ważne jest aby wiadomości
protokołu nie wykorzystywały zbyt dużo pasma transmisyjnego, chociaż przy obecnych
szybkościach transmisji staje się to coraz mniejszym problemem. Następca obecnie
wykorzystywanego protokołu IP [2], opisany w dokumencie [1] i określany nazwą IPv6,
zawiera ciekawe rozszerzenie, które może być wykorzystane do optymalizacji przesyłania
wiadomości routingowych. Jest to nagłówek rozszerzające (ang. Extension Headers) typu
ang. hop-by-hop, który umożliwia dołączanie do pakietów użytkowych dodatkowej informacji
7
[1, 4.3 Hop-by-Hop Options Header]. Jeżeli będą w nim przesyłane wiadomości protokołu
AODV uzyska się dzięki temu oszczędność radiowego pasma transmisyjnego. Standardowo
wiadomości protokołu są przesyłane na żądanie, czyli w momencie gdy potrzebne jest
znalezienie ścieżki do przesłania danych. Jeżeli wykorzysta się nagłówek hop-by-hop, wtedy
będzie można na bieżąca aktualizować wiedzę o ścieżkach w sieci ad-hoc, co usprawni
transmisję. Komputery będą posiadały wiedzę na temat zmieniającej się struktury sieci, która
ze swojej natury nie jest trwała. Możliwość bardzo częstego przesyłania dodatkowych
wiadomości, razem z ruchem użytkowników, można wykorzystać też do drugiej optymalizacji
działania sieci bezprzewodowej. Chodzi o mechanizm sterowania mocą, który występuje
w telefonii komórkowej, w której występuje dostęp do pasma typu ang. CDMA (Code
Division Multiple Access), np. w sieciach ang. UMTS. W tej technologii precyzyjne
kontrolowanie siłą sygnału jest bardzo ważne, gdyż użytkownicy nadają na tych samych
częstotliwościach, a rozróżnienie ich transmisji odbywa się z użyciem specjalnych kodów.
Jeżeli podobny mechanizm, kontrolowania siłą nadawania, zastosuje się w sieciach ad-hoc,
wtedy zmniejszą się zakłócenia i efektywność wykorzystania pasma transmisyjnego może
wzrosnąć.
8
1.1 CEL I ZAKRES PRACY
Celem pracy jest stworzenie programu testowego, który wykorzystuje nagłówki hop-by-hop
występujące w protokole IPv6, do przesyłania dodatkowych wiadomości, które mogą być
dołączane do każdego pakietu. Stworzona warstwa transportowa ma umożliwiać
przekazywanie wiadomości generowanych przez aplikacje klienckie, które z niej korzystają.
Ten sposób transportu mógłby być wykorzystany do wysyłania wiadomości sterujących,
takich jak pakiety routingowe czy informacje kontrolujące pracę urządzeń radiowych
w sieciach ad-hoc. Badania przeprowadzone na aplikacji testowej, mają na celu sprawdzić
możliwość implementacji takiego rozwiązania oraz zweryfikać, czy przesyłanie wiadomości
w nagłówku hop-by-hop ma zalety w porównaniu z wysyłaniem ich w oddzielnych pakietach.
Przewidywanymi zaletami jest lepsze wykorzystanie łącza transmisyjnego.
Praca składa się z części teoretycznej i praktycznej. W rozdziale 2 przedstawiono podstawowe
wiadomości o protokole IPv6, które są przydatne z punktu widzenia realizacji
bezprzewodowych sieci ad-hoc. Zaprezentowano nie tylko nagłówek hop-by-hop, ale także
mechanizm bezstanowego przydzielania adresu (ang. stateless autoconfiguration) oraz
protokół mobilności. W rozdziale 3 przeprowadzono analizę implementacji protokołu IPv6
w jądrze systemu Linux. Analiza jest wstępem do zaproponowania realizacji programu, który
wykorzystuje nagłówek hop-by-hop jako środek transportowy. W rozdziale 4 zaprezentowano
możliwe typy implementacji, która może być wykonana w przestrzeni jądra, w przestrzeni
użytkownika, oraz z wykorzystaniem różnych bibliotek. W rozdziale 5 przedstawiono kod
źródłowy stworzonego programu, która jest realizacją jednego z możliwych sposobów
przedstawionych w rozdziale 4. Rozdziały 6, 7, 8 i 9 zawierają testy funkcjonalności aplikacji.
Ich celem jest stwierdzenie, czy wykorzystanie nagłówków hop-by-hop ma zalety
w porównaniu z wysyłaniem odzielnych pakietów, w kontekście wykorzystania
w bezprzewodowych sieciach ad-hoc.
9
2. Protokół IPv6
W rozdziale tym opisano podstawowe różnice pomiędzy protokołem IPv6 i obecnie
wykorzystywanym protokołem IP, który jest też nazywany jako wersja 4 (IPv4). Należą do
nich budowa podstawowego nagłówka pakietu i format adresacji. Po wprowadzeniu opisano
kolejne cechy protokołu w wersji 6, które mogą być wartościowe w wykorzystaniu
w bezprzewodowych sieciach ang. ad-hoc. Zostało omówione, z jakich powodów dane cechy
mogą być korzystne. Opisano proces bezstanowej konfiguracji adresu IP, rozbudowany
mechanizm mobilności, nagłówek hop-by-hop. Opisowi nagłówka hop-by-hop towarzyszy
opis wszystkich nagłówków rozszerzających, gdyż przedstawienie ich pozwoli lepiej
zrozumieć możliwości tych rozszerzeń.
10
2.1 Adresacja IPv6
Protokół IPv6 jest następcą protkołu IP, w obecnej wersji 4. Głównym powodem stworzenia
nowej wersji protokołu IP jest wyczerpywanie się wolnych pul adresów publicznych. Jeżeli
dostępne do przydzielenia adresy się skończą, to rozwój Internetu będzie bardzo ograniczony.
Adres w nowej wersji protkołu ma 128 bitów, a w wersji 4 są to 32 bity. Adres zapisany na
128 bitach daje 3,4 x 10
38
adresów, co jest ogromną liczbą. 32 bity umożliwiają stworzenie
4,3 x 10
9
unikalnych identyfikatorów. Wyjaśnienia wymaga, dlaczego kończy się pula
adresów, mimo że teoretycznie można utworzyć ponad 4 miliardy adresów. Wynikło to
z faktu, że na samym początku rozwoju Internetu nie przewidziano jak bardzo rozwinie się
sieć i podjęto błędne decyzje w alokacji ogromnych pul adresów do małych organizacji, oraz
standard nie przewidywał wykorzystania części z dostępnych adresów, jako możliwych do
routowania.
W protokole IPv6 odpowiednikiem adresu publicznego jest adres Global Unicast.
Odpowiednikiem adresu prywatnego jest adres Link Local. Był zdefiniowany także trzeci typ
adresu Site-Local, który miał być adresem do stosowania wewnątrz pojedynczej organizacji.
Jednak z powodu wielu kontrowersji został on uznany jako nieaktualny, w dokumencie RFC
3879 [18].
Jednym z problemów, który występuje w obecnej sieci Internet są duże tablice routingowe.
W standardzie IPv6 postanowiono rozwiązać ten problem definiując strukturę adresów
publicznych, składającą się z prefiksu i adresu interfejsu. Prefiks jest zależny od
geograficznego położenia węzła i dzięki temu adresy o podobnym prefiksie znajdują się
w tym samym obszarze sieci. Routery mogą rozpoznać po nim, w którą część Internetu
powinny przekazać pakiet.
Struktura adresu typu Link Local przedstawiona jest na Rys. 1. Początek adresu to prefiks
FE80 w zapisie heksadecymalnym. Kolejne 48 bitów mają wartość 0. Ostatnie 64 bity są
adresem interfejsu.
16 bits
48 bits
64 bits
FE80
0
Interface ID
Rys. 1: Adres IPv6 Link-local
64 bitowy identyfikator interfejsu Interface ID jest zmodyfikowaną wersją adresu EUI-64
i tworzony jest z 48 bitowego adresu MAC. Pierwsze 24 bity IF-ID są pierwszymi 24 bitami
11
adresu MAC. Dodatkowo 7 bit jest zamieniany na wartość 1, która oznacza, że adres jest
unikalny globalnie. Kolejne 16 bitów jest stałe i w zapisie szesnastkowym jest to ciąg znaków
FFFE. Ostatnie 24 bity są ostatnimi 24 bitami adresu MAC. Budowa identyfikatora interfejsu
jest przedstawiona na Rys. 2.
Rys. 2: Adres interfejsu IF-ID
Z adresu MAC 00:16:D4:CC:65:90 powstanie IF-ID 02:16:D4:FF:FE:CC:65:90. Cały adres
Link-local będzie miał postać fe80::216:d4ff:fecc:6590.
Adres typu Global Unicast jest odpowiednikiem adresu publicznego w IPv4. Budowę adresu
przedstawiono na Rys. 3. Składa się on z następujących części:
•
48 bitów które wynikają z położenia geograficznego podsieci; jedną z części 48
bitowego adresu jest między innymi kod kraju,
•
16 bitów identyfikujących podsieć, której adres jest określany przez dostawcę
dostępu do Internetu,
•
ostatnie 64 bity są identyfikatorem interfejsu; adres Global Unicast jest publicznym
adresem umożliwiający komunikację węzłów znajdujących się w Internecie
w różnych podsieciach.
48 bits
16 bits
64 bits
Public Net-id
Subnet ID
Interface ID
Rys. 3: Adres IPv6 Global Unicast
W protokole IPv6 interfejs może mieć równocześnie adres Link Local i Global Unicast.
W protokole IPv4 urządzenie sieciowe może mieć albo adres prywatny, albo adres publiczny.
12
24 bits
24 bits
24 bits
24 bits (7 – inv)
FFFE
MAC
IF-ID
2.2 Struktura nagłówka IPv6
Podstawowy nagłówek IPv6 składa się z 40 bajtów i przedstawiony jest na Rys. 5. Nagłówek
składa się z następujących pól (nazwy angielskie) [1]:
•
Version – 4 bitowy numer wersji protokołu IP, w wersji IPv6 przyjmuje wartość 6.
•
Class – 8 bitowy identyfikator klasy ruchu, umożliwiający rozróżnienie różnych
priorytetów i wprowadzenie różnych typów jakości przesyłania danych QoS.
•
Flow Label – 20 bitowa etykieta przepływu, używana do zapewnienia QoS dla
strumienia powiązanych ze sobą pakietów
•
Payload Length – 16 bitowa liczba oznaczająca długość pakietu bez podstawowego
nagłówka o długości 40 bajtów, ale wliczając nagłówki rozszerzające
•
Next Header – pole identyfikuje typ kolejnego nagłówka; może to być nagłówek
rozszerzający lub nagłówek wyższej warstwy, np. TCP lub UDP
•
Hop Limit – liczba przeskoków pakietu między węzłami, po której pakiet zostanie
skasowany
•
Source Address – 128 bitowy adres źródłowy pakietu
•
Destination Address – 128 bitowy adres docelowy pakietu
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rys. 4: Nagłówek IPv4
13
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rys. 5: Nagłówek IPv6
Porównując nagłówek IPv4, przedstawiony na Rys. 4 z nagłówkiem IPv6 można stwierdzić,
że budowa obu jest bardzo podobna. Nagłówek w wersji 6 ma trochę prostszą budowę. Nie
występuje w nim odpowiednik pól obecnych w nagłówku w wersji 4 o nazwach angielskich:
IHL, Identification, Flags, Header Checksum, Options. Pozostałe pola występujące w wersji 4
mają swoje odpowiedniki. W Tab. 1 zestawiono nazwy odpowiadających sobie pól, pod
względem ich znaczenia w nagłówku IPv4 i IPv6. Nowym polem w nagłówku IPv6 jest pole
Flow Label.
Tab. 1: Odpowiadające sobie pole w nagłówkach IPv4 i IPv6
Pole nagłówka w IPv4
Odpowiadające pole w IPv6
Version
Version
Type of Service
Traffic Class
Total Length
Payload Length
Time To Live
Hop Limit
Protocol
Next Header
Source Address
Source Address
Destination Address
Destination Address
14
Z punktu widzenia pracy ważny jest fakt, że pole Options, które zostało zarezerwowane
w nagłówku IPv4 do tworzenia rozszerzeń, nie występuje w podstawowym nagłówku IPv6.
W wersji 6 możliwość dodawania nowej zawartości nagłówka IP wyniesiono z podstawowego
nagłówka do nagłówków rozszerzających. Ma to dwojakie zalety. Po pierwsze nagłówek
podstawowy ma stałą długość, co umożliwia wprowadzenie optymalizacji w sprzętowym
przetwarzaniu pakietów. Po drugie takie rozwiązanie jest bardziej elastyczne. Jeżeli
dodatkowa informacja nie jest potrzebna, wtedy nagłówek rozszerzający nie występuje
w ogóle. Możliwe jest przesyłanie kilku nagłówków rozszerzających w jednym pakiecie.
2.3 Bezstanowa konfiguracja adresu IPv6
Bezstanowa (ang. stateless) konfiguracja adresu IP urządzenia włączającego się do sieci może
być szczególnie przydatna w sieciach typu ad-hoc. Ten typ przydzielenia adresu jest
domyślnym trybem w protokole IP w wersji 6 i nie występuje w ogóle w IP w wersji 4
Urządzenie włączające się do sieci generuje własny adres typu Link Local i wysyła zapytanie,
czy w sieci istnieje jakiś router. Jeżeli tak, to prosi go o przydzielenie adresu typu Global
Unicast. Autokonfiguracja bezstanowa wymaga minimalnej konfiguracji routera oraz nie
wymaga konfiguracji maszyny podłączającej się do sieci. Router przechowuje globalny
prefiks sieci, który odsyła maszynie proszącej o przydzielenie go. Ewentualna możliwość
wystąpienia duplikatu adresu w sieci lokalnej jest rozwiązywana przez mechanizm
zdefiniowany w protokole ICMPv6 i nie wymaga zaangażowania routera. W przypadku, gdy
w sieci lokalnej nie ma routera, wtedy adres Link Local jest wystarczający do komunikacji
między komputerami. Mechanizm stanowej konfiguracji adresu IP (ang. stateful), wymaga,
aby w sieci był zainstalowany sewer DHCP. Serwer ten przechowuje informacje na temat
przydzielonych adresów IP i zarządza nimi. Protokół DHCP występuje zarówno w protokole
IP w wersji 4 jak i 6. Zaletą konfiguracji stanowej jest to, że serwer DHCP dystrybuuje adresy
DNS, co nie jest robione przy konfiguracji bezstanowej. Między innymi dlatego oba typy
konfiguracji uzupełniają się i mogą być stosowane równocześnie.
15
Rys. 6: Bezstanowa konfiguracja adresu IPv6
Proces autokonfiguracji bezstanowej wykorzystuje komunikaty protokołu ICMPv6.
Przedstawiony jest na Rys. 6 i składa się z następujących kroków:
1. Komputer generuje adres IPv6 Link Local. Adres ten składa się z prefiksu FE80 i 64-
bitowego adresu interfejsu wygenerowanego z adresu MAC karty sieciowej.
Komputer wysyła do wszystkich sąsiadów wygenerowany adres w wiadomości
Neighbour Solicitation w celu sprawdzenia jego unikalności. Jeżeli adres jest
unikalny, to komputer nie otrzymuje żadnej wiadomości zwrotnej typu Neighbour
Advertisement.
2. Komputer wysyła prośbę o przydzielenie prefiksu adresu i innych parametrów
podłączenia do sieci, za pomocą wiadomości Router Solicitation .
3. Jeżeli w sieci, w której znajduje się komputer istnieje router , to odsyła mu odpowiedź
z prefiksem sieci, w wiadomości Router Advertisement. Komputer tworzy globalny
adres IPv6 łącząc prefiks sieci i wygenerowany z adresu MAC adres interfejsu.
W Tab. 2 przedstawiono jaki adres Global Unicast uzyska komputera o podanym adresie
MAC i prefiksie sieci, w której się łączy.
Tab. 2: Bezstanowa konfiguracja adresu IPv6. Przykład.
MAC
Link Local
Router prefix Global Unicast
00:16:D4:CC:65:90
fe80::216:d4ff:fecc:6590 fec0::0
fec0::216:d4ff:fecc:6590
16
Neighbor solicitation
Router solicitation
Router advertisement
Komputer
Router
2.4 Nagłówek hop-by-hop i inne nagłówki rozszerzające
Nagłówki rozszerzające (ang. Extension Headers) są nowym rozwiązaniem, które
wprowadzono w protokole IPv6. Funkcjonalności, które są zrealizowane za pomocą
nagłówków rozszerzających, mogą mieć zastosowanie w bezprzewodowych sieciach ad-hoc.
Są to: mobilność, bezpieczne przesyłanie danych, czy mechanizm sterowania routowaniem
pakietów, czyli tzw. source routing. Wykorzystanie jednego z nagłówków rozszerzających,
nagłówka hop-by-hop, jest celem pracy. W podrozdziale zostały opisane krótko wszystkie
nagłówki rozszerzające oraz sposób ich dołączania do pakietu.
W Tab. 3 przedstawiono listę nagłówków rozszerzających protokołu IPv6 z informacją, które
węzły analizują ich zawartość. W jednym pakiecie może występować wiele nagłówków
rozszerzających. Ich obecność jest wskazywana przez pole Next Header występujące
w podstawowym nagłówku IPv6 i w każdym nagłówku rozszerzającym. Wskazuje ono typ
następnego nagłówka lub protokół wyższej warstwy, jeżeli jest to ostatni nagłówek
rozszerzający w pakiecie. Protokołem wyższej warstwy może być np. protokół TCP lub UDP.
Każdy typ nagłówka może występować w pakiecie tylko raz. Wyjątkiem jest typ Destination
Options który może występować dwa razy. Nagłówki rozszerzające muszą być odczytywane
przez węzeł w kolejności, w której występują. Na Rys. 7 przedstawiono strukturę pakietu
zawierającego maksymalną sekwencję nagłówków rozszerzających.
Tab. 3: Nagłówki rozszerzające IPv6.
Numer typu
Nazwa (angielska)
Procesowanie
0
Hop-by-Hop Options
każdy węzeł
60
Destination Options header
for routers
routery i węzeł docelowy
43
Routing header
routery
44
Fragmentation header
węzeł docelowy
50
Authentication header
węzeł docelowy
51
Encapsulation
security
payload header
węzeł docelowy
135
Mobility header
węzeł docelowy
17
IPv6 header
Next header: 0
Header type: Hop-by-Hop Options (0)
Next header: 60
Header type: Destination Options (60)
Next header: 43
Header type: Routing header (43)
Next header: 44
Header type: Fragmentation header (44)
Next header: 50
Header type: Authentication header (50)
Next header: 51
Header type: Encapsulation security payload
header (51)
Next header: 60
Header type: Destination Options (60)
Next header: 6
TCP
Rys. 7: Sekwencja nagłówków rozszerzających
Nagłówek typu Routing Header (o numerze 43) służy do wskazania węzłów pośredniczących,
przez które powinien być przesyłany pakiet. Jest to mechanizm zwany source routing. Pakiet
zawiera listę routerów pośredniczących. Każdy kolejny router zmienia w nagłówku Routing
Header listę węzłów, które muszą być jeszcze odwiedzone oraz zamienia zawartość pola
Destination Address w nagłówku podstawowym IPv6.
Nagłówek typu Fragment Header (o numerze 44) służy do przesłania wiadomości większej
niż minimalna wartość MTU na trasie od nadawcy do odbiorcy. W protokole IPv6 podział
pakietu na części może wykonywać tylko węzeł źródłowy. Węzły pośredniczące nie mogą
dokonać podziału pakietu. W przypadku gdy węzeł pośredniczący nie może przesłać dalej
pakietu, bo pakiet jest większy niż MTU kolejnego odcinka na trasie, wtedy do węzła
źródłowego przesyłana jest wiadomość o błędzie, w pakiecie ICMPv6 Packet too big o
numerze 2. Brak możliwości podziału pakietu na części jest ważną różnicą w stosunku do
protokołu IPv4, w którym możliwy był podział pakietu przez routery przekazujące pakiety
(tzw. fragmentacja).
Nagłówek typu Destination Options Header (o numerze 60) może wystąpić dwa razy.
Pierwszy raz przed nagłówkiem typu Routing Header, który jest odczytywany przez routery
pośredniczące w przesyłaniu pakietu. Drugi raz nagłówek występuje przed wyższą warstwą
18
sieciową i jest przeznaczony dla komputera docelowego. Zawartość może spowodować, że
pakiet będzie specjalnie potraktowany.
Nagłówek typu Mobility Header (o numerze 135) jest wykorzystywany do zestawiania,
utrzymywania i kończenia połączenia z węzłem mobilnym. Protokół IPv6 zapewnia obsługę
mobilności [12]. W protokole IPv4 była ona wspierana częściowo. Mobilność ma zapewnić
poruszającemu się węzłowi bezproblemowy i najlepiej ciągły dostęp do sieci, także bez
zerwania nawiązanych sesji. Taka funkcjonalność będzie miała coraz szersze zastosowania,
gdyż nowe urządzenia przenośne, np. telefony, są przystosowana do podłączania się do sieci
Internet.
Implementacja mobilności w protokole IPv6 jest związana z budową adresu IP. Adres składa
się z prefiksu sieci, w której znajduje się węzeł i identyfikatora interfejsu. Taka budowa
adresu powoduje, że rzeczywisty adres komputera nie może być zachowany w przypadku
przemieszczenia się do podsieci o innym prefiksie. Z drugiej strony dla aplikacji
komunikujących się z mobilnym węzłem (ang. Mobile) nie powinna być widoczna zmiana
rzeczywistego adresu IP. Problem ze zmianą adresu IP poruszającego się węzła rozwiązany
jest poprzez wykorzystanie pośrednika (ang. Home Agent), który zna pierwotny adres IP
węzła i przekierowuje ruch na nowy adres IP.
Rys. 8: Bezpośrednia komunikacja z węzłem mobilnym
Rys. 9: Komunikacja z węzłem mobilnym; Wykorzystanie pośrednika
19
Mobile (Home Link)
Home addre ss
Corre sponde nt
Correspondent
Home Agent (Home Link)
Mobile (Foreign Link)
Home addre ss
Corre sponde nt
Care -of addre ss
Home Age nt
Correspondent
Na Rys. 8 i 9 przedstawiono schemat komunikacji ]węzła, który ma skonfigurowaną obsługę
mobilności (ang. Mobile) z węzłem, znajdującym w się w odległym miejscu sieci (ang.
Correspondent). Jeżeli węzeł mobilny znajduje się w swojej sieci domowej (ang. Home Link),
wtedy komunikuje się z innym węzłem z sieci Internet przy wykorzystaniu swojego
rzeczywistego adresu, przydzielonego mu w sieci domowej (ang. Home Address) (Rys. 8). Po
przemieszczeniu się węzła mobilnego do obcej sieci (ang. Foreign Link) zostaje mu
przydzielony nowy adres globalny (ang. Care-of Address) (Rys. 8). Węzeł mobilny informuje
pośrednika, znajdującego się w sieci domowej, o jego nowym adresie. Komputery z sieci
Internet, z którymi się komunikował przed przemieszczeniem, nie wiedzą, że zmienił się jego
adres i wysyłają pakiety na adres z sieci domowej. Pośrednik przekierowuje te pakiety do
węzła mobilnego, na jego nowy adres w obcej sieci. Węzeł mobilny odsyła pakiety również
przez pośrednika. Taki sposób routowania pakietów występuje w momencie, gdy węzeł
komunikujący się z węzłem, który zmienił położenie nie wspiera optymalizacji
przekazywania pakietów. Jeżeli węzeł umie wprowadzić optymalizację, wtedy komunikacja
będzie odbywała się bezpośrednio pomiędzy węzłami bez przesyłania pakietów przez
pośrednika.
Nagłówki Authentication Header (AH) i Encapsulation Security Payload Header (ESP) służą
do zabezpieczania transmisji. Nagłówek Authentication Header umożliwia uwierzytelnienie
nadawcy, integralność danych oraz uodpornienie się na atak polegający na przejęciu pakietu
przez atakującego i podszyciu pod nadającego pakiet w późniejszym momencie. Nagłówek
ESP zapewnia szyfrowanie przesyłanych danych i opcjonalnie funkcjonalność oferowaną
przez nagłówek AH, czyli uwierzytelnienie nadawcy, integralność i obronę przed atakiem
polegającym na ponownym użyciu przejętego pakietu.
Nagłówek hop-by-hop różni się od pozostałych nagłówków rozszerzających z dwóch
powodów. Po pierwsze musi być przetwarzany przez każdy komputer, który przetwarza
pakiet. Po drugie jego zawartość nie jest sztywno określona w standardzie. Jednym
z opisanych zastosowań jest przesyłanie pakietów, których długość, nie wliczając
podstawowego 40 bajtowego nagłówka, jest większa niż 65 535 bajtów. Tak zwane
jumbograms są możliwe do przesłania przy wykorzystaniu nagłówka hop-by-hop [15].
Nagłówek hop-by-hop zawiera pola:
•
Next Header – identyfikator kolejnego nagłówka
20
•
Hdr Ext Len – długość nagłówka hop-by-hop, liczona jako wielokrotność 8 oktetów,
bez pierwszych 8 oktetów. Na przykład jeżeli w polu jest wartość 0 oznacza to, że
długość całego nagłówka hop-by-hop wynosi 8 oktetów, jeżeli w polu jest wartość 1 to
długość całego nagłówka wynosi 16 oktetów
•
Options – jest to zawartość nagłówka hop-by-hop, zawiera opcje - dane zakodowane
w formacie indetyfikator, długość, zawartość (ang. TLV, Type-Length-Value); Pole
Options jest wypełniane tak, że cały nagłówek hop-by-hop jest wielokrotnością
8 oktetów
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rys. 10: Nagłówek hop-by-hop
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Rys. 11: Struktura opcji nagłówka hop-by-hop
Sposób kodowania opcji jest przedstawiony na Rys. 11. Poszczególne pola oznaczają:
•
Option Type – identyfikator, typ
•
Opt Data Len – długość pola Option Data
•
Option Data – pole będące zawartością opcji
•
Option Type - identyfikator opcji; dwa najstarsze bity to informacja o zachowaniu
komputera nie rozpoznającego identyfikatora:
00 – opcja będzie zignorowana
01 – pakiet będzie skasowany
10 – pakiet będzie skasowany, do nadawcy będzie odesłana wiadomość ICMPv6
ze wskaźnikiem na nierozpoznaną opcję
11 - pakiet będzie skasowany, do nadawcy będzie odesłana wiadomość ICMPv6
ze wskaźnikiem na nierozpoznaną opcję, jeżeli adresat nie był typu multicast
Dzięki takiemu oznaczeniu, wybrane komputery w sieci mogą zdefiniować swoje własne
wiadomości przesyłane w nagłówku hop-by-hop, rozpoznawane tylko przez niektóre węzły.
Mimo to, węzły nie rozpoznające numerów opcji, w nagłówku hop-by-hop, nie porzucą
21
pakietu, ale prześlą go dalej. Jedynym warunkiem koniecznym jest, aby dwa najstarsze bity
numeru opcji miały wartość 00. Taka możliwość oferuje elastyczność w projektowaniu
rozszerzeń do protokołu IPv6.
W nagłówku hop-by-hop zdefiniowano także specjalny format wypełnień, które mogą być
użyte jako przerwa między opcjami lub do dopełnienia zawartości nagłówka, tak żeby jego
długość była wielokrotnością 8 oktetów. Zdefiniowano dwa typy opcji wypełniających.
Pierwszy typ, przedstawiony na Rys. 12, jest pojedynczym bajtem o wartości 0. Drugi typ
(Rys. 13) jest zakodowany w formacie TLV. Numer opcji ma wartość 1. W polu Opt Data Len
jest długość pola Option Data. Bajty Option Data powinny mieć wartość zero. Minimalna
długość wypełnienia drugiego typu wynosi 2. Wtedy drugie pole Opt Data Len ma wartość 0
a pole Option Data nie występuje.
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
Rys. 12: Padding 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Rys. 13: Padding n bajtów
22
3. Implementacja protokołu IPv6 w systemie Linux
W tym rozdziale przedstawiono analizę wybranych fragmentów implementacji protokołu
IPv6 w jądrze systemu Linux [14], w wersji numer 2.6.37 bez rozszerzeń. Kod źródłowy jądra
dołaczony jest do pracy i występuje w Załączniku B. Analiza ma pomóc w zrozumieniu, w
jaki sposób pakiety są przetwarzane. Uwaga skupiona jest na strukturach danych i funkcjach
dotyczących przetwarzania nagłówka IPv6 i nagłówków rozszerzających, w tym nagłówka
hop-by-hop. Dzięki analizie będzie można lepiej zrozumieć sposób implementacji warstwy
sieciowej w systemie Linux. Analiza będzie też punktem wyjścia do opisu, w jaki sposób
zaimplementować przesyłanie wiadmości w nagłówkach hop-by-hop w przestrzeni jądra.
23
3.1 Obsługa pakietów przychodzących i wychodzących.
Obsługa pakietów przychodzących pokazana jest na Rys. 14. Odebrany pakiet, w warstwie
łącza danych, jest rozpoznawany jako pakiet IPv6 i przekazywany do funkcji odbierającej
ipv6_rcv,
zadeklarowanej w pliku
net/ipv6/ip6_input.c
. Dalej funkcja
ip6_input
przejmuje wskaźnik do fragmentu pamięci, w którym znajduje się pakiet i są przeprowadzane
testy zgodności sumy kontrolnej i inne testy poprawności pakietu. Potem pakiet trafia do
funkcji
ip6_input_finish
, w której parsowane są nagłówki rozszerzające. Następnie
funkcja ta przekazuje pakiet do odpowiedniego protokołu wyższej warstwy, np. protokołu
TCP.
Rys. 14: Obsługa pakietów przychodzących
Pakiety wychodzące z wyższej warstwy przekazywane są do
funkcji ip6_xmit w pliku
net/ipv6/ip6_output.c
, która dodaje nagłówek IPv6. Jeżeli pakiet należy wysłać do
innego komputera trafia on ostatecznie do funkcji
ip6_output_finish2
, która przekazuje go
do sterownika urządzenia sieciowego. Schemat obsługi pokazany jest na Rys. 15.
24
ipv6_rcv
ip6_input
ip6_input_finish
Urządzenie sieciowe
Wyższa warstwa sieciowa,
np. TCP lub UDP
Rys. 15: Obsługa pakietów wychodzących
3.2 Bufor na pakiet – skb_buff
Bufory na pakiety są to struktury używane w jądrze do przechowywania zawartości pakietów
wraz z wszystkimi nagłówkami. Kolejne pakiety są połączone wskaźnikami, tworząc listę
dwukierunkową. Struktury te umożliwiają dostęp do zawartości poszczególnym protokołom
i uzpełnienie, bądź odczytanie wybranych fragmentów pakietu. Struktura
sk_buff
(ang.
socket buffer) jest używana jako nośnik danych pomiędzy warstwą protokołów i warstwą
urządzeń sieciowych. W implementacji struktura bufora ma nazwę
sk_buff
, często
oznaczana jest też symbolem
skb
. Na Listingu 1 przedstawiony jest fragment deklaracji
struktury
sk_buff
. Struktura jest zaimplementowana jako lista dwukierunkowa.
Listing 1: Struktura bufora sk_buff (include/linux/sk_buff.h)
struct sk_buff {
/* These two members must be first. */
struct sk_buff *next;
25
ip6_xmit
ip6_dev_loopback_xmit
ip6_finish_output
Wyższa warstwa sieciowa,
np. TCP lub UDP
Urządzenie sieciowe
ip6_finish_output2
ip6_output
Pętla zwrotna
Pakiety do wysłania
struct sk_buff *prev;
struct sk_buff_head *list;
struct sock *sk;
struct timeval stamp;
struct net_device *dev;
Protokoły TCP, UDP, nagłówki rozszerzające IPv6, ICMP korzystają z wskaźników do
miejsc, w których zaczynają się interesujące dla nich fragmenty pakietu. Wskaźniki do tych
miejsc są również przechowywane w strukturze
sk_buff
. Wskaźnik
h
pokazuje na nagłówek
transportowy TCP, UDP, ICMP lub IP. Wskaźnik
nh
wskazuje na początek nagłówka
sieciowego, czyli w przypadku IPv6 jest to nagłówek IP.
Listing 2: Struktura wskaźników do nagłówków (include/linux/sk_buff.h)
union {
struct tcphdr *th;
struct udphdr *uh;
struct icmphdr *icmph;
struct igmphdr *igmph;
struct iphdr *ipiph;
unsigned char *raw;
} h;
union {
struct iphdr *iph;
struct ipv6hdr *ipv6h;
struct arphdr *arph;
unsigned char *raw;
} nh;
union {
struct ethhdr *ethernet;
unsigned char *raw;
} mac;
Struktura
sk_buff
zawiera bufor
cb
,wykorzystywany przez protokoły do przechowywania
danych przydatnych przy przetwarzaniu. Protokół IPv6 przechowuje tam przesunięcie
nagłówka rozszerzającego liczone od początku nagłówka. W zmiennych
pkt_type
26
i
protocol
przechowywana jest informacja, który protokół będzie operował na buforze.
Deklaracja wybranych składowych struktury
sk_buff
przedstawiona jest na Listingu 3.
Listing 3: Dane tymczasowe protokołów obsługujących include/linux/sk_buff.h
char cb[48];
...
unsigned int len,
data_len,
...
unsigned char pkt_type,
...
unsigned short protocol,
...
unsigned char *head,
*data,
*tail,
*end;
3.3 Pakiety – obsługa w warstwie łącza danych
Pakiet odebrany w warstwie łącza danych jest przekazywany warstwie wyższej. Decyzja
o tym, któremu protokołowi warstwy wyższej będzie przekazany pakiet, jest podejmowana na
podstawie zawartości struktury
packet_type
, przedstawionej na Listingu 4. Pakiety
protokołu IPv6 w nagłówku MAC są identyfikowane za pomocą kodu 0x86DD. Ten typ
pakietu ma swoją strukturę, dla której definicja jest przedstawiona na Listingu 5.
Najważniejsza jest zmienna wskazująca funkcję, której będzie przekazany pakiet.
W przypadku IPv6 jest to funkcja
ipv6_rcv
znajdująca się w pliku
net/ipv6/ip6_input.c
Listing 4: Struktura packet_type (include/linux/netdevice.h)
struct packet_type
{
unsigned short type; /* This is really htons(ether_type) */
struct net_device *dev; /* Device on which packet can be recieved
NULL is a wildcard here */
int (*func) (struct sk_buff *, struct net_device *,
27
struct packet_type *);
/* Packet Type Handler. */
void *data;
/* Private to the packet type */
struct packet_type *next;
};
Listing 5: Struktura ipv6_packet_type (net/ipv6/ipv6_sockglue.c)
static struct packet_type ipv6_packet_type =
{
.type = __constant_htons(ETH_P_IPV6),
.dev = NULL, /* All devices */
.func = ipv6_rcv,
.data = (void*)1,
};
3.4 Rodzina protokołów INET6
W systemie Linux grupa protokołów wykorzystująca protokół IPv6, a także niektóre jego
rozszerzenia tworzą rodzinę protokołów INET6 [17]. Grupa ta obejmuje m. in. protokoły:
IPv6, ICMPv6, TCPv6, UDPv6. Nagłówki rozszerzające są również zarejestrowane jako
oddzielne protokoły. Rodzina protokołów INET6 została stworzona jako odpowiednik
rodziny protokołów INET dla IPv4. Funkcjonalności protokołów IPv4 i IPv6 pogrupowane
w rodziny oferują podobny interfejs do wykorzystania. Tab. 4 pokazuje protokoły INET6
wraz z plikami, w których są one zaimplementowane.
Tab. 4: Protokoły Inet6
Inet6_protocol
file
destopt_protocol
net/ipv6/exthdrs.c
rthdr_protocol
net/ipv6/exthdrs.c
icmpv6
net/ipv6/icmp.c
frag
net/ipv6/reassembly.c
tcpv6
net/ipv6/tcp_ipv6.c
esp6
net/ipv6/esp6.c
udpv6
net/ipv6/udp.c
ah6
net/ipv6/ah6.c
28
Każdy protokół musi mieć zdefiniowaną strukturę pokazaną na Listingu 6. Struktura
inet6_protocol
musi być zarejestrowana za pomocą funkcji
INET6_REGISTER_PROTOSW
.
Najważniejszym składnikiem struktury jest funkcja
handler
, której przekazywana jest
obsługa pakietu.
Listing 6: Struktura Inet6_protocol (include/net/protocol.h)
struct inet6_protocol
{
int (*handler)(struct sk_buff **skb, unsigned int *nhoffp);
void (*err_handler)(struct sk_buff *skb, struct inet6_skb_parm *opt,
int type, int code, int offset, __u32 info);
unsigned int flags; /* INET6_PROTO_xxx */
};
3.5 Gniazdka sieciowe w IPv6
Do przesyłania wiadomości za pomocą protokołu IP wykorzystywane są, w systemie Linux,
gniazdka sieciowe (ang. sockets). Gniazdka sieciowe oferują prosty interfejs, który posiada
m. in. funkcje, które umożliwiają wysłanie i odebranie bufora bajtów. Dla IPv6, podobnie jak
IPv4, występują 3 typy gniazdek sieciowych. Gniazdko strumieniowe (ang. stream) jest
wykorzystuje protokół TCPv6 do transportu wiadomości pomiędzy komputerami. Gniazdko
pakietowe (ang. datagram) wykorzystuje protokół UDPv6 do przesyłania wiadomosci.
Trzecim typem gniazdka jest gniazdko RAW. Jest to gniazdko czyste, które umozliwia
projektowanie własnych protokołów transportowych. Gniazdka sieciowe, podobnie jak
protokoły, są zarejestrowane w rodzine protokołów INET6. Gniazdko musi mieć
zdefiniowaną strukturę
proto_ops
, zawierającą referencje do funkcji, które muszą być
zdefiniowane. Fragment definicji struktury
proto_ops
pokazany jest na Listingu 7. Dla
gniazd strumieniowych zdefiniowana jest struktura pokazana na Listingu 8. Dla gniazd
pakietowych zdefiniowana jest struktura pokazana na Listingu 9.
Listing 7: Struktura proto_ops (include/linux/net.h)
struct proto_ops {
int family;
...
29
int (*sendmsg) (struct kiocb *iocb, struct socket *sock,
struct msghdr *m, int total_len);
int (*recvmsg) (struct kiocb *iocb, struct socket *sock,
...
};
Listing 8: Struktura Inet6_stream_ops (net/ipv6/af_inet6.c)
struct proto_ops inet6_stream_ops = {
.family = PF_INET6,
.release = inet6_release,
.bind = inet6_bind,
.connect = inet_stream_connect, /* ok */
.socketpair = sock_no_socketpair, /* a do nothing */
.accept = inet_accept, /* ok */
.getname = inet6_getname,
.poll = tcp_poll, /* ok */
.ioctl = inet6_ioctl, /* must change */
.listen = inet_listen, /* ok */
.shutdown = inet_shutdown, /* ok */
.setsockopt = inet_setsockopt, /* ok */
.getsockopt = inet_getsockopt, /* ok */
.sendmsg = inet_sendmsg, /* ok */
.recvmsg = inet_recvmsg, /* ok */
.mmap = sock_no_mmap,
.sendpage = tcp_sendpage
};
Listing 9: Struktura Inet6_dgram_ops (net/ipv6/af_inet6.c)
Struct proto_ops inet6_dgram_ops = {
.family = PF_INET6,
.release = inet6_release,
.bind = inet6_bind,
.connect = inet_dgram_connect, /* ok */
.socketpair = sock_no_socketpair, /* a do nothing */
.accept = sock_no_accept, /* a do nothing */
.getname = inet6_getname,
30
.poll = datagram_poll, /* ok */
.ioctl = inet6_ioctl, /* must change */
.listen = sock_no_listen, /* ok */
.shutdown = inet_shutdown, /* ok */
.setsockopt = inet_setsockopt, /* ok */
.getsockopt = inet_getsockopt, /* ok */
.sendmsg = inet_sendmsg, /* ok */
.recvmsg = inet_recvmsg, /* ok */
.mmap = sock_no_mmap,
.sendpage = sock_no_sendpage,
};
31
4. Przegląd możliwych implementacji programu.
Rozdział ten prezentuje cztery zaproponowane sposoby napisania programu, który wysyła
i odbiera wiadomości za pomocą nagłówków hop-by-hop protokołu IPv6. Przedstawione
sposoby były albo przetestowane w ramach pracy albo, jak zaczepy najprawdopodobniej
użyte w projekcie EFIPSANS[19, rozdział 4 WARF], co wynika z analizy fragmentu wstępnej
wersji kodu źródłowego programu, dołączonej do Załącznika B. Przedstawiono dwa sposoby
implementacji w jądrze systemu Linux oraz dwa sposoby implementacji w przestrzeni
użytkownika. W podsumowaniu przedstawiono porównanie przedstawionych możliwości
wskazując ich wady i zalety. Pierwszy z przedstawionych typów implementacji (rozdział 4.1)
zrealizowano w jądrze systemu Linux o numerze 2.6.X. Realizacja opisana w rozdziałach 4.3
i 4.4 została wykonana dla systemu pracującego z jądrem o numerze 2.6.37. Kod
wykorzystujący zaczepy, przedstawiony w rodziale 4.2, nie był wykonany samodzielnie, ale
przeznaczony był także dla jąder z rodziny 2.6.
32
4.1 Implementacja w jądrze
Jedną z możliwych implementacji warstwy transportowej wykorzystującej nagłówki hop-by-
hop protkołu IPv6 jest umieszczenie jej w jądrze. Taki typ implementacji został wykonany
w ramach studium wykonalności aplikacji. Zrealizowana implementacja zostanie omówiona.
Zmiana w kodzie jądra po stronie komputera wysyłającego wiadomość została wykonana
w pliku
net/ipv6/ip6_output.c
w funkcji:
ip6_xmit()
. Polega na uzupełnieniu struktury
zawierającej dane, które należy umieścić w nagłówkach rozszerzających. Struktury, które
zostały utworzone w przedstawionym fragmencie to:
•
ipv6_txoptions - struktura z zawartością nagłówków rozszerzających
•
hopopt - zawartość nagłówka typu hop-by-hop
Na obie struktury alokowana jest pamięć poleceniem
kmalloc()
. Dla struktury hopopt
zarezerwowano 16 bajtów. W przedstawionym fragmencie kodu wypełniono zawartość
nagłówka hop-by-hop, bez dwóch pierwszych bajtów, czyli pól Next Header i Hdr Ext Len.
Pola te są wypełniane automatycznie przez funkcje jądra w zależności od długości nagłówka
hop-by-hop i protokołu wyższej warstwy, czyli na przykład TCP lub UDP. W przedstawionym
fragmencie zawartość nagłówka hop-by-hop stanowi jedna opcja zakodowana w formacie
TLV. Jej numer, pole Option Type, ustawiony jest na arbitralnie dobraną wartość 6. Długość
zawartości opcji, czyli pole Opt Data Len ma wartość 12. Wartość 12 jest to długość bez pól
Option Type i Opt Data Len. Zawartość opcji, czyli pole Option Data wypełnione jest 4
znakami tworzącymi napis test. Pozostałe 8 znaków ma losową zawartość. Po wypełnieniu
danymi wskaźnik do struktury
hopopt
jest ustawiany jako atrybut
hopopt
w strukturze
ipv6_txoptions
.
Listing 10: Uzupełnianie strukty ipv6_txoptions
printk(KERN_INFO "build_hop_opt()\n");
hopopt = kmalloc(16,GFP_ATOMIC);
hopopt->nexthdr = NEXTHDR_TCP;
hopopt->hdrlen = 1; //bo 1*8 oktetow bez pierwszych 8 oktetow, czyli 64
len=hopopt->hdrlen;
printk(KERN_INFO "hopopt->hdrlen %d\n",len);
ptr=hopopt;
33
/* zapisz tekst w kolejnych bajtach
*/
strcpy(s,"test");
printk(KERN_INFO "string: %s \n",s);
ptr[2]=6; // Option Type
ptr[3]=12; // Opt Data Length
for(i=4,k=0;i<8;i++,k++)
{
ptr[i]=s[k];
}
for(i=4;i<8;i++)
{
printk(KERN_INFO "value: %c\n",ptr[i]);
}
tx = kmalloc(sizeof(struct ipv6_txoptions),GFP_ATOMIC);
printk(KERN_INFO "sizeof(struct ipv6_txoptions) %u\n", sizeof(struct
ipv6_txoptions));
tx->tot_len=(int) sizeof(struct ipv6_txoptions);
tx->opt_nflen=16; //liczba bajtow zajetych przez naglowki hop-by-hop,
source routing destination options
tx->opt_flen=0; //liczba bajtow zajetych przez naglowek destination
options
tx->hopopt= hopopt;
//ipv6_hopopt_hdr null_opt_hdr;
tx->dst0opt=NULL;
tx->srcrt=NULL;
tx->dst1opt=NULL;
/*koniec tworzenia*/
opt_save=opt; //zapamietaj miejsce w pamieci
34
opt=tx; //wskaz na utworzona strukture
Zmiana w kodzie jądra po stronie komputera odbierającego wiadomość z nagłówka hop-by-
hop została wykonana w plikach:
include/net/ipv6.h
,
net/ipv6/sysctl_net_ipv6.c
i
net/ipv6/exthdrs.c
. Dane są odczytywane z nagłówka hop-by-hop i zapisywane do
zmiennej w przestrzeni jądra, której wartość można odczytać z pliku znajdującego się na
dysku. Mechanizm zapisu i odczytu zmiennych do pliku na dysku jest standardowym
mechanizmem używanym do sterowania pracą jądra i modułów. Fragment z pliku
net/ipv6/sysctl_net_ipv6.c
, w którym zdefiniowana jest nowa zmienna przedstawiono
na Listingu 11. Zdefiniowano dwie zmienne typu znakowego o długości 128 znaków. Po
zdefiniowaniu dwóch zmiennych, struktura z tymi zmiennymi musi być zarejestrowana
z użyciem funkcji
register_sysctl_table().
Listing 11: Rejestracja nowej zmiennej w przestrzeni jądra
static int busy_ontime = 0; /*zmienna nie wykorzystywana*/
static struct ctl_table_header *ip6_header;
/*zmienne systemowe, ktore zostana podpiete do struktury ctl_table*/
char ipv6_exthdrs_my_hopbyhop_buf[128];
char ipv6_exthdrs_my_hopbyhop_buf_rec[128];
/*definicja dwoch zmiennych systemowych typu bufor znakow char
static ctl_table my_hopbyhop_table[] = {
/*zmienna zapasowa, nie wykorzystywana*/
{
.ctl_name = CTL_UNNUMBERED,
.procname = "exthdrs_my_hopbyhop_buf",
.data = ipv6_exthdrs_my_hopbyhop_buf,
.maxlen = sizeof(char) * 128,
.mode = 0666,
.proc_handler = proc_dostring,
},
/*zmienna wykorzystywana*/
{
.ctl_name = CTL_UNNUMBERED,
.procname = "exthdrs_my_hopbyhop_buf_rec",
.data = ipv6_exthdrs_my_hopbyhop_buf_rec,
35
.maxlen = sizeof(char) * 128,
.mode = 0666,
.proc_handler = proc_dostring,
},
{}
};
/*glowna struktura zdefiniowanej zmiennej systemowej*/
static struct ctl_table my_hopbyhop_root_table[] = {
{
.ctl_name = CTL_UNNUMBERED,
.procname = "my_hopbyhop", /*nazwa funkcji*/
.maxlen = 0,
.mode = 0555,
.child = my_hopbyhop_table, /*odnosnik do struktury definiujacej zmienna*/
},
{}
};
[...]
static int ipv6_sysctl_net_init(struct net *net)
{
struct ctl_table *ipv6_table;
struct ctl_table *ipv6_route_table;
struct ctl_table *ipv6_icmp_table;
int err;
// my_hopbyhop
printk(KERN_INFO "Ladowanie rozszerzenia sysctl my_hopbyhop\n");
ip6_header
=
register_sysctl_table(my_hopbyhop_root_table);
//zarejestruj strukture definiujace nowa zmienna systemowa
[...]
Po zarejestrowaniu zmiennej w jądrze jest ona dostępna zarówno przez plik, a także
z poziomu jądra. Na Listingu 12 przedstawiono fragment zmodyfikowanego pliku
net/ipv6/exthdrs.c
, w którym funkcja
ipv6_my_hopbyhop()
odczytuje zawartość
nagłówka hop-by-hop i kopiuje ją do zmiennej
ipv6_exthdrs_my_hopbyhop_buf_rec
.
Użycie tej metody występuje w funkcji
ip6_parse_tlv()
w pliku
net/ipv6/exthdrs.c
,
która jest uruchamiana, jeżeli jądro znajdzie nagłówek hop-by-hop z opcjami zakodowanymi
w formacie TLV.
36
Listing 12: Odczytanie nagłówka hop-by-hop
/* Parse tlv encoded option header (hop-by-hop or destination) */
/* oryginalna funkcja z jądra */
static int ip6_parse_tlv(struct tlvtype_proc *procs, struct sk_buff *skb)
{
struct tlvtype_proc *curr;
const unsigned char *nh = skb_network_header(skb);
int off = skb_network_header_len(skb);
int len = (skb_transport_header(skb)[1] + 1) << 3;
printk(KERN_INFO "funkcja ip6_parse_tlv");
if (skb_transport_offset(skb) + len > skb_headlen(skb))
goto bad;
off += 2;
len -= 2;
while (len > 0) {
int optlen = nh[off + 1] + 2;
ipv6_my_hopbyhop(nh,off);
[...]
/* funkcja uruchamiana w funkcji ip6_parse_tlv dla parsowanej zawartosci
naglowka hop-by-hop */
int ipv6_my_hopbyhop(unsigned char *nh, int optoff)
{
int i;
int opttype = nh[optoff];
int optlen = nh[optoff + 1] + 2;
printk(KERN_INFO "funkcja ip6_efip");
/* przekopiuj zawartosc naglowka hop-by-hop do zmiennej */
for(i=0;i<optlen;i++)
{
printk(KERN_INFO "bufor, %d char: %c \n",i,nh[optoff+i]);
if(i>1){
printk(KERN_INFO "i: %d",i-2);
ipv6_exthdrs_efipsans_buf_rec[i-2]=nh[optoff+i];
}
}
printk(KERN_INFO "dopisanie 0");
printk(KERN_INFO "i: %d",i-2);
37
ipv6_exthdrs_my_hopbyhop_buf_rec[i-2]=0;
/* wypisz zawartosc zmiennej */
for(i=0;i<optlen-1;i++)
{
printk(KERN_INFO "my_hopbyhop_buf_rec,int: %d char: %c
\n",ipv6_exthdrs_my_hopbyhop_buf_rec[i]);
}
return 0;
}
Przedstawiona implementacja w plikach jądra została zrealizowana i przetestowana. Udało się
wysłać wybrany ciąg znaków z jednego komputera i odebrać go na drugim komputerze,
odczytując go z pliku na dysku.
4.2 Implementacja z wykorzystaniem zaczepów
Kolejną z możliwych implementacji warstwy transportowej wykorzystującej nagłówki hop-
by-hop protokołu IPv6 jest umieszczenie jej w jądrze i wykorzystanie makrodefinicji
tworzącej zaczep - NF_HOOK. Taki typ implementacji został najprawdopodobniej użyty w
projekcie EFIPSANS, którego kod źródłowy we wczesnej wersji o numerze 0.1 był
przeglądany.
Zaczep (ang. hook) to miejsce w jądrze, w którym pakiet może być przekazany do
zarejestrowanej funkcji. Może to być moduł, który weryfikuje lub modyfikuje pakiet. Funkcja
podejmuje decyzję, czy pakiet ma być dalej przetwarzany w jądrze, czy będzie skasowany.
38
Rys. 16: Zaczepy
Na Rys. 16 przedstawiono schemat przetwarzania pakietu w jądrze systemu Linux,
z zaznaczonymi miejscami, w których można zarejestrować zaczepy:
•
NF_INET_PRE_ROUTING – gdy pakiet zostanie odebrany przez kartę sieciową i nie
ma jeszcze decyzji co do jego dalszego routingu: czy będzie on przekazywany do
innego komputera, czy też jest adresowany do gniazdka sieciowego na komputerze,
w którym jest przetwarzany
•
NF_INET_FORWARD – gdy pakiet został odebrany przez kartę sieciową i podjęto
decyzję, że pakiet będzie przekazany do innego komputera; pakiet jest kierowany na
wybrany interfejs wyjściowy
•
NF_INET_POST_ROUTING – gdy pakiet został wysłany do karty sieciowej w celu
wysłania do innego komputera
•
NF_INET_LOCAL_IN – gdy pakiet został przetworzony przez warstwę IP i jest
przekazywany wyższej warstwie, gdyż jest adresowany do gniazdka sieciowego na
komputerze, w którym jest przetwarzany
•
NF_INET_LOCAL_OUT – gdy pakiet został przekazany przez aplikację kliencką do
warstwy IP, w celu wysłania na wybrany adres IP
39
Urz ądzenie sieciowe
Routing
NF_INET_PRE_ROUTING
NF_INET_FORWARD
NF_INET_LOCAL_IN
NF_INET_LOCAL_OUT
NF_INET_POST_ROUTING
Urządz enie sieciowe
Routing
Wyższ e warstwy sieciowe
Pakiety przekazywane dalej
Pakiety adresowane do komputera
Pakiety wysyłane z komputera
Na Listingu 13 przedstawiono fragmenty z pliku
net/ipv6/ip6_output.c
z jądra o numerze
2.6.37. W pliku tym występuje uruchomienie niektórych z omówionych makrodefinicji
NF_HOOK.
Listing 13: Fragmenty jądra, w których zarejestrowano zaczepy. Plik net/ipv6/ip6_output.c
static int ip6_finish_output2(struct sk_buff *skb)
{
[...]
if (newskb)
NF_HOOK(NFPROTO_IPV6, NF_INET_POST_ROUTING,newskb, NULL, newskb-
>dev,ip6_dev_loopback_xmit);
[...]
int ip6_output(struct sk_buff *skb)
{
[...]
return NF_HOOK_COND(NFPROTO_IPV6, NF_INET_POST_ROUTING, skb, NULL,
dev,ip6_finish_output,!(IP6CB(skb)->flags & IP6SKB_REROUTED));
[...]
int ip6_xmit(struct sock *sk, struct sk_buff *skb, struct flowi *fl,struct
ipv6_txoptions *opt)
{
[...]
return NF_HOOK(NFPROTO_IPV6, NF_INET_LOCAL_OUT, skb, NULL,dst->dev,
dst_output);
[...]
int ip6_forward(struct sk_buff *skb)
{
[...]
return NF_HOOK(NFPROTO_IPV6, NF_INET_FORWARD, skb, skb->dev, dst-
>dev,ip6_forward_finish);
Na kolejnym Listingu 14 przedstawiono fragmenty z pliku
net/ipv6/ip6_input.c
. W pliku
tym występują kolejne uruchomienia makrodefinicji NF_HOOK. Występują tu symbole
zaczepów NF_INET_PRE_ROUTING i NF_INET_LOCAL_IN. Są to brakujące dwa miejsca
widoczne na Rys. 16, które nie występują w pliku
net/ipv6/ip6_output.c
.
Listing 14: Fragmenty jądra, w których zarejestrowano zaczepy. Plik net/ipv6/ip6_input.c
net/ipv6/ip6_input.c
int ipv6_rcv(struct sk_buff *skb, struct net_device *dev, struct
40
packet_type *pt, struct net_device *orig_dev)
{
[...]
return NF_HOOK(NFPROTO_IPV6,NF_INET_PRE_ROUTING,skb,dev,NULL,
ip6_rcv_finish);
[...]
}
int ip6_input(struct sk_buff *skb)
{
[...]
return NF_HOOK(NFPROTO_IPV6,NF_INET_LOCAL_IN,skb,skb->dev,NULL,
ip6_input_finish);
[...]
}
W momencie uruchomienia makra NF_HOOK sprawdzane jest, czy nie są zarejestrowane
funkcje, które chcą przejąć i przetworzyć pakiet. Jeżeli nie ma żadnej w danym zaczepie lub
wszystkie zwrócą wartość NF_ACCEPT, wykonywana jest funkcja podana jako ostatni
parametr makra, czyli np.
ip6_rcv_finish()
czy
ip6_input_finish()
.
W celu zarejestrowania funkcji, która przejmie przetwarzanie pakietu, należy zdefiniować
strukturę
nf_hook_ops
, pokazaną na Listingu 15. Funkcja ta jest wskazywana przez argument
hook
. Atrybut
hooknum
jest wybranym zaczepem, określającym miejsce w którym pakiet
zostanie przekazany funkcji. Kolejny atrybut
pf
jest typem protokołu, dla którego zaczep
będzie uruchamiany. Może to być protkół IPv4 lub IPv6. Ostatnim atrybutem struktury jest
priorytet, który określa, w jakiej kolejności zarejestrowane w tym samym zaczepie funkcje
będą wykonywane.
W dalszym fragmencie Listingu 15 przedstawiono przykładowy kod definiujący strukturę
nf_hook_ops
. Funkcja, która będzie uruchamiana to
hook_fun()
. Pakiety protokołu IPv6
będa przekazywane tej funkcji. Moment, w którym funkcja będzie uruchamiana to miejsce
w kodzie tuż przed przekazaniem pakietu do urządzenia sieciowego, czyli
NF_IP_POST_ROUTING. Priorytet tej funkcji jest utawiony na najwyższy. Na Listingu 15
przedstawiono też zarejestrowanie i wyrejestrowanie struktury
nf_hook_ops
.
Listing 15: Użycie zaczepów. Przykład
static struct nf_hook_ops nfho = {
41
.hook = hook_func,
.hooknum = NF_IP_PRE_ROUTING,
.pf = NFPROTO_IPV4,
.priority = NF_IP_PRI_FIRST,
};
static struct nf_hook_ops netfnetfer_ops_in;
netfilter_ops_in.hook = hook_fun;
netfilter_ops_in.pf = PF_INET6;
netfilter_ops_in.hooknum = NF_IP_POST_ROUTING;
netfilter_ops_in.priority = NF_IP_PRI_FIRST;
nf_register_hook(&netfilter_ops_in);
nf_unregister_hook(&netfilter_ops_in);
Każda funkcja przetwarzającej pakiety i zarejestrowana jako zaczep zwraca informację,
ukrytą pod symbolicznymi nazwami, co zrobić z pakietem:
•
NF_ACCEPT – pakiet ma być dalej przetwarzany przez jądro
•
NF_DROP – pakiet powinien zostać skasowany przez jądro
•
NF_REPEAT – pakiet powinien zostać ponownie przekazany funkcji, która go przed
chwilą przetworzyła
•
NF_STOLEN – pakiet powinien zostać skasowany przez jądro
•
NF_QUEUE – pakiet powinien zostać przekazany do przestrzeni użytkownika
Jeżeli funkcja ma za zadanie filtrować pakiety, będzie zwracała wartość NF_ACCEPT, gdy
pakiet nie ma być skasowany lub NF_DROP, gdy pakiet ma zostać skasowany. Jeżeli funkcja
modyfikuje pakiet, będzie zwracać wartość NF_ACCEPT, a w ciele funkcji będzie
wykonywana modyfikacja bufora, który reprezentuje pakiet.
Implementacja warstwy tranportowej w nagłówkach hop-by-hop protokołu IPv6 przy
wykorzystaniu zaczepów została wykonana w ramach europejskiego projektu EFIPSANS
[12, rozdział 4 WARF]. Zaproponowano dwa zastosowania takiego sposobu przesyłania
wiadomości. Pierwsze to routing wielościeżkowy, a drugi to autokonfiguracja kanałów
radiowych (skrót i nazwa WARF). Routing wielościeżkowy ma polegać na dynamicznym
kierowaniu ruchem, na podstawie chwilowej wiedzy o obciążeniu różnych ścieżek routingu,
prowadzących do sieci Internet. W projekcie WARF zaproponowano wymianę chwilowych
42
danych o parametrach fizycznych kanałów radiowych, dla komputerów kontaktujących się
między sobą za pomocą interfejsów radiowych. Na podstawie aktualnych, chwilowych
danych o stosunku sygnału do szumu, karty sieciowe mogą sterować parametrami pracy,
w celu podniesienia jakości i wydajności połączenia radiowego.
4.3 Implementacja w przestrzeni użytkownika
.
Pakiety w systemie Linux mogą być filtrowane i modyfikowane nie tylko w jądrze [5]. Są
dostępne specjalne funkcjonalności, które umożliwiają przekazanie pakietu z przestrzeni jądra
do przestrzeni użytkownika i wykonanie na nim operacji. Funkcjonalności te wykorzystują
część jądra o nazwie Netfilter [14].
Filtrowanie pakietów, tak aby zostały przekazane do przestrzeni użytkownika jest
wykonywane poleceniem iptables dla protokołu IP lub ip6tables dla protkołu IPv6. Na
Listingu 16 przedstawiono przykładowe polecenie, które przekazuje pakiety wychodzące
z komputera do kolejki o numerze 1. W przestrzeni użytkownika należy uruchomić proces,
który będzie oczekiwał na pakiety z tej kolejki. Funkcja, która otrzyma pakiet, będzie mogła
go zmodyfikować lub nie i przekazać do jądra informację zwrotną, czy pakiet ma zostać
skasowany, czy dalej przetwarzany.
Ograniczeniem polecenia ip6tables w porównaniu z mechanizmem zaczepów jest możliwość
wyboru jedynie trzech miejsc przechwycenia pakietu. Są to miejsca o nazwach INPUT,
OUTPUT i FORWARD. Tym trzem miejscom odpowiadają miejsca, zdefiniowane przy
mechanizmie zaczepów o nazwach NF_INET_LOCAL_IN, NF_INET_LOCAL_OUT
i NF_INET_FORWARD. Oznacza to, że nie można przekazać pakietów do kolejki
w przestrzeni
użytkownika
w
miejscach
NF_INET_PRE_ROUTING
i NF_INET_POST_ROUTING.
Listing 16: Stworzenie filtra pakietów. Polecenie ip6tables. Przykład 1
ip6tables -A OUTPUT -d "fec0::1:2/64" -j NFQUEUE --queue-num 0
Biblioteką oferującą możliwość przetwarzania pakietów w przestrzeni użytkownika jest
libnetfilter_queue [5]. Jest ona częścią projektu, w ramach którego rozwijane jest polecenie
iptables. Jest przeznaczona dla programów napisanych w języku C++. Na Listingu 17
przedstawiono fragment kodu programu napisanego w C++, który odbiera pakiet z kolejki
NFQUEUE o numerze 0 i przekazuje go do funkcji
cb
. W funkcji tej pakiet jest przetwarzany,
43
może być zmieniona jego zawartość i jest ponownie odsyłany do przestrzeni jądra za pomocą
funkcji
nfq_set_verdict
, która jako parametr otrzymuje bufor zawierający zmodyfikowany
pakiet i wartość NF_ACCEPT, oznaczającą że pakiet ma być dalej przetwarzany.
Listing 17: Przetwarzanie pakietów w przestrzeni użytkownika. Język C++
#include <linux/netfilter.h>
/* for NF_ACCEPT */
#include <libnetfilter_queue/libnetfilter_queue.h>
int main(int argc, char **argv)
{
struct nfq_handle *h;
struct nfq_q_handle *qh;
struct nfnl_handle *nh;
int fd;
int rv;
char buf[4096] __attribute__ ((aligned));
printf("opening library handle\n");
h = nfq_open();
if (!h) {
fprintf(stderr, "error during nfq_open()\n");
exit(1);
}
printf("binding nfnetlink_queue as nf_queue handler for AF_INET\n");
if (nfq_bind_pf(h, AF_INET6) < 0) {
fprintf(stderr, "error during nfq_bind_pf()\n");
exit(1);
}
printf("binding this socket to queue '0'\n");
qh = nfq_create_queue(h, 0, &cb, NULL);
if (!qh) {
fprintf(stderr, "error during nfq_create_queue()\n");
exit(1);
}
44
printf("setting copy_packet mode\n");
if (nfq_set_mode(qh, NFQNL_COPY_PACKET, 0xffff) < 0) {
fprintf(stderr, "can't set packet_copy mode\n");
exit(1);
}
[...]
static int cb(struct nfq_q_handle *qh, struct nfgenmsg *nfmsg,
struct nfq_data *nfa, void *data)
{
[...]
printf("Sending buffer copied from original and with modified
payload, size %d\n",new_ip_total_length);
//printf("Sending original buffer\n");
return_value
=
nfq_set_verdict(qh,
id,
NF_ACCEPT,
new_ip_total_length, new_buffer);
return return_value;
}
W ramach niniejszej pracy stworzono prosty program, dołączający do wiadomości
wychodzących nagłówek hop-by-hop przy użyciu biblioteki libnetfilter_queue oraz
odczytujący zawartość nagłówka hop-by-hop w wiadomościach przychodzących. Kod
źródłowy programu został załączony do pracy. Odnośnik do niego znajduje się w Załączniku
D.
Biblioteka libnetfilter_queue ma dopisany interfejs, który umożliwia wykorzystanie jej
funkcjonalności przy użyciu języka Python [6]. Funkcjonalność ta zawarta jest w bibliotece
nfqueue-bindings. Interfejs biblioteki nfqueue-bindings w języku Python jest bardzo podobny
do interfejsu biblioteki libnetfilter_queue dla języka C++. Tak samo jak w przypadku
implementacji w języku C++ trzeba za pomocą polecenia ip6tables przekierować pakiety do
kolejki NFQUEUE, co pokazane jest na Listingu 18.
Listing 18: Utworzenie filtra pakietów. Polecenie ip6tables. Przykład 2
ip6tables -A OUTPUT -d "fec0::1:2/64" -j NFQUEUE --queue-num 1
45
Fragment implementacji, która odbiera pakiety IPv6 z kolejki NFQUEUE o numerze 1
i przekazuje pakiet do przetworzenia w funkcji o nazwie
cb
przedstawiono na Listingu 19.
Listing 19: Przetwarzanie pakietów w przestrzeni użytkownika. Język Python
q1 = nfqueue.queue(1)
q1.open()
q1.unbind(AF_INET6)
q1.bind(AF_INET6);
q1.set_callback(cb)
print "creating queue"
q1.create_queue(1)
q1.set_queue_maxlen(5000)
try:
q1.try_run()
except KeyboardInterrupt, e:
print "interrupted"
q1.unbind(AF_INET6)
q1.close()
Na Listingu 20 pokazano strukturę funkcji
cb
, w której przetwarzany jest pakiet. Pakiet jest
reprezentowany jako ciąg znaków, tworzących obiekt typu string. Każdy znak reprezentuje
jeden bajt pakietu. Analogicznie do implementacji w języku C++ w ciele funkcji musi
wystąpić wywołanie funkcji, która zwraca ponownie do jądra zmodyfikowany lub oryginalny
pakiet z symboliczną wartością, decydującą o dalszym przetwarzaniu.. Znacznik
NF_ACCEPT oznacza, że pakiet ma być dalej obsługiwany przez jądro.
46
Listing 20: Funkcja przetwarzająca pakiety. Język Python
#uruchamiana funkcja
def cb(i,payload):
data = payload.get_data()
#modyfikacja bajtów pakietu ip
[...]
ret
=
payload.set_verdict_modified(nfqueue.NF_ACCEPT,new_payload,len(new_payload
)) # pakiet ze zmieniona dlugoscia
return 1
4.4
Podsumowanie
Przedstawiono 4 możliwe rodzaje implementacji dodawania i odczytywania nagłówków hop-
by-hop. Dwa pierwsze sposoby są realizowane w przestrzeni jądra, jako modyfikacja
istniejących fragmentów jądra lub jako oddzielne moduły. Pierwszy rodzaj implementacji
polega na zmodyfikowaniu plików, w których przetwarzane są pakiety przechodzące przez
jądro. Taki sposób implementacji umożliwia przechwycenie i przetwarzanie pakietu
w dowolnym momencie, podczas przetwarzania go przez protkół IPv6. Rozwiązanie to choć
bardzo elastyczne, jest też najbardziej ryzykowne, gdyż trzeba uważać, żeby nie zepsuć
implementacji protokołu IPv6.
Drugi sposób jest również realizowany w przestrzeni jądra, ale z wykorzystaniem
funkcjonalności zaczepów (HOOKS), która umożliwia rejestrowanie funkcji, które przejmą
przetwarzanie pakietu w wybranych miejscach w jądrze. W jądrze jest zdefiniowanych
5 miejsc, w których pakiet może być przekazany do funkcji zarejestrowanej
z wykorzystaniem mechanizmu zaczepów. Jest to ograniczenie w stosunku do implementacji
bezpośrednio w plikach jądra. Ma to jednak taką zaletę, że implementację tworzy się
w oddzielnym module, który nie modyfikuje bezpośrednio protkołu IPv6 w jądrze.
Sposób trzeci i czwarty jest realizowany w przestrzeni użytkownika. Sposób trzeci
wykorzystuje bibliotekę libnetfilter_queue, która umożliwia przetwarzanie pakietu
w przestrzeni użytkownika. Ograniczeniem w stosunku do mechanizmu zaczepów jest
wolniejsze działanie, gdyż trzeba przekazać pakiet do przestrzeni użytkownika i potem
47
z powrotem do jądra, oraz ograniczenie do tylko trzech miejsc, z których pakiet może być
przekazany do przetworzenia. Zaletą tego typu rozwiązania jest implementacja w języku C++
i brak ingerencji w jądro. Nie jest też konieczne pisanie modułów do jądra. Implementacja
w przestrzeni użytkownika jest prostsza i szybsza.
Czwarty sposób implementacji jest bardzo podobny do trzeciego. Różni się językiem
programowania. Wykorzystuje bibliotekę nfqueue-bindings, która umożliwia korzystanie
z biblioteki libnetfiletr_queue, z poziomu języka Python. Upraszacza i przyspiesza to
implementację w stosunku do implementacji w języku C++. Jednak wykonanie takiego
programu będzie wolniejsze, gdyż język Python jest językiem interpretowalnym. W Tab. 5
zestawiono razem główne cechy, czterech przedstawionych sposobów implementacji
programu.
Tab. 5: Porównanie cech sposobó implementacji.
sposób implementacji
pliki jądra jądro-
nf_hooks
libnetfilter
_queue
nfqueue-
bindings
cechy
szybkość pisania programu
mała
średnia
duża
bardzo
duża
negatywne skutki błędów w implementacji
bardzo
duże
duże
małe
małe
wydajność gotowego rozwiązania
bardzo
duża
duża
średnia
średnia/
mała
48
5. Środowisko stworzone do testownia wykorzystania nagłówka hop-by-hop,
jako kanału komunikacyjnego
Rozdział zawiera opis implementacji środowiska, stworzonego w celu przetestowania kanału
transportowego, opartego na nagłówkach hop-by-hop, protokołu IPv6. Docelowe miejsce
wykorzytania proponowanego sposobu komunikacji, to bezprzewodowe sieci kratowe (ad-
hoc), w których pożądanymi cechami jest oszczędność pasma transmisyjnego i odpowiednia
wydajność. Program wykonano w systmie Linux, w przestrzeni użytkownika, w języku
Python. Aplikacja umożliwia mierzenie ważnych z punktu widzenia komunikacji cech, takich
jak opóźnienie w przesyłaniu wiadomości pomiędzy komputerami i wydajność. Dla
porównania komunikacji opartej o nagłówek hop-by-hop, warstwa transportowa umożliwia
też wykorzystanie pakietów UDP do przesyłania wiadomości.
49
5.1 Wstęp do funkcjonalności stworzonego środowiska testowego.
Wytworzone i skonfigurowane środowisko testowe (Rys. 24) podzielone jest na dwie
warstwy: warstwę transportową, umożliwiającą komunikację między komputerami i program
klienta, wykorzystującego jej interfejs. Razem tworzą aplikację, która umożliwia testowanie
przesyłania różnych sekwencji wiadomości, między dwoma komputerami, z wykorzystaniem
nagłówka hop-by-hop. Charakterystyka czasowa strumienia przesyłanych danych ma
symulować przesyłanie różnego typu ruchu, który może być potencjalnie transportowany.
Manipulowanie charakterystyką czasową strumienia ma na celu zbadanie wydajności,
pewności dostarczenia i opóźnienie jakie charakteryzuje stworzony kanał transmisyjny.
W celu porównania ze standardowym mechanizmem wysyłania wiadomości, warstwa
transportowa umożliwia wysyłanie danych w pakietach UDP.
Funkcjonalność zrealizowanej aplikacji można opisać poprzez przypadki użycia.
Zdefiniowano następujące podstawowe przypadki użycia:
1. Przesłanie wiadomości przez warstwę trasportową z priorytetem N
2. Odebranie wiadomości z warstwy transportowej
3. Zmierzenienie opóźnienia warstwy transportowej
4. Przesłanie ruchu o charakterze N przez warstwę transportową
5. Wybór konfigurowalnych parametrów warstwy transportowej
6. Wybór charakteru przesyłanego ruchu w warstwie klienckiej
7. Wybór konfigurowalnych parametrów przesyłanego ruchu w warstwie klienckiej
Opis przypadków użycia:
1. Przesłanie wiadomości przez warstwę trasportową z priorytetem N
Przesłanie wiadomości pomiędzy aplikacjami klienckimi na różnych komputerach
z wykorzystaniem warstwy transportowej znajdującej się na obu komputerach.
Wiadomości są przesyłane w określony sposób, charakterystyczny dla danego
priorytetu ruchu, charakteryzowanych polityką wysyłania. Zdefiniowano 4 polityki:
•
priorytet 1 – pakiet jest doklejany w nagłówku hop-by-hop pakietów IPv6
wychodzących z komputera, dodatkowe pakiety nie są generowane
•
priorytet 2 – co określony okres czasu sprawdzana jest kolejka wiadomości
oczekujących na wysłanie i generowana jest taka liczba dodatkowych pakietów
50
IPv6, do których wiadomości będą mogły być doklejone w nagłówku hop-by-
hop
•
priorytet 3 - dla każdej wiadomości generowany jest dodatkowy pakiet IPv6,
wiadomość jest przesyłana w nagłówku hop-by-hop pakietu
•
priorytet 4 – wiadomość jest przesyłana nie w nagłówku hop-by-hop, ale
w pakiecie UDP za pomocą protokołu IPv6.
Szczegółowy opis dostępnych priorytetów przedstawiony jest w rodziale 4.2.1
2. Odebranie wiadomości z warstwy transportowej
Odebranie przez aplikację kliencką jednej lub wielu wiadomości z warstwy
transportowej.
3. Zmierzenienie opóźnienia warstwy transportowej
Przesłanie jednej lub wielu wiadomości pomiędzy aplikacjami klienckimi
znajdującymi się na różnych komputerach, wykorzystując warstwę transportową,
która przesyła wiadomości w nagłówku hop-by-hop protokołu IPv6. Moment wysłania
i odebrania wiadomości w aplikacjach klienckich jest logowany i umożliwia
obliczenia czasu, jaki upłynął pomiędzy wysłaniem i odebraniem wiadomości.
4. Przesłanie ruchu o charakterze N przez warstwę transportową
Wygenerowanie w aplikacji klienckiej wielu wiadomości, które składają się na ruch
o określonym rozkładzie czasowym. Aplikacja umożliwia generowanie 3 typów
sygnału:
•
constant – o stałych odstępach między wiadomościami
•
random – o losowych odstępach czasu między wiadomościami
•
snmp-like – symulacja komunikacji generowanej przez protokół snmp.
Szczegółowy opis możliwych do wygenerowania typów ruchu jest przedstawiony
w rodziale 5.3.1. Ruch jest przesłany do drugiego komputera za pomocą warstwy
transportowej.
5. Wybór konfigurowalnych parametrów warstwy transportowej
51
Wybranie konfigurowalnych parametrów warstwy transportowej. Wybór dotyczy
priorytetów o numerze 2 i 4. Dla priorytetu 2, wysyłającego wiadomości
z dopuszczalnym maksymalnym opóźnieniem możliwe jest określenie tego
opóźnienia. W przypadku priorytetu 4 można wybrać jaki typ potwierdzenia wysłania
wiadomości będzie wykorzystany. Szczegółowy opis przedstawiony jest w rozdziale
5.2.1. Po wybraniu parametrów danego priorytetu warstwa transportowa jest
testowana przy użyciu aplikacji klienckich. Pomiędzy komputerami przesyłany jest
ruch, składający się z wielu wiadomości.
6. Wybór charakteru przesyłanego ruchu w warstwie klienckiej
Wybranie jednego z 3 typów generowanego sygnału: constant, random, snmp-like. Po
wybraniu jednego z 3 typów sygnału i dowolnego priorytetu jest on wysyłany do
warstwy transportowej.
7. Wybór konfigurowalnych parametrów przesyłanego ruchu w warstwie klienckiej
Wybranie konfigurowalnych parametrów charakteru przesyłanego ruchu w aplikacji
klienckiej i przesłanie go do aplikacji klienckiej na drugim komputerze. Są to dla
poszczególnych sygnałów:
•
constant - odstęp czasu między wiadomościami.
•
random – wartość minimalna i maksymalna między którymi losowany jest
odstęp czasu między wiadomościami
•
snmp-like – wartość minimalna i maksymalna między którymi losowany jest
długi odstęp czasu między wiadomościami, liczba wiadomości w serii, odstęp
czasu między wiadomościami w serii
5.2 Program warstwy transportowej.
Implementację warstwy transportowej zrealizowano wykorzystując czwarty wariant,
z przedstawionych w rozdziale 4, czyli implementację w przestrzeni użytkownika
z wykorzystaniem bibliotek libnetfilter_queue i nfqueue_bindings. W tym wariancie językiem
programowania jest język Python.
52
Warstwa transportowa otrzymuje, z przestrzeni jądra, pakiety IPv6. Do pakietów
wychodzących może dołączyć nagłówek rozszerzający hop-by-hop, a z pakietów
przychodzących, może odczytać zawartość takiego nagłówka. Z warstwą transportową
komunikuje się aplikacja kliencka. Przekazuje wiadomości do wysłania oraz odbiera
wiadomości, które zostały odczytane przez warstwę transportową.
Na Rys. 17 przedstawiono architekturę aplikacji. Przedstawione są dwa komputery, które
mogą komunikować się przy wykorzystaniu warstwy tranportowej. Stworzona aplikacja
składa się z warstwy transportowej i aplikacji klienckiej. Warstwa tranportowa komunikuje
się z przestrzenią jądra, w celu wysłania lub odebrania pakietów. Poszczególne numery
kanałów komunikacyjnych zaznaczone na rysunku mają następujące znaczenie:
•
1, 1' – komunikacja pomiędzy klientem i warstwą transportową zrealizowana poprzez
gniazdko sieciowe; klient przesyła wiadomości do warstwy tranportowej w celu
wysłania ich do drugiego komputera
•
2, 2' – komunikacja pomiędzy warstwą transportową i klientem zrealizowana poprzez
gniazdko sieciowe; warstwa transportowa przesyła klientowi wiadomości, które
zostały odebrane przez warstwę tranportową
•
3, 3' – komunikacja pomiędzy przestrzenią jądra i warstwą transportową zrealizowana
z wykorzystaniem biblioteki nfqueue_bindings; kanałem tym pakiety wychodzące
z komputera są przekazywane do warstwy tranportowej; warstwa tranportowa może
zmodyfikować pakiet dołączając wiadomość w nagłówku hop-by-hop
•
4, 4' – komunikacja pomiędzy przestrzenią jądra i warstwą transportową zrealizowana
z wykorzystaniem biblioteki nfqueue_bindings; kanałem tym pakiety przychodzące
do komputera są przekazywane do warstwy tranportowej; warstwa tranportowa może
odczytać, jeżeli występuje, zawartość nagłówka hop-by-hop pakietu IPv6
•
6 – komunikacja pomiędzy komputerami protokołem IPv6; przesyłane pakiety mogą
zawierać nagłówki hop-by-hop, dołączone przez warstwę transportową
•
5, 5' – bezpośrednia komunikacja pomiędzy warstwami transportowymi
z wykorzystaniem protokołu UDP i protokołu IPv6; tryb bezpośredniej komunikacji
jest dodatkowym trybem, w którym może pracować warstwa transportowa
53
Rys. 17: Architektura aplikacji: warstwa transportowa i aplikacja kliencka
Standardowy scenariusz wykorzystania aplikacji wygląda następująco. Aplikacja kliencka
wysyła wiadomość do warstwy transportowej (1). Warstwa tranportowa może wykorzystać
nagłówki hop-by-hop (3) lub bezpośrednio protokół UDP (5) do przesłania wiadomości do
warstwy transportowej na drugim komputerze (6). Warstwa tranportowa na drugim
komputerze przekazuje odebraną wiadomość do aplikacji klienckiej na tym komputerze
(4' i 2').
5.2.1 Funkcjonalność
Zaimplementowany program warstwy transportowej umożliwia komunikację z klientem, oraz
wysyłanie wiadomości w nagłówkach hop-by-hop, lub bezpośrednio w protokole UDP
w pakietach IPv6. Dla przypadku wysyłania wiadomości w nagłówkach hop-by-hop
zdefiniowano i zrealizowano kilka typów transportu, nazwanych priorytetami. Warstwa
transportowa oferuje 4 typy priorytetów. Każdy z priorytetów charakteryzuje się innymi
parametrami opóźnienia w przesyłaniu wiadomości i wykorzystuje nagłówki rozszerzające
hop-by-hop lub protokół UDPv6. Każdy z priorytetów warstwy transportowej posiada
mechanizm potwierdzenia, że warstwa transportowa przyjęła wiadomość do wysłania. Klient
oczekuje na to potwierdzenie przed przekazaniem kolejnej wiadomości. Warstwa
transportowa, dla poszczególnych priorytetów, w różnym momencie wysyła takie
potwierdzenie. Ma to duży wpływ na możliwy charakter generowanego ruchu przez klienta
jak też na opóźnienie w dostarczeniu wiadomości do odbiorcy.
Priorytet 1
54
klient
warstwa transportowa
jądro (stos IP)
klient
warstwa transportowa
jądro (stos IP)
Komputer 1
Komputer 2
1
2
2'
1'
3
4
5
5'
4'
3'
6
Wykorzystuje przesyłany ruch. Dołącza do niego nagłówki hop-by-hop z wiadomościami do
przesłania.
Warstwa transportowa potwierdza klientowi, że przyjęła wiadomość do wysłania,
w momencie, gdy skopiuje wiadomość do odpowiedniej kolejki.
Priorytet 2
Wykorzystuje przesyłany ruch, ale także generuje dodatkowe pakiety, aby zapewnić
dopuszczalne maksymalne opóźnienie w przesyłaniu wiadomości. Mechanizm został
zaimplementowany tak, że cyklicznie co określony jako parametr okres czasu sprawdzana jest
zawartość kolejki wiadomości oczekujących na wysłanie. Generowanych jest tyle
dodatkowych pakietów, ile wynosi długość kolejki. Szczegółowy opis w jaki sposób ustawić
parametr czasowy maksymalnego opóźnienia, znajduje się w Załączniku A.
Na zbiorczym Rys. 18 dla priorytetów 2, 3 i 4 przedstawiono histogramy opóźnienia warstw
transportowych. Na wykresie „Priorytet 2” pokazano historgramy opóźnienia dla warstwy
transportowej o priorytecie 2. Parametr maksymalnego, dopuszczalnego opóźnienia
ustawiony był na 20 ms. Większość pakietów została dostarczona z opóźnieniem
nieprzekraczającym 30 ms.
Warstwa transportowa potwierdza klientowi, że przyjęła wiadomość do wysłania
w momencie, gdy skopiuje wiadomość do odpowiedniej kolejki.
Priorytet 3
Od razu po odebraniu wiadomości od klienta, generuje dodatkowy pakiet IPv6 na adres
ustawiony jako parametr warstwy transportowej. Ma to zapewnić minimalne opóźnienie
przesyłania wiadomości. Następnie wiadomość jest dołączana do pakietu wychodzącego
w nagłówku hop-by-hop.
Na Rys. 18 na wykresie „Priorytet 3”, przedstawiono histogram opóźnienia warstwy
transportowej dla priorytetu 3. Łącze było nie obciążone. Warstwa transportowa zapewniła
opóźnienie pomiędzy 4 ms i 6 ms dla większości pakietów.
Warstwa transportowa potwierdza klientowi, że przyjęła wiadomość do wysłania
w momencie, gdy wiadomość zostanie dołączona w nagłówku hop-by-hop do pakietu
wychodzącego. Takie rozwiązanie wprowadza możliwe do wystąpienia opóźnienie,
w generowaniu wiadomości przez klienta, ale zapewnia małe opóźnienie w dostarczeniu
wiadomości do odbiorcy.
55
Priorytet 4
Jako jedyny nie wykorzystuje nagłówków hop-by-hop do przesyłania wiadomości.
Wiadomości są przesyłane bezpośrednio w protkole UDP w pakietach IPv6. Ten typ
przesyłania wiadomości współpracuje z mechanizmem kształtowania ruchu, który umożliwia
retransmisję pakietów. Dzięki temu wiadomości nie są tracone, ale wprowadzane jest duże
opóźnienie w sytuacjach, gdy interfejs jest wysycony ruchem. Szczegółowy opis w jaki
sposób ustawić tryb potwierdzenia dla priorytetu 4 znajduje się w Załączniku A.
Na Rys. 18 na wykresie „Priorytet 4”, przedstawiono histogram opóźnienia warstwy
transportowej dla priorytetu 4. Łącze było nieobciążone. Warstwa transportowa zapewniła
opóźnienie pomiędzy 3 ms i 6 ms dla większości pakietów.
Możliwa jest praca w dwóch trybach potwierdzenia klientowi, że wiadomość została przyjęta
do wysłania. W pierwszym z nich warstwa transportowa wysyła wiadomość do odbiorcy.
Odbiorca odsyła potwierdzenie w pakiecie UDP. Dopiero po odebraniu potwierdzenia
warstwa transportowa nadawcy potwierdza przyjęcie wiadomości klientowi warstwy
transportowej. Zaletą takiego rozwiązania jest uniknięcie sytuacji, gdy w warstwie
transportowej odbiorcy nagromadzą się komunikaty do przetworzenia. Wadą jest mniejsza
wydajność w przesyłaniu wiadomości.
W drugim trybie pracy potwierdzenie do klienta o wysłaniu wiadomości jest generowane
w momencie, gdy funkcja
sendto
operująca na gniazdku zakończy swoje działanie. Warstwa
transportowa nie oczekuje na potwierdzenie od warstwy transportowej odbiorcy. Warstwa
transportowa odbiorcy wiadomości nie generuje takiego potwierdzenia. Rozwiązanie to jest
bardziej wydajne, ale może wystąpić problem z przetwarzaniem dużej liczby komunikatów po
stronie odbiorcy, co wprowadzi opóźnienie w dostarczaniu wiadomości do aplikacji klienta na
drugim komputerze.
56
Priorytet 2
Priorytet 3
Priorytet 4
Rys. 18: Przykładowe histogramy opóźnienia dla priorytetów 2, 3, 4.
legenda wykresów: oś pionowa – liczba wiadomości, oś pozioma – opóźnienie dostarczenia
wiadomości [s]
57
5.2.2 Implementacja
Implementacja warstwy transportowej zrealizowana jest w języku Python. Program
komunikuje się z aplikacją kliencką przy wykorzystaniu gniazdek sieciowych, oraz
komunikuje się z przestrzenią jądra z wykorzystaniem biblioteki nfqueue_bindings. Warstwa
transportowa oferuje kilka priorytetów przesyłania ruchu, które działają równolegle.
Stworzona architektura, która umożliwia pracę w wielu trybach jednocześnie, składa się
z wielu wątków i kolejek. Kolejki umożliwiają bezpieczne działanie wsytuacji, w której kilka
wątków pisze do kolejki lub z niej czyta. W kolejnych fragmentach pracy zostanie omówiona
struktura kolejek i wątków tworzących aplikację oraz fragmenty implementacji warstwy
transportowej.
Rys. 19: Warstwa transportowa; Część wysyłająca; Logowanie zdarzeń
Część wysyłająca.
58
Direct Sender
Priority Queue
Generate HopByHop
Socket Server
Delay Queue
Delay Sender
cb_output
klient
Q10
Q9
Q0
Q2
Q3
Q12
Q7
Q4
Q5
Q6
Q11
Q8
p1 p2 p3 p4
p1 p2 p3 p4
p1 p2 p3
p4
p4
p4
p1 p2 p3
p2
p2
p2
p3
p3
p3
p1
p2
p3
p1
p2
p3
p3
server3.txt
server1.txt
server2.txt
server4.txt
server8.txt
Na Rys. 19 przedstawiono strukturę części wysyłającej, aplikacji warstwy transportowej.
Składa sie ona z kilku wątków i kolejek. Elementy diagramu zawierają etykiety priorytetów
(p1, p2, p3, p4). Etykieta oznacza, że dany element aplikacji jest wykorzystywany do
przetwarzania wiadomości o podanym priorytecie.
Opis wątków.
W kolejnych akapitach zostało opisane funkcjonowanie wątków i funkcja
cb_output
, które
tworzą strukturę przetwarzania pakietów o różnych priorytetach z Rys. 19. W dalszej części
będzie jeszcze przedstawiony inny typ opisu programu, polegający na prześledzeniu, w jaki
sposób przetwarzany jest wiadomość o wybranym priorytecie.
Wątek o nazwie SocketServer służy do odbierania wiadomości od klienta i wstawiania jej do
wybranej kolejki w zależności od priorytetu, z jaką wiadomość ma zostać wysłana.
Wiadomości o priorytecie 1 są wstawiane do kolejki Q0. Wiadomości o priorytecie 2 są
wstawiane do kolejki Q2. Wiadomości o priorytecie 3 - do kolejki Q3. Po wstawieniu
wiadomości o priorytecie 3 do kolejki Q3, wątek SocketServer czeka na potwierdzenie
wysłania wiadomości, które jest wstawione do kolejki Q8 przez funkcję, która wstawiła
wiadomość do nagłówka hop-by-hop. Skutkuje to tym, że warstwa transportowa potwierdzi
klientowi, że przyjęła wiadomość o priorytecie 3 do wysłania, dopiero w momencie, gdy
wiadomość zostanie doklejona do pakietu wychodzącego. Wiadomości o priorytecie 4
wstawiane są do kolejki Q9. Dla wiadomości o priorytecie 4 wątek czeka na potwierdzenie,
że wiadomość została wysłana. Potwierdzenie jest wstawione do kolejki numer Q10 przez
wątek DirectSender. Dopiero po odebraniu potwierdzenia, wątek potwierdzi klientowi, że
wiadomość została przyjęta do wysłania i pobierze kolejną wiadomość do wysłania od
klienta.
Wątek GenerateHopByHop pobiera wiadomości z kolejek Q0, Q2 i Q3, konwertuje je na
gotowy nagłówek hop-by-hop i wstawia do kolejek Q5, Q6 lub Q11. Wiadomości pobrane
z kolejki Q0, czyli te o priorytecie 1, są wstawiane po przetworzeniu do kolejki Q6.
Wiadomości pobrane z kolejki Q2, czyli te o priorytecie 2, są wstawiane po przetworzeniu do
kolejki Q11. Wiadomości pobrane z kolejki Q3, czyli te o priorytecie 3, są wstawiane po
przetworzeniu do kolejki Q5. Dodatkowo dla tego priorytetu wątek wstawia symboliczną
wiadomość do kolejki Q4. Jest to informacja dla wątku PriorityQueue, żeby wygenerować
dodatkowy pakiet IPv6, do którego zostanie dołączona wiadomość właśnie wstawiona do
kolejki Q5.
59
Kolejnym ważnym fragmentem implementacji jest funkcja
cb_output
, która jest
wywoływana asynchronicznie, dla każdego pakietu wychodzącego spełniającego regułę,
utworzoną przez polecenie ip6tables. Argument funkcji
cb_output
jest buforem,
zawierającym pakiet IPv6. Algorytm dołączania wiadomości do pakietu jest następujący.
Sprawdzane jest, czy jest wiadomość w kolejkace Q5, czyli o priorytecie 3. Jeżeli kolejka jest
pusta, sprawdzane jest, czy nie ma wiadomości o priorytecie 2 w kolejce Q11. Jeżeli kolejka
Q11 jest pusta, sprawdzana jest jeszcze kolejka Q6, która zawiera wiadomości o priorytecie 1.
Dzięki temu wprowadzono zasadę, że wiadomości o wyższym priorytecie są najpierw
wysłane w nagłówku rozszerzającym. Pobrany z kolejki Q5, Q6 lub Q11 nagłówek hop-by-
hop, zawierający wiadomość odebraną od klienta, jest dołączany do nagłówka IPv6. Pakiet po
przetworzeniu jest przekazywany do jądra systemu, w celu wysłania go przez interfejs
sieciowy komputera. Jeżeli doklejono wiadomość z kolejki Q5, czyli o priorytecie 3,
wstawiana jest do kolejki Q7 i Q8 wiadomość, będąca symbolicznym potwierdzeniem
wysłania.
Wątek PriorityQueue pobiera symboliczne wiadomości z kolejki Q4. Każda wiadomość jest
informacją, że przyjęto do wysłania wiadomość o priorytecie 3. Generowany jest dodatkowy
pakiet do którego może być doklejony nagłówek hop-by-hop z wiadomością oczekującą na
wysłanie w funkcji
cb_output
.
Wątek Delay Queue co określony odstęp czasu sprawdza długość kolejki Q11. Długość tej
kolejki jest liczbą wiadomości o priorytecie 2, które oczekują na wysłanie. Tę wartość wątek
wstawia do kolejki Q12.
Wątek DelaySender z kolejki Q12 pobiera wstawioną wartość i generuje taką liczbę
dodatkowych pakietów. W ten sposób zapewniona jest cecha priorytetu 2, czyli
gwarantowanie maksymalnego dopuszczalnego opóźnienia wysłania wiadomości.
Wątek DirectSender pobiera wiadomości o priorytecie 4 z kolejki Q9. Wątek ten wysyła
wiadomość do warstwy transportowej na drugim komputerze w pakiecie UDP protokołem
IPv6. Priorytet 4 może pracować w dwóch trybach potwierdzenia wysłania. Tryb pracy musi
być zgodnie ustawiony na obu komputerach. W pierwszym trybie wątek oczekuje na
odebranie wiadomości UDP z drugiego komputera, będącą potwierdzeniem, że wiadomość
została odebrana. Dopiero po otrzymaniu takiego potwierdzenia wątek wstawia potwierdzenie
wysłania do kolejki Q10. W drugim trybie wątek wysyła wiadomość w pakiecie UDP i od
razu wstawia potwierdzenie do kolejki Q10, że pakiet został wysłany. Praca w drugim trybie
60
umożliwia osiągnięcie większej wydajności w przesyłaniu wiadomości, ale może wystąpić
opóźnienie w odbieraniu wiadomości na drugim komputerze, jeżeli wydajność odbierania
będzie mniejsza niż wysyłania. Praca w pierwszym trybie spowoduje zmniejszenie
wydajności połączenia, ale zapewniony zostanie mały czas pomiędzy nadaniem wiadomości i
odebraniem na drugim komputerze.
Opis przetwarzania priorytetów.
Powyżej zostały opisane wątki, które tworzą strukturę przetwarzania pakietów o różnych
priorytetach. Innym sposobem opisu architektury jest prześledzenie drogi, jaką przechodzą
pakiety o poszczególnych priorytetach. Taki opis jest zaprezentowany poniżej.
Priorytet 1 oznacza, że wiadomość będzie wysłana w nagłówku hop-by-hop pakietu IPv6
wychodzącego z komputera. Wiadomość będzie oczekiwała do czasu pojawienia się pakietu
IPv6. Może to być dowolnie długi czas.
Wiadomość o priorytecie 1 jest odbierana od klienta przez wątek SocketServer. Wiadomość ta
jest wstawiana do kolejki Q0. Z kolejki Q0 jest pobierana przez wątek GenerateHopByHop
i konwertowana do gotowej postaci nagłówka hop-by-hop. Następnie wątek
GenerateHopByHop wstawia gotowy nagłówek do kolejki Q6. Gdy funkcja
cb_ouput
jest
wywołana przez jądro i nie ma oczekujących na wysłanie wiadomości o priorytecie 2 lub 3,
wtedy nagłówek jest pobierany z kolejki Q6 i dołączany do pakietu. Wiadomość została
wysłana do drugiego komputera.
Wiadomość o priorytecie 2 jest odbierana od klienta przez wątek SocketServer. Wiadomość ta
jest wstawiana do kolejki Q2. Z kolejki Q1 jest pobierana przez wątek GenerateHopByHop
i konwertowana do postaci gotowego nagłówka hop-by-hop. Następnie wątek
GenerateHopByHop wstawia gotowy nagłówek do kolejki Q11. Co określony odstęp czasu
wątek DelayQueue sprawdza długość kolejki Q11. Jeżeli kolejka Q11 nie jest pusta to
wstawia liczbę określającą jej długość do kolejki Q12. Z kolejki Q12 wstawioną wartość
pobiera wątek DelaySender. Wątek DelaySender generuje dodatkową liczbę pakietów. Gdy
funkcja
cb_ouput
jest wywołana przez jądro i nie ma oczekujących na wysłanie wiadomości
o priorytecie 3, wtedy nagłówek z wiadomością o priorytecie 2 jest pobierany z kolejki Q11
i dołączany do pakietu. Wiadomość została wysłana do drugiego komputera.
Wiadomość o priorytecie 3 jest odbierana od klienta przez wątek SocketServer. Wiadomość ta
jest wstawiana do kolejki Q3. Z kolejki Q3 jest pobierana przez wątek GenerateHopByHop
61
i konwertowana do gotowej postaci nagłówka hop-by-hop. Następnie wątek
GenerateHopByHop wstawia gotowy nagłówek do kolejki Q5 i wiadomość znacznik do
kolejki Q4. Z kolejki Q4 wątek PriorityQueue pobiera wiadomość i generuje od razu pakiet
IPv6 do drugiego komputera. Gdy ten lub inny przypadkowy pakiet jest przetwarzany przez
jądro, jest wywoływana funkcja
cb_ouput
. Nagłówek z wiadomością jest pobierany z kolejki
Q5 i dołączany do pakietu. Wiadomość została wysłana do drugiego komputera.
Potwierdzenie o wysłaniu jest wstawiane do kolejki Q8. Dopiero po otrzymaniu tego
potwierdzenia, wątek SocketServer pobierze kolejną wiadomość o tym priorytecie do
wysłania.
Wiadomość o priorytecie 4 jest odbierana od klienta przez wątek SocketServer. Jest ona
wstawiana do kolejki Q9. Z kolejki Q9 jest pobierana przez wątek DirectSender. Wątek
DirectSender wysyła tę wiadomość do wartwy transportowej na drugim komputerze i,
w zależności od trybu, w którym działa albo od razu wstawia potwierdzenie do kolejki Q10
(drugi tryb pracy), albo czeka na pakiet UDP od odbiorcy (pierwszy tryb). Po wstawieniu
potwierdzenia do kolejki Q10 wątek SocketServer potwierdzi klientowi, że wiadomość została
przyjęta do wysłania i pobierze kolejną wiadomość do wysłania od klienta.
Część odbierająca.
Kolejna część warstwy transportowej odpowiada za odbieranie wiadomości i przekazywanie
ich klientom. Jest ona mniej skomplikowana od części wysyłającej, gdyż składa się tylko
z dwóch typów kanałów. Schemat tej części aplikacji jest przedstawiony na Rys. 20.
Pierwszy kanał to wiadomości odebrane bezpośrednio w pakiecie UDP przez wątek
DirectReceiver. Dotyczy to wiadomości wysłanych z priorytetem 4. Wątek może pracować
w dwóch trybach. W pierwszym trybie po odebraniu wiadomości odsyłana jest wiadomość
UDP protokołem IPv6, jako potwierdzenie odebrania. W drugim trybie nie jest odsyłane
żadne potwierdzenie. Wiadomość odebrana tym kanałem jest wstawiana do kolejki QIN2.
Wiadomości z pozostałymi priorytetami, czyli 1, 2 i 3, są przesyłane w nagłówku hop-by-hop.
Gdy pakiet jest odebrany w komputerze, jest przekazywany do funkcji
cb_input
w przestrzeni użytkownika. Funkcja ta sprawdza, czy występuje w nim nagłówek hop-by-hop
i jeżeli tak, to kopiuje ten nagłówek do kolejki QIN1. Z kolejki tej wątek ReadHopByHop
odczytuje nagłówek i konwertuje go do postaci pojedynczej wiadomości, pozbywając się
zbędnych pól, takich jak długość wiadomości. Po przekonwertowaniu wiadomość jest
62
wstawiana do kolejki QIN2. Z kolejki QIN2 wątek SocketServerRecevier pobiera wiadomości
i przekazuje je do klienta.
Rys. 20: Architektura warstwy transportowej; część odbierająca
5.3 Program klienta
Aplikacja kliencka zrealizowana w języku Python posiada graficzny interfejs użytkownika.
Program komunikuje się z warstwą transportową przy użyciu gniazdek sieciowych.
W programie można wygenerować różne typy sygnałów, różniące się rozkładem czasu
pomiędzy wiadomościami. Aplikacja służy też do odbierania wiadomości z warstwy
transportowej.
5.3.1 Funkcjonalność
Głównym zadaniem aplikacji klienckiej jest wysyłanie i odbieranie wiadomości do warstwy
transportowej. Komunikacja z warstwą transportową jest zrealizowana przy użyciu gniazdek
63
Direct Receiver
Socket Server Receiver
klient
QIN2
QIN1
cb_input
Read HopByHop
server7.txt
server9.txt
server6.txt
server5.txt
sieciowych. Aplikacja generuje kilka typów sygnałów składających się z wielu wiadomości.
Sygnały różnią się między sobą rozkładem czasowym pomiędzy kolejnymi wiadomościami.
Na Rys. 21 przestawiono wykresy histogramów odstępu czasu między wiadomościami, dla
trzech typów sygnałów. Na Rys. 22 przedstawiono także wykres czasu, dla sygnału snmp-like,
w którym odstęp między sygnałami składa się z bardzo małych i dużych przerwach, co dobrze
widać na tego rodzaju wykresie.
Sygnał no-delay
Sygnał ten charakteryzuje się pracą w pętli bez dodatkowego opóźnienia czasowego.
Szybkość generowania nowych wiadomości jest ograniczona tylko szybkością odsyłania
przez warstwę transportową potwierdzeń, że wiadomość została przyjęta do przesłania.
W scenariuszu, w którym warstwa transportowa nie wykonuje dodatkowych czynności poza
skopiowaniem wiadomości, opóźnienie generowania kolejnych wiadomości przez klienta
może wynosić około 1ms, co widać na wykresie histogramu odstępu czasu między
wiadomościami na Rys. 21, na wykresie „Sygnał no-delay. Test 1”. Jeżeli warstwa
transportowa czeka na rzeczywiste wysłanie wiadomości, zanim potwierdzi klientowi
odebranie wiadomości, to w konsekwencji moment wygenerowania kolejnego sygnału może
być dowolnie duży. Na Rys. 21, na wykresie „Sygnał no-delay. Test 2”, przedstawiono
histogram odstępu czasu między wiadomościami, dla sygnału generowanego przez klienta,
gdy warstwa transportowa wprowadza opóźnienie przy potwierdzaniu klientowi, że przyjęła
wiadomość do wysłania.
Sygnał constant
Sygnał ten generuje wiadomości w regularnych odstępach czasu. Odstęp czasu jest
parametryzowany. Szybkość generowania nowych wiadomości jest jednak ograniczona przez
warstwę transportową. Warstwa transportowa musi potwierdzić, że przyjęła wiadomość do
wysłania. W konsekwencji moment wygenerowania kolejnego sygnału może być dowolnie
duży. Na Rys. 21 na wykresie „Sygnał constant” przedstawiono histogram odstępu czasu
między wiadomościami, dla sygnału typu constant. Parametr odstępu czasu był ustawiony na
50 ms. Szczegółowy opis w jaki sposób ustawić parametr czasowy znajduje się
w Załączniku A.
Sygnał random
Sygnał ten charakteryzuje się losowymi odstępami czasu pomiędzy kolejnymi
wiadomościami. Zakres losowanych odstępów czasu jest ustawiany jako parametr przez
64
podanie najmniejszej i największej wartości. Rozkład w tym obszarze jest równomierny.
Szybkość generowania nowych wiadomości jest jednak ograniczona przez warstwę
transportową. Warstwa transportowa musi potwierdzić, że przyjęła wiadomość do wysłania.
Na Rys. 21 na wykresie „Sygnał random” przedstawiono histogram odstępu czasu między
wiadomościami, dla sygnału typu random, przy ustawionym zakresie losowania odstępu
czasu pomiędzy 16 ms i 26 ms. Szczegółowy opis w jaki sposób ustawić parametry czasowe
sygnału znajduje się w Załączniku A.
Sygnał snmp-like
Sygnał ten ma symulować ruch generowany przez protokół SNMP. Składa się z dłuższych
przerw o losowej długości i szybkich serii, o losowej liczności i stałym odstępie pomiędzy
wiadomościami w serii. Stały odstęp pomiędzy wiadomościami w serii jest podawany jako
parametr. Zakres losowania dłuższego odstępu czasu też jest podawany jako parametr.
Szybkość generowania nowych wiadomości jest ograniczona także przez warstwę
transportową. Warstwa transportowa musi potwierdzić, że przyjęła wiadomość do wysłania.
Na Rys. 21 na wykresie „Sygnał snmp-like” i Rys. 22 przedstawiono histogram odstępu czasu
między wiadomościami i wykres czasu. Długie przerwy pomiędzy seriami dobrze widać na
Rys. 22, na wykresie „Sygnał snmp-like”. Parametry sygnału były następujące: odstęp czasu
pomiędzy seriami pomiędzy 0,5 s i 5 s, liczba wiadomości w serii pomiędzy 1 i 100, odstęp
czasu pomiędzy wiadomościami w serii 6 ms. Szczegółowy opis w jaki sposób ustawić
parametry czasowe sygnału znajduje się w Załączniku A.
65
Sygnał no-delay. Test 1
Sygnał no-delay. Test 2
Sygnał constant
Sygnał random
Sygnał snmp-like
Rys. 21: Histogramy sygnałów – prezentacja sygnałów
legenda wykresów: oś pionowa – liczba wiadomości, oś pozioma – odstęp czasu pomiędzy
kolejnymi wiadomościami [s]
66
Sygnał snmp-like
Rys. 22: Wykres sygnału – prezentacja sygnałów
legenda wykresu: oś pionowa – odstęp pomiędzy kolejnymi wiadomościami [s], oś pozioma
– numer wiadomości
67
5.3.2 Implementacja
Implementacja aplikacji klienckiej została zrealizowana w języku Python. Program
komunikuje się z warstwą transportową przez gniazdka sieciowe. Aplikacja ma graficzny
interfejs użytkownika. Konfigurowalne parametry są ładowane podczas startu aplikacji.
Szczegółowy opis w jaki sposób ustawić parametry startowe znajduje się w Załączniku A.
Na Rys. 23 przedstawiono architekturę aplikacji klienckiej. Aplikacja zawiera GUI –
graficzny interfejs do sterowania aplikacją. Z poziomu GUI można uruchomić 3 wątki. Wątek
o nazwie SocketClient podłącza się do warstwy tranportowej za pomocą gniazdka sieciowego,
w celu wysyłania wiadomości do warstwy tranpsportowej. Wiadomość, która pojawi się
w kolejce Q, jest pobierana przez ten wątek i wysyłana do warstwy transportowej. Warstwa
transportowa odpowiada potwierdzeniem, że pakiet został przyjęty do wysłania. Po tym
potwierdzeniu wątek SocketClient wstawia do kolejki Qack potwierdzenie, że wiadomość
została wysyłana. Wątek SignalGenerator generuje wiadomości, których rozkład czasowy ma
określony charakter. Dostępne są 4 typy sygnałów o różnym rozkładzie czasowym odstępu
pomiędzy kolejnymi wiadomościami. Trzecim wątkiem jest wątek SocketClientListener, który
łączy się z warstwą transportową przez gniazdko sieciowe i oczekuje na wiadomości, które
odebrała warstwa transportowa.
68
Rys. 23: Aplikacja kliencka. Logowanie zdarzeń
5.4 Pomiar opóźnienia przesyłania wiadomości
Aplikacja kliencka i warstwa transportowa ma wbudowany mechanizm raportowania czasu
przetworzenia wiadomości. Podczas przetwarzania wiadomości jest zapisywany do pliku
moment czasu przetworzenia wiadomości i sama wiadomość. Dzięki temu mechanizmowi
można mierzyć i badać, które fragmenty przetwarzania pakietu są najbardziej czasochłonne.
W aplikacji klienckiej raportowane są dwa miejsca. Wątek SocketClient zapisuje do pliku
o nazwie
client1.txt
moment wysłania do warstwy transportowej wiadomości. Wątek
SocketClientListener zapisuje do pliku o nazwie
client2.txt
moment odebrania wiadomości
od warstwy transportowej. Na Rys. 23 przedstawiono miejsca w aplikacji klienckiej, w której
występuje logowanie zdarzeń do plików.
W warstwie transportowej także zastosowano logowanie przetwarzania wiadomości. Miejsca
logowania zaznaczone są na Rys. 19 i 20. Rys. 19 dotyczy części wysyłącej, a Rys. 20
odbierającej. Do pliku
server3.txt
funkcja cb_output zapisuje moment doklejenia
wiadomości w nagłówku hop-by-hop do wychodzącego pakietu IPv6. Do pliku
server5.txt
69
Socket Client Listener
Socket Server Receiver
GUI
Qack
Q
warstwa transportowa
Socket Client
client1.txt
client2.txt
funkcja cb_input loguje moment odebrania nagłówka hop-by-hop. Wątek SocketServer
zapisuje do pliku
server1.txt
moment odebrania wiadomości od klienta. Wątek
GenerateHopByHopThread zapisuje do pliku
server2.txt
moment przekonwertowania
wiadomości na nagłówek hop-by-hop. Wątek PriorityQueueThread loguje do pliku
server4.txt
moment odebrania potwierdzenia od funkcji cb_output, że nagłówek hop-by-
hop został doklejony do wychodzącego pakietu. Wątek ReadHopByHopThread loguje do
pliku
server6.txt
moment odczytania wiadomości z nagłowka hop-by-hop pakietu
przychodzącego do komputera. Wątek SocketServerReceiver loguje do pliku
server7.txt
moment wysłania wiadomości do klienta. Wątek DirectSenderThread loguje do pliku
server8.txt
moment wysłania wiadomości bezpośrednio do drugiej warstwy transportowej
w pakiecie UDP. Wątek DirectReceiverThread loguje do pliku
server9.txt
moment
odebrania od wątku DirectSender na drugim komputerze wiadomości w pakiecie UDP.
Opóźnienie warstwy transportowej było mierzone z wykorzystaniem plików
client1.txt
i
client2.txt
. Obliczana była różnica w czasie pomiędzy nadaniem wiadomości przez
klienta na jednym komputerze i odebraniem wiadomości przez klienta na drugim komputerze.
Przed obliczaniem faktycznych wartości zapewniono, za pomocą protokołu NTP, że zegary na
obu komputerach są zsynchronizowane.
70
6. Środowisko testowe
W rozdziale przedstawiono schemat środowiska testowego użytego do przeprowadzenia
testów akceptacyjnych oraz badań, z wykorzystaniem stworzonego programu. Na środowisko
składają się dwa komputery połączone przez sieć, wykonany program, aplikacje generujące
ruch testowy oraz mechanizm kształtowania ruchu dostępny w systemie Linux. Generowany
ruch oraz użycie mechanizmu kształtowania, mają na celu próbę zasymulowania
rzeczywistych warunków, w jakich stworzona aplikacja może być wykorzystywana,
i w których jej zastosowanie będzie przynosiło wymierne korzyści.
71
6.1 Schemat środowiska testowego
Rys. 24: Środowisko testowe
Środowisko do testów przedstawione jest na Rys. 24. Składa się z dwóch komputerów
połączonych przez router. Komputer 1 jest podłączony do routera przez kabel sieciowy.
Komputer 2 jest podłączony do routera przez bezprzewodową kartę sieciową, pracującą
w standardzie 802.11b/g. Z powodu bardzo bliskiej odległości między interfejsami
radiowymi, która wynosi około 1 metra, założono, że nie występują zakłócenia transmisji
wynikające ze słabej jakości sygnału. Różnica między połączeniem radiowym, a połączeniem
po kablu jest taka, że w kablu transmisja jest dwukierunkowa. Wykorzystując łączność
radiową, transmisja jest możliwa tylko w jednym kierunku w danym momencie.
W komputerze 1 i komputerze 2 uruchamiana jest warstwa transportowa, z której korzystają
po jednym kliencie na każdym komputerze. Klient warstwy transportowej może wysyłać
wiadomości do drugiego klienta i odbierać wybrane wiadomości od klienta z drugiego
komputera. W przeprowadzonych scenariuszach testowych klienci realizowali jedną z funkcji,
72
Komputer 1
Komputer 2
Warstwa
transportowa
Warstwa
transportowa
traffic control
vlc/scp
wlan0
eth0
traffic control
vlc/scp
router wifi
wysyłanie lub odbieranie wiadomości. Klient może zadecydować w jaki sposób wiadomości
będą przesłane do drugiego klienta poprzez podanie priorytetu wiadomości.
Oprócz wiadomości przesyłanych między klientami, może być dodatkowo wygenerowany
ruch podkładowy między komputerami, za pomocą uruchomionych aplikacji vlc lub scp. Oba
typy ruchu opisane są w kolejnych podrozdziałach.
Ruch podkładowy i sygnał generowany przez klienta jest wspólnie kolejkowany
w mechanizmie kształtowania ruchu (ang. traffic control). Mechanizm ten umożliwia
określenie maksymalnej przepływności ruchu wychodzącego przez interfejs i innych
parametrów związanych z kształtowaniem ruchu, np. maksymalnej długości bufora.
Mechanizm kształtowania ruchu może być też wyłączony. Wtedy pakiety kolejkowane są
w kolejce typu fifo o bardzo dużej długości. Mechanizm kształtowania ruchu jest
szczegółowo opisany w dalszym podrozdziale.
73
6.2 Program scp
Przygotowano dwa rodzaje ruchu podkładowego. Jeden generowany przez przesyłanie
poleceniem scp dużego pliku, drugi polega na strumieniowaniu transmisji wideo. Ruch
podkładowy ma symulować rzeczywistą sytuację, w której różne aplikacje generują pakiety
wysyłane i odbierane przez protokół IPv6. Typy ruchu wybrano tak, że są do siebie mało
podobne, jeżeli chodzi o charakterystykę wielkości pakietów i odstępów czasowych między
nimi. Transmisja pakietów nie jest symetryczna, czyli innej wielkości i w innej częstotliwości
wysyłane są pakiety od komputera 1 do komputera 2, a inna jest charakterystyka nadawania
danych od komputera 2 do komputera 1. Kierunek,w którym jest wykonywana transmisja
pliku lub strumienia wideo, będzie też nazywany jako „w przód”. Przeciwny kierunek będzie
nazywana jako „wstecz”.
Ruch podkładowy pierwszego rodzaju był generowany za pomocą polecenia scp. Przesyłany
był duży plik około 700MB, taki, żeby podczas testu transmisja pliku nie zakończyła się.
Przykładowe polecenie, które generowało ruch:
scp kamil@[fec0::1:3]:~/Videos/plik.avi ./
Kierunek przesyłania pliku – charakterystyka ruchu.
Przeprowadzono 1 test. Wyniki przedstawiono w Tab. 6
Tab. 6: Ruch scp; Kierunek „w przód”
mierzony okres czasu [s]
11.00
minimalny odstęp czasu pomiędzy pakietami [s]
0.0
maksymalny odstęp czasu pomiędzy pakietami [s]
0.300
wartość średnia odstępu czasu [s]
0.001
odchylenie standardowe odstępu czasu
0.006
liczba pakietów
9464
minimalna wielkość pakietu [b]
92
maksymalna wielkość pakietu [b]
1460
wartosc średnia wielkości pakietu [b]
1418.7
odchylenie standardowe wielkości pakietu
239.4
lista numerów protokołów
6
liczba pakietów protokołu: 6 (TCP)
9464
74
Na Rys. 25 – Rys. 28 przedstawiono, wspólnie dla ruchu scp i vlc, wykresy wielkości
pakietów, odstępu między wiadomościami, histogram wielkości pakietów, histogram odstępu
między wiadomościami.
Ruch w kierunku przesyłania pliku składa się w większości z plików o wielkości 1460 bajtów.
Poza tym rzadziej występują pliki o wielkości 32 bajty. Odstęp pomiędzy pakietami jest
bardzo mały dla 80% pakietów jest to poniżej 1ms. Średnia liczba pakietów przypadających
na 1 sekundę wyniosła 864. Wszystkie pakiety były pakietami protokołu TCP (numer 6).
Kierunek przeciwny do przesyłania pliku – charakterystyka ruchu.
Przeprowadzono 1 test. Wyniki przedstawiono w Tab 7.
Tab. 7: Ruchu scp; Kierunek „wstecz”
mierzony okres czasu [s]
10.9
minimalny odstęp czasu pomiędzy pakietami [s]
0.0
maksymalny odstęp czasu pomiędzy pakietami [s]
0.303
wartość średnia odstępu czasu [s]
0.002
odchylenie standardowe odstępu czasu
0.008
liczba pakietów
6505
minimalna wielkość pakietu [b]
32
maksymalna wielkość pakietu [b]
92
wartosc średnia wielkości pakietu [b]
37.00
odchylenie standardowe wielkości pakietu
8.15
lista numerów protokołów
6
liczba pakietów protokołu: 6 (TCP)
6505
Ruch przeciwny do kierunku przesyłania pliku składa się z pakietów o wielkości poniżej 100
bajtów. Średnio przesyłanych jest 591 pakietów na sekundę, co jest nie dużo mniej niż średnia
liczba pakietów przesyłanych w kierunku przesyłania pliku. Odstęp pomiędzy większością
pakietów to około 1ms.
6.3 Program vlc
Drugi typ ruchu podkładowego był generowany przez strumieniowanie pliku dźwiękowego
w formacie mp3. Długość pliku dobrano w taki sposób, aby czas odtwarzania był większy niż
75
czas trwania testu. Do strumieniowania wykorzystano program vlc, w wersji 1.0.6, należący
do standardowej dystrybucji systemu Linux Mandriva 2010. Na jednym z komputerów
uruchamiane było strumieniowanie pliku do drugiego komputera. Na drugim odbierano
strumień danych.
Parametry strumieniowania:
•
protokół RTP, port 5004
•
dodatkowe opcje:
:sout=#transcode{vcodec=mp2v,vb=800,scale=1,acodec=mpga,ab=128,channels=2,sa
mplerate=44100}
Kierunek przesyłania transmisji ścieżki dźwiękowej – charakterystyka ruchu.
Przeprowadzono 1 test. Wynki przedstawiono w Tab. 8.
Tab. 8: Ruch vlc; Kierunek „w przód”
mierzony okres czasu [s]
259.94
minimalny odstęp czasu pomiędzy pakietami [s]
0.0001
maksymalny odstęp czasu pomiędzy pakietami [s]
0.070
wartość średnia odstępu czasu [s]
0.056
odchylenie standardowe odstępu czasu
0.005
liczba pakietów
4654
minimalna wielkość pakietu [b]
32
maksymalna wielkość pakietu [b]
1336
wartosc średnia wielkości pakietu [b]
1326.95
odchylenie standardowe wielkości pakietu
107.04
lista numerów protokołów
17,58
liczba pakietów protokołu: 17 (UDP)
4647
liczba pakietów protokołu: 58 (ICMPv6)
7
Ruch w kierunku przesyłania ścieżki dźwiękowej, składa się w większości z pakietów, o
wielkości 1336 bajtów. Czasem występują pliki o wielkości 32 bajty. Odstęp pomiędzy
pakietami jest mały i wynosi dla większości pakietów 56ms. Średnia liczba pakietów
przypadających na 1 sekundę wyniosła 18. Przesyłane pakiety były pakietami protokołu UDP
(17).
Kierunek przeciwny do przesyłania transmisji ścieżki dźwiękowej – charakterystyka ruchu.
76
W kierunku przeciwnym do strumieniowania pliku dźwiękowego, nie jest generowany żadny
ruch sieciowy przez aplikację vlc.
77
Ruch scp; Kierunek „w przód”
Ruch scp; Kierunek „wstecz”
Ruch vlc; Kierunek „w przód”
Rys. 25: Wykres ruchu scp i vlc – wielkość pakietów
legenda wykresów: oś pionowa – wielkość pakietu [b], oś pozioma – numer pakietu
Ruch scp; Kierunek „w przód”
Ruch scp; Kierunek „wstecz”
78
Ruch vlc; Kierunek „w przód”
Rys. 26: Wykres ruchu scp i vlc – odstęp między pakietami
legenda wykresów: oś pionowa – odstęp pomiędzy kolejnymi pakietami [s], oś pozioma –
numer pakietu
Ruch scp; Kierunek „w przód”
Ruch scp; Kierunek „wstecz”
Ruch vlc; Kierunek „wprzód”
79
Rys. 27: Ruch scp i vlc – histogram wielkości pakietów
legenda wykresów: oś pionowa – liczba pakietów, oś pozioma – wielkość pakietu [b]
Ruch scp; Kierunek „w przód”
Ruch scp; Kierunek „wstecz”
Ruch vlc; Kierunek „w przód”
Rys. 28: Ruch scp i vlc – histogram odstępu
legenda wykresów: oś pionowa – liczba pakietów, oś pozioma – odstęp czasu pomiędzy
kolejnymi pakietami [s]
6.4 Mechanizm kształtowania ruchu
Mechanizm kształtowania ruchu (ang. traffic control) [7], dostępny w systemie Linux jako
polecenie tc, zostanie wykorzystany w pracy do symulowania obciążenia połączenia między
komputerami. Symulacja obciążenia będzie polegała głównie na określeniu maksymalnej
80
przepływności, na interfejsie wyjściowym karty sieciowej. Przeprowadzenie testów
w sytuacji, gdy łącza pomiędzy komputerami są obciążone, będzie umożliwiało sprawdzenie,
jak zachowa się mechanizm przesyłania wiadomości, w nagłówkach hop-by-hop, w takich
warunkach. Stworzony mechanizm będzie dzięki temu lepiej przetestowany i będzie można
zauważyć jego mocne i słabe strony.
Polecenie tc udostępnia kilka różnych mechanizmów kształtowania ruchu sieciowego,
opartych na różnych modelach teoretycznych. Do testów wybrano strukturę wykorzystującą
typ kolejkowania typu wiadra żetonów (ang. tocken bucket).
Rys. 29: Mechanizm wiadra żetonów
Mechanizm wiadra żetonów, przedstawiony na Rys. 29, jest modelowany jako dwie kolejki.
Jedna kolejka jest zasilana ze stałą częstotliwością żetonami, do drugiej kolejki wpadają
pakiety oczekujące na wysłanie. Jeżeli kolejka z żetonami zawiera żeton, określona porcja
danych może zostać wysłana. Żeton po użyciu, zostaje skasowany z kolejki z żetonami.
Maksymalna prędkość tak sterowanego interfejsu jest proporcjonalna do szybkości
napływania żetonów do kolejki. Ważnymi parametrami jest także pojemność kolejki na
żetony i długość kolejki z pakietami oczekującymi na wysłanie. Jeżeli kolejka z żetonami jest
zapełniona, wtedy możliwe jest, przy szybkim napływie pakietów, wysłanie większej liczby
pakietów. Chwilowa szybkość jest większa od średniej szybkości. Przekłada się to na
parametr ruchu o angielskiej nazwie burstiness. Jeżeli długość kolejki z żetonami jest duża,
wtedy możliwe są krótkotrwałe, duże paczki pakietów i przekroczenie chwilowe średniej
szybkości na interfejsie. Kolejnym ważnym parametrem jest długość kolejki z pakietami
oczekującymi na żetony. Jeżeli kolejka jest długa, wtedy jest większa szansa, że pakiet
zostanie wysłany, ale średnia wartość opóźnienia będzie większa.
81
żetony
pakiety
bufor
wiadro
żetonów
Za pomocą polecenia tc dostępnego w systemie Linux, tworzona jest struktura, której
elementy stanowią klasy ruchu charakteryzujące się innymi parametrami. Przykładowy
zestaw komend przedstawiono w Tab. 9.
Tab. 9: Parametry kształtowania ruchu. Przykład.
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 1 -
Qos
kompter 1, wlan0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev wlan0 handle 1: root htb
tc class add dev wlan0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev wlan0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev wlan0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb
latency 70ms peakrate 200kbit minburst 1540
tc filter add dev wlan0 parent 1: protocol ipv6 prio 16 u32 match ip6 src
fec0::1:2 flowid 1:11
Potencjalny ruch przechodzący przez interfejs wlan0 jest dzielony na dwie klasy
z wykorzystaniem hierarchicznego wiadra żetonów (ang. hierarichcal token bucket, htb).
Stworzono dwie klasy. Pierwsza o szybkości 10Mbit, druga o szybkości 100kbit. Pod klasy
podpięte są mechanizmy kształtowania ruchu typu wiadra żetonów. Mechanizm wiadra
żetonów przyjmuje parametry:
•
rate – średnia szybkość ruchu – sterowanie częstotliwością napływania żetonów
•
burst – cecha ruchu burstiness – związana z długością kolejki na żetony
•
latency – maksymalny czas oczekiwania pakietu na wysłanie – związany z długością
kolejki na pakiety, parametr ten może być wymiennie stosowany z parametrem
określającym długość kolejki o nazwie limit
•
peakrate – parametr, który wprowadza ograniczenie szybkości wysyłania pakietów w
momencie wystąpienia efektu burstiness
•
minburst – parametr, który powinien być ustawiony na długość pakietu
Po stworzenie struktury z klasami i mechanizmami kształtowania ruchu konieczne jest jeszcze
stworzenie filtrów, które przekażą wybrane pakiety do stworzonego mechanizmu. Filtrować
pakiety można w różny sposób. Jednym z najprostszym jest stworzenie warunków
obejmujących adres źródłowy lub docelowy z nagłówka IPv4/IPv6. Wykorzystane zostało do
tego polecenie tc z parametrem filter i identyfikatorem mechanizmu sterującego ruchem.
W podanym przykładzie w komputerze 1 wszystkie pakiety mające w nagłówku IPv6 adres
82
źródłowy fec0::1:2 będą kierowane do struktury o identyfikatorze 1:11, która jest
mechanizmem sterowania typu wiadra żetonów. Struktura utworzona poleceniami tc
przedstawiona jest na Rys. 30. Wszystkie pakiety wychodzące przez interfejs wlan0
przechodzą przez elementy struktury. Te spełniające warunek filtru trafiają do klasy 1:11,
która wprowadza ograniczenie do 100kbit.
Rys. 30: Struktura kształtowania ruchu; Przykład
83
Class 1:11
root htb
class 1:1
filter
wlan0
tbf
tak
nie
7. Testy akceptacyjne.
W rozdziale zdefiniowano listę testów akceptacyjnych, które mają sprawdzić, czy
zaprojektowane funkcje programu testowego działają poprawnie. Wszystkie testy zakończyły
się sukcesem.
84
7.1 Środowisko testowe
Do testów akceptacyjnych zostało wykorzystane środowisko testowe przedstawione
w rodziale 6.1.
7.2 Scenariusze testów akceptacyjnych.
Scenariusze testów akceptacyjnych dobrano tak, żeby przetestować wszystkie typy sygnałów,
generowanych przez aplikację kliencką i wszystkie priorytety dostarczenia wiadomości przez
warstwę transportową. Testy parmetryzacji typów ruchu i priorytu numer 2 zrealizowano
w ramach bardziej szczegółowych testów warstwy transportowej.
1. Uruchomienie warstwy transportowej
Wykonywane czynności:
1. Uruchomić program warstwy transportowej.
Oczekiwany wynik:
Program warstwy transportowej jest widoczny
jako proces w systemie.
2. Uruchomienie aplikacji klienckiej
Wykonywane czynności:
1. Uruchomić aplikację kliencką.
Oczekiwany wynik:
Aplikacja kliencka jest widoczna jako proces
w systemie. Wyświetlił się graficzny interfejs
użytkownika.
3. Podłączenie aplikacji klienckiej do warstwy transportowej
Wykonywane czynności:
1. Włączyć aplikację warstwy transportowej.
2. Włączyć aplikację kliencką.
3. Podłączyć aplikację kliencką do procesu warstwy
transportowej.
Oczekiwany wynik:
Połączenie aplikacji klienckiej z warstwą transportową
jest zaraportowane w logach aplikacji klienckiej
i warstwy transportowej.
4. Przesłanie przez warstwę transportową ruchu o typie no-delay i priorytecie 2
85
Wykonywane czynności:
1. Włączyć aplikację warstwy transportowej na dwóch
komputerach. Parametr priorytetu 2 ustawić na wartość
0.1s.
2. Włączyć aplikację kliencką na obu komputerach.
3. Podłączyć aplikację kliencką do procesu warstwy
transportowej w komputerze, który będzie wysyłał
wiadomości.
4. Podłączyć aplikację kliencką do procesu warstwy
transportowej na drugim komputerze.
5. Wysłać z aplikacji klienckiej na pierwszym
komputerze ruchu typu no-delay do aplikacji klienckiej
na drugim komputerze z priorytetem 2.
Oczekiwany wynik:
Ruch typu no-delay został odebrany w aplikacji
klienckiej na drugim komputerze. Moment wysłania
i odebrania jest zalogowany w plikach client1.txt
i client2.txt
5. Przesłanie przez warstwę transportową ruchu o typie no-delay i priorytecie 1
Wykonywane czynności:
1. Włączyć aplikację warstwy transportowej na dwóch
komputerach.
2. Włączyć aplikację kliencką na obu komputerach.
3. Podłączyć aplikację kliencką do procesu warstwy
transportowej w komputerze, który będzie wysyłał
wiadomości.
4. Podłączyć aplikację kliencką do procesu warstwy
transportowej na drugim komputerze.
5. Wysłać z aplikacji klienckiej na pierwszym
komputerze ruch typu no-delay wybierając priorytet 1.
6. Wygenerować ruch między komputerami np.
poleceniem scp.
86
Oczekiwany wynik:
Ruch składający się z wielu wiadomości został odebrany
w aplikacji klienckiej na drugim komputerze.
Wiadomości zostały przesłane w nagłówkach hop-by-
hop pakietów IPv6 co widać w programi Wireshark.
Moment wysłania i odebrania jest zalogowany w plikach
client1.txt i client2.txt
6. Przesłanie przez warstwę transportową ruchu o typie constant i priorytecie 2
Wykonywane czynności:
1. Włączyć aplikację warstwy transportowej na dwóch
komputerach. Parametr priorytetu 2 ustawić na wartość
0.1s.
2. Włączyć aplikację kliencką na obu komputerach.
3. Podłączyć aplikację kliencką do procesu warstwy
transportowej w komputerze, który będzie wysyłał
wiadomości. Parametr ruchu constant ustawić na 0.01s.
4. Podłączyć aplikację kliencką do procesu warstwy
transportowej na drugim komputerze.
5. Wysłać z aplikacji klienckiej na pierwszym
komputerze ruch typu constant wybierając priorytet 2.
Oczekiwany wynik:
Ruch składający się z wielu wiadomości został odebrany
w aplikacji klienckiej na drugim komputerze.
Wiadomości zostały przesłane w nagłówkach hop-by-
hop pakietów IPv6 co widać w programi Wireshark.
Wygenerowane zostały dodatkowe pakiety co widać
w programie Wirshark. Moment wysłania i odebrania
jest zalogowany w plikach client1.txt i client2.txt
7. Przesłanie przez warstwę transportową ruchu o typie snmp-like i priorytecie 4
Wykonywane czynności:
1. Włączyć aplikację warstwy transportowej na dwóch
komputerach. Parametr priorytetu 2 ustawić na wartość
0.1s.
87
2. Włączyć aplikację kliencką na obu komputerach.
Parametr ruchu snmp-like oznaczający odległość między
wiadomościami w serii ustawić na 0.006s. Parametry
ruchu snmp-like oznaczające czas między seriami
ustawić na 1s i 2s.
3. Podłączyć aplikację kliencką do procesu warstwy
transportowej w komputerze, który będzie wysyłał
wiadomości.
4. Podłączyć aplikację kliencką do procesu warstwy
transportowej na drugim komputerze.
5.Wysłać z aplikacji klienckiej na pierwszym
komputerze ruch typu constant wybierając priorytet 2.
Oczekiwany wynik:
Ruch składający się z wielu wiadomości został odebrany
w aplikacji klienckiej na drugim komputerze.
Wiadomości zostały przesłane w nagłówkach hop-by-
hop pakietów IPv6 co widać w programi Wireshark.
Wygenerowane zostały dodatkowe pakiety co widać w
programie Wirshark. Moment wysłania i odebrania jest
zalogowany w plikach client1.txt i client2.txt
8. Zalogowanie różnicy pomiędzy wysłaniem i odebraniem wiadomości ruchu o typie random
przesyłanych przez warstwę transportową z priorytetem 3.
Wykonywane czynności:
1. Włączyć aplikację warstwy transportowej na dwóch
komputerach.
2. Włączyć aplikację kliencką na obu komputerach.
3. Podłączyć aplikację kliencką do procesu warstwy
transportowej w komputerze, który będzie wysyłał
wiadomości. Parametry ruchu random oznaczające czas
między wiadomościami ustawić na 0.01s i 1s.
4. Podłączyć aplikację kliencką do procesu warstwy
transportowej na drugim komputerze.
88
5. Wysłać z aplikacji klienckiej na pierwszym
komputerze ruch typu random wybierając priorytet 3.
Oczekiwany wynik:
Ruch składający się z wielu wiadomości został odebrany
w aplikacji klienckiej na drugim komputerze.
Wiadomości zostały przesłane w nagłówkach hop-by-
hop pakietów IPv6 co widać w programi Wireshark.
Wygenerowane zostały dodatkowe pakiety co widać w
programie Wireshark. Moment wysłania i odebrania jest
zalogowany w plikach client1.txt i client2.txt. W plikach
client1.txt i client2.txt można znaleźć odpowiadające
sobie wiadomości, gdyż zawartość wiadomości zawiera
numer porządkowy.
9. Wygenerowanie ruchu podkładowego z wykorzystaniem polecenia scp między
komputerami.
Wykonywane czynności:
1. Skonfigurować dwa komputery, tak by miały adresy
IPv6 należące do tej samej podsieci.
2. Wygenerować ruch pakietów między komputerami
przesyłając plik scp pomiędzy komputerami.
Oczekiwany wynik:
W programie Wireshark widać wysyłane pakiety
pomiędzy komputerami.
10. Wygenerowanie ruchu podkładowego między komputerami z wykorzystaniem programu
vlc.
Wykonywane czynności:
1. Skonfigurować dwa komputery, tak by miały
adresy IPv6 należące do tej samej podsieci.
2. Uruchomić streaming pliku dźwiękowego
między komputerami.
Oczekiwany wynik:
W programie Wireshark widać wysyłane pakiety
pomiędzy komputerami.
89
Przeprowadzono zaprojektowane testy akceptacyjne. Wszystkie scenariusze zakończyły się
sukcesem. Szczegółowe testy parametryzacji typów ruchu i sygnałów generowanych przez
aplikację kliencką zrealizowano w ramach oddzielnych testów skoncentrowanych na
parametrach czasowych warstwy transportowej.
90
8. Testy wydajności i opóźnienia
W testach wydajności użyto klienta generującego sygnału typu no-delay. Wiadomości są
generowane tak szybko, jak szybko warstwa transportowa odeśle potwierdzenie o przyjęciu
wiadomości do wysłania. Testy przeprowadzono dla priorytetu 3 i priorytetu 4, które
z założenia mają wproawdzać minimalne możliwe opóźnienie w przesłaniu wiadomości. Dla
priorytetu numer 4 zastosowano oba mechanizmy potwierdzenia. Sposób potwierdzenia
pierwszego typu w większym stopniu ogranicza szybkość generowania sygnałów przez
klienta.
Sprawdzono opóźnienie wprowadzane przez warstwę transportową działającą z priorytetem 2,
priorytetem 3 i priorytetem 4. Wykorzystano wyniki badań wydajności warstwy
transportowej. W testach dla priorytetu 3 i 4 wykorzystano sygnał typu constant. Testy
priorytetu 2 przeprowadzono także dla sygnałów snmp-like i random. Nie przeprowadzono
badania opóźnienia wprowadzanego przez priorytet 1, gdyż ten typ transportu opiera się na
ruchu podkładowym, którego nie generowano.
Na Rys. 31 – Rys. 33 przedstawiono, wspólnie dla testów wydajności i opóźnienia, wykresy
opóźnienia w dostarczeniu wiadomości, histogramu opóźnienia, histogram odstępu między
wiadomościami.
91
8.1 Test w. 1. Priorytet 3.
Tab. 10: Test w. 1; Priorytet 3; Parametry kształtowania ruchu.
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 - Qos
Brak ograniczeń
Komputer 2 - Qos
Brak ograniczeń
Tab. 11: Test w. 1; Priorytet 3; Parametry przesyłanego sygnału
Generowany sygnał
no-delay
Kierunek generowanego sygnału
Z komputera 1 do komputera 2.
Parametry sygnału
Generowanie następnej wiadomości po
potwierdzeniu od warstwy transportowej.
Tab. 12: Test w. 1; Priorytet 3; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 3
Parametry warstwy transportowej
Maksymalna długość pakietu do którego
można dokleić nagłówek: 1360
Dodatkowe parametry
Brak
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami
Wyniki testu.
Liczba wysłanych wiadomości: 10000,10000,10000
Liczba odebranych wiadomości: 10000,10000,10000
Czas nadania wiadomości przez klienta nadawcę: 12.936s,12.986s,13.09s
Średni odstęp pomiędzy nadawanymi wiadomościami (z 3 eksperymentów):
1.3ms
Czas odebrania wszystkich wiadomości przez klienta odbiorcę:
15.762s,15.498s,15.896s
Średni odstęp pomiędzy odbieranymi wiadomościami (z 3 eksperymentów):
1.6ms
Średnia wartość opóźnienia: 2.88s,2.63s,2.85s
92
W teście tym użyto wariant warstwy transportowej o priorytecie numer 3. Średnie opóźnienie
pomiędzy kolejnymi pakietami generowanymi przez klienta wyniosło 1.3ms. Średni odstęp
czasu pomiędzy odbieranymi wiadomościami, przez klienta odbierającego, wyniósł 1.6ms.
Warstwa transportowa osiągnęła dużą wydajność, ale opóźnienie jest bardzo duże. Średnie
opóźnienie warstwy transportowej z 3 testów wyniosło 2.79s. Warstwa transportowa
odbierająca nie była w stanie nadążyć nad prędkością nadawania pakietów przez warstwę
transportową po stronie klienta nadającego. Widać to dobrze na Rys. 31 na wykresie „Test w.
1; Priorytet 3”.
8.2 Test w. 2. Priorytet 4. Typ potwierdzenia 2.
Tab. 13: Test w. 2; Priorytet 4; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 - Qos
Brak ograniczeń
Komputer 2 - Qos
Brak ograniczeń
Tab. 14: Test w. 2; Priorytet 4; Parametry przesyłanego sygnału
Generowany sygnał
no-delay
Kierunek generowanego sygnału
Z komputera 1 do komputera 2.
Parametry sygnału
Generowanie następnej wiadomości po
potwierdzeniu od warstwy transportowej.
Tab. 15: Test w. 2; Priorytet 4; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 4
Parametry warstwy transportowej
Brak
Dodatkowe parametry
Drugi tryb pracy mechanizmu potwierdzenia.
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami
93
Wyniki testu.
Liczba wysłanych wiadomości: 10000,10000,10000
Liczba odebranych wiadomości: 10000,10000,10000
Czas nadania wiadomości przez klienta nadawcę: 12.744s,12.695s,12.682s
Średni odstęp pomiędzy nadawanymi wiadomościami: 1.3ms
Czas odebrania wiadomości przez klienta odbiorcę: 14.587s,14.686s,14.417s
Średni odstęp pomiędzy odbieranymi wiadomościami: 1.5ms
Średnia wartość opóźnienia: 1.74s,1.96s,1.22s
sdsd
W teście tym wykorzystano wariant warstwy transportowej o priorytecie numer 4 z
mechanizmem potwierdzenia drugiego typu. Średnie opóźnienie pomiędzy kolejnymi
pakietami generowanymi przez klienta wyniosło 1.3ms. Średni odstęp czasu pomiędzy
odbieranymi wiadomościami przez klienta odbierającego wyniósł 1.6ms. Warstwa
transportowa osiągnęła dużą wydajność, ale opóźnienie jest bardzo duże. Średnie opóźnienie
z 3 testów warstwy transportowej wyniosło 1.64s. Warstwa transportowa odbierająca nie była
w stanie nadążyć nad prędkością nadawania pakietów przez warstwę transportową po stronie
klienta nadającego. Widać to dobrze na Rys. 31 na wykresie „Test w. 2; Priorytet 4”.
8.3 Test w. 3. Priorytet 4. Typ potwierdzenia 1.
Tab. 16: Test w. 3; Priorytet 4; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 - Qos
Brak ograniczeń
Komputer 2 - Qos
Brak ograniczeń
Tab. 17: Test w. 3; Priorytet 4; Parametry przesyłanego sygnału
Generowany sygnał
no-delay
Kierunek generowanego sygnału
Z komputera 1 do komputera 2.
Parametry sygnału
Generowanie następnej wiadomości po
potwierdzeniu od warstwy transportowej.
94
Tab. 18: Test w. 3; Priorytet 4; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 4
Parametry warstwy transportowej
Brak
Dodatkowe parametry
Pierwszy tryb pracy mechanizmu
potwierdzenia.
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami
Wyniki testu.
Liczba wysłanych wiadomości: 10000,10000,10000
Liczba odebranych wiadomości: 10000,10000,10000
Średnia wartość opóźnienia:
Czas nadania wiadomości przez klienta nadawcę: 52.478s,51.63s,51.335s
Średni odstęp pomiędzy nadawanymi wiadomościami: 5.2ms
Czas odebrania wiadomości przez klienta odbiorcę: 52.475s,51.627s,51.332s
Średni odstęp pomiędzy odbieranymi wiadomościami: 5.2ms
Średnia wartość opóźnienia: 2.0ms,2.7ms,2.8ms
W teście tym użyto wariant warstwy transportowej, o priorytecie numer 4, z trybem
potwierdzenia pierwszego typu. Średnie opóźnienie pomiędzy kolejnymi pakietami
generowanymi przez klienta wyniosło 5.2ms, co widać na Rys. 33 na wykresie „Test w. 3;
Priorytet 4”. Jest to około 5 razy mniejsza wydajność w porównaniu do testu z mechanizmem
potwierdzenia drugiego typu i tym samym priorytetem. Jednak średnie opóźnienie przesłania
pakietu wyniosło 2.5ms. A w teście bez tego rodzaju potwierdzenia 2s. Jest to około 1000
razy mniejsze opóźnienie.
8.4. Test o. 1. Priorytet 2. Syg. Constant.
Warstwa transportowa jest w stanie dostarczać wiadomości klientowi odbierającemu bez
wprowadzania dodatkowego opóźnienia, jeżeli odstęp między wiadomościami jest nie
mniejszy niż 6ms. Dlatego do testów opóźnienia wykorzystano sygnał typu constant,
z odstępem czasu pomiędzy kolejnymi wiadomościami nie mniejszym niż 6 ms. Dodatkowo
95
dla priorytetu 2 przeprowadzono testy opóźnienia dla sygnału typu random i sygnału typu
snmp-like. Priorytet 2 jest szczególnie interesujący, gdyż wykorzystuje przesyłany ruch, ale
także zapewnia maksymalne dopuszczalne opóźnienie wprowadzane przez warstwę
transportową.
Tab. 19: Test o. 1; Priorytet 2; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 - Qos
Brak ograniczeń.
Komputer 2 - Qos
Brak ograniczeń.
Tab. 20: Test o. 1; Priorytet 2; Parametry przesyłanego sygnału
Generowany sygnał
constant
Kierunek generowanego sygnału
Z komputera 2 do komputera 1.
Parametry sygnału
Odstęp czasu pomiędzy wiadomościami 6ms
Tab. 21: Test o. 1; Priorytet 2; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 2
Parametry warstwy transportowej
Maksymalne dopuszczalne opóźnienie 10ms.
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami.
Wyniki testu.
Liczba wysłanych wiadomości: 10000,10000,10000
Liczba odebranych wiadomości: 10000,10000,10000
Średnia wartość opóźnienia: 15ms,12ms,11ms
Histogram opóźnienia warstwy transportowej, przedstawiony na Rys. 32 na wykresie „Test
o. 1; Priorytet 2”, pokazuje, że opóźnienie dla większości pakietów mieściło się w zakresie
pomiędzy 5ms i 15ms, co jest dobrym wynikiem. Średnia wartość opóźnienia wyniosła w
trzech testach 13ms.
8.5 Test o. 2. Priorytet 3. Syg. Constant.
96
Tab. 22: Test o. 2; Priorytet 3; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 - Qos
Brak ograniczeń.
Komputer 2 - Qos
Brak ograniczeń.
Tab. 23: Test opóźnienia 2; Priorytet 3; Parametry przesyłanego sygnału
Generowany sygnał
constant
Kierunek generowanego sygnału
Z komputera 2 do komputera 1.
Parametry sygnału
Odstęp czasu pomiędzy wiadomościami 6ms
Tab. 24: Test opóźnienia 2; Priorytet 3; Parametry warstwy transportowej;
Typ warstwy transportowa
Priorytet 3
Parametry warstwy transportowej
Maksymalna długość pakietu do którego
można dokleić nagłówek: 1360
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami.
Wyniki testu.
Liczba wysłanych wiadomości: 10000,10000,10000
Liczba odebranych wiadomości: 10000,10000,10000
Średnia wartość opóźnienia: 5ms,5ms,6ms
Histogram opóźnienia warstwy transportowej, przedstawiony na Rys. 32 na wykresie „Test o.
2; Priorytet 3”, pokazuje, że opóźnienie dla większości pakietów było między 4ms i 7ms.
Średnia wartość opóźnienia wyniosła w trzech testach 5ms.
8.6 Test o. 3. Priorytet 4. Syg. Const.
Tab. 25: Test o. 3; Priorytet 4; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
97
Komputer 1 - Qos
Brak ograniczeń.
Komputer 2 - Qos
Brak ograniczeń.
Tab. 26: Test o. 3; Priorytet 4; Parametry przesyłanego sygnału
Generowany sygnał
constant
Kierunek generowanego sygnału
Z komputera 2 do komputera 1.
Parametry sygnału
Odstęp czasu pomiędzy wiadomościami 6ms
Tab. 27: Test o. 3; Priorytet 4; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 4
Parametry warstwy transportowej
Drugi tryb pracy mechanizmu potwierdzenia.
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami.
Wyniki testu.
Liczba wysłanych wiadomości: 10000,10000,10000
Liczba odebranych wiadomości: 10000,10000,10000
Średnia wartość opóźnienia: 6ms,7ms,6ms
Histogram opóźnienia warstwy transportowej, przedstawiony na Rys. 32 na wykresie „Test o.
3; Priorytet 4”, pokazuje, że opóźnienie dla większości pakietów jest pomiędzy 5ms i 7ms.
Średnia wartość opóźnienia wyniosła w trzech testach 6ms.
8.7 Test o. 4. Priorytet 2. Syg. Random.
Tab. 28: Test o. 4; Priorytet 2; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 - Qos
Brak ograniczeń.
Komputer 2 - Qos
Brak ograniczeń.
Tab. 29: Test o. 4; Priorytet 2; Parametry przesyłanego sygnału
Generowany sygnał
random
98
Kierunek generowanego sygnału
Z komputera 2 do komputera 1.
Parametry sygnału
Zakres generatora losowego odstępu czasu
0.015s – 0.025s
Tab. 30: Test o. 4; Priorytet 2; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 2
Parametry warstwy transportowej
Maksymalne dopuszczalne opóźnienie 20ms.
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami.
Wyniki testu.
Liczba wysłanych wiadomości: 3000,3000,3000
Liczba odebranych wiadomości: 3000,3000,3000
Średnia wartość opóźnienia: 19ms,20ms,17ms
Histogram opóźnienia warstwy transportowej, przedstawiony na Rys. 32 na wykresie „Test o.
4; Priorytet 2”, pokazuje, że opóźnienie dla większo ści pakietów mieściło się w zakresie
pomiędzy 5ms i 25ms, co jest dobrym wynikiem. Średnia wartość opóźnienia wyniosła w
trzech testach 19ms.
8.8 Test o. 5. Priorytet 2. Sygnał snmp-like.
Tab. 31: Test o. 5; Priorytet 2; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 - Qos Brak ograniczeń.
Komputer 2 - Qos Brak ograniczeń.
Tab. 32: Test o. 5; Priorytet 2; Parametry przesyłanego sygnału
Generowany sygnał
snmp-like
Kierunek generowanego sygnału
Z komputera 2 do komputera 1.
Parametry sygnału
Odstęp czasu pomiędzy wiadomościami w
serii: 6ms.
Ilość wiadomości w serii: pomiędzy 10 i 100.
99
Dłuższa przerwa pomiędzy seriami:
pomiędzy 0.5s i 1s.
Tab. 33: Test o. 5; Priorytet 2; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 2
Parametry warstwy transportowej
Maksymalne dopuszczalne opóźnienie 20ms.
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami.
Wyniki testu.
Liczba wysłanych wiadomości: 3000,3000,3000
Liczba odebranych wiadomości: 3000,3000,3000
Średnia wartość opóźnienia: 22ms,21ms,19ms
Histogram opóźnienia warstwy transportowej, przedstawiony na Rys. 32 na wykresie „Test o.
5; Priorytet 2”, pokazuje, że opóźnienie dla większości pakietów mieściło się w zakresie
pomiędzy 5ms i 30ms, co jest dobrym wynikiem. Średnia wartość opóźnienia wyniosła w
trzech testach 21ms.
8.9 Podsumowanie testów wydajności i opóźnienia.
Przeprowadzone testy dla sygnału typu no-delay i warstwy transportowej pracującej
z priorytetem 3 i priorytetem 4, z mechanizmem potwierdzenia typu drugiego pokazały, że
szybkość wysyłania wiadomości dla priorytetu 3 wynosi około 770 wiadomości/s, a dla
priorytetu 4 wynosi około 790 wiadomości/s. Jednak z taką szybkością nie jest wstanie
pracować warstwa transportowa po stronie klienta odbierającego wiadomości. Wydajność
przekazywania pakietów klientowi odbierającemu, dla priorytetu 3, wyniosła 640
wiadomości/s, a dla priorytetu 4 wyniosła 690 wiadomości/s. Mniejsza wydajność po stronie
odbiorcy powoduje powstanie dużego opóźnienia w dostarczeniu wiadomości. Testy pokazały
też, że wydajność warstwy transportowej, przesyłającej wiadomości w nagłówkach hop-by-
hop (priorytet 3) i w protokole UDPv6 (priorytet 4 z mechanizmem potwierdzenia drugiego
rodzaju) są do siebie bardzo zbliżone.
Wynik opóźnienia jaki uzyskano z wykorzystaniem sygnału typu no-delay i warstwy
transportowej pracującej z priorytetem 4, z mechanizmem potwierdzenia typu pierwszego
100
pokazały, że wydajność warstwy transportowej, gwarantujące minimalne opóźnienie
w dostarczeniu wiadomości do klienta odbiorcy będzie zapewnione, gdy wiadomości będą
generowane nie częściej niż co 6ms. Taki odstęp czasu równoznaczny jest przesyłaniu
wiadomości z szybkością 167 wiadomości/s.
Testy opóźnienia warstwy transportowej pracującej z priorytetem 3 i 4 pokazały,
że opóźnienie dla większości pakietów jest pomiędzy 4ms i 6ms. Najciekawsze są wyniki
testów opóźnienia wprowadzanych przez warstwę transportową o priorytecie 2.
Przetestowano ją generując sygnały trzech typów: typu constant, typu random i typu snmp-
like. Dla wszystkich tych typów sygnałów, warstwa zapewniła dla większości pakietów
opóźnienie pomiędzy 5ms i 30ms. Parametr maksymalnego opóźnienia był ustawiony na
20ms. Wynika z tego, że warstwa spełnia zakładane parametry czasowe, ale trzeba pamiętać,
że maksymalne opóźnienie będzie większe o około 10ms, w porównaniu z ustawionym.
101
Test w. 1; Priorytet 3
Test w. 2; Priorytet 4
Test w. 3; Priorytet 4
Test o. 1; Priorytet 2
Test o. 2; Priorytet 3
Test o. 3; Priorytet 4
102
Test o. 4; Priorytet 2
Test o. 5; Priorytet 2
Rys. 31: Wykres opóźnienia – testy opóźnienia
legenda wykresów: oś pionowa – opóźnienie dostarczenia wiadomości [s], oś pozioma –
numer wiadomości
Test w. 1; Priorytet 3
Test w. 2; Priorytet 4
103
Test w. 3; Priorytet 4
Test o. 1; Priorytet 2
Test o. 2; Priorytet 3
Test o. 3; Priorytet 4
Test o. 4; Priorytet 2
Test o. 5; Priorytet 2
Rys. 32: Histogram opóźnienia – testy opóźnienia
legenda wykresów: oś pionowa – liczba wiadomości, oś pozioma – opóźnienie dostarczenia
wiadomości [s]
104
Test w. 1; Priorytet 3
Test w. 2; Priorytet 4
Test w. 3; Priorytet 4
Test o. 1; Priorytet 2
Test o. 2; Priorytet 3
Test o. 3; Priorytet 4
105
Test o. 4; Priorytet 2
Test o. 5; Priorytet 2
Rys. 33: Histogram odstępu – testy opóźnienia
legenda wykresów: oś pionowa – liczba wiadomości, oś pozioma – odstęp czasu pomiędzy
kolejnymi wiadomościami [s]
106
9. Testy przesyłania danych.
Ten rozdział prezentuje wyniki szczegółowych testów warstwy transportowej w sytuacji, gdy
między komputerami jest przesyłany ruch sieciowy. Ma to symulować rzeczywisty scenariusz
wykorzystania warstwy transportowej. Testy od 1-7 były prowadzone z ruchem podkładowym
generowanym przez polecenie scp. Testy od 8-15 były prowadzone z ruchem podkładowym
generowanym przez strumieniowanie pliku dźwiękowego programem vlc. Dodatkowo
zastosowano mechanizm kształtowania ruchu, z wykorzystaniem polecenia tc, którego
wykorzystanie ma symulować sytuację niewystarczającej przepustowości łącza i
współzawodnictwo o dostęp do pasma.
Decydując o kształcie testów podjęto decyzję o parametrach takich jak priorytet przesyłania
wiadomości przez warstwę transportową, parametry mechanizmu kształtowania ruchu, czy
typ przesyłanego sygnału. Po pierwsze, celem było zaprezentowanie wszystkich możliwych
typów sygnału oprócz sygnału no-delay, zaprezentowanie wszystkich typów priorytetów
przesyłania ruchu oraz wpływu mechanizmu kształtowania ruchu na parametry czasowe
przesyłania wiadomości.
Testy zaprojektowano tak aby można wyodrębnić dwie grupy różniące się ustawionymi
parametrami kształtowania ruchu. Pierwsza grupa to testy, w których mechanizm
kształtowania ruchu nie spowodował wysycenia przepustowości. Do tej grupy należą testy
numer 1, 2, 3, 8, 9, 10, 11, 12 i 13. Druga grupa to testy, w których mechanizm kształtowania
ruchu był tak skonfigurowany by zasymulować współzawodnictwo o przepustowość łącza.
Do tej grupy należą testy numer 4, 5, 6, 7, 14 i 15.
Projektując parametry testów 1, 2 i 10 chciano pokazać parametry czasowe opóźnienia
w dostarceniu wiadomości, przy zastosowaniu priorytetu 1.
Kolejną cechą, która jest widoczna w wynikach testów, to wpływ długości bufora na
oszczędność wynikającą z wykorzystania przesyłanych pakietów przez interfejs sieciowy dla
priorytetu numer 2. Szczególnie widoczne jest to przy porównaniu wyników testów 8 i 9.
Celem testów 11, 12 i 13 było porównanie szybkości przesyłania wiadomości przez priorytety
2, 3 i 4.
Grupa testów 4, 5, 6 i 7 służy pokazaniu jak mechanizm kształtowania ruchu wpływa na
kształt generowanego sygnału, z powodu wbudowanej funkcji ponawiania wysyłki pakietów,
107
które zostały odrzucone z kolejki oczekujących na wysłanie. Porównanie dotyczy priorytetów
2 i 4. Zbadano również wpływ długości bufora mechanizmu kształtowania ruchu.
Testy 14 i 15 służa porównaniu priorytetów 3 i 4 w sytuacji wysycenia pasma transmisyjnego.
Największą liczbę testów przeprowadzono dla priorytetu 2, gdyż jest on najciekawszym
z dostępnych sposobów przesyłania danych przez warstwę transportową.
Na Rys. 34 – Rys. 39 przedstawiono, wspólnie dla testów przesyłania ruchu, wykresy
dystrybuanty opóźnienia w dostarczeniu wiadomości, wykres opóźnienia, statystyki
transmisji, histogram opóźnienia, wykres sygnału, histogram odstępu między generowanymi
wiadomościami sygnału. Nie dla wszystkich 15 testów przesyłania, zamieszczono wszystkie
typy wykresów, lecz wybrano te, które uznano za szczególnie dobrze prezentujące
charakterystykę wyniku testu.
108
9.1 Test p. 1. Priorytet 1. Scp. Syg. random.
Tab. 34: Test p. 1; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 -
Qos
kompter 1, wlan0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev wlan0 handle 1: root htb
tc class add dev wlan0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev wlan0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev wlan0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb
latency 70ms peakrate 200kbit minburst 1540
Komputer 2 -
Qos
kompter 2, eth0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev eth0 handle 1: root htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev eth0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb latency
70ms peakrate 200kbit minburst 1540
Tab. 35: Test p. 1; Parametry ruchu podkładowego
Generator ruchu
Przesyłanie dużego pliku z komputera 1 do
komputera 2 za pomocą protokołu scp.
Charakterystyka ruchu
Opis w rozdziale 6.2
Tab. 36: Test p. 1; Parametry przesyłanego sygnału
Generowany sygnał
random
Kierunek generowanego sygnału
Z komputera 2 do komputera 1.
Parametry sygnału
Zakres odstępu czasu 0.08s – 0.18s
Tab. 37: Test p. 1; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 1
Parametry warstwy transportowej
Maksymalna długość pakietu do którego
można dokleić nagłówek: 1360 bajtów.
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami.
109
Dystrybuanta opóźnienia, przedstawiona na Rys. 34, na wykresie „Test p. 1”, jest liniowa
w początkowym fragmencie, pomiędzy 10ms i 150ms. W końcowym fragmencie wykres
dystrybuanty się wypłaszcza, jest niewielka grupa pakietów, których opóźnienie jest
pomiędzy 150ms i 300ms. Wynika to z faktu, że ruch podkładowy jest regularny, a
generowany sygnał ma charakter losowy. Losowe są odstępy czasu pomiędzy kolejnymi
wiadomościami. Dystrybuanta przesyłanego sygnału ma liniowy wykres w obszarze od 0.08s
do 0.18s. Mimo pewnego opóźnienia średnia intensywność ruchu podkładowego jest większa
niż intensywność generowanego sygnału, gdyż opóźnienie nie rośnie liniowo wraz
upływającym czasem od rozpoczęcia generowania sygnału.
9.2 Test p. 2. Priorytet 1. Scp. Syg. random rzadki.
Tab. 38: Test p. 2; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 -
Qos
kompter 1, wlan0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev wlan0 handle 1: root htb
tc class add dev wlan0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev wlan0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev wlan0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb
latency 70ms peakrate 200kbit minburst 1540
Komputer 2 -
Qos
kompter 2, eth0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev eth0 handle 1: root htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev eth0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb latency
70ms peakrate 200kbit minburst 1540
Tab. 39: Test p. 2; Parametry ruchu podkładowego
Generator ruchu
Przesyłanie dużego pliku z komputera 1 do
komputera 2 za pomocą protokołu scp.
Charakterystyka ruchu
Opis w rozdziale 6.2
Tab. 40: Test p. 2; Parametry przesyłanego sygnału
110
Generowany sygnał
random
Kierunek generowanego sygnału
Z komputera 2 do komputera 1.
Parametry sygnału
Zakres odstępu czasu 0.26s - 0.32s
Tab. 41: Test p. 2; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 1
Parametry warstwy transportowej
Maksymalna długość pakietu do którego
można dokleić nagłówek: 1360 bajtów.
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami.
Test różni się od testu 1 tylko parametrem generatora sygnału. Zakres losowanego odstępu
czasu wynosi pomiędzy 0.26s i 0.32s, podczas gdy w teście 1 wynosił od 0.08s do 0.18s.
Opóźnienie warstwy transportowej, czyli czas od wysłania do odebrania sygnału wynosi od
bardzo małej wartości bliskiej zeru do około 120ms. Dystrybuanta opóźnienia, przedstawiona
na Rys. 34, na wykresie „Test p. 2”, jest liniowa w tym zakresie. W porównaniu z testem 1,
dystrybuanta zachowała liniowy charakter w całym zakresie. Wynikło to ze zwiększenia
odstępu czasu pomiędzy kolejnymi wiadomościami. Ruch podkładowy był wystarczająco
regularny i intensywny, żeby bufor oczekujących na wysłanie wiadomości był bardzo szybko
opróżniany.
9.3 Test p. 3. Priorytet 2. Scp. Syg. const. Kier. przeciwny.
Tab. 42: Test p. 3; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 -
Qos
kompter 1, wlan0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev wlan0 handle 1: root htb
tc class add dev wlan0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev wlan0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev wlan0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb
111
latency 70ms peakrate 200kbit minburst 1540
Komputer 2 -
Qos
kompter 2, eth0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev eth0 handle 1: root htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev eth0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb latency
70ms peakrate 200kbit minburst 1540
Tab. 43: Test p. 3; Parametry ruchu podkładowego
Generator ruchu
Przesyłanie dużego pliku z komputera 1 do
komputera 2 za pomocą protokołu scp.
Charakterystyka ruchu
Opis w rozdziale 6.2
Tab. 44: Test p. 3; Parametry przesyłanego sygnału
Generowany sygnał
constant
Kierunek generowanego sygnału
Z komputera 1 do komputera 2
Parametry sygnału
Odstęp czasu pomiędzy wiadomościami
50ms
Tab. 45: Test p. 3; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 2
Parametry warstwy transportowej
Maksymalne dopuszczalne opóźnienie 25ms
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami.
Wyniki testu.
Liczba dodatkowo wygenerowanych pakietów: 2649,2697,2649
Liczba odebranych wiadomości: 3000,3000,3000
Opóźnienie dla prawie wszystkich pakietów jest mniejsze niż 35ms, co jest bardzo dobrym
wynikiem. Warstwa transportowa miała zapewnić opóźnienie nie większe niż około 50ms,
jednak ruch podkładowy był wystarczająco intensywny, żeby opóźnienie okazało się jeszcze
mniejsze. Liczba wygenerowanych dodatkowo pakietów to średnio 2665. Liczba wiadomości,
112
która została przesłana wynosi 3000. Oznacza to, że oszczędność dzięki wykorzystaniu ruchu
podkładowego wyniosła 365 na 3000 pakietów, co wynosi około 12%.
9.4 Test p. 4. Priorytet 2. Scp. Syg. const. Kier. zgodny.
Tab. 46: Test p. 4; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 -
Qos
kompter 1, wlan0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev wlan0 handle 1: root htb
tc class add dev wlan0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev wlan0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev wlan0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb
latency 70ms peakrate 200kbit minburst 1540
Komputer 2 -
Qos
kompter 2, eth0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev eth0 handle 1: root htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev eth0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb latency
70ms peakrate 200kbit minburst 1540
Tab. 47: Test p. 4; Parametry ruchu podkładowego
Generator ruchu
Opis w rozdziale 6.2
Charakterystyka ruchu
Tab. 48: Test p. 4; Parametry przesyłanego sygnału
Generowany sygnał
constant
Kierunek generowanego sygnału
Z komputera 1 do komputera 2
Parametry sygnału
Odstęp czasu pomiędzy wiadomościami
50ms
Tab. 49: Test p. 4; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 2
Parametry warstwy transportowej
Maksymalne dopuszczalne opóźnienie 25ms
113
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami.
Wyniki testu.
Liczba dodatkowo wygenerowanych pakietów: 2997,2998,2996
Liczba odebranych wiadomości: 1237,1293,1149
Liczba doklejonych nagłówków hop-by-hop: 3000,3000,3000
Test wykorzystuje parametry testu 3. Jednak sygnały są generowane w przeciwną stronę, od
komputera 1 do komputera 2, czyli zgodnie z kierunkiem przesyłania dużego pliku. Okazuje
się, że transport programem scp wykorzystuje maksymalnie duże pakiety IP równe
parametrowi MTU. Do takich wiadomości nie jest możliwe doklejenie nagłówka hop-by-hop.
Łącze jest wyjątkowo silnie nasycone.
Do komputera 2 dotarło średnio tylko 1226 wiadomości. Wąskim gardłem okazał się
mechanizm kształtowania ruchu, który odrzuca pakiety, jeżeli czekają na wysłanie zbyt długo,
tutaj ustawione było maksymalne opóźnienie 70ms. Mimo, że wiadomości były doklejane do
nagłówka hop-by-hop, zostały przy przetwarzaniu odrzucone przez mechanizm kształtowania
ruchu. Warstwa transportowa wygenerowała dodatkowe pakiety, w ilości prawie równej
liczbie nadawanych sygnałów, które zostały w większości odrzucone. W komputerze 2
odebrano mniej niż połowę nadanych sygnałów, około 41%. Dodatkowo opóźnienie
w dostarczeniu było duże, wyniosło od 150ms do 400ms.
9.5 Test p. 5. Priorytet 2. Scp. Syg. const. Kier. zgodny. Tc duże opóźnienie.
Tab. 50: Test p. 5; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 -
Qos
kompter 1, wlan0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev wlan0 handle 1: root htb
tc class add dev wlan0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev wlan0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev wlan0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb
114
latency 700ms peakrate 200kbit minburst 1540
Komputer 2 -
Qos
kompter 2, eth0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev eth0 handle 1: root htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev eth0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb latency
700ms peakrate 200kbit minburst 1540
Tab. 51: Test p. 5; Parametry ruchu podkładowego
Generator ruchu
Przesyłanie dużego pliku z komputera 1 do
komputera 2 za pomocą protokołu scp.
Charakterystyka ruchu
Komputer 1 – Komputer 2 – wiekszosc
pakietow to 1460bajtowe pakiety, ktore
uniemozliwiaja doklejanie naglowka hop-by-
hop.
Komputer 2 – Komputer 1 – małe pakiety
wielkosci 40-50 bajtow, regularne odstępy
czasu pomiędzy pakietami
Tab. 52: Test p. 5; Parametry przesyłanego sygnału
Generowany sygnał
constant
Kierunek generowanego sygnału
Z komputera 1 do komputera 2
Parametry sygnału
Odstęp czasu pomiędzy wiadomościami
50ms
Tab. 53: Test p. 5; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 2
Parametry warstwy transportowej
Maksymalne dopuszczalne opóźnienie 25ms.
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami.
Wyniki testu.
Liczba dodatkowo wygenerowanych pakietów: 2999,2998,2996
Liczba odebranych wiadomości: 2810,2819,2837
Liczba doklejonych nagłówków hop-by-hop: 3000,3000,3000
115
W porównaniu z testem 4 zwiększono parametr latency z 70ms do 700ms. Parametr ten
określa jak długo mogą oczekiwać pakiety IP na wysłanie za pomocą mechanizmu wiadra
żetonów. Takie rozwiązanie zmniejsza problem “wąskiego gardła” z testu 4.
Do komputera 2 dotarło średnio 2822 sygnały, czyli 94%. W teście 3 do komputera 3 dotarło
średnio tylko 38% sygnałów. Opóźnienie w dostarczeniu wiadomości było bardzo duże i dla
większości pakietów było między 1s i 1.7s.
9.6 Test p. 6. Priorytet 4. Scp. Syg. const. Kier. zgodny. Tc duże opóźnienie.
Tab. 54: Test p. 6; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 -
Qos
kompter 1, wlan0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev wlan0 handle 1: root htb
tc class add dev wlan0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev wlan0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev wlan0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb
latency 700ms peakrate 200kbit minburst 1540
Komputer 2 -
Qos
kompter 2, eth0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev eth0 handle 1: root htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev eth0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb latency
700ms peakrate 200kbit minburst 1540
Tab. 55: Test p. 6; Parametry ruchu podkładowego
Generator ruchu
Przesyłanie dużego pliku z komputera 1 do
komputera 2 za pomocą protokołu scp.
Charakterystyka ruchu
Opis w rozdziale 6.2
Tab. 56: Test p. 6; Parametry przesyłanego sygnału
Generowany sygnał
constant
116
Kierunek generowanego sygnału
Z komputera 1 do komputera 2
Parametry sygnału
Odstęp czasu pomiędzy wiadomościami
150ms
Tab. 57: Test p. 6; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 4
Parametry warstwy transportowej
Mechanizmu potwierdzenia drugiego typu.
Przebieg testu.
Przeprowadzono 1 eksperyment.
Wyniki testu.
Liczba wysłanych wiadomości: 100,100,100
Liczba odebranych wiadomości: 100,100,100
Okazało się, że mechanizm kształtowania ruchu umożliwia retransmisję pakietów UDP, które
zostały odrzucone z powodu skończonej długości bufora. Przez to operacja wysyłająca
wiadomość przez gniazdko sieciowe trwała aż do momentu udanej transmisji pakietu do
warstwy łącza danych. Na wykresie „Test p. 6” na Rys. 37 , pokazującym różnicę w czasie,
między wygenerowaniem wiadomości i wysłaniem, , widać że opóźnienie wynosiło pomiędzy
1.1s i 1.8s. Chociaż klient miał generować pakiety co 50ms to czeka on na potwierdzenie, że
operacja socket.sendto() została zakończona przed wygenerowaniem kolejnego sygnału.
Ponieważ operacja ta trwała bardzo długo 1.1s-1.8s, więc też czas pomiędzy kolejnymi
sygnałami wynosił w przybliżeniu tyle co czas oczekiwania na zakończenie się operacji
socket.sendto(). Opóźnienie, które wprowadza kolejka tocken bucket wynosi 700ms, jednak
jeżeli pakiet jest ponownie wstawiany do kolejki bo został odrzucony, otrzymujemy czas
ponad 1s. Średnie opóźnienie wyniosło 1.40s.
9.7 Test p. 7. Priorytet 4. Scp. Syg. const. Kier. zgodny. Tc małe opóźnienie.
Tab. 58: Test p. 7; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
117
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 -
Qos
kompter 1, wlan0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev wlan0 handle 1: root htb
tc class add dev wlan0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev wlan0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev wlan0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb
latency 70ms peakrate 200kbit minburst 1540
Komputer 2 -
Qos
kompter 2, eth0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev eth0 handle 1: root htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev eth0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb latency
70ms peakrate 200kbit minburst 1540
Tab. 59: Test p. 7; Parametry ruchu podkładowego
Generator ruchu
Przesyłanie dużego pliku z komputera 1 do
komputera 2 za pomocą protokołu scp.
Charakterystyka ruchu
Opis w rozdziale 6.2
Tab. 60: Test p. 7; Parametry przesyłanego sygnału
Generowany sygnał
constant
Kierunek generowanego sygnału
Z komputera 1 do komputera 2
Parametry sygnału
Odstęp czasu pomiędzy wiadomościami
50ms
Tab. 61: Test p. 7; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 4
Parametry warstwy transportowej
Mechanizm potwierdzenia drugiego typu
Przebieg testu.
Przeprowadzono 1 eksperyment.
Wyniki testu.
Liczba wysłanych wiadomości: 100,100,100
Liczba odebranych wiadomości: 100,100,100
118
Wyniki testu w porównaniu z testem 6 są dużo lepsze. Różnica między tymi testami polegała
tylko na parametrze latency, mechanizmu kolejkowania typu tocken bucket. Zmniejszono ten
parametr z 700ms na 70ms. Średnie opóźnienie wyniosło 310ms, podczas gdy w teście 6 było
1.4s. Mechanizm retransmisji pakietu, który został odrzucony z bufora wiadra żetonów,
umożliwił przesłanie wszystkich pakietów do komputera 2, z dużo mniejszym opóźnieniem.
Mimo mniejszego opóźnienia sygnał jest bardzo zniekształcony, gdyż ustawione było stałe
opóźnienie między wiadomościami na 50ms. Patrząc na histogram sygnału „Test p. 7” na Rys.
39, widać, że odstęp pomiędzy wiadomościami składa się z opóźnienia wykonania polecenia
sendto na gniazdku sieciowym i opóźnienia stałego ustawionego 50ms.
9.8 Test p. 8. Priorytet 2. Vlc. Syg. const.
Tab. 62: Test p. 8; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 -
Qos
kompter 1, wlan0, ograniczenie do 500kbit, (1000kbit burst)
tc qdisc add dev wlan0 handle 1: root htb
tc class add dev wlan0 parent 1: classid 1:1 htb rate 10Mbit
tc class replace dev wlan0 parent 1:1 classid 1:11 htb rate 500kbit
tc qdisc replace dev wlan0 parent 1:11 handle 2 tbf rate 500kbit burst 10kb
latency 70ms peakrate 1000kbit minburst 1540
Komputer 2 -
Qos
kompter 2, eth0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev eth0 handle 1: root htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev eth0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb latency
70ms peakrate 200kbit minburst 1540
Tab. 63: Test p. 8; Parametry ruchu podkładowego
Generator ruchu
Streaming pliku mp3 z komputera 1 do
komputera 2 za pomocą protokołu RTP,
programem vlc.
Charakterystyka ruchu
Opis w rozdziale 6.3
119
Tab. 64: Test p. 8; Parametry przesyłanego sygnału
Generowany sygnał
constant
Kierunek generowanego sygnału
Z komputera 1 do komputera 2
Parametry sygnału
Odstęp czasu pomiędzy wiadomościami
50ms
Tab. 65: Test p. 8; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 2
Parametry warstwy transportowej
Maksymalne dopuszczalne opóźnienie 25ms.
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami.
Wyniki testu.
Liczba dodatkowo wygenerowanych pakietów: 2193,2140,2207
Liczba odebranych wiadomości: 3000,2999,3000
Liczba doklejonych nagłówków hop-by-hop: 3000,3000,300
Średnia wartość opóźnienia: 21ms,22ms,23ms
Średnia wartość opóźnienia wyniosła 21ms. Rozkład opóźnienia był w zakresie od 9 ms do 40
ms. Osiągnięto oszczędność wynikającą z wykorzystania ruchu podkładowego.
Wygenerowano dodatkowo średnio 2180 pakietów, co wynosi 73% wszystkich przesłanych
wiadomości.
9.9 Test p. 9. Priorytet 2 duży odstęp. Vlc. Syg. const.
Tab. 66: Test p. 9; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 - kompter 1, wlan0, ograniczenie do 500kbit, (1000kbit burst)
120
Qos
tc qdisc add dev wlan0 handle 1: root htb
tc class add dev wlan0 parent 1: classid 1:1 htb rate 10Mbit
tc class replace dev wlan0 parent 1:1 classid 1:11 htb rate 500kbit
tc qdisc replace dev wlan0 parent 1:11 handle 2 tbf rate 500kbit burst 10kb
latency 70ms peakrate 1000kbit minburst 1540
Komputer 2 -
Qos
kompter 2, eth0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev eth0 handle 1: root htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev eth0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb latency
70ms peakrate 200kbit minburst 1540
Tab. 67: Test p. 9; Parametry ruchu podkładowego
Generator ruchu
Streaming pliku mp3 z komputera 1 do
komputera 2 za pomocą protokołu RTP,
programem vlc.
Charakterystyka ruchu
Opis w rozdziale 6.3
Tab. 68: Test p. 9; Parametry przesyłanego sygnału
Generowany sygnał
constant
Kierunek generowanego sygnału
Z komputera 1 do komputera 2
Parametry sygnału
Odstęp czasu pomiędzy wiadomościami
50ms
Tab. 69: Test p. 9; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 2
Parametry warstwy transportowej
Maksymalne dopuszczalne opóźnienie
100ms.
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami.
Wyniki testu.
Liczba dodatkowo wygenerowanych pakietów: 312,314,314
Liczba odebranych wiadomości: 1000,1000,1000
Liczba doklejonych nagłówków hop-by-hop: 1000,1000,1000
121
Średnia wartość opóźnienia: 36ms,34ms,33ms
Średnia wartość opóźnienia to 34ms. Rozkład opóźnienia w wykonanych testach był
w zakresie od 10ms do 65 ms. Opóźnienie było mniejsze od ustawionego maksymalnego
opóźnienia w warstwie transportowej na 100ms. Wynikło to z faktu, że intensywność ruchu
podkładowego była większa od intensywności generowania sygnału. Osiągnięto oszczędność
wynikającą z wykorzystania ruchu podkładowego. Wygenerowano dodatkowo średnio 313
pakietów, co wynosi 31% wszystkich przesłanych sygnałów.
9.10 Test p. 10. Priorytet 1. Vlc. Syg. const.
Tab. 70: Test p. 10; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 -
Qos
kompter 1, wlan0, ograniczenie do 500kbit, (1000kbit burst)
tc qdisc add dev wlan0 handle 1: root htb
tc class add dev wlan0 parent 1: classid 1:1 htb rate 10Mbit
tc class replace dev wlan0 parent 1:1 classid 1:11 htb rate 500kbit
tc qdisc replace dev wlan0 parent 1:11 handle 2 tbf rate 500kbit burst 10kb
latency 70ms peakrate 1000kbit minburst 1540
Komputer 2 -
Qos
kompter 2, eth0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev eth0 handle 1: root htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev eth0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb latency
70ms peakrate 200kbit minburst 1540
Tab. 71: Test p. 10; Parametry ruchu podkładowego
Generator ruchu
Streaming pliku mp3 z komputera 1 do
komputera 2 za pomocą protokołu RTP,
programem vlc.
Charakterystyka ruchu
Opis w rozdziale 6.3
122
Tab. 72: Test p. 10; Parametry przesyłanego sygnału
Generowany sygnał
constant
Kierunek generowanego sygnału
Z komputera 1 do komputera 2
Parametry sygnału
Odstęp czasu pomiędzy wiadomościami
150ms
Tab. 73: Test p. 10; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 1
Parametry warstwy transportowej
Maksymalna długość pakietu do którego
można dokleić nagłówek: 1360 bajtów.
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami.
Wyniki testu.
Liczba odebranych wiadomości: 1000,1000,1000
Liczba doklejonych nagłówków hop-by-hop: 1000,1000,1000
Średnia wartość opóźnienia: 39ms,39ms,39ms
Średnia wartość opóźnienia to 39ms. Rozkład opóźnienia w wykonanych testach był w miarę
równomiernie rozłożony, w zakresie od 10ms do 65 ms. Osiągnięto 100% oszczędność
wynikającą z wykorzystania ruchu podkładowego. Wszystkie 1000 sygnałów zostało
wysłanych w nagłówkach hop-by-hop, w ruchu istniejącym. Jednocześnie opóźnienie było na
niskim poziomie. Było to możliwe, gdyż odstęp pomiędzy generowanymi sygnałami wynosił
150ms.
9.11 Test p. 11. Priorytet 2. Vlc. Syg. snmp-like.
Tab. 74: Test p. 11; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 - kompter 1, wlan0, ograniczenie do 500kbit, (1000kbit burst)
123
Qos
tc qdisc add dev wlan0 handle 1: root htb
tc class add dev wlan0 parent 1: classid 1:1 htb rate 10Mbit
tc class replace dev wlan0 parent 1:1 classid 1:11 htb rate 500kbit
tc qdisc replace dev wlan0 parent 1:11 handle 2 tbf rate 500kbit burst 10kb
latency 70ms peakrate 1000kbit minburst 1540
Komputer 2 -
Qos
kompter 2, eth0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev eth0 handle 1: root htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev eth0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb latency
70ms peakrate 200kbit minburst 1540
Tab. 75: Test p. 11; Parametry ruchu podkładowego
Generator ruchu
Streaming pliku mp3 z komputera 1 do
komputera 2 za pomocą protokołu RTP,
programem vlc.
Charakterystyka ruchu
Opis w rozdziale 6.3
Tab. 76: Test p. 11; Parametry przesyłanego sygnału
Generowany sygnał
snmp-like
Kierunek generowanego sygnału
Z komputera 1 do komputera 2.
Parametry sygnału
Odstęp czasu pomiędzy wiadomościami w
serii: 6ms.
Ilość wiadomości w serii: pomiędzy 1 i 100.
Dłuższa przerwa pomiędzy seriami:
pomiędzy 0.5s i 5s.
Tab. 77: Test p. 11; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 2
Parametry warstwy transportowej
Maksymalna dopuszczalne opóźnienie 10ms
Przebieg testu.
Przeprowadzono 3 eksperymenty.
Wyniki testu.
Liczba dodatkowo wygenerowanych pakietów: 453,460,451
Liczba odebranych wiadomości: 500,500,500
Liczba doklejonych nagłówków hop-by-hop: 500,500,500
124
Średnia wartość opóźnienia: 16ms,16ms,16ms
Średnia wartość opóźnienia wyniosła 16ms. Jest to bardzo dobry wynik. W warstwie
transportowej parametr maksymalnego opóźnienia był ustawiony na 10ms. Rozkład
opóźnienia jest układa się pomiędzy 10ms i 25ms. Osiągnięto małą oszczędność wynikającą
z wykorzystania ruchu podkładowego. Wygenerowano dodatkowo średnio 455 pakietów na
500 przesłanych wiadomości.
9.12 Test p. 12. Priorytet 4. Vlc. Syg. snmp-like.
Tab. 78: Test p. 12; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 -
Qos
kompter 1, wlan0, ograniczenie do 500kbit, (1000kbit burst)
tc qdisc add dev wlan0 handle 1: root htb
tc class add dev wlan0 parent 1: classid 1:1 htb rate 10Mbit
tc class replace dev wlan0 parent 1:1 classid 1:11 htb rate 500kbit
tc qdisc replace dev wlan0 parent 1:11 handle 2 tbf rate 500kbit burst 10kb
latency 70ms peakrate 1000kbit minburst 1540
Komputer 2 -
Qos
kompter 2, eth0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev eth0 handle 1: root htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev eth0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb latency
70ms peakrate 200kbit minburst 1540
Tab. 79: Test p. 12; Parametry ruchu podkładowego
Generator ruchu
Strumieniowanie pliku mp3 z komputera 1 do
komputera 2 za pomocą protokołu RTP,
programem vlc.
Charakterystyka ruchu
Opis w rodziale 6.3
Tab. 80: Test p. 12; Parametry przesyłanego sygnału
Generowany sygnał
snmp-like
125
Kierunek generowanego sygnału
Z komputera 1 do komputera 2.
Parametry sygnału
Odstęp czasu pomiędzy wiadomościami w
serii: 6ms.
Ilość wiadomości w serii: pomiędzy 1 i 100.
Dłuższa przerwa pomiędzy seriami:
pomiędzy 0.5s i 5s.
Tab. 81: Test p. 12; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 4
Parametry warstwy transportowej
Mechanizm potwierdzenia drugiego typu
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami.
Wyniki testu.
Liczba wysłanych wiadomości: 500,500,500
Liczba odebranych wiadomości: 500,500,500
Średnia wartość opóźnienia: 7ms,7ms,7ms
Rozkład opóźnienia jest w skoncentrowany wokół wartości 7ms. Sygnał generowany ma
charakter prawie taki jak zakładany, są dłuższe przerwy i serie z krótkimi odstępami między
wiadomościami. Krótkie przerwy wynoszą około 10ms, co jest nieznacznie więcej niż
ustawione 6ms. Opóźnienie wprowadził między innymi mechanizm potwierdzenia. Warstwa
transportowa wstrzymuje klienta generującego sygnał, dopóki polecenie sendto na gniazdku
sieciowym, nie zakończy działania. W kolejnym teście numer 13 został wykorzystany inny
rodzaj warstwy transportowej, bez mechanizmu potwierdzenia charakterystycznego dla
priorytetu 4, dzięki czemu odstęp pomiędzy kolejnymi wiadomościami w serii jest mniejszy
niż 10ms.
9.13 Test p. 13. Priorytet 3. Vlc. Syg. snmp-like.
Tab. 82: Test p. 13; Parametry kształtowania ruchu
Ustawione parametry
126
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 -
Qos
kompter 1, wlan0, ograniczenie do 500kbit, (1000kbit burst)
tc qdisc add dev wlan0 handle 1: root htb
tc class add dev wlan0 parent 1: classid 1:1 htb rate 10Mbit
tc class replace dev wlan0 parent 1:1 classid 1:11 htb rate 500kbit
tc qdisc replace dev wlan0 parent 1:11 handle 2 tbf rate 500kbit burst 10kb
latency 70ms peakrate 1000kbit minburst 1540
Komputer 2 -
Qos
kompter 2, eth0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev eth0 handle 1: root htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev eth0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb latency
70ms peakrate 200kbit minburst 1540
Tab. 83: Test p. 13; Parametry ruchu podkładowego
Generator ruchu
Strumieniowanie pliku mp3 z komputera 1 do
komputera 2 za pomocą protokołu RTP,
programem vlc.
Charakterystyka ruchu
Opis w rozdziale 6.3
Tab. 84: Test p. 13; Parametry przesyłanego sygnału
Generowany sygnał
snmp-like
Kierunek generowanego sygnału
Z komputera 1 do komputera 2.
Parametry sygnału
Odstęp czasu pomiędzy wiadomościami w
serii: 6ms.
Ilość wiadomości w serii: pomiędzy 1 i 100.
Dłuższa przerwa pomiędzy seriami:
pomiędzy 0.5s i 5s.
Tab. 85: Test p. 13; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 3
Parametry warstwy transportowej
Maksymalna długość pakietu do którego
można dokleić nagłówek: 1360 bajtów.
Przebieg testu.
127
Przeprowadzono 3 eksperymenty z tymi samymi parametrami.
Wyniki testu.
Liczba wysłanych wiadomości: 500,500,500
Liczba odebranych wiadomości: 500,500,500
Liczba dodatkowo wygenerowanych pakietów: 500,500,500
Średnia wartość opóźnienia: 9ms,7ms,7ms
Ruchem przesyłanym był ruch mający symulować ruch protokołu SNMP. Średnia wartość
opóźnienia wyniosła 8ms. Jest to wynik właściwie taki sam co w przypadku wysyłania
wiadomości bezpośrednio w protokole UDP (test p. 12). Rozkład opóźnienia jest
skoncentrowany wokół wartości 7ms. Charakter ruchu jest taki jak zakładany. Występują
dłuższe i krótkie przerwy. Krótkie przerwy mają wartość około 6ms. Jest to lepszy
charakterystyka niż w teście 11. Wynika to z faktu, że użyta tutaj warstwa transportowa ma
mechanizm potwierdzenia, nie czekający na faktyczne wysłanie wiadomości.
9.14 Test p. 14. Priorytet 4. Vlc. Tc. Syg. snmp-like.
Tab. 86: Test p. 14; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 -
Qos
kompter 1, wlan0, ograniczenie do 500kbit, (1000kbit burst)
tc qdisc add dev wlan0 handle 1: root htb
tc class add dev wlan0 parent 1: classid 1:1 htb rate 10Mbit
tc class replace dev wlan0 parent 1:1 classid 1:11 htb rate 500kbit
tc qdisc replace dev wlan0 parent 1:11 handle 2 tbf rate 160kbit burst 10kb
latency 70ms peakrate 400kbit minburst 1540
Komputer 2 -
Qos
kompter 2, eth0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev eth0 handle 1: root htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev eth0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb latency
70ms peakrate 200kbit minburst 1540
Tab. 87: Test p. 14; Parametry ruchu podkładowego
128
Generator ruchu
Strumieniowanie pliku mp3 z komputera 1 do
komputera 2 za pomocą protokołu RTP,
programem vlc.
Charakterystyka ruchu
Opis w rozdziale 6.3
Tab. 88: Test p. 14; Parametry przesyłanego sygnału
Generowany sygnał
snmp-like
Kierunek generowanego sygnału
Z komputera 1 do komputera 2.
Parametry sygnału
Odstęp czasu pomiędzy wiadomościami w
serii: 6ms.
Ilość wiadomości w serii: pomiędzy 1 i 100.
Dłuższa przerwa pomiędzy seriami:
pomiędzy 0.5s i 5s.
Tab. 89: Test p. 14; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 4
Parametry warstwy transportowej
Mechanizm potwierdzenia drugiego typu.
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami.
Wyniki testu.
Liczba wysłanych wiadomości: 1000,1000,1000
Liczba odebranych wiadomości: 1000,1000,1000
Średnia wartość opóźnienia: 148ms,149ms,151ms
Ruchem przesyłanym był ruchem typu snmp. Jednak z powodu mechanizmu potwierdzenia
sygnał został zupełnie zniekształcony. Z wykresu w małej skali widać, ze opóźnienie
pomiędzy pakietami w serii wynosiło około 13ms lub około 21ms. Jeżeli spojrzymy na
wykres histogramu opóźnienia „Test p. 14” na Rys. 37, widać że sygnał został zniekształcony
do wartości opóźnienia.
Jest widoczna zaleta mechaznimu transportu w oddzielnych pakietach UDP. Do komputera 2
dotarło 100% wiadomości. Wynika to z cechy mechanizmu kształtowania ruchu, który
129
umożliwia retransmisję pakietów protokołu UDP, jeżeli pakiet został odrzucony z kolejki
z powodu przekroczenia czasu oczekiwania na wysłanie.
9.15 Test p. 15. Priorytet 3. Vlc. Tc. Syg. snmp-like.
Tab. 90: Test p. 15; Parametry kształtowania ruchu
Ustawione parametry
Komputer 1
adres fec0::1:2, interfejs wlan0
Komputer 2
adres fec0::1:3, interfejs eth0
Komputer 1 -
Qos
kompter 1, wlan0, ograniczenie do 500kbit, (1000kbit burst)
tc qdisc add dev wlan0 handle 1: root htb
tc class add dev wlan0 parent 1: classid 1:1 htb rate 10Mbit
tc class replace dev wlan0 parent 1:1 classid 1:11 htb rate 500kbit
tc qdisc replace dev wlan0 parent 1:11 handle 2 tbf rate 160kbit burst 10kb
latency 70ms peakrate 400kbit minburst 1540
Komputer 2 -
Qos
kompter 2, eth0, ograniczenie do 100kbit, (200kbit burst)
tc qdisc add dev eth0 handle 1: root htb
tc class add dev eth0 parent 1: classid 1:1 htb rate 10Mbit
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 100kbit
tc qdisc add dev eth0 parent 1:11 handle 2 tbf rate 100kbit burst 10kb latency
70ms peakrate 200kbit minburst 1540
Tab. 91: Test p. 15; Parametry ruchu podkładowego
Generator ruchu
Strumieniowanie pliku mp3 z komputera 1 do
komputera 2 za pomocą protokołu RTP,
programem vlc.
Charakterystyka ruchu
Opis w rozdziale 6.3
Tab. 92: Test p. 15; Parametry przesyłanego sygnału
Generowany sygnał
snmp-like
Kierunek generowanego sygnału
Z komputera 1 do komputera 2.
Parametry sygnału
Odstęp czasu pomiędzy wiadomościami w
serii: 6ms.
Ilość wiadomości w serii: pomiędzy 1 i 100.
Dłuższa przerwa pomiędzy seriami:
pomiędzy 0.5s i 5s.
130
Tab. 93: Test p. 15; Parametry warstwy transportowej
Typ warstwy transportowa
Priorytet 3
Parametry warstwy transportowej
Maksymalna długość pakietu do którego
można dokleić nagłówek: 1360 bajtów.
Przebieg testu.
Przeprowadzono 3 eksperymenty z tymi samymi parametrami.
Wyniki testu.
Liczba wysłanych wiadomości: 1000,1000,1000
Liczba odebranych wiadomości: 869,900,864
Liczba dodatkowo wygenerowanych pakietów: 1000,1000,1000
Średnia wartość opóźnienia: 196ms,196ms,199ms
Do komputera 2 dotarło średnio 878 pakietów na 1000 wysłanych. Wiadomości były
doklejane do pakietów IP, ale mechanizm kształtowania ruchu odrzucał niektóre z nich, gdy
bufor był przepełniony. Opóźnienie przyjmowało wartości głównie od około 150ms do około
250ms. Rozkład w tym obszarze był w miarę równomierny. Sygnał typu snmp nie został
zniekształcony. Widać to na wykresie „Test p. 15”, histogramu odstępu czasu pomiędzy
kolejnymi wiadomościami na Rys. 39.
131
Test p. 1
Test p. 2
Rys. 34: Dystrybuanta opóźnienia – testy przesyłania danych
legenda wykresów p1,p2: oś pionowa – dystrybuanta opóźnienia w dostarczeniu
wiadomości, oś pozioma – czas[s]
Test p. 4
Test p. 5
Rys. 35: Wykres opóźnienia – testy przesyłania danych
legenda wykresów p4, p5: oś pionowa – opóźnienie dostarczenia wiadomości [s], oś
pozioma – numer wiadomości
132
Test p. 3
Test p. 4
Test p. 5
Test p. 8
Test p. 9
Test p. 11
133
Test p. 15
Rys. 36: Statystyki transmisji – testy przesyłania danych
legenda wykresów p3, p4, p5, p8, p9, p11, p15: oś pionowa – liczba wiadomości
Test p. 3
Test p. 4
Test p. 5
Test p. 6
134
Test p. 7
Test p. 8
Test p. 9
Test p. 10
Test p. 11
Test p. 12
135
Test p. 13
Test p. 14
Test p. 15
Rys. 37: Histogram opóźnienia – testy przesyłania danych
legenda wykresów p3-p15: oś pionowa – liczba wiadomości, oś pozioma – opóźnienie
dostarczenia wiadomości [s]
Test p. 11
Test p. 12
136
Test p. 13
Test p. 14
Test p. 15
Rys. 38: Wykres sygnału – testy przesyłania danych
legenda wykresów p11-p5: oś pionowa – odstęp pomiędzy kolejnymi wiadomościami [s], oś
pozioma – numer wiadomości
Test p. 1
Test p. 2
137
Test p. 3
Test p. 4
Test p. 5
Test p. 6
Test p. 7
Test p. 8
138
Test p. 9
Test p. 10
Test p. 11
Test p. 12
Test p. 13
Test p. 14
139
Test p. 15
Rys. 39: Histogram odstępu – testy przesyłania danych
legenda wykresów p1-p15: oś pionowa – liczba wiadomości, oś pozioma – odstęp czasu
pomiędzy kolejnymi wiadomościami [s]
140
9.16 Podsumowanie testów przesyłania danych
Przeprowadzone testy są pewnym wycinkiem wszystkich możliwych kombinacji ruchu
podkładowego, przesyłanego sygnału, priorytetu przesyłania wiadomosci oraz parametrów
mechanizmu kształtowania ruchu. Nie ma pewności, że wszystkie cechy tego sposobu
transportu uwidoczniły się w zbiorze przeprowadzonych testów, ale jest przypuszczenie, że
większość cech transportu można było zaobserwować na podstawie wyników testów. Wyniki
testów zostały omówione poprzez pogrupowanie testów i omówienie każdej grupy oddzielnie.
Podsumowanie testów 4, 5, 6 i 7
W teście 4 i 5 pokazano, jak będzie się zachowywała warstwa transportowa dla priorytetu 2,
gdy interfejs sieciowy będzie wysycony pakietami o wartości MTU. W takiej sytuacji
warstwa transportowa będzie musiała wygenerować dodatkowe pakiety, które będą często
odrzucane przez mechanizm kształtowania ruchu, ograniczający pasmo. W teście 4 dotarło do
odbiorcy tylko około 40% wiadomości. Poprawę dostarczania wiadomości można zwiększyć
zwiększając bufor na pakiety oczekujące na wysłanie. Po zwiększeniu maksymalnego czasu
oczekiwania w buforze z 70ms, w teście 4, do 700ms, w teście 5, do odbiorcy dotarło już
około 94% wszystkich wysyłanych wiadomości.
W celu porównania zachowania priotetu 2, przeprowadzono takie same testy
z wykorzystaniem priorytetu 4. Okazało się, że przesyłania wiadomości bezpośrednio
w protokole UDP powoduje, że odrzucone pakiety przez mechanizm kształtowania ruchu są
ponownie transmitowane aż do skutku. Dzięki temu do odbiorcy w testach 5 i 6 dotarło 100%
wysłanych wiadomości. Jest jednak poważna wada tego mechanizmu. Warstwa transportowa
wysyłająca pakiety wprowadza duże opóźnienia pomiędzy kolejno nadawanymi pakietami.
Sięgają one 1.5s w teście 6. Priorytet 2 nie zniekształcił generowanego sygnału, czyli odstęp
pomiędzy pakietami w serii był rzędu 6ms.
Podsumowanie testów 3, 8, 9
Testy 3, 8 i 9 pokazały, jak zachowuje się warstwa transportowa przesyłająca wiadomości
z priorytetem 2, gdy łącze nie jest wysycone. Zachowana zostaje wartość masymalnego
opóźnienia przy przesyłaniu wiadomości. Gdy dopuszczalne opóźnienie jest większe wtedy
zysk, polegający na wykorzystaniu ruchu podkładowego do przesyłania wiadomości, jest
większy. W teście numer 9 zysk wyniósł 31%.
141
Podsumowanie testów 1, 2, 10
Testy 1, 2 i 10 pokazały, jak zachowuje się warstwa transportowa przesyłająca wiadomości
z priorytetem 1. Dla każdego z trzech testów dostarczono wszystkie wiadomości do odbiorcy
z małym opóźnieniem. Takie wyniki uzyskano, ponieważ ruch podkładowy był bardziej
intensywny od przesyłanego sygnału. Ruch o priorytecie 1 nadaje się do przesyłania
wiadomości, dla których nie jest krytyczne opóźnienie w dostarczeniu, oraz występuje
wystarczająco intensywny ruch podkładowy.
Podsumowanie testów 11,12 i 13
Testy 11, 12 i 13 pokazały jakie opóźnienie jest wprowadzane przez warstwę transportową dla
priorytetów 2, 3 i 4, w przypadku gdy łącze nie jest wysycone. Przesyłanym sygnałem był
sygnał typu snmp-like. Priorytety 3 i 4 uzyskały taką samą wartośc opóźnienia, około 7ms.
Priorytet 2 z ustawioną wartością maksymalnego opóźnienia na 10ms, osiągnął wartość
średnią opóźnienia około 16ms. Najszybciej wiadomości dostarczane są priorytetem 3 i 4,
tylko trochę wolniej priorytetem 2.
Podsumowanie testów 14 i 15
Testy 14 i 15 pokazały jaki wpływ na przesyłany ruch ma priorytet 3 i 4 w przypadku, gdy
łącze jest wysycone pakietami nie mającymi wartości MTU. Priorytet 3 z powodu
mechanizmu retransmisji pakietów UDP zniekształaca generowany sygnał. Opóźnienie
pomiędzy kolejnymi wiadomościami wynosi około 150ms, mimo że powinno to być około
6ms. Priorytet 4 nie zniekształca generowanego sygnału. Odstęp pomiędzy wiadomościami
w serii wynosi około 8ms. Wadą priorytetu 4 jest to, że dotarło do odbiorcy tylko 88%
wysłanych pakietów.
142
10. Podsumowanie testów
Wykonany program i przeprowadzone testy wydajności i opóźnienia pokazały, że cel
postawiony przed częścią praktyczną pracy został osiągnięty. Stworzona implementacja
umożliwia przesyłanie wiadomości w nagłówkach hop-by-hop pakietów IPv6 z dość dobrą
wydajnością i wprowadzanym małym opóźnieniem. Wydajność jest wystarczająca do
przeprowadzonych testów z rodziału 9, które symulują przesyłanie wiadomościz szybkością
maksymalną około 200 razy na sekundę. Zaimplementowane rozwiązanie nie jest jednak
skalowale, gdyż nie da się za jego pomocą testować bardziej skomplikowanych scenariuszy,
wymagających większej wydajności i jeszcze mniejszego opóźnienia. Wydaje się,
że oczekiwane rezultaty spełniłoby rozwiązanie przedstawione w rozdziale 4.2 Implementacja
z wykorzystaniem zaczepów. Rozwiązanie to polega na napisaniu kodu przetwarzającego
pakiety w przestrzeni jądra z wykorzystaniem mechanizmu rejestrowania funkcji, którym
zostaje przekazana obsługa pakietu, w wybranych momentach przetwarzania.
Testy warstwy tranportowej pokazały, że wykorzystanie nagłówków hop-by-hop może być
ciekawym i korzystnym rozwiązaniem alternatywnym do wysyłania wiadomości
w odzielnych pakietach. Nagłówki hop-by-hop umożliwiają przysyłanie dużej liczby
informacji bez dużego wykorzystania radiowego pasma transmisyjnego. Nagłówek hop-by-
hop sprawdzi się szczególnie dobrze w sytuacji, gdy jest konieczność przesyłania danych
bardzo często, kilkadziesiąt lub kilkaset razy na sekundę, a łącze radiowe jest mocno
obciążone. Ograniczeniem będzie tutaj konieczność sprawdzenia czy po dodaniu nagłówka
nie przekroczona zostanie wartość MTU łącza. Drugą wadą zauważoną w trakcie testów jest
fakt, że pakiety, także te z dołączonym nagłówkiem hop-by-hop mogą być odrzucone przez
mechanizm kształtowania ruchu stosowany w systemie Linux.
Mimo, że zbiór testów jest dość obszerny, gdyż zawiera 15 różnych scenariuszy testowych, to
stanowi on tylko mały wkład nad zbadaniem mechanizmu transportu wykorzystującego
nagłówki hop-by-hop w protokole IPv6. Rzeczywisty ruch internetowy ma dużo bardziej
złożony charakter, a z jednego radiowego punktu dostępowego może korzystać więcej niż
jeden komputer, co powoduje większe zakłócenia.
143
LITERATURA
[1]
RFC 2460, Internet Protocol, Version 6 (IPv6), 1998
[2]
RFC 791, INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL
SPECIFICATION, 1981
[3]
Dokumentacja języka Python, http://docs.python.org/, strona odwiedzona 10.09.2011
[4]
Dokumentacja do Pythonowego API dla biblioteki GTK+,
http://www.pygtk.org/docs/pygtk/, strona odwiedzona 10.09.2011
[5]
Dokumentacja do biliotek libnetfilter_queue, libnfnetlink, http://www.netfilter.org/,
strona odwiedzona 10.09.2011
[6]
Dokumentacja do biblioteki nfqueue-bindings, http://software.inl.fr/trac/wiki/nfqueue-
bindings i http://www.nufw.org/projects/nfqueue-bindings/wiki/Wiki, strony
odwiedzone 10.09.2011
[7]
Marcin Króliczak, praca inżynierska pt.: Graficzna aplikacja zarządzająca pasmem
w łączu współdzielonym, Wydział Elektroniki i Technik Informacyjnych, Warszawa
2007
[8]
Bert Hubert, Linux Advanced Routing & Traffic Control HOWTO, Opis mechanizmu
Traffic Control w systemie Linux, rozdział 9: Queueing Disciplines for Bandwidth
Management, http://lartc.org/lartc.html, strona odwiedzona 10.09.2011
[9]
Differentiated Service on Linux HOWTO, rozdział 2.1.- Linux Traffic Control, Opis
mechanizmu Traffic Control w systemie Linukx, http://opalsoft.net/qos/DS-21.htm,
strona odwiedzona 10.09.2011
[10]
Dokumentacja polecenia tc w systemie Linux, strona man w systemie Linux Mandriva
2010
[11]
Dokumentacja polecenia ip6tables w systemie Linux, strona man w Linuksie
Mandriva 2010
[12]
prof. Zieher, materiały dydaktyczne New Internet Protocols, Hochschule Esslingen,
Niemcy, 2008
[13]
Peter Benko (ETH), Domonkos Asztalos (ETH), Csaba Simon (BME), Vassilios
Kaldanis (VELTI), EFIPSANS Integration Framework, INFSO-ICT-
215549/WP5/D.5.1, , dokument powstał w ramach projektu EFIPSANS, artykuł
dostępny na http://www.efipsans.org, odwiedzonej 01.06.2011
144
[14]
Kod źródłowy jądra systemu Linux 2.6.37, dostępny jako pakiet rpm w dystrybucji
systemu Linux Mandriva 2010
[15]
RFC 2675, IPv6 Jumbograms, 1998
[16]
RFC 2711, IPv6 Router Alert Option, 1999
[17]
Emanuela Lins, Saurabh Agarwal, IPv6 Implementation Study, A study of IPv6
Implementation in Linux, 2003
[18]
RFC 3879, Deprecating Site Local Addresses, 2004
[19]
Sławomir Kukliński, Paweł Radziszewski, Jacek Wytrębowicz, Ipv6 in Wireless
Networks – Selected Issues, Journal of Telecommunications and Information
Technology 2/2011
145
Spis tabel.
Tab. 1: Odpowiadające sobie pole w nagłówkach IPv4 i IPv6.................................................14
Tab. 2: Bezstanowa konfiguracja adresu IPv6. Przykład..........................................................16
Tab. 3: Nagłówki rozszerzające IPv6........................................................................................17
Tab. 4: Protokoły Inet6..............................................................................................................28
Tab. 5: Porównanie cech sposobó implementacji.....................................................................48
Tab. 6: Ruch scp; Kierunek „w przód”.....................................................................................74
Tab. 7: Ruchu scp; Kierunek „wstecz”.....................................................................................75
Tab. 8: Ruch vlc; Kierunek „w przód”.....................................................................................76
Tab. 9: Parametry kształtowania ruchu. Przykład.....................................................................81
Tab. 10: Test w. 1; Priorytet 3; Parametry kształtowania ruchu................................................92
Tab. 11: Test w. 1; Priorytet 3; Parametry przesyłanego sygnału.............................................92
Tab. 12: Test w. 1; Priorytet 3; Parametry warstwy transportowej...........................................92
Tab. 13: Test w. 2; Priorytet 4; Parametry kształtowania ruchu................................................93
Tab. 14: Test w. 2; Priorytet 4; Parametry przesyłanego sygnału.............................................93
Tab. 15: Test w. 2; Priorytet 4; Parametry warstwy transportowej...........................................93
Tab. 16: Test w. 3; Priorytet 4; Parametry kształtowania ruchu................................................94
Tab. 17: Test w. 3; Priorytet 4; Parametry przesyłanego sygnału.............................................94
Tab. 18: Test w. 3; Priorytet 4; Parametry warstwy transportowej...........................................95
Tab. 19: Test o. 1; Priorytet 2; Parametry kształtowania ruchu................................................96
Tab. 20: Test o. 1; Priorytet 2; Parametry przesyłanego sygnału..............................................96
Tab. 21: Test o. 1; Priorytet 2; Parametry warstwy transportowej............................................96
Tab. 22: Test o. 2; Priorytet 3; Parametry kształtowania ruchu................................................97
Tab. 23: Test opóźnienia 2; Priorytet 3; Parametry przesyłanego sygnału...............................97
Tab. 24: Test opóźnienia 2; Priorytet 3; Parametry warstwy transportowej;............................97
Tab. 25: Test o. 3; Priorytet 4; Parametry kształtowania ruchu................................................97
Tab. 26: Test o. 3; Priorytet 4; Parametry przesyłanego sygnału..............................................98
Tab. 27: Test o. 3; Priorytet 4; Parametry warstwy transportowej............................................98
Tab. 28: Test o. 4; Priorytet 2; Parametry kształtowania ruchu................................................98
Tab. 29: Test o. 4; Priorytet 2; Parametry przesyłanego sygnału..............................................98
Tab. 30: Test o. 4; Priorytet 2; Parametry warstwy transportowej............................................99
Tab. 31: Test o. 5; Priorytet 2; Parametry kształtowania ruchu................................................99
Tab. 32: Test o. 5; Priorytet 2; Parametry przesyłanego sygnału..............................................99
Tab. 33: Test o. 5; Priorytet 2; Parametry warstwy transportowej..........................................100
Tab. 34: Test p. 1; Parametry kształtowania ruchu.................................................................109
Tab. 35: Test p. 1; Parametry ruchu podkładowego................................................................109
Tab. 36: Test p. 1; Parametry przesyłanego sygnału...............................................................109
Tab. 37: Test p. 1; Parametry warstwy transportowej.............................................................109
Tab. 38: Test p. 2; Parametry kształtowania ruchu..................................................................110
Tab. 39: Test p. 2; Parametry ruchu podkładowego................................................................110
Tab. 40: Test p. 2; Parametry przesyłanego sygnału...............................................................110
Tab. 41: Test p. 2; Parametry warstwy transportowej.............................................................111
Tab. 42: Test p. 3; Parametry kształtowania ruchu..................................................................111
146
Tab. 43: Test p. 3; Parametry ruchu podkładowego................................................................112
Tab. 44: Test p. 3; Parametry przesyłanego sygnału...............................................................112
Tab. 45: Test p. 3; Parametry warstwy transportowej.............................................................112
Tab. 46: Test p. 4; Parametry kształtowania ruchu..................................................................113
Tab. 47: Test p. 4; Parametry ruchu podkładowego................................................................113
Tab. 48: Test p. 4; Parametry przesyłanego sygnału...............................................................113
Tab. 49: Test p. 4; Parametry warstwy transportowej.............................................................113
Tab. 50: Test p. 5; Parametry kształtowania ruchu..................................................................114
Tab. 51: Test p. 5; Parametry ruchu podkładowego................................................................115
Tab. 52: Test p. 5; Parametry przesyłanego sygnału...............................................................115
Tab. 53: Test p. 5; Parametry warstwy transportowej.............................................................115
Tab. 54: Test p. 6; Parametry kształtowania ruchu..................................................................116
Tab. 55: Test p. 6; Parametry ruchu podkładowego................................................................116
Tab. 56: Test p. 6; Parametry przesyłanego sygnału...............................................................116
Tab. 57: Test p. 6; Parametry warstwy transportowej.............................................................117
Tab. 58: Test p. 7; Parametry kształtowania ruchu..................................................................117
Tab. 59: Test p. 7; Parametry ruchu podkładowego................................................................118
Tab. 60: Test p. 7; Parametry przesyłanego sygnału...............................................................118
Tab. 61: Test p. 7; Parametry warstwy transportowej.............................................................118
Tab. 62: Test p. 8; Parametry kształtowania ruchu..................................................................119
Tab. 63: Test p. 8; Parametry ruchu podkładowego................................................................119
Tab. 64: Test p. 8; Parametry przesyłanego sygnału...............................................................120
Tab. 65: Test p. 8; Parametry warstwy transportowej.............................................................120
Tab. 66: Test p. 9; Parametry kształtowania ruchu.................................................................120
Tab. 67: Test p. 9; Parametry ruchu podkładowego................................................................121
Tab. 68: Test p. 9; Parametry przesyłanego sygnału...............................................................121
Tab. 69: Test p. 9; Parametry warstwy transportowej.............................................................121
Tab. 70: Test p. 10; Parametry kształtowania ruchu...............................................................122
Tab. 71: Test p. 10; Parametry ruchu podkładowego..............................................................122
Tab. 72: Test p. 10; Parametry przesyłanego sygnału.............................................................123
Tab. 73: Test p. 10; Parametry warstwy transportowej...........................................................123
Tab. 74: Test p. 11; Parametry kształtowania ruchu................................................................123
Tab. 75: Test p. 11; Parametry ruchu podkładowego..............................................................124
Tab. 76: Test p. 11; Parametry przesyłanego sygnału.............................................................124
Tab. 77: Test p. 11; Parametry warstwy transportowej...........................................................124
Tab. 78: Test p. 12; Parametry kształtowania ruchu...............................................................125
Tab. 79: Test p. 12; Parametry ruchu podkładowego..............................................................125
Tab. 80: Test p. 12; Parametry przesyłanego sygnału.............................................................125
Tab. 81: Test p. 12; Parametry warstwy transportowej...........................................................126
Tab. 82: Test p. 13; Parametry kształtowania ruchu...............................................................126
Tab. 83: Test p. 13; Parametry ruchu podkładowego..............................................................127
Tab. 84: Test p. 13; Parametry przesyłanego sygnału.............................................................127
Tab. 85: Test p. 13; Parametry warstwy transportowej...........................................................127
Tab. 86: Test p. 14; Parametry kształtowania ruchu...............................................................128
Tab. 87: Test p. 14; Parametry ruchu podkładowego..............................................................128
Tab. 88: Test p. 14; Parametry przesyłanego sygnału.............................................................129
147
Tab. 89: Test p. 14; Parametry warstwy transportowej...........................................................129
Tab. 90: Test p. 15; Parametry kształtowania ruchu...............................................................130
Tab. 91: Test p. 15; Parametry ruchu podkładowego..............................................................130
Tab. 92: Test p. 15; Parametry przesyłanego sygnału.............................................................130
Tab. 93: Test p. 15; Parametry warstwy transportowej...........................................................131
148
Spis rysunków.
Rys. 1: Adres IPv6 Link-local...................................................................................................11
Rys. 2: Adres interfejsu IF-ID...................................................................................................12
Rys. 3: Adres IPv6 Global Unicast............................................................................................12
Rys. 4: Nagłówek IPv4..............................................................................................................13
Rys. 5: Nagłówek IPv6..............................................................................................................14
Rys. 6: Bezstanowa konfiguracja adresu IPv6..........................................................................16
Rys. 7: Sekwencja nagłówków rozszerzających.......................................................................18
Rys. 8: Bezpośrednia komunikacja z węzłem mobilnym.........................................................19
Rys. 9: Komunikacja z węzłem mobilnym; Wykorzystanie pośrednika...................................19
Rys. 10: Nagłówek hop-by-hop................................................................................................21
Rys. 11: Struktura opcji nagłówka hop-by-hop.........................................................................21
Rys. 12: Padding 0....................................................................................................................22
Rys. 13: Padding n bajtów.........................................................................................................22
Rys. 14: Obsługa pakietów przychodzących.............................................................................24
Rys. 15: Obsługa pakietów wychodzących...............................................................................25
Rys. 16: Zaczepy.......................................................................................................................39
Rys. 17: Architektura aplikacji: warstwa transportowa i aplikacja kliencka............................54
Rys. 18: Przykładowe histogramy opóźnienia dla priorytetów 2, 3, 4......................................57
Rys. 19: Warstwa transportowa; Część wysyłająca; Logowanie zdarzeń.................................58
Rys. 20: Architektura warstwy transportowej; część odbierająca.............................................63
Rys. 21: Histogramy sygnałów – prezentacja sygnałów...........................................................66
Rys. 22: Wykres sygnału – prezentacja sygnałów....................................................................67
Rys. 23: Aplikacja kliencka. Logowanie zdarzeń.....................................................................69
Rys. 24: Środowisko testowe....................................................................................................72
Rys. 25: Wykres ruchu scp i vlc – wielkość pakietów..............................................................78
Rys. 26: Wykres ruchu scp i vlc – odstęp między pakietami....................................................79
Rys. 27: Ruch scp i vlc – histogram wielkości pakietów..........................................................79
Rys. 28: Ruch scp i vlc – histogram odstępu............................................................................80
Rys. 29: Mechanizm wiadra żetonów.......................................................................................81
Rys. 30: Struktura kształtowania ruchu; Przykład....................................................................83
Rys. 31: Wykres opóźnienia – testy opóźnienia......................................................................103
Rys. 32: Histogram opóźnienia – testy opóźnienia.................................................................104
Rys. 33: Histogram odstępu – testy opóźnienia......................................................................106
Rys. 34: Dystrybuanta opóźnienia – testy przesyłania danych...............................................132
Rys. 35: Wykres opóźnienia – testy przesyłania danych.........................................................132
Rys. 36: Statystyki transmisji – testy przesyłania danych......................................................134
Rys. 37: Histogram opóźnienia – testy przesyłania danych....................................................136
Rys. 38: Wykres sygnału – testy przesyłania danych..............................................................137
Rys. 39: Histogram odstępu – testy przesyłania danych.........................................................141
Rys. 40: Klient - GUI..............................................................................................................154
149
Spis listingów.
Listing 1: Struktura bufora sk_buff (include/linux/sk_buff.h)..................................................26
Listing 2: Struktura wskaźników do nagłówków (include/linux/sk_buff.h).............................27
Listing 3: Dane tymczasowe protokołów obsługujących include/linux/sk_buff.h..................28
Listing 4: Struktura packet_type (include/linux/netdevice.h)...................................................28
Listing 5: Struktura ipv6_packet_type (net/ipv6/ipv6_sockglue.c)..........................................29
Listing 6: Struktura Inet6_protocol (include/net/protocol.h)....................................................30
Listing 7: Struktura proto_ops (include/linux/net.h).................................................................30
Listing 8: Struktura Inet6_stream_ops (net/ipv6/af_inet6.c)....................................................31
Listing 9: Struktura Inet6_dgram_ops (net/ipv6/af_inet6.c).....................................................31
Listing 10: Uzupełnianie strukty ipv6_txoptions......................................................................34
Listing 11: Rejestracja nowej zmiennej w przestrzeni jądra.....................................................36
Listing 12: Odczytanie nagłówka hop-by-hop..........................................................................38
Listing 13: Fragmenty jądra, w których zarejestrowano zaczepy. Plik net/ipv6/ip6_output.c. 41
Listing 14: Fragmenty jądra, w których zarejestrowano zaczepy. Plik net/ipv6/ip6_input.c. .41
Listing 15: Użycie zaczepów. Przykład....................................................................................42
Listing 16: Stworzenie filtra pakietów. Polecenie ip6tables. Przykład 1..................................44
Listing 17: Przetwarzanie pakietów w przestrzeni użytkownika. Język C++...........................45
Listing 18: Utworzenie filtra pakietów. Polecenie ip6tables. Przykład 2.................................46
Listing 19: Przetwarzanie pakietów w przestrzeni użytkownika. Język Python......................47
Listing 20: Funkcja przetwarzająca pakiety. Język Python......................................................48
Listing 21: Plik iniput-1.ini.....................................................................................................159
Listing 22: Plik input2-2.ini....................................................................................................161
150
Załącznik A. Dokumentacja użytkowa programu testowego
Wymagania systemowe:
•
system operacyjny Linux z wersją jądra mininum 2.6.37; jądro musi być
skompilowane ze wsparciem dla mechanizmu nfnetlink_queue, np. Jądro dostępne w
systemie Mandriva 2010
•
biblioteka libnfnetlink, wersja minimum 1.0.0
•
biblioteka libnetfilter_queue, wersja minimum 1.0.0
•
zainstalowany język Python w wersji minimum 2.6.5
•
biblioteka do języka Python pygtk, wersja minimum 2.17
•
biblioteka do języka Python dpkt, wersja minimum 1.7
•
biblioteka do języka Python nfqueue, wersja minimum 0.3
Pliki programu testowego
Program warstwy transportowej:
•
gtk-widget6-v2.py – plik programu
•
input-1.ini – plik z parametrami konfiguracyjnymi
Program aplikacji klienckiej:
•
client-gen-data-v3.py – plik programu
•
input-2.ini – plik z parametrami konfiguracyjnymi
Uruchamianie programu testowego
Program warstwy transportowej:
1. Skonfigurować poleceniem ip6tables filtrację pakietów, które będą trafiały do aplikacji. ?
2. Przejść do katalogu z plikami gtk-widget6-v2.py oraz input-1.ini i wykonać komendę z linii
poleceń z użytkownika root (bash, sh): python gtk-widget6-v2.py.
Program aplikacji klienckiej:
151
1. Przejść do katalogu z plikami client-gen-data-v3.py i input-2.ini. Program testowy
powinien być uruchamiany z użytkownika innego niż root. W linii poleceń wykonać
komendę: python client-gen-data-v3.py
Zatrzymywanie programu testowego.
Program warstwy transportowej:
1. Zabić proces programu warstwy tranportowej przy użyciu polecenia kill.
Program aplikacji klienckiej:
2. Zabić proces programu klienta przy użyciu polecenia kill.
Opis pliku konfiguracyjnego init-1.ini
Przykładowa zawartość pliku init-1.ini przedstawiona jest na Listingu 21.
Listing 21: Plik iniput-1.ini
[Address]
152
Rys. 40: Klient - GUI
MY_ADDRESS: fec0::1:2
DEST_ADDRESS: fec0::1:3
DELAY_PORT: 6665
DIRECT_PORT: 6661
PRIORITY_PORT: 6666
CLIENT_SENDER_PORT: 23000
CLIENT_RECEIVER_PORT: 23002
[Transport]
MAX_PAYLOAD=1360
MAX_DELAY=0.020
DIRECT_TYPE=0
[Log]
LOG_ALL_PACKET: 1
[Others]
NUM_OF_PACKETS: 10000
DELAY_LOOP: 100000
Znaczenie poszczególnych pól pliku input-1.ini:
MY_ADDRESS – adres IPv6 komputera
DEST_ADDRESS – adres IPv6 komputera warstwy transportowej do której będą wysyłane
dodatkowe pakiety generowane przez warstwę transportową
DELAY_PORT – numer portu na który wysyłane są dodatkowe pakiety dla priorytetu 2
DIRECT_PORT – numer portu na który wysyłane są dodatkowe pakiety dla priorytetu 3
-PRIORITY_PORT – numer portu na który wysyłane są dodatkowe pakiety dla priorytetu 4
-CLIENT_SENDER_PORT – numer portu na którym warstwa transportowa nasłuchuje na
podłączenie się klienta, jest to kanał do wysyłania wiadomości od klienta do warstwy
transportowej
-CLIENT_RECEIVER_PORT – numer portu na którym warstwa transportowa nasłuchuje na
podłączenie się klienta, jest to kanał do przesyłania klientowi wiadomości odebranych przez
warstwę transportową
-MAX_PAYLOAD – maksymalna długość pakietu wychodzącego do którego zostanie
doklejony nagłówek hop-by-hop
-MAX_DELAY – czas po którym wysyłane sa dodatkowe pakiety dla priorytetu 2
153
-DIRECT_TYPE – typ mechanizmu potwierdzenia dla priorytetu 4, wartość 0 oznacza
mechnizm potwierdzenia drugiego typu, wartość 1 oznacza mechanizm potwierdzenia
pierwszego typu
-LOG_ALL_PACKET – włączenie logowania wszystkich pakietów przychodzących i
wychodzących, wartość 1 oznacza, że logowane są do pliku server3b.txt i server5b.txt
wszystkie pakiety przekazywane przez jądro do programu, zarówno wychodzące jak i
przychodzące, wartość 0 oznacza że pakiety nie są logowane
-NUM_OF_PACKETS – maksymalna liczba wiadomości, które przetworzy warstwa
transportowa, po tej liczbie program przestanie przetwarzać nowe wiadomości
-DELAY_LOOP – maksymalna liczba przejścia przez pętlę wątku, który wysyła dodatkowe
wiadomości dla priorytetu 2, uruchomienie nowego przejścia przez pętlę odbywa się co okres
czasu ustawiony w parametrze MAX_DELAY
Opis pliku konfiguracyjnego init-2.ini
Przykładowa zawartość pliku init-2.ini przedstawiona jest na Listingu 22.
Listing 22: Plik input2-2.ini
[Address]
MY_ADDRESS: fec0::1:2
CLIENT_SENDER_PORT: 23000
CLIENT_RECEIVER_PORT: 23002
[Signal]
CONSTANT_TIME_SLEEP: 0.030
RANDOM_MIN_FLOAT: 0.045
RANDOM_MAX_FLOAT: 0.085
CONSTANT_TIME_FAST: 0.020
FAST_MODE_MIN_COUNT: 100
FAST_MODE_MAX_COUNT: 200
SLOW_MODE_MIN_FLOAT: 1.0
SLOW_MODE_MAX_FLOAT: 1.1
[Others]
NUM_OF_PACKETS: 1000
Znaczenie poszczególnych pól pliku input-1.ini:
- MY_ADDRESS – adres IPv6 komputera
154
-CLIENT_SENDER_PORT – numer portu na którym warstwa transportowa nasłuchuje na
podłączenie się klienta, jest to kanał do wysyłania wiadomości od klienta do warstwy
transportowej
-CLIENT_RECEIVER_PORT – numer portu na którym warstwa transportowa nasłuchuje na
podłączenie się klienta, jest to kanał do przesyłania klientowi wiadomości odebranych przez
warstwę transportową
-CONSTANT_TIME_SLEEP – parametr sygnału typu constant, odstęp pomiędzy kolejnymi
wiadomościami
-RANDOM_MIN_FLOAT – parametr sygnału typu random, minimalna wartość generatora
losowego odstępu czasu
-RANDOM_MAX_FLOAT – parametr sygnału typu random, maksymalna wartość
generatora losowego odstępu czasu
-CONSTANT_TIME_FAST – parametr sygnału typu snmp-like, odstęp pomiędzy kolejnymi
wiadomościami w serii
-FAST_MODE_MIN_COUNT – parametr sygnału typu snmp-like, minimalna liczba
wiadomości w serii
-FAST_MODE_MAX_COUNT – parametr sygnału typu snmp-like, maksymalna liczba
wiadomości w serii
-SLOW_MODE_MIN_FLOAT – parametr sygnału typu snmp-like, minimalna wartość
generatora losowego odstępu czasu
-SLOW_MODE_MAX_FLOAT – parametr sygnału typu constant, maksymalna wartość
generatora losowego odstępu czasu
-NUM_OF_PACKETS – liczba wiadomości, które wygeneruje klient
Obsługa GUI aplikacji klienta
Na Rys. 40 przedstawiono okno aplikacji klienta. Znaczenie poszczególnych fragmentów
GUI:
Obszar Signal składa się z następujących pól:
- check box Generate – uruchamia generowanie i wysyłanie wiadomości do serwera dla
sygnału opisanego przez ustawienia pól z obszaru Signal: Opt Type, Priority, Signal oraz z
wartościami parametrów z pliku wsadowego input-1.ini
- pole wyboru wartości Opt Type - numer opcji, który będzie nadany przesyłanym danym
w formacie TLV upakowanym w nagłówku hop-by-hop
155
- pole wyboru Priority – priorytet przesłania danych, który będzie nadany wygenrowanym
wiadomościom
- pole wyboru Signal – wybór typu sygnału
Obszar Statistic składa się z następujących pól:
- etykieta Packet generated – szacowana liczba wysłanych wiadomości do serwera
- etykieta Packet received – szacowana liczba odebranych wiadomości od serwera
- etykieta Packet waiting for send – szacowana liczba wiadomości oczekujących na wysłanie
do serwera
Obszar Client-Server communication składa się z dwóch podobszarów: Client->Server i
Server<-Client.
Podobszar Client->Server składa się z następujących pól:
- checkbox Connect to Server – uruchamia połączenie do wysyłania wiadomości między
klientem i serwerem wykorzystując parametry ustawione w polach Host i Port
- etykieta Host – ustawiony adres serwera
- etykieta Port – ustawiony port serwera
- pole do wprowadzania Host – pole do wprowadzenia adresu serwera
- pole do wprowadzania Port – pole do wprowadzenia portu serwera
Podobszar Client<-Server składa się z następujących pól:
- checkbox Connect to Server – uruchamia połączenie do odbierania wiadomości między
klientem i serwerem wykorzystując parametry ustawione w polach Host, Port i Check
Interval (s).
- pole do wprowadzenia List Opt Types – lista numerów opcji oddzielonych przecinkiem,
które będą przekazywane przez serwer do klienta
- etykieta Host – ustawiony adres serwera
- etykieta Port – ustawiony port serwera
- pole do wprowadzania Host – pole do wprowadzenia adresu serwera
- pole do wprowadzania Port – pole do wprowadzenia portu serwera
156
Załącznik B. Zawartość płyty CD dołączonej do pracy.
⁃ app - kod źródłowy programu testowego
⁃ app/resultAnalyzer2-v2.py - skrypt w języku Python do analizowania logów
programu, generuje wykresy, które zostały wykorzystane w pracy
⁃ doc - tekst pracy w formacie pdf i odt
⁃ app-cpp - kod źródłowy implementacji dodawania nagłówka hop-by-hop z użyciem
biblioteki libnetfilter_queue, napisany w języku C++
⁃ app-kernel – zmodyfikowane pliki jądra systemu Linux w wersji ..., które umożliwiają
nadawanie i odbieranie wiadomości wykorzystując nagłówek hop-by-hop
⁃ app-warf – fragment wstępnej wersji implementacji, wykorzystującej zaczepy,
związanej z projektem EFIPSANS
⁃ kod źródłowy bibliotek, które były zainstalowane na komputerze ze źródeł:
app-depend/dpkt-1.7 - dpkt
app-depend/iptables-1.4.10 - iptables
app-depend/libnfnetlink-1.0.0.tar.bz2 - libnfnetlink
app-depend/libnfnetlink-1.0.0.tar.bz2 - libnetfilter_queue
app-depend/nfqueue-bindings-0.3.tar.gz - nfqueue-bindings
157
Document Outline
- WYKAZ UŻYWANYCH SKRÓTÓW
- 1. WSTĘP
- 2. Protokół IPv6
- 3. Implementacja protokołu IPv6 w systemie Linux
- 4. Przegląd możliwych implementacji programu.
- 5. Środowisko stworzone do testownia wykorzystania nagłówka hop-by-hop, jako kanału komunikacyjnego
- 6. Środowisko testowe
- 7. Testy akceptacyjne.
- 8. Testy wydajności i opóźnienia
- 8.1 Test w. 1. Priorytet 3.
- 8.2 Test w. 2. Priorytet 4. Typ potwierdzenia 2.
- 8.3 Test w. 3. Priorytet 4. Typ potwierdzenia 1.
- 8.4. Test o. 1. Priorytet 2. Syg. Constant.
- 8.5 Test o. 2. Priorytet 3. Syg. Constant.
- 8.6 Test o. 3. Priorytet 4. Syg. Const.
- 8.7 Test o. 4. Priorytet 2. Syg. Random.
- 8.8 Test o. 5. Priorytet 2. Sygnał snmp-like.
- 8.9 Podsumowanie testów wydajności i opóźnienia.
- 9. Testy przesyłania danych.
- 9.1 Test p. 1. Priorytet 1. Scp. Syg. random.
- 9.2 Test p. 2. Priorytet 1. Scp. Syg. random rzadki.
- 9.3 Test p. 3. Priorytet 2. Scp. Syg. const. Kier. przeciwny.
- 9.4 Test p. 4. Priorytet 2. Scp. Syg. const. Kier. zgodny.
- 9.5 Test p. 5. Priorytet 2. Scp. Syg. const. Kier. zgodny. Tc duże opóźnienie.
- 9.6 Test p. 6. Priorytet 4. Scp. Syg. const. Kier. zgodny. Tc duże opóźnienie.
- 9.7 Test p. 7. Priorytet 4. Scp. Syg. const. Kier. zgodny. Tc małe opóźnienie.
- 9.8 Test p. 8. Priorytet 2. Vlc. Syg. const.
- 9.9 Test p. 9. Priorytet 2 duży odstęp. Vlc. Syg. const.
- 9.10 Test p. 10. Priorytet 1. Vlc. Syg. const.
- 9.11 Test p. 11. Priorytet 2. Vlc. Syg. snmp-like.
- 9.12 Test p. 12. Priorytet 4. Vlc. Syg. snmp-like.
- 9.13 Test p. 13. Priorytet 3. Vlc. Syg. snmp-like.
- 9.14 Test p. 14. Priorytet 4. Vlc. Tc. Syg. snmp-like.
- 9.15 Test p. 15. Priorytet 3. Vlc. Tc. Syg. snmp-like.
- 9.16 Podsumowanie testów przesyłania danych
- 10. Podsumowanie testów
- LITERATURA
- Spis tabel.
- Spis rysunków.
- Spis listingów.
- Załącznik A. Dokumentacja użytkowa programu testowego
- Załącznik B. Zawartość płyty CD dołączonej do pracy.
Wyszukiwarka
Podobne podstrony:
5a 6 5 2 5 Lab Rozwiązywanie problemów związanych z trasami statycznymi IPv4 oraz IPv6
IPv4 oraz IPv6, Prace - dokumenty
8 2 5 4 Lab Identifying IPv6?dresses
lab2 IPv6
IPv6 2 Datagram IPv6
8 2 5 5 Lab Configuring IPv6?dresses on Network?vices
IP v 6, IPv6
Protokol internetowy IPv6
IPv6 4 Neighbor Discovery
IPv6 r6
0 0 0 2 Lab Installing the IPv6 Protocol with Windows XP
Czy IPv6 SEIP2013
8 3 2 8 Packet Tracer Troubleshooting IPv4 and IPv6?dressing Instructions
IPv6 3 ICMPv6
IPV6 RIP
8 3 2 5 Packet Tracer Verifying IPv4 and IPv6?dressing Instructions
8 2 5 4 Lab Identyfikowanie adresow IPv6 id (2)
IPv6 Lekturka
więcej podobnych podstron