in last 10 minutes
SIK - Temat G - symulator NS-2 - Zadania
Dokumentacja i materiały o NS-2:główna strona projektu: http://www.isi.edu/nsnam/ns
tutorial 1, tutorial 2, tutorial 3 (pdf), tutorial po polsku (pdf), for beginers (pdf)
manual (pdf), główna książka (do rozszerzania NS-2)
książka: T. Issariyakul, E. Hossain, "Introduction to Network Simulator NS2"
Instalacja NS-2:
potrzebne są pliki: ns, nam, nstk, libpcap*.so.*, katalogi ./bin i ./lib z zawartością, przykłady *.tcl oraz skrypt "e"
(UWAGA: wystarczy ściągnąć ns-2_all.zip z folderu)
uruchamiamy skrypt "e" ustawiający zm. env: "source ./e" lub ". ./e"
potem możemy uruchamiać wszystkie programy:
./ns ns01.tcl; # dokonuje symulacji, tworzy log-i: ns01.tr i ns01.nam
./nam ns01.nam &; # wizualizuje symulację
./nstk sciezka/konsola2c.tcl &; # interaktywne ns
Uwagi na temat NS-2:
1. skrypty definiujące siec i ruch w sieci programuje się w j. OTcl (obiektowe rozszerzenie Tcl);
programy ns, nstk, nse to po prostu interpretery Tcl8.4 z dodanymi klasami NS-2
2. NS-2 jest rozszerzalny - można dodawać nowe protokoły, robi się to w j. OTcl i C++;
techn. "split-objects", każdy obiekt ma 2 połówki: w OTcl i w C++;
dlaczego używa się 2 języków? odp: ???
3. NS-2 zawiera bardzo wiele protokołów różnych warstw (np. kilka(naście) odmian TCP)
4. j. OTcl (tak jak Tcl) posiada introspekcję, dlatego czasami warto uruchomić konsolę: ./nstk konsola2c.tcl
możemy wtedy interaktywnie "zajrzeć" do obiektów, wyświetlić ich metody, zmienne...
możemy wyświetlić klasy, np. "info comm Agent/Tcp/*" wyświetli wszystkie wersje prot. TCP w NS-2 !
jednak symulacje wygodniej prowadzić wsadowo, czyli bez konsoli...
5. zawartość pliku .tr
omówione na stronie 27 w for beginners (pdf);
każda linia oznacza pojedyncze zdarzenie dotyczące połączenia;
pierwszy znak to typ zdarzenia:
"r" receive, odebranie komunikatu na wyjsciu połączenia
"+" "-" dodanie do kolejki, zdjęcie z kolejki
"d" dropped, strata pakietu
pozostałe pola linii to: czas, wezeł "from", węzeł "to", typ pakietu (np. cbr), długość pakietu, i inne
6. narzędzia do analizowania .tr
awk, gnuplot, ???, ...
7. w ns-2 występują głównie sieci dwuwęzłowe ("links"), czyli węzły to routery...
sieci wielowęzłowe (LAN/eth) tworzy się specjalną metodą make-lan
(w rzeczywistości jest to graf pełny utworzony z "links")
Budowanie sieci w NS-2:
1. tworzymy symulator (set ns [new Simulator])
2. włączamy tworzenie logów .tr i .nam ($ns trace-all [open plik.tr]; ...)
3. tworzymy węzły (set n1 [$ns node]; ...)
4. tworzymy połączenia między węzłami ($ns duplex-link $n1 $n2 100Mb 50ms DropTail)
5. tworzymy agentów; reprezentują prot. TCP (różne odmiany), UDP;
6. tworzymy aplikacje; np. FTP, Telnet;
7. trzeba połączyć (attach) aplikacje z agentem i agenta z węzłem
trzeba też połączyć (connect) agenta wysyłającego i agenta odbiorcę
8. trzeba zdef. kiedy aplikacje się wł/wył ($ns at 0.5 "$ftp start"; ...)
9. na końcu uruchamiamy symulację ($ns run)
patrz przykład
Klasy/obiekty NS-2:
klasa SimpleLink
reprezentuje jednokierunkowe połączenie (kabel)
$ns simplex-link ... - tworzy 1 ob. klasy SimpleLink
$ns duplex-link ... - tworzy dwa takie obiekty
$ns link $n1 $n2 - zwraca ob. tej klasy repr. połączenie od $n1 do $n2
zawiera kilka podobiektów, np. kolejkę komunikatów czekających na wysłanie (ob. klasy Queue/*)
wysylanie pakietu przez połączenie przebiega tak:
1. (+) wstawia sie pakiet do kolejki połączenia
2. (-) wyciąga się pakiet z tej kolejki, i jest on przesylany fizycznie przez połązcenie
3. (r) pakiet wychodzi drugim końcem połączenia
4. (d) jest też możliwe ze poakiet został porzucony, np. z powodu przepełnienia kolejki
Pytania/wątpliwości co do NS-2:
1. w przypadku symulacji app kli/ser, w której jest wielu klientów i 1 serwer
po stronie serwera musi być tylu agentów ilu jest klientów (dziwne?)
2. nam: jak uzyskać różne kolory pakietów różnych strumieni (flows)?
$ns color 1 red
$ns color 2 blue
$agent1 set fid_ 1; # fid = "flow id"
$agent2 set fid_ 2
.........................................
UWAGA: co należy wstawiać do sprawozdań z zadań używających NS-2 ?
1. kod tcl definiujacy siec/ruch w sieci
2. fragmenty logów .tr (i czasami także .nam (?))
3. odpowiedzi na pytania, wlasne uwagi itp
Zadanie G.1
Introspekcja, konsola, oglądanie obiektów NS-2, ...
Proszę uruchomić ./nstk konsola2c.tcl i zbadać jakie zmienne mają różne obieky NS-2:
source ns2_poprawki.tcl
proc bgerror args {_puts $args}; # błedy będą wyświetlana w "output"
set ns [new Simulator]; # tworzymy ob. repr. symulator...
set udp [new Agent/UDP]
$udp info vars; # introspekcja w OTcl; pokazuje zmienne ob. $udp
$udp info commands; # pokazuje metody(?) ob.
Agent/UDP info vars; # wyswietla zmienne klasy
set tcp [new Agent/TCP]
$tcp info vars
Agent/TCP info vars
sprawdź też jakie typy prot. TCP implementuje NS-2:
info commands Agent/TCP*; # introspekcja w Tcl; klasy=komendy
przeanalizuj też plik nstk01.tcl pokazujący jak się dostać do
obiektów składowych ob. "link" (klasy SimpleLink)
np. do obiektu Queue (kolejki komunikatów, którą posiada każdy link)
spróbuj samodzielnie powtórzyć podobne czynności i wstaw to do sprawozdania
...
wszystkie wydruki z konsoli nstk wstawić do sprawozdania...
złota myśl: "introspekcja to alternatywa dokumentacji..."
UWAGA: to nie jest normalny sposób używania NS-2 !!!
normalnie symulację robi się "wsadowo" a nie interaktywnie...
Zadanie G.2
Aby dokładnie zrozumieć zawartość pliku .tr, przygotuj sieć która tworzy scieżkę
n1 - n2 - n3 - n4
do n1 dodaj agenta udp, do n4 dodaj agenta null
do agenta udp na n1 dodaj aplikacje cbr i połącz agentów
przeanalizuja zdarzenia opisujące jak pakiety udp przeskakują od n1 do n4...
Zadanie G.3
Wykonaj ekperyment analogiczny do tego z G.2, ale użyj prot. TCP i apliacji FTP;
postaraj sie zobaczyć (w wizualizacji nam) jak prot. TCP przystosowuje się do przepustowości połączeń;
wymaga to pewnej wprawy w dobieraniu parametrów agenta tcp i aplikacji ftp...
do sprawozdania wstaw skrypt i fragment pliku .tr
wskazówka: znajdź przykłady (w plikach *.tcl w folderze), w których używa się FTP, lub popatrz niżej:
set tcp [new Agent/TCP]
$tcp set fid_ 1
set sink [new Agent/TCPSink]
$ns attach-agent $n1 $tcp
$ns attach-agent $n4 $sink
$ns connect $tcp $sink
set ftp [new Application/FTP]
$ftp attach-agent $tcp
Zadanie G.4
Zbuduj sieć jak na rysunku;
na węzłach po lewej stronie umieść agentów i aplikacje CBR nad UDP, po prawej odbiorców;
przeprowadź symulację i ją zwizualizuj przy pomocy nam;
---
następnie dodaj połączenie, które bedzie "wąskim gardłem":
ustaw konkretną długość kolejki oraz przepustowość tego dodatkowego połączenia
tak, aby dało się zaobserwować gubienie pakietów ...
(ustawienie wszystkich parametrów wymaga pewnej wprawy!)
przeprowadź symulację i ją zwizualizuj przy pomocy nam.
Zadanie G.5
dodaj wizualizację kolejki dla wąskiego gardła w zadaniu G.4
$ns duplex-link-op $nX $nY queuePos 0.25; # 0.25 to kąt (45 stopni)
(patrz też rozdz z tutoriala nr. 1)
---
przy pomocy poleceń awk, grep, wc, lub innych oblicz "statystyki" :
1. ile datagramów jest wysylanych
2. ile datagramów dociera na miejssce przeznaczenia
3. jak wyglądają te liczby z podziałem na pary kli/ser (czyli osobno dla każdej pary)
(krótki opis awk, poszukaj "*** awk ***")
---
następnie spróbuj zwiększyć długość kolejki, i zobacz jak to wpłynie na statystyki
$ns queue-limit $nX $nY 25
[[$ns link $nX $nY] queue] set limit_ 25; # alternatywa!
---
zmień kolejkę wąskiego gardła na bardziej sprawiedliwą, np. SFQ,
oraz sprawdź jak to wpływa na statystyki ....
#$ns duplex-link $nX $nY 2Mb 50ms DropTail
$ns duplex-link $nX $nY 2Mb 50ms SFQ; # SFQ zamiast DropTail
Poszukaj w dokumentacji opisu kolejki SFQ i napisz jak ona działa...
Zadanie G.6
Przeprowadź eksperyment z wąskim gardłem, z zadania G.4,
ale tym razem używając FTP nad TCP (zamiast CBR nad UDP);
prot. TCP powinien się bronić przed stratami pakietów na wąskim gardle,
postaraj się to zaobserować ...
Zadanie G.7
Przeprowadź symulację sytuacji, w której 3 klientów FTP używa 1 serwera FTP, w takiej sieci:
(serwer jest prawym skrajnym węzłem)
Dobierz odpowiednio wszystkie parametry i obserwuj ruch pakietów,
zwłaszcza pakiety ACK prot. TCP, wędrujące w przeciwną stronę niż dane...
UWAGA: po stronie serwera użyj tylu agentów TCPSink ilu jest klientów!!!
---
jak tworzyć aplikacje FTP oraz agentów TCP i TCPSink:
set tcp [new Agent/TCP]
set sink [new Agent/TCPSink]
$ns attach-agent $nA $tcp
$ns attach-agent $nB $sink
$ns connect $tcp $sink
set ftp [new Application/FTP]
$ftp attach-agent $tcp
Zadanie G.8
(niepewne połączenia a dynamiczny routing...)
Zbuduj cykl węzłów n1 - n2 - n3 - n4 - n5 - n1
i niech w węźle n1 będzie aplikacja CBR wysyłająca datagramy do n3;
oczywiście statyczny routing poprowadzi te datagramy przez wierz. n2...
---
Możemy spowodować, że niektóre połączenia będą się czasowo psuły:
$ns rtmodel-at 0.5 down $n1 $n2
$ns rtmodel-at 1.0 up $n1 $n2
$ns rtmodel-at 1.5 down $n3 $n4
$ns rtmodel-at 2.0 up $n3 $n4
Oblicz ile datagramów wysyłanych przez n1 gubi sie z powodu tych uszkodzeń...
---
Następnie włącz "dynamiczny routing", DV,
$ns rtproto DV
i ponownie sprawdź ile datagramów się gubi.
Jak zwykle przeprowadź też wizualizację obu eksperymentów;
oba eksperymenty wymagają odpowiedniego dobrania parametrów,
tak aby rezultat był "spektakularny" ;);
Zadanie G.9
(porównanie prot. TCP i UDP...)
Mamy sieć zbudowana z 3 węzłów: src - prx - dst,
oraz następującą aplikację CBR, wysyłającą pakiety z src do dst,
działającą od chwili 0.1 do 4.9:
set cbr [new Application/Traffic/CBR]
$cbr attach-agent $src
$cbr set packetSize_ 25555
$cbr set rate_ 2Mb
$ns at 0.1 {$cbr start}
$ns at 4.9 {$cbr stop}
$ns at 5.0 {$ns halt}
---
Zbadaj ile danych zostaje przeslanych jesli "prot. transportowym" jest:
a) TCP, b) UDP.
Sprawdź, jak sie te proporcje zmieniają jeśli połączenia nie są zbyt szybkie
(tj gdy dużo pakietów się gubi).
Zadanie G.10
(Sieci LAN)
Sprobuj zwizualizować działanie 2 sieci LAN, A i B,
połączonych dwoma routerami (które nie należą do tych sieci, ale maja 2 poł. do A i do B).
Ruch pakietów w sieci powinien pochodzić od 2 aplikacji FTP,
działających między różnymi sieciami LAN.
Koniecznie użyj kolorów dla odróżnienia sesji FTP.
Oprócz kodu tcl wstaw do sprawozdania 1 zrzut ekranu z programem nam.
Sieci LAN tworzymy w NS-2 następująco:
set lan1 [$ns make-lan "$n1 $n2 $n3" 2Mb 50ms LL Queue/DropTail Mac/802_3]
# w tym przykładzie sieć LAN składa sie z 3 węzłów!
Węzły w sieci LAN zachowują się jak zwykłe węzły;
UWAGA: program nam niezbyt "ciekawie" rysuje sieci LAN.
Zadanie G.11
(TCP czasami gubi pakiety...)
Proszę zaprojektować eksperyment pod NS-2, który pokaże, że
prot. TCP czasem jednak gubi pakiety
(chociaż stara się przed tym bronić ze wszystkich sił...)
Wskazówki:
+ można zrobić ścieżke n1 - n2 - n3,
na n1 umiescic app FTP wysyłającą plik do n3,
po pewnym czasie spowodować zmniejszenie przepustowości poł. n2 - n3
(np. poprzez puszczenie dodatkowego ruchu UDP miedzy n2 a n3
lub w inny sposób...)
Zadanie G.12
Mamy sieć jak we wskazówce do zadania G.11;
zobacz co się dzieje z "przepustowością" połączenia TCP n1-n3,
używanego przez app FTP,
gdy zaczynamy "zalewać" link n2-n3 pakietami UDP...
a) gdy n2-n3 używa kolejki DropTail
b) gdy n2-n3 używa kolejki SFQ
Wskazówki:
Trzeba badać ile segmentów TCP dociera do n3 w różnych przedziałach czasu.
Jakiego efektu oczekujemy? SFQ powinno być dużo lepsze (dla app FTP).