Úvodní stránka > Programátorská dokumentace

Předcházející    Následující

Programátorská dokumentace

V následujících podkapitolách bude popsán výběr simulátoru, realizace komunikace mezi jednotlivými uzly v rámci topologie, realizace komunikace pomocí protokolů http, ssh a pop. V poslední podkapitole budou shrnuty nedostatky simulátoru.


Výběr simulátoru

Při výběru simulátoru jsem se snažil najít takový simulátor, který by měl grafické uživatelské rozhraní a ve kterém by síť byla snadno realizovatelná. Dalším kritériem bylo, aby simulátor fungoval pod MS Windows. Jediným takovým simulátorem byl OMNet++. Tento simulátor ovšem špatně fungoval v koexistenci s MS .net Studiem 2008. Dalším simulátorem, který přicházel v úvahu, byl simulátor NCTuns. Tento simulátor ovšem ke svému běhu vyžaduje operační systém Linux, distribuci Fedora. Výrobce uvádí, že by simulátor měl fungovat i pod jinými distribucemi Linuxu, preferovaná a vyzkoušená je ale jen již uvedená Fedora. Při instalaci simulátoru bylo ještě potřeba doinstalovat balíček „rsh server“, který není součástí distribuce.

Nahoru


Realizace komunikace mezi uzly

Jak již bylo zmíněno výše, simulátor obsahuje grafické uživatelské rozhraní, ve kterém lze intuitivně nakreslit celou topologii sítě, nastavit komunikaci mezi jednotlivými počítači a v neposlední řadě i nastavit propustnost jednotlivých linek. Simulátor automaticky nastavuje IP adresy počítačům.

Realizace komunikace mezi dvěma uzly je dle mého zjištění rychlejší editací vytvořeného xml dokumentu s topologií sítě. Nejprve je potřeba realizovat komunikaci mezi dvěma uzly pomocí GUI a topologii uložit, protože je potřeba zjistit strukturu příkazu v tomto dokumentu. Pro ostatní uzly lze provést editaci zmíněného souboru. Komunikace mezi dvěma uzly se realizuje pomocí příkazů „stcp“ a „rtcp“ (předpokládám, že uzly budou komunikovat pomocí protokolu TCP/IP). Příkaz „stcp“ vyžaduje ještě IP adresu druhého zařízení, se kterým bude komunikovat. Dále je potřeba u každého tohoto příkazu definovat, jak dlouho bude aktivní, tedy jak dlouho bude vysílat (stcp) nebo jak dlouho má přijímat (rtcp).

Z výše uvedeného plyne zásadní věc – v simulátoru nelze nastavit objem přenesených dat mezi uzly, nastavuje se pouze čas komunikace. V tomto bodě jsem tedy nemohl přesně dodržet zadání. Tento „nedostatek“ simulátoru jsem se snažil vynahradit tím, že vysílám na dané lince vždy jen takový čas, za který by se takový objem dat přibližně přenesl.

Nahoru


Realizace komunikace z/do internetu

Simulátor neobsahuje žádnou komponentu, jejíž pomocí by bylo možné realizovat komunikaci z/do internetu. Pro simulování jsem zvolil nejjednodušší možnost – celý internet bude představovat jedna stanice připojená k routeru R1.

Nahoru


Realizace protokolu http

Protokol http slouží k přenosu dat (dokumentů) mezi klientem a serverem. V naší topologii klient i server může představovat jakýkoli počítač. Při běžné komunikaci vyšle nejprve klient „GET adresa protokol \n HOST”. Tato zpráva je v mé implementaci reprezentována krátkým vysíláním (1/100s). Server odpovídá (zjednodušeně budu předpokládat, že vše probíhá v pořádku) zprávou ve tvaru: „protokol 200 OK \n co obsahuje dokument \n datum \n dokument“. Délka této zprávy může být různě dlouhá, nicméně ze zadání předpokládám, že má konstantní délku 10MB při komunikaci mezi uzly resp. 100MB při komunikaci z ;internetu. Odpověď serveru je v mé implementaci realizována vysíláním po dobu 1s pro 10MB přenos po lince s rychlostí  100Mb/s resp. 10s pro 100MB po téže lince.

Nahoru


Realizace protokolu ssh

Protokol ssh (Secure Shell) slouží obecně k práci na vzdáleném počítači, přihlášení se na vzdáleném počítači či ke spouštění skriptů na vzdáleném počítači. Ke komunikaci používá zabezpečený kanál. Klient se nejprve přihlásí na server, vymění si se serverem verze používaného protokolu, následně si vymění šifrovací klíče a poté již probíhá zabezpečená komunikace. Klient i server mohou být v mé implementaci libovolné počítače. Přihlášení, zjištění protokolu a výměnu klíčů jsem v simulaci realizoval opět krátkými vysíláními (1/100s). Následnou výměnu dat jsem opět realizovat pomocí krátkého vysílání (1/100s) vzhledem k malému množství přenášených dat.

Nahoru


Realizace protokolu pop

Pop je emailový protokol, který obecně slouží ke zjištění obsahu schránky, zjištění nové pošty, načtení celé zprávy nebo jen její části. Protokol se používá v offline modelu architektury, tj. klient si stáhne zprávu ze serveru (když je on-line) a následně ji může číst (může být off-line). Server je v mé implementaci pouze jeden (počítač, který reprezentuje internet), klientem může být kdokoli. Při používání pop protokolu klient se klient nejprve připojí na server, autorizuje se a následně probíhá požadovaná transakce. V rámci simulace budu předpokládat, že připojení na server a autorizace probíhají najednou, opět krátkým vysíláním (1/100s). Transakce bude představována stažením e-mailu o délce 80kB (ze zadání). Realizace transakce bude opět simulována krátkým vysíláním (1/100s).

Nahoru


Nalezené nedostatky simulátoru a jejich řešení

Laskavému čtenáři jistě neuniklo, že jsem pro malé množství přenášených dat vždy použil stejnou dobu přenosu, tj. 1/100s. Toto číslo sice neprezentuje přesně množství přenášených dat, nicméně bylo zvoleno úmyslně. Při různých pokusech v simulátoru jsem zjistil, že při použití menších časových úseků na ně simulátor nereaguje, tudíž se v simulaci tyto komunikace neobjevují.

Dalším nedostatkem, na který jsem přišel při realizaci semestrální práce, byla nestabilita při načítání topologie s více než cca 150 počítači (s nastavenou komunikací). Tato chyba se projevuje pádem celého programu. Chyba je pravděpodobně způsobena při parsování xml souboru s topologií sítě. Tento nedostatek způsobuje, že v simulátoru není možné simulovat celou síť. Zaměřil jsem se proto na simulaci těch uzlů, které při své komunikaci používají linku 4, tedy sledovanou linku. Z ostatních uzlů jsem náhodně zvolil uzly, které budou komunikovat. Počet uzlů jsem se snažil navýšit tak, aby aplikace fungovala.

Nahoru


Naposledy změněno dne 6.12.2008         Vytvořil: Pavel Bžoch

Valid XHTML 1.0 Strict