zastosowanie systemc do modelowania protokołów tcp/ip

www.pwt.et.put.poznan.pl
2005
Agata Zieli ska
Piotr Dziurza ski
Wydział Informatyki
Politechnika Szczeci ska
ul. ołnierska 49, 71-210 Szczecin
[email protected]
Poznańskie Warsztaty Telekomunikacyjne
Poznań 8 - 9 grudnia 2005
ZASTOSOWANIE SYSTEMC DO MODELOWANIA PROTOKOŁÓW TCP/IP
Streszczenie: W referacie zaprezentowano j zyk SystemC
jako narz dzie modelowania protokołów sieciowych
z grupy
TCP/IP.
Nast pnie
opracowano
i zaimplementowano protokół DHCP w j zyku SystemC,
a tak e przeprowadzono badania eksperymentalne
i okre lono przydatno
omawianego narz dzia do
modelowania protokołów sieciowych.
cyfrowych w j zyku C++. SystemC pozwala
modelowa
algorytmy programowe, architektury
sprz towe, układy SoC (System on a Chip) oraz
projekty na poziomie systemów. Poł czenie j zyka
programowania obiektowego i zestandaryzowanej
biblioteki umo liwia tworzenie modeli na poziomie
systemów oraz szybk symulacj , pozwalaj c na
weryfikacj i optymalizacj modeli ju na poziomie
projektu, badanie wielu algorytmów oraz dostarczenie
wykonywalnej
specyfikacji
systemu
zespołom
zajmuj cym si ró nymi zagadnieniami systemu [4].
J zyk SystemC jest dost pny w wersji
referencyjnej na zasadach oprogramowania otwartego,
co pozwala na jego szerokie wykorzystanie.
Oprogramowanie komercyjne wspieraj ce tworzenie
projektów w j zyku C++ mo e bez adnych przeszkód
dostarcza
rozwi zania
wspieraj ce
równie
modelowanie w SystemC. Biblioteka SystemC jest
udost pniana w wersji zarówno dla maszyn
pracuj cych z systemem Microsoft Windows jak
i UNIX. Zarówno bibliotek jak i ró nego rodzaju
dokumentacj
mo na
pobra
ze
strony
www.systemc.org.
Modelowanie systemów cyfrowych w SystemC
dzi ki zastosowaniu mechanizmów wprowadzanych
przez bibliotek SystemC jest łatwe i przypomina
konstruowanie modeli w j zykach opisu sprz tu takich
jak VHDL [5]. Uzyskano narz dzie wyposa one
w nowoczesne mechanizmy modelowania takie jak
enkapsulacja, dziedziczenie, wzorce, czy polimorfizm,
które umiej tnie zastosowane prowadz do tworzenia
wysokiej jako ci modeli oraz do łatwo ci
przekształcania ich od poziomu funkcjonalnego do
poziomu przesła
miedzy rejestrowych, bez
konieczno ci zmiany narz dzia.
Podstawowymi elementami budowy modelu w
j zyku SystemC s hierarchicznie zorganizowane
moduły, implementowane jako klasy pochodne klasy
bazowej sc_module, dzi ki czemu naturalne dla C++
mechanizmy s przeniesione do SystemC, co stanowi
istotne rozszerzenie w stosunku do typowych j zyków
opisu sprz tu [5].
SystemC pozwala na elastyczne wykorzystanie
portów pozwalaj c na ich bezpo rednie wi zanie lub
ł czenie za po rednictwem sygnałów w zale no ci od
tego, które rozwi zanie jest wygodniejsze lub lepiej
1.
WST P
Ze wzgl du na cechy charakterystyczne
protokołów z grupy TCP/IP oraz zmienne rodowisko
pracy
tych
protokołów
tworzenie
modeli
i przeprowadzanie bada pozwalaj cych oceni ich
wydajno
i funkcjonalno
stanowi do
istotny
problem. Dodatkowo dost pno
oprogramowania
wspieraj cego tworzenie modeli i ich badanie jest
niewielka ze wzgl du na jego wysokie ceny i mał
elastyczno odno nie poziomu abstrakcji tworzonych
modeli.
W niniejszym referacie zostanie opisany j zyk
SystemC uwa any głównie za narz dzie modelowania
sprz towego. Pokazane zostanie, e poziom abstrakcji
tego j zyka pozwala z powodzeniem modelowa
równie rozwi zania programowe. W rozdziale 3
zostanie pokrótce omówiony wybrany protokół
TCP/IP, który posłu y jako przykład modelu
zaimplementowanego w SystemC. Przedstawiona
zostanie droga od opracowania uproszczonego
algorytmu protokołu poprzez opisanie modelu w
j zyku UML i ostateczne zaimplementowanie
stworzonego modelu w j zyku SystemC.
Celem niniejszego referatu jest zaprezentowanie
j zyka SystemC jako narz dzia modelowania
protokołów sieciowych z grupy TCP/IP. Wybrany
protokół z rodziny TCP/IP, DHCP, zostanie
opracowany pod wzgl dem modelowania w SystemC
i zaimplementowany,
a
nast pnie
zostan
przeprowadzone badania eksperymentalnie i okre lona
przydatno omawianego narz dzia do modelowania
protokołów sieciowych.
2. SYSTEMC JAKO J ZYK MODELOWANIA
PROTOKOŁÓW.
J zyk SystemC jest zestandaryzowan bibliotek
oraz metodologi modelowania systemów i układów
PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005
1/6
www.pwt.et.put.poznan.pl
odzwierciedlaj ce
rzeczywiste
przekazywanie
komunikatów.
Sprowadzenie
zadania
projektanta
do
konieczno ci przygotowania programu w j zyku C++
z wykorzystaniem biblioteki SystemC, który jest
wykonywany na danej platformie sprz towej w celu
przeprowadzenia symulacji modelu, powoduje
wymuszenie kompletno
modelu wyró niaj c
SystemC w ród j zyków opisu sprz tu. Dodatkowo
baza w postaci obiektowego j zyka programowania
pozwala uzupełni model np. o graficzny interfejs
u ytkownika symulacji czy te
interfejsy do
rzeczywistych urz dze peryferyjnych. Własno ta
jest własno ci dodan j zyka SystemC, niedost pn
lub trudno dost pn w innych j zykach modelowania
sprz tu [5].
3. OPIS DZIAŁANIA PROTOKOŁU DHCP
Po upłyni ciu połowy czasu wynajmu klient ma
prawo do próby odnowienia powi zania adresu na
kolejny okres czasu. W tym celu wysyła na adres
serwera, który przyznał mu konfiguracj , komunikat z
pro b o odnowienie wynajmu. Serwer mo e udzieli
takiej zgody lub j odrzuci – w takim przypadku
klient ma obowi zek natychmiastowego porzucenia
adresu sieciowego i mo e rozpocz
procedur
uzyskania konfiguracji od nowa. W przypadku, kiedy
po 87,5% czasu wynajmu klient nie otrzyma
odpowiedzi od serwera, wysyła ponownie komunikat
z pro b
o przedłu enie wynajmu tym razem
rozgłaszaj c go. Dowolny serwer w podsieci mo e
wyrazi zgod na przedłu enie wynajmu adresu lub
pro b
odrzuci . Otrzymanie komunikatu
tak
przedłu aj cego czas wynajmu upowa nia klienta do
dalszego wykorzystywania adresu, brak zgody
powoduje natychmiastowe porzucenie adresu i
rozpocz cie procedury inicjuj cej, a brak odpowiedzi
powoduje samoczynne wyga ni cie czasu wynajmu
i przej cie klienta do stanu inicjalizacji.
Aby lepiej zobrazowa
sposób działania
protokołu DHCP został stworzony sko czony automat
obrazuj cy wszystkie stany protokoły oraz komunikaty
powoduj ce zmiany stanów. Automat został
zaprezentowany na Rys. 1.
Protokół DHCP pracuje w architekturze klient –
serwer, w zwi zku z tym rozdzielone s funkcje
zarówno serwera i klienta. Jedynie uprawnione
maszyny w podsieci mog udziela odpowiedzi na
komunikaty DHCP. Serwery po uruchomieniu
odczytuj swoj baz danych gdzie zapami tana jest
pula adresów sieciowych, którymi dysponuje serwer.
W bazie zapisywane s pó niej informacje czy adres
jest wolny, czy został zaproponowany lub przyznany
i jakiej maszynie – identyfikowanej po jej adresie
fizycznym. Po odczytaniu bazy danych serwer
przechodzi w stan oczekiwania i nasłuchuje czy nie
pojawi si komunikaty od klientów zawieraj cych
zapotrzebowanie na parametry konfiguracji sieci.
Klient zaraz po uruchomieniu odczekuje losowo
wybrany czas i wysyła pierwszy komunikat
rozgłaszaj cy
zapotrzebowanie
na
parametry
konfiguracyjne. Do wysłania tego komunikatu
wykorzystywane jest ograniczone rozgłaszanie, które
dost pne jest dla wszystkich maszyn w podsieci
niezale nie od tego, czy posiada ona własny adres IP,
czy nie. Pakiety wysyłane przez klienta nie
posiadaj cego jeszcze adresu IP s identyfikowane za
pomoc
jego adresu sprz towego, który jest
wystarczaj cy do przesyłania danych na poziomie
sprz towym.
Po otrzymaniu komunikatu z zapotrzebowaniem
klienta wszystkie serwery, je eli maj wolne adresy
sieciowe, wysyłaj odpowied zawieraj c propozycj
konfiguracji maszyny. Odpowied zostaje wysłana za
pomoc ograniczonego rozgłaszania a komunikat poza
danymi niezb dnymi do konfiguracji klienta zawiera
adres IP i adres sprz towy serwera. Klient zbiera
odpowiedzi od serwerów i na podstawie okre lonego
kryterium wybiera jedn
z zaproponowanych
konfiguracji.
W kolejnym rozgłaszanym komunikacie klient
wysyła informacj , któr konfiguracj wybrał i prosi
serwer o jej przyznanie. Serwer zaznacza w swojej
bazie danych, e wybrany adres IP został u yty i
zapisuje adres fizyczny klienta, któremu został on
przyznany. Od tej pory klient mo e u ywa adresu
dopóki nie nast pi odł czenie klienta od sieci lub nie
upłynie czas wynajmu przyznany przez serwer.
Rys. 1. Automat sko czony protokołu DHCP [1]
PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005
Z pełnym składem i opisem wszystkich pól
komunikatu DHCP mo na zapozna si w dokumencie
opisuj cym standard protokołu [3] natomiast na
potrzeby modelu budowanego w j zyku SystemC
komunikaty zostały ograniczone do najwa niejszych
pól niezb dnych do poprawnego skonfigurowania
maszyny do pracy w sieci lokalnej.
W prezentowanym modelu zostan pomini te
niektóre rodzaje komunikatów. Głównym celem
tworzenia modelu było jasne przedstawienie sposobu
działania protokołu oraz zbadanie sposobu jego
zachowania na zmieniaj ce si warunki w sieci.
Pomini te komunikaty nie wpływaj w sposób istotny
na działanie protokołu.
Komunikaty, które zostały wybrane do
implementacji w modelu to [3]: DHCPDISCOVER
2/6
www.pwt.et.put.poznan.pl
(pierwszy komunikat nadawany przez klienta po
wej ciu
w
stan
inicjalizacji
słu cy
do
zakomunikowania potrzeby konfiguracji automatycznej
i umo liwiaj cy odszukanie serwerów wiadcz cych
usługi DHCP), DHCPOFFER (komunikat serwera
zawieraj cy
propozycj
konfiguracji
maszyny
wysyłany w odpowiedzi na zapytanie klienta),
DHCPREQUEST (klient wysyła ten komunikat po
wybraniu konfiguracji z ofert, które nadeszły w
odpowiedzi na jego zapytanie. Komunikat zawiera
identyfikator wybranego serwera dla którego
komunikat jest przeznaczony), DHCPACK (komunikat
wysyłany przez serwer w celu potwierdzenia
przyznania wybranego przez klienta adresu, mo e by
równie u ywany do wyra enia zgody na przedłu enie
czasu wynajmu), DHCPNACK (komunikat wysyłany
przez serwer w momencie odrzucenia pro by klienta,
po otrzymaniu takiego komunikatu klient musi
natychmiast porzuci dotychczasow komunikacj i
przej
do stanu inicjalizacji), DHCPRELEASE
(komunikat wysyłany przez klienta w celu zwolnienia
u ywanego dotychczas zestawu konfiguracyjnego).
Wymienione komunikaty zostały przewidziane
i zaimplementowane w modelu protokołu, przy czym
ka dy komunikat ma dokładnie taki sam format
zaprezentowany powy ej. Jedyne zmiany jakie
zachodz w komunikacie wynikaj z negocjacji mi dzy
klientem i serwerem adresu IP i czasu wynajmu.
doł czony do niniejszej pracy mógł poprawnie
funkcjonowa .
Rys.2. Diagram sekwencji dla modelu DHCP
Diagram stanów, przedstawiony na Rys. 3, słu y
do modelowania ycia jednego obiektu, grupy tych
obiektów lub całego systemu. Opisuje on dynamiczne
zachowanie systemu, przy czym reakcja systemu na ten
sam sygnał mo e si zmienia , w zale no ci od stanu
w jakim si znajdował w momencie nadej cia
komunikatu. Diagram stanów powstał na podstawie
automatu sko czonego z Rys. 1.
4. MODEL DHCP W J ZYKU UML
J zyk UML (Unifield Modeling Laguage) został
stworzony
przez
G.
Booch’a,
I. Jacobson’a
i Rumbaugh’a w 1994 r. i od tamtego czasu był
rozbudowywany najpierw przez konsorcjum wielu firm
a nast pnie przez OMG (Object Managment Group).
Jest to j zyk znormalizowany i mo e by
wykorzystany do tworzenia reprezentacji graficznej
ró nych aspektów modelowanego systemu. Mo na za
jego pomoc
przedstawi
ka dy etap procesu
powstawania systemu, od projektu przez modelowanie,
dokumentacj ,
wdra anie
implementacj ,
i utrzymywanie systemu [2].
Model realizowany na potrzeby niniejszej
pracy został zaprojektowany z wykorzystaniem
diagramów: przypadków u ycia, klas, sekwencji oraz
stanów. Poni ej przedstawiono jedynie diagram
sekwencji i diagram stanów.
Diagram sekwencji, przedstawiony na Rys. 2, jest
jednym z diagramów interakcji, które słu
do
modelowania dynamicznych aspektów modelu.
Diagram sekwencji pokazuje, w jaki sposób i kiedy
wykonywane s operacje oraz przesyłane komunikaty.
Rys. 3. Diagram stanów dla modelu DHCP
Dodatkowo konieczne jest zbudowanie biblioteki
SystemC. W tym celu nale y skorzysta z gotowego
projektu przygotowanego pod Microsoft Visual C++
i wykona kompilacj . Po poprawnym zbudowaniu
biblioteki mo emy tworzy projekty z wykorzystaniem
biblioteki SystemC. Nale y utworzy nowy projekt
jako aplikacj konsoli WIN32.
5. IMPLEMENTACJA DHCP W SYSTEMC
W RODOWISKU WINDOWS
6. BADANIA EKSPERYMENTALNE
Do implementacji modelu w j zyku SystemC
wybrane zostało rodowisko Microsoft Visual C++ 6.0
głównie ze wzgl du na łatwo wbudowania biblioteki
SystemC 2.0.1. Microsoft Visual C++ 6.0 wymaga
zainstalowania co najmniej servicepack 5, eby projekt
W tym rozdziale zostan przedstawione wyniki
bada
eksperymentalnych przeprowadzonych na
modelu DHCP, opracowanym na podstawie algorytmu
zaprezentowanego
w
rozdziale
trzecim
i zaimplementowanego w j zyku SystemC.
PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005
3/6
www.pwt.et.put.poznan.pl
Zaproponowany model DHCP przyjmuje na
wej cie nast puj ce parametry: liczba klientów w
systemie, liczba adresów IP jakimi dysponuje serwer,
domy lny czas wynajmu adresu przyznawany przez
serwer, adresy IP b d ce w puli serwera DHCP,
procentowy poziom zakłóce w kanale.
Parametry badane na wyj ciu pozwol ustali
przy jakich parametrach wej ciowych protokół działa
najbardziej optymalnie oraz pozwol znale granic
obci alno ci serwera.
Badane parametry na wyj ciu to: czas od wysłania
komunikatu DHCPDISCOVER przez klienta do
momentu skonfigurowania w zła, liczba powrotów
klienta do stanu inicjalizuj (resetów klienta) do
momentu skonfigurowania w zła, obci enie kanału
(liczba przesyłanych pakietów na sekund ), liczba
zapyta odebranych przez serwer na sekund .
We wszystkich przypadkach podstaw
do
wyprowadzenia wniosków b dzie rednia danego
parametru
z
okre lonej
liczby
symulacji
przeprowadzonych na konkretnych parametrach
wej ciowych. W badaniach, w których nie jest badana
wydajno systemu w zale no ci od liczby dost pnych
adresów IP zało ono, e serwer DHCP dysponuje pul
pi tnastu adresów sieciowych. Zało ono równie , e
ka da symulacja przeprowadzana b dzie przez 900
sekund, standardowy czas wynajmu wynosi 90 sekund,
czyli 10% czasu ycia systemu, a poziom zakłóce
kanału jest na poziomie 0%, chyba e zaznaczono
inaczej. Wyniki bada
zostały przedstawione
w tabelach.
Skróty zastosowane w tabelach: K – liczba
klientów, A – liczba adresów, W – czas wynajmu, Z –
procentowy wska nik zakłóce w kanale przesyłowym.
Analizuj c wyniki pierwszego badania mo na
zauwa y , e czas skonfigurowania w zła jest
odwrotnie proporcjonalny do ró nicy mi dzy liczb
dost pnych adresów a liczb klientów oczekuj cych na
skonfigurowanie. Zgodnie z oczekiwaniami im wi cej
klientów musi czeka na przyznanie konfiguracji
zwolnionej przez innego klienta, tym dłu szy jest czas
oczekiwania na przydzielenie konfiguracji. Mo na te
zauwa y ,
e
redni czas oczekiwania na
skonfigurowanie w zła przy jednakowej liczbie
klientów i adresów jest podobny niezale nie od liczby
adresów i klientów.
Wprowadzenie
do
kanału
przesyłowego
dodatkowych zakłóce , zgodnie z oczekiwaniami,
czas
oczekiwania
klienta
na
wydłu yło
skonfigurowanie proporcjonalnie do liczby zakłóce .
Wynika to mo e w faktu, e w przypadku braku
odpowiedzi od serwera klient ponawia zapytania po
okre lonym odst pie czasu. Tłumaczy to mo e tak e,
liniowy wzrost czasu oczekiwania w stosunku do
liczby zakłóce .
Drugi zestaw tabel (Tab. 3 i Tab. 4) przestawia
rednie obci enie kanału przesyłowego w zale no ci
od parametrów takich jak liczba dost pnych adresów,
liczba klientów i procent zakłóce
w kanale
przesyłowym.
A
5
K
7
10
15
5
7
10
15
0,18
0,22
0,23
0,21
0,34
0,31
0,32
0,31
0,42
0,47
7,5
7,5
0,65
0,65
7,47
6,18
Tabela 3. rednie obci enie kanału
przesyłowego – liczba pakietów na sekund .
A
5
K
7
10
15
Z
5
8,2
8,3
8,1 7,9
7
16,4
9,7
7,9 8,2
10
30,5 17,5
9,2 8,2
15
64,2 56,8 15,2 8,7
Tabela 1. redni czas upływaj cy od momentu
wysłania pierwszego komunikatu DHCPDISCOVER
przez klienta do momentu skonfigurowania w zła
K
5
7
10
15
5
7
10
15
10
30
50
80
9,4/9,4
18,4/15,7
33,5/29,8
70,6/63,2
9,9/9,9
19,8/12,1
36,9/30,2
76,2/66,6
10,8/10,8
21,8/18,2
40,6/36,1
82,8/70,3
12,3/12,3
24,5/20,9
44,9/39,4
93,2/100,6
Tabela 2. redni czas upływaj cy od momentu
wysłania pierwszego komunikatu DHCPDISCOVER
przez klienta do momentu skonfigurowania w zła przy
pi ciu/pi tnastu adresach sieciowych w puli serwera
DHCP
50
80
0,24/0,18
0,29/0,21
0,45/0,23
0,52/0,41
0,08/0,08
0,14/0,10
0,26/0,11
0,53/0,29
0,08/0,03
0,14/0,08
0,47/0,13
0,35/0,19
0,09/0,12
0,09/0,15
0,23/0,17
0,35/0,24
Z
30
Tabela 4. rednie obci enie kanału
przesyłowego na sekund przy pi ciu/dziesi ciu
adresach sieciowych w puli serwera DHCP
K
10
Wyniki otrzymane w przypadku tego badania
ró ni si od przewidywa autorów. W pierwszej tabeli
w 25% przebiegów generowana jest wyj tkowo du a
liczba pakietów, powoduj ca znaczne zwi kszenie
obci enia kanału. Przypadki takie wyst powały przy
najwi kszych branych pod uwag warto ciach co do
ilo ci klientów i dost pnych adresów. Po przejrzeniu
zapisów z przebiegu symulacji zauwa ono, e po
zwi kszeniu liczby klientów do 10 pojawiły si
stosunkowo du e liczby komunikatów generowanych
przez klienta o identyfikatorze C10. Nie udało si
ustali bezpo redniej przyczyny wyst powania tego
zjawiska, natomiast mo e by wynikiem albo warstwy
sieciowej, do uproszczonej w przypadku badanego
modelu,
albo
wynikiem
nieprawidłowego
funkcjonowania implementacji algorytmu emuluj cego
prac klienta.
Pierwszy zestaw tabel (Tab. 1 i Tab. 2) przestawia
redni czas (w sekundach) skonfigurowania w zła
w zale no ci od parametrów takich jak liczba
dost pnych adresów, liczba klientów i procent
zakłóce w kanale przesyłowym.
PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005
4/6
www.pwt.et.put.poznan.pl
Pozostałe tabele (Tab. 5 - Tab. 7) uwzgl dniaj ce
zakłócenia pojawiaj ce si w kanale przesyłowym
równie wykazuj wyst powanie wy ej omówionego
zjawiska. Jednak wbrew oczekiwaniom, zwi kszanie
liczby zakłóce w kanale nie przyniosło znacz cego
wzrostu obci enia kanału. Z wyj tkiem 25%
odchylenia od reszty wyników spowodowanego
nadmiern aktywno ci jednego z klientów, uzyskane
warto ci s bardzo niskie. Wynika to mo e ze sposobu
reakcji algorytmu klienta na brak odpowiedzi od
serwera. Nie generuje on komunikatów z wi ksz
cz stotliwo ci a wydłu a czas oczekiwania po ka dej
kolejnej próbie. Ostatecznie wraca do stanu
inicjalizacji. Powoduje to zrównowa one obci enie
kanału niezale nie od liczby zakłóce , co potwierdzaj
uzyskane wyniki.
Tabela 7 przestawia redni czas skonfigurowania
w zła w zale no ci od liczby klientów w systemie
i czasu wynajmu.
tym idzie liczba skonfigurowanych klientów
w akceptowalnym czasie jest bliska zera. Bardzo
wyra na jest tendencja, e im wi ksze zakłócenia tym
mniej zapyta odebranych przez serwer. Najni sza
zarejestrowana rednia wyniosła 0,01 komunikatu na
sekund , a wi c liczba komunikatów docieraj cych do
serwera ju przy zakłóceniach na poziomie 50% mo e
by bliska zeru.
A
5
7
10
15
15
0,07
0,11
0,13
0,17
odebranych
Z
10
30
50
80
0,09/0,06
0,12/0,07
0,19/0,07
0,23/0,14
0,06/0,03
0,04/0,03
0,09/0,04
0,20/0,09
0,04/0,01
0,04/0,02
0,17/0,03
0,11/0,06
0,03/0,03
0,03/0,03
0,03/0,03
0,04/0,5
K
9
27
45
72
7,9/7,9
17,4/15,3
29,5/24,7
67,2/55,4
10,3/10,3
22,6/19,9
38,4/32,1
87,4/72
15,4/15,4
33,9/29,8
57,7/48,2
131,1/108,8
27,7/27,8
61,1/53,6
103,5/86,7
235,9/194,5
K
10
W
7
5
0,06 0,11 0,08
7
0,15 0,11 0,11
10
0,19 0,20 0,13
15
0,30 0,29 0,22
Tabela 6. rednia liczba zapyta
przez serwer na sekund
5
K
5
7
10
15
Tabela 7. rednia liczba zapyta odebranych
przez serwer na sekund przy pi ciu/dwudziestu
adresach sieciowych w puli serwera DHCP
Tabela 5. redni czas upływaj cy od momentu
wysłania pierwszego komunikatu DHCPDISCOVER
przez klienta do momentu skonfigurowania w zła przy
pi ciu/dwudziestu adresach sieciowych w puli serwera
DHCP
Podsumowuj c
wyniki
bada
nale y
zauwa y , e pomimo faktu, e niektóre wyniki ró niły
si od oczekiwa autorów, model protokołu działa w
sposób poprawny. Wykryte odmienne wyniki od
oczekiwanych
mo na
łatwo
wytłumaczy
mechanizmami
wbudowanymi
w protokół
i realizowanymi przez implementacj stworzon na
potrzeby niniejszej pracy. Prezentowany model
protokołu wykazuje zachowania wła ciwe dla
protokołu DHCP mo na wi c uzna , e model spełnił
oczekiwania projektanta.
Wyniki uzyskane w tym badaniu potwierdziły
oczekiwania zakładaj ce, e im dłu szy czas wynajmu,
tym dłu szy jest redni czas oczekiwania na
konfiguracj
w zła. Zarówno w przypadku puli
adresów mog cych obsłu y 33 % całkowitej liczby
klientów, jak i w przypadku puli obejmuj cych 100%
zapotrzebowania klientów, zauwa ono proporcjonalny
wzrost czasu oczekiwania w zale no ci od długo ci
czasu wynajmu przyznawanego klientowi.
Czwarty zestaw tabel przestawia redni liczb
zapyta
odebranych przez serwer na sekund
w zale no ci od parametrów takich jak liczba
dost pnych adresów, liczba klientów i procent
zakłóce w kanale przesyłowym.
W Tabeli 6 mo na zauwa y proporcjonalny
wzrost liczby zapyta odebranych przez serwer w
ci gu sekundy w zale no ci od rosn cej liczby
klientów i adresów w puli serwera. Zauwa ono
wi ksz liczb zapyta w sytuacji kiedy liczba
klientów przekraczała liczb dost pnych adresów,
jednak w przypadku kiedy maksymalna liczba klientów
odpowiadała liczbie dost pnych adresów, liczba
zapyta odbieranych przez serwer pozostawała na
podobnym poziomie.
Po wprowadzeniu do kanału dodatkowych
zakłóce okazało si (Tab. 7), e liczba zapyta
odbierana przez serwer jest odwrotnie proporcjonalna
do liczby zakłóce wyst puj cych w kanale. Wynika z
tego, e przy bardzo du ym zakłóceniu niewiele
komunikatów ma szanse dotrze do serwera, a co za
7. WNIOSKI I PODSUMOWANIE
PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005
Niniejsza praca miała na celu przedstawienie
j zyka
modelowania
SystemC
jako
j zyka
projektowania i badania protokołów sieciowych
z grupy TCP/IP poprzez tworzenie funkcjonalnych
modeli tych protokołów. Przegl d protokołów pozwolił
ustali najwa niejsze cechy jakimi charakteryzuj si
protokoły sieciowe a przyjrzenie si konstrukcjom
j zyka SystemC pozwoliło pozna podstawowe zalety
i wady tego j zyka modelowania.
Zauwa ono, e podstawowe konstrukcje j zyka
SystemC bardzo dobrze wpasowuj si w potrzeb
zamodelowania warstwowego podziału funkcjonalnego
stosu protokołów. Dzi ki odr bno ci funkcjonalnej
ka dego z projektowanych modułów mo liwe było
stworzenie struktur funkcjonalnych, odpowiadaj cych
tym, jakie pojawiaj si w przeczystej pracy
protokołów sieciowych.
Rozwi zaniem kolejnego problemu modelowania
protokołów sieciowych jest cisła współpraca j zyka
modelowania SystemC z j zykiem programowania
obiektowego C++. Dzi ki takiemu rozwi zaniu
5/6
www.pwt.et.put.poznan.pl
mo liwo ci i zalety programowania obiektowego
zostały naturalnie przeniesione do
rodowiska
modelowania SystemC.
J zyk SystemC umo liwia łatwe zamodelowanie
ró nych rodowisk pracy protokołu bez znacz cej
ingerencji w model. Budowa modułowa pozwala na
szybk i mało kosztown zmian jednego modułu,
a uzyskanie w konsekwencji mo liwo ci szerokiego
przetestowania protokołu przed zastosowaniem go
w rzeczywistym rodowisku sieciowym.
Wszystkie
wymienione
cechy,
zarówno
protokołów jak i rodowiska modelowania SystemC,
pokazuj wiele elementów wspólnych, które daj
mo liwo
zastosowania j zyka SystemC do
modelowania protokołów sieciowych.
Wykorzystuj c
wykonywalny
model
przeprowadzono szereg bada maj cych ustali , czy
model spełnia funkcjonalno zało on w projekcie,
a wymagan przez standard badanego protokołu.
Wyniki uzyskane w trakcie bada pokazały, e model
zgodnie z oczekiwaniami przy
zachowuje si
zało onych warunkach przeprowadzanej symulacji.
Mo na z cał pewno ci powiedzie , e prezentowany
model protokołu TCP/IP z grupy protokołów
o architekturze klient – serwer pracował zgodnie
wyników ró niła
z zało eniami. Mimo tego, e cz
si od przewidywa
autorów, mo na było je
wytłumaczy mechanizmami zawartymi w algorytmie
realizuj cym prac klienta i serwera protokołu.
Podsumowuj c wszystkie elementy zauwa one
w trakcie realizacji projektu, mo na powiedzie e ze
wzgl du na poprawn prac modelu wybranego
protokołu z grupy protokołów sieciowych, uznano e
rodowisko
modelowania
SystemC
zapewnia
wszystkie mechanizmy niezb dne do projektowania
i badania protokołów sieciowych.
SPIS LITERATURY
1.
2.
3.
4.
PWT 2005 - POZNAŃ 8-9 GRUDNIA 2005
D. E. Comer, D. L. Stevens, Sieci
komputerowe TCP/IP: Tom 1. Zasady,
protokoły
i architektura,
Tom
2.
Projektowanie i realizacja protokołów.”,
Wydawnictwa
Naukowo-Techniczne,
Warszawa 1997
G. Booch, J. Rumbaugh, I. Jacobson, UML
przewodnik u ytkownika”, Wydawnictwa
Naukowo-Techniczne, Warszawa 2001, 2002
R. Droms, RFC 2131: Dynamic Host
Configuration Protocol, Bucknell University
1997
SystemC User’s Guide Version 2.0, Synopsis,
Inc. 2002 http://www.systemc.org
D. C. Black, J. Donovan, SystemC: From the
ground up, Kluwer Academic Publishers 2004
5.
6/6