Piotr Dziurzański, mgr inż. Agata Zielińska ZASTOSOWANIE SYSTEMC DO MODELOWANIA PROTOKOŁÓW TCP/IPSesja: Nowe obszary badań systemów i sieci telekomuniacyjnych.Politechnika Szczecińska, Wydział Informatyki

Pełen tekst

(1)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 pdziurzanski@wi.ps.pl. 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.

(2) 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.

(3) 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.

(4) 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.

(5) 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.

(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.

(7)