Mendelova univerzita v Brně Provozně ekonomická fakulta
Realizace komunikačního profilu a uživatelského rozhraní pro generátor síťového provozu Diplomová práce
Vedoucí práce: Ing. Petr Zach
Bc. Rudolf Bilka
Brno 2014
Rád bych zde poděkoval vedoucímu práce Ing. Petru Zachovi za čas, který mi při přípravě této práce věnoval, jeho trpělivost a za cenné podněty, bez kterých by práce nemohla vzniknout. Dále bych chtěl poděkovat bývalému vedoucímu Ing. Janu Kryštofovi, Ph.D., a Ing. Martinu Pokornému, Ph.D., za poskytnuté konzultace a spolupráci na projektu síťového generátoru. V neposlední řadě děkuji všem, kteří práci přečetli a pomohli mi s odstraněním drobných chyb a překlepů, zejména Leničce.
Čestné prohlášení Prohlašuji, že jsem tuto práci: Realizace komunikačního profilu a uživatelského rozhraní pro generátor síťového provozu vypracoval samostatně a veškeré použité prameny a informace jsou uvedeny v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s § 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů, a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle § 60 odst. 1 Autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity o tom, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše.
Abstract Bilka, R. Implementation of communication profile and user interface for network traffic generator. Diploma thesis. Brno, 2014. This diploma thesis deals with the design and implementation of a communication profile and user interface for already created software core of the network traffic generator. Author introduces the reader to possibilities of creating user interfaces in programming language Java, including a brief evaluation of them. Further, the available low-level tools for network traffic generation are analyzed. Based on the requirements specification is then designed and implemented user interface of the generator, which allows you to manage communication profiles and run individual tests over them. Finally, the project is economically evaluated and future development trends of the application are proposed. Keywords network traffic generator, Java, XML, graphical user interface, communication profile
Abstrakt Bilka, R. Realizace komunikačního profilu a uživatelského rozhraní pro generátor síťového provozu. Diplomová práce. Brno, 2014. Tato diplomová práce se zabývá návrhem a implementací komunikačního profilu a uživatelského rozhraní pro již vytvořené softwarové jádro generátoru síťového provozu. Autor seznamuje čtenáře s možnostmi tvorby uživatelských rozhraní v programovacím jazyce Java, včetně jejich stručného zhodnocení. Dále jsou analyzovány dostupné nízkoúrovňové nástroje pro generování síťového provozu. Na základě specifikace požadavků je poté navrženo a implementováno uživatelské rozhraní generátoru, které umožňuje spravovat komunikační profily a spouštět nad nimi jednotlivé testy. Závěrem je projekt ekonomicky zhodnocen a navrženy směry dalšího vývoje nástroje. Klíčová slova generátor síťového provozu, Java, XML, grafické uživatelské rozhraní, komunikační profil
6
OBSAH
Obsah 1 Úvod
8
2 Cíl práce
9
3 Specifikace požadavků 3.1 Souhrnný popis . . . . . . . 3.2 Funkční požadavky . . . . . 3.3 Nefunkční požadavky . . . . 3.4 Revize požadavků na systém
B GUI drag and drop nástroje Swing GUI Builder (Matisse)
68
C GUI drag and drop nástroje WindowBuilder
69
D Návrhový diagram tříd komunikačního profilu
70
E XML soubory pro ukládání komunikačního profilu
71
F Ukázka běhu aplikace
76
1
1
ÚVOD
8
Úvod
Moderní počítačové sítě už neslouží pouze ke sdílení zdrojů a dat mezi počítači, ale čím dál tím více roste i jejich multimediální využití. Lidé spolu mohou komunikovat, vést videokonference a přitom být na opačných stranách zeměkoule. Milovník počítačových her už nepotřebuje ten nejvýkonnější počítač, aby si zahrál své oblíbené hry. Stačí si jen pohodlně otevřít webový prohlížeč a všechen výpočetní výkon za něj obstará vzdálený server. Tím se samozřejmě zvyšují nároky na veškerou síťovou infrastrukturu. Nejde jen o to mít velkou šířku pásma, ale přednostně musí být zpracovávány multimediální pakety (jako je například IP telefonie, videokonference, apod.), aby se nám hovor neztrácel a my ho slyšeli plynule. Toto přednostní zpracování zabezpečuje funkce QoS – Quality of Service, která by však měla být podporována všemi uzly na cestě paketu. Pokud však hovoříme o rostoucím významu počítačových sítí, a to nejen v prostředí podniku, ale i mezi jednotlivci, nesmíme opomenout bezpečnost. Podniková data mohou být velkým zdrojem konkurenčních výhod nad ostatními. Jednotlivci naproti tomu mají na sociálních sítích virtuální identity, provádí online platby apod. Pokud by se tedy útočníkovi podařilo nabourat do naší sítě (ať už podnikové, nebo jen domácí bezdrátové sítě), mohl by získat velmi cenné zdroje informací, které se dají různými způsoby zneužít. V prostředí síťové laboratoře PEF MENDELU studenti provádí řadu experimentů zaměřených právě na zabezpečení či nastavení síťové infrastruktury. A to buď v rámci svých závěrečných prací, nebo během standardní výuky. Po návrhu a zapojení se však dostávají do problému, jak si danou síť a její nastavení otestovat. V laboratorním prostředí není možnost posadit za počítače desítky uživatelů, kteří by simulovali běžné činnosti (jakými jsou např. prohlížení webu, čtení pošty, stahování souborů apod.). Z tohoto důvodu vznikla myšlenka vytvořit vlastní generátor síťového provozu, který by tak sloužil nejen pro potřebu těchto studentů, ale mohl by být využíván v jakékoli TCP/IP síti.
2
CíL PRÁCE
2
9
Cíl práce
Cílem této diplomové práce je navrhnout a implementovat nástroj pro správu komunikačního profilu a uživatelské rozhraní pro generátor síťového provozu. Řešení bude postaveno na již vytvořeném softwarovém jádru tohoto generátoru1 . Pro dosažení výše uvedeného cíle bude postupováno podle následujících kroků: • Analyzovat dostupné nízko-úrovňové nástroje na generování síťového provozu a jejich stručné zhodnocení. • Nastudovat problematiku tvorby uživatelských rozhraní. • Navrhnout vlastní řešení komunikačního profilu a uživatelského rozhraní pro generátor síťového provozu. • Implementovat a integrovat navrhované řešení s již vytvořeným výkonným jádrem. • Provést zhodnocení projektu se zaměřením na ekonomický přínos a navržení dalšího postupu.
1
Zach, P. Návrh komunikačního jádra generátoru síťového provozu. Diplomová práce. Brno, 2012. Mendelova univerzita v Brně.
3
SPECIFIKACE POŽADAVKŮ
3
10
Specifikace požadavků
Tato kapitola byla sepsána společně s kolegou Ing. Petrem Zachem. Diplomová práce úzce navazuje na diplomovou práci výše zmiňovaného a není tedy možné při návrhu a implementaci vycházet z jiných požadavků. Kapitola Specifikace požadavků je tedy součástí i této práce: Zach, P. Návrh komunikačního jádra generátoru síťového provozu. Diplomová práce. Brno, 2012.
3.1 3.1.1
Souhrnný popis Základní popis síťového generátoru
Úkolem vyvíjeného nástroje bude generovat síťový provoz v prostředí síťové laboratoře PEF MENDELU v Brně. Bez větších problémů však bude použitelný v jakékoliv TCP/IP síti. Primárně bude simulovat množství uživatelů koncových stanic, kteří využívají služeb připojené sítě. Nástroj bude pracovat jako softwarová aplikace na koncovém uzlu a bude do síťe vysílat běžný provoz, čímž umožní různé testování dané síťě. Aby věrně napodobil opravdového uživatele, musí být možno předem vytvořit plán komunikací (komunikační profil, scénář ) včetně jejich parametrů. Dílčí komunikace se ve správný čas aktivují. Pro snadné nastavení plánu komunikace v celé síti je nutno ovládat všechny koncové uzly z jednoho místa. 3.1.2
Uživatelé
Uživatelé nástroje budou zejména studenti univerzity, kteří ho mohou používat k simulaci reálné sítě vytvořené v rámci závěrečné práce nebo různých experimentů. Obecně lze ale za uživatele označit kohokoliv, kdo potřebuje ověřit správné nastavení své soukromé sítě nebo odhalit její problémy. V praxi to kromě studentů budou hlavně síťoví administrátoři. Nástroj předpokládá, že uživatel bude osoba, která má odpovídající znalosti síťových technologií minimálně na úrovni, kterou mají absolventi předmětu Počítačové sítě I. Při neopatrném nebo neodborném zacházení může dokonce nástroj působit jako zdroj (D)DoS2 útoku, kdy zapříčiní zhavarování síťové služby. 3.1.3
Přehled hlavních funkcí
Elementární účel aplikace je generovat síťový provoz z koncových uzlů tak, aby věrně napodoboval opravdového uživatele stanice a poskytl tak cenný zdroj testovacích dat pro experimenty na struktuře a technologii počítačové sítě. Pro zajištění této funkcionality je vhodné vyjmenovat hlavní funkce: 2
1. Správa komunikačního profilu se specifikacemi datových toků, které se mají generovat v rámci jednoho testu. 2. Ovládání dílčích generátorů (Senderů) generujích provoz (lokální nebo vzdálené) předáním informací v komunikačním profilu. 3. Generování síťového provozu ze zdrojové stanice (Senderu). 4. Sběr proběhlé komunikace. 5. Tvorba statistik na základě proběhlé komunikace. 6. Správa testů (řízení generátoru, profilu a statistik pro každý test zvlášť).
Obr. 1: Znázornění základních funkcí systému.
3.1.4
Omezující podmínky
Hlavní omezující podmínkou tohoto nástroje je výkon koncových stanic, které budou síťový provoz fyzicky generovat. V závislosti na výkonu hostujícího stroje se bude měnit maximální výkon generátoru. Není například pravděpodobné, aby byl v rámci komunikačního profilu zadán požadavek generovat v jeden okamžik na daném uzlu (generátoru) velké množství různých paketů (tisíce za sekundu) a jakýkoliv stroj je dokázal vygenerovat v požadovaném čase. Co se týče samotné aplikace, je nutné, aby bylo možno vzdáleně navázat řídící spojení mezi uzly v síti (dílčími generátory, Sendery), které chceme pro generování síťového provozu použít a řídící částí celého systému. 3.1.5
Provozní požadavky
Základním provozním požadavkem je přítomnost virtuálního stroje JRE3 na každé pracovní stanici. Bez tohoto nástroje není možné spustit instanci aplikace napsané v jazyce Java, která bude základním vývojovým prostředkem. 3
Java Runtime Enviroment.
3.2
Funkční požadavky
12
Aplikace simuluje činnost uživatelů na koncových uzlech v síti. Stejně jako uživatel přistupuje k určitým již fungujícím službám v síti (např. v prohlížeči otevře určitou webovou stránku), tak i tato aplikace funkční služby předpokládá. Z tohoto důvodu je třeba, aby pro každý zvolený aplikační protokol, jehož pakety mají být generovány, existoval v síti daný aplikační server, který bude s klientem (Senderem) komunikovat. Pokud chce např. uživatel z uzlu A generovat webový provoz na uzel B, je nutné aby na uzlu B fungoval např. Apache. Bez tohoto nebude navázáno řádné TCP spojení a korektní webový provoz neproběhne (jako v reálném provozu). Sender se pokusí inicializovat komunikaci i v případě, že požadovaná serverová služba nebude dostupná, protože se snaží napodobit reálného uživatele, který také pozná nefunkční službu pouze neúspěšnou komunikací. O neúspěchu bude řídící stanice informována příšlušným logem z dílčího Senderu. Při ovládání vzdálených stanic generujících provoz z jedné řídící stanice bude nutno akceptovat režijní komunikaci mezi koncovými uzly. Tomu se musí přizpůsobit i zabezpečení sítě – například musí být při komunikaci mimo jednu podsíť na firewallu povoleny příslušné komunikační porty režijní komunikace.
3.2
Funkční požadavky
V této kapitole budou představeny funkční požadavky, které definují funkcionalitu budoucího generátoru síťového provozu. 3.2.1
Generování síťového provozu
Samotné jádro systému, které zajišťuje vygenerování požadovaných datových toků přijatých v komunikačním profilu. Musí zde probíhat korektní komunikace mezi vyvíjeným systémem a používanou síťovou službou (např. webový server). V případě komunikace přes transportní protokol TCP to znamená navázání správného TCP spojení (3cestný handshake). Systém bude jednoduše rozšiřitelný o další aplikační protokoly, v rámci předchozího vývoje byly implementovány HTTP, SMTP, POP3 zapouzdřené v TCP, na UDP běžící RTP a dále ICMP. 3.2.2
Centrální řízení dílčích generátorů
Tak jako v reálném provozu, tak i při simulovaném, se v síti zpravidla nachází více než jeden zdroj komunikace. Bylo by neefektivní až téměř nepoužitelné řešení nastavovat komunikační profil na každém zdroji (Senderu) zvlášť při testu síťové topologie obsahující už jen desítky uzlů. Proto je nutné, aby systém umožňoval centrální vzdálenou správu všech dílčích Senderů, které se v rámci konkrétního testu budou používat.
3.2
Funkční požadavky
3.2.3
13
Správa komunikačního profilu
Systém umožňuje řídit generování síťového provozu na základě komunikačního profilu, který přesně definuje, kterou stanicí, jaký druh komunikace má být generován. Komunikační profil je tvořen množinou záznamů obsahujících informace pro dílčí Sendery o tom, jakou komunikaci a kdy generovat, například: PC1 ve 12:00 v intervalu 60 sekund 5× přistoupí na stránku webového serveru s URL http://192.168.1.1/index.html. Systém také musí umět přidávat, editovat a odebírat záznamy z komunikačního profilu, uložit si celý profil pro budoucí práci či načíst již vytvořený. Je zřejmé, že záznamů bude v profilu mnoho, navíc při využití řádově desítek stanic generujících síťový provoz (nejčastěji virtualizované stroje) musí být tvorba profilu zjednodušena, aby uživatel nemusel pro každý stroj definovat každý konkrétní typ komunikace (záznam v komunikačním profilu). 3.2.4
Sběr proběhlé komunikace
Aby mohl systém vypočítat potřebné statistiky, musí shromažďovat data o provozu mezi všemi dvojicemi, které v síti komunikují. Simulovaný síťový provoz nesmí být ovlivněn režijní komunikací mezi vzdálenou řídící jednotkou a Sendery. 3.2.5
Report proběhlé komunikace
Systém po ukončení testu nabídne statistiku proběhlé komunikace, se kterou může uživatel dále pracovat nebo ji exportovat do jiných formátu pro další využití. Jako výstup uživateli by měl systém zobrazit například: • Zpoždění paketů mezi dvěma uzly (Delay). • Procento ztracených paketů (Packet Loss). • Variaci ve zpoždění paketů (Jitter). • Dostupnou šířku pásma (Bandwidth). • Zátěž rozhraní (Load). • Propustnost rozhraní (Throughtput). Detailním popisem síťových charakteristik se ve své práci věnuje Zach (2012). 3.2.6
Správa testů
Po vytvoření nebo načtení komunikačního profilu může uživatel spustit test nad tímto profilem. Systém musí odeslat pokyny pro generování jednotlivým stanicím (Senderům) a zároveň odeslat startovní signál monitorům proběhlé komunikace (Capture). Systém také umožní kdykoliv probíhající test zastavit.
3.3
3.3
Nefunkční požadavky
14
Nefunkční požadavky
• Z důvodu síťové komunikace musí být všechny používané stanice nějakým způsobem propojeny. Každý uzel tedy musí mít síťovou kartu a nainstalovány potřebné ovladače k ní. Důležitá je také správná instalace a nastavení protokolů TCP/IP (IP adresa, maska sítě a výchozí brána). • Tato aplikace by neměla být používána v produkční síti, kterou může neopatrným zacházením narušit. Určena je hlavně pro testování nové sítě nebo k experimentům ve specializovaných síťových laboratořích, které jsou navenek uzavřené. • Systém bude ukládat data o již vytvořeném komunikačním profilu, odchycená data vygenerovaná nástrojem a pak také logy o průběhu generované komunikace. Není tedy třeba data žádným zvláštním způsobem zabezpečovat, protože se nejedná o uživatelská data nebo osobní údaje, ale čistě o produkt generátoru. Případné zálohy souborů budou čistě v režii uživatele, stejně jako zabezpečení případného zneužití dat. • Výsledná aplikace musí být vytvořena s ohledem na budoucí rozšíření. Současně se předpokládá využití návrhových vzorů, což jistě zkvalitní výsledný produkt.
3.4
Revize požadavků na systém
Původní seznam požadavků byl přepracován do aktuální podoby a rozvržen do několika sekcí dle logické souvislosti. Kurzívou označené požadavky již byly v předchozím vývoji aplikace implementovány a současně není potřeba jejich předělávání. Cílem bylo získat aktuální pohled na systém tak, aby zároveň reflektoval budoucí vývoj. 1. Definice topologie testované sítě a) Aplikace bude schopna automaticky detekovat uzly v testované síti. i. Systém bude automaticky detekovat IP adresu uzlu. ii. Systém bude detekovat hostname (název počítače), pokud je řádně nastaven. b) Systém bude detekovat spuštěné komponenty generátoru na uzlu. c) Systém bude mít možnost přidat uzel do topologie ručně. d) Systém bude schopen uzel z topologie smazat nebo ho změnit. e) Systém bude mít možnost otestovat dostupnost všech uzlů v topologii. f) Systém bude schopen zobrazit testovanou topologii graficky. g) Systém bude umět topologii uložit do XML souboru nebo načíst ze souboru ve formátu XML.
3.4
Revize požadavků na systém
15
2. Správa komunikačního profilu4 a) Systém bude schopen vytvářet komunikační profil, tj. přidávat, mazat a editovat záznamy (datové toky) v něm. i. Systém bude mít možnost manuální definice datového toku. Pozn. to zahrnuje tvorbu profilu prostřednictvím jednotlivých typů datových toků mezi uzly v síti. ii. Systém bude nabízet možnost zjednodušené tvorby komunikačního profilu prostřednictvím stereotypů5 . b) Systém bude uživateli poskytovat možnost vytvářet komunikační profil vizuálně. c) Systém by měl mít možnost uložit vytvořený komunikační profil do XML souboru. d) Systém bude mít možnost načíst komunikační profil ze souboru ve formátu XML. e) Systém bude nabízet možnost vytvářet a editovat profil mimo aplikační prostředí systému. 3. Správa stereotypů a) Systém se bude pomocí stereotypů snažit emulovat reálný provoz v síti. i. Systém bude vytvářet stereotypy tak, aby byly univerzálně použitelné na různých topologiích. b) Systém bude podporovat přidání stereotypu. c) Systém bude podporovat smazání stereotypu. d) Systém bude podporovat změnu stereotypu. e) Systém bude podporovat načítání stereotypu ze souboru ve formátu XML. f) Systém bude stereotyp ukládat do XML souboru. 4. Komunikace mezi komponentami systému a) Systém bude verifikovat, zda komunikace mezi komponentami proběhla úspěšně. b) Systém bude umět odesílat komunikační profil po síti. 4
Komunikační profil je seznam všech datových toků, které mají být v rámci testu generovány. Jasně říká odkud a kam budou zprávy odesílány, v jakém čase a co bude jejich obsahem. 5 Stereotyp představuje seznam již předdefinovaných datových toků, které se mají v rámci testu generovat. Stereotyp by měl představovat chování uživatele, nebo skupiny příbuzných uživatelů na síti.
3.4
Revize požadavků na systém
16
c) Systém bude přijímat komunikační profil na komponentě Sender 6 . d) Systém bude odesílat logy komponent. Pozn. Rychlost doručení je důležitější než-li záruka doručení. 5. Logování a) Systém bude logovat aktivitu komponent generátoru. i. Formát logovacího souboru bude textový. b) Systém bude podporovat zobrazení logu uživateli. c) Systém bude podporovat uložení souboru na diskový systém. d) Systém bude podporovat export logu na zvolený Syslog server 7 . e) Systém bude umožňovat vypnutí logování komponent. 6. Řízení testů a) Systém bude umět spustit připravený test nad zvolenou topologií a komunikačním profilem. i. Systém bude po spuštění testu odesílat dílčí komunikační profily8 na všechny Sender komponenty. ii. Systém bude schopen po spuštění testu odeslat řídící signál na všechny Capture9 komponenty, aby zahájily odchyt komunikace. b) Aplikace bude mít možnost v jakémkoli okamžiku zastavit spuštěný test. i. Po vynuceném ukončení testu systém zastaví generování provozu na komponentách Sender. ii. Po vynuceném ukončení testu systém přestane odchytávat provoz na komponentách Capture. c) Systém automaticky zastaví test po ukončení generování provozu všemi komponentami Sender. 7. Generování provozu a) Systém bude generovat datové toky podle harmonogramu, který je uveden v komunikačním profilu. 6
Sender je komponenta systému, která se ve správný okamžik stará o samotné generování síťového provozu. 7 Syslog server je nástroj pro centralizovanou správu informací ze všech aplikací na síti, které podporují logování. 8 Dílčí profil je podmnožinou kompletního komunikačního profilu. Obsahuje však pouze ty záznamy, které má ten konkrétní uzel generovat. 9 Komponenta Capture zajišťuje odchyt provozu, který je v rámci testu generován. Ten pak slouží pro tvorbu statistik.
3.4
Revize požadavků na systém
17
b) Systém bude podporovat generování komunikace s využitím protokolů HTTP, SMTP, POP3, RTP a ICMP. 8. Sběr proběhlé komunikace a) Systém bude umět nasbírat pakety proběhlé komunikace celé, ale zachytí jen jejich potřebnou část. Pozn. pro potřeby zobrazení statistik není nutné zachytit veškerá aplikační data v paketu, ale postačí sbírat jen záhlaví. b) Systém bude mít možnost předem určit, která data chce sbírat. Pozn. na síti paralelně probíhá i jiná komunikace, než jen data generovaných protokolů, např. ARP. 9. Statistiky a) Systém bude umět ze zachycených dat přečíst údaje potřebné pro sestavení statistik proběhlého provozu. b) Systém bude schopen vizuálně zobrazit výsledky testu. i. Systém bude zobrazovat odeslaný provoz. ii. Systém bude zobrazovat přijatý provoz. iii. Systém bude zobrazovat charakteristiku provozu – jitter. iv. Systém bude zobrazovat charakteristiku provozu – delay. v. Systém bude zobrazovat charakteristiku provozu – packet loss. vi. Systém bude zobrazovat charakteristiku provozu – bandwith. vii. Systém bude zobrazovat charakteristiku provozu – load. Součástí této závěrečné práce bude návrh a implementace jen některých požadavků. Autor se bude soustředit zejména na správu komunikačního profilu a definici topologie testované sítě podle zadání a cíle práce. Ostatní požadavky by měly být součástí dalšího vývoje aplikace.
4
TECHNOLOGICKÁ VÝCHODISKA PRÁCE
4
18
Technologická východiska práce
4.1
Java
Java je objektově orientovaný programovací jazyk, vyvinutý společností Sun Microsystems ke konci minulého století. Sun Microsystems však byla v relativně nedávné době převzata společností Oracle, která je teď vlastníkem Javy a jazyk dále vyvíjí. Ten si rychle získal velkou oblibu a v současné době je hojně používán. Využívá se zejména u webových aplikací na bázi klient-server. Aktuálně je Java už ve své 7. verzi. Java je postavena na principech programovacích jazyků C a C++. Na rozdíl od nich však není jazykem kompilovaným, ale interpretovaným. Zdrojový kód se překládá do tzv. byte-kódu (soubory class), který potom může běžet na kterékoliv Java virtual machine (JVM). Samotný byte-kód je platformně nezávislý, a tak jsou programy napsané v Javě snadno přenositelné. Vazbu na hardware a operační systém zajišťuje JVM. Úplná přenositelnost Javy je jednou z její největší předností. Java není jen programovací jazyk, ale musí obsahovat i další speciální programy, které přenositelnost zajišťují. Základem jsou dvě komponenty – již zmiňovaný virtuální stroj JVM a Java Core API. API (Application Programming Interface) je balík knihoven, které se vyskytují v každém prostředí Javy. API je velmi dobře dokumentováno. Dokumentace je generována ze speciálních komentářů ve zdrojovém kódu dané knihovny. Java umožňuje vytvářet klasické desktop aplikace, ale i tzv. applety. Ty se spouští na WWW stránkách pomocí standardního prohlížeče. V obou případech jsou výsledné programy interpretované pomocí JVM, a tudíž přenositelné. (Herout, 2010) Součástí této diplomové práce bude i realizace grafického uživatelského rozhraní pro generátor síťového provozu. Implementace bude probíhat právě v jazyce Java a to nejen z důvodu, že autor má s prací v tomto jazyce dřívější zkušenosti, ale zejména pro její multiplatformní využití. Detaily tvorby uživatelských rozhraní v Javě jsou popsány v kapitole Analýza možností tvorby GUI v jazyce Java.
4.2
XML
XML je zkratka anglického výrazu Extensible Markup Language, což se dá přeložit jako rozšířitelný značkovací jazyk. Vyvinul se z jiného značkovacího jazyka – SGML. Ten byl však až moc komplexní, což brzdilo jeho masovější využití, ačkoliv ho např. využívalo americké ministerstvo obrany pro dokumentaci svých projektů. Dalším známým derivátem SGML je Hypertext Markup Language (HTML). XML je otevřený formát, který spravuje konsorcium W3C10 . Zároveň je platformně nezávislým řešením, jelikož celý obsah XML dokumentu je v textové podobě, přičemž v záhlaví dokumentu je explicitně vyjádřeno kódování znaků. To zajišťuje 10
http://www.w3.org/
4.2
XML
19
dobrou přenositelnost dat, bez problémů spojených se špatnou interpretací obsahu dokumentu na jiném systému. Dokumenty XML mají využití v mnoha různých oblastech. Tato diplomová práce naráží hned na dvě. První je využití jazyka XML pro popis informace, která má být nějakým způsobem zobrazena uživateli. Pokud máme např. takovou knihu označkovanou pomocí XML jazyka, pak není žádný problém ji pomocí stylů exportovat do formátu PDF nebo jako HTML stránky určené pro web. Kapitola Analýza možností tvorby GUI v jazyce Java se mj. zabývá i využitím jazyka XML pro popis uživatelských rozhraní. Takto univerzálně popsané GUI pak můžeme samozřejmě také exportovat do vícero různých formátů (podrobnosti viz sekce 6.3). Druhou oblastí využití XML je ukládaní strukturovaných dat a jejich výměna mezi různými systémy. Výhodou XML oproti binárním formátům je snadná čitelnost obsahu dokumentu, bez nutné znalosti vnitřního uspořádání. Jak data, tak jejich popis pomocí značek jsou totiž obyčejným textem. Pro editaci nepotřebujeme přístup k aplikaci, ve které byla data pořízena, ale postačí obyčejný textový editor. Z toho však pramení pravděpodobně největší nevýhoda jazyka XML. Je to velké množství režijních dat, která sama o sobě nenesou žádnou informaci, ale slouží pouze pro popis struktury. (Kosek, 2000) Základem každého XML dokumentu je element. Ten se skládá z počáteční a koncové značky. Mezi počáteční a koncovou značkou je uložena samotná informace. Dokument musí obsahovat právě jeden element, který se nazývá kořenový. Všechny ostatní elementy musí být od něj odvozeny a nazývají se elementy vnořené. Element může být i prázdný. V tom případě nenese žádnou informaci. Elementy mohou obsahovat ještě atributy, které se zapisují do počáteční značky a jsou nositelé informace. Jako takové mohou být nahrazeny vnořeným elementem. (Herout, 2007) <prazdnyElement> 4.2.1
Schémata dokumentu XML
Jedna z dalších výhod formátu XML je, že umožňuje validaci dat na několika různých úrovních. První úroveň zahrnuje ověření, zda je dokument správně sestaven, tzv. well-formed. Jedná se o nejjednodušší úroveň validace správnosti dokumentu. Mj. se ověřuje fakt, zda dokument obsahuje právě jeden kořenový element, zda se elementy navzájem nekříží apod. Pro další dvě úrovně validace si již nevystačíme s pouhým XML dokumentem, ale potřebujeme nějaký další mechanismus pro ověření správnosti. Tímto mechanis-
4.2
XML
20
mem jsou právě XML schémata. XML schéma je jazyk, který umožňuje definovat jaké elementy a atributy budeme v dokumentu používat. Tím omezíme původní naprostou volnost XML dokumentu, ve kterém jsme mohli vytvářet všemožné značky dle vlastní vůle. Nezávisle na sobě vzniklo několik různých jazyků pro popis XML schémat. Jako první byl vytvořen jazyk DTD (zkratka Document Type Definition). Postupem času se však přišlo na to, že je vzhledem ke svým omezeným možnostem nedostatečný a začaly vznikat jazyky nové. Ty se ve svém vývoji snažily hlavně o to, aby odstranily nedostatky DTD. Příkladem je např. jazyk XML Schema, Relax NG či Schematron. (Kosek, 2005) I přes své nevýhody je DTD v současnosti relativně hojně používán. Jedním faktorem tohoto tvrzení může být skutečnost, že DTD existuje v podstatě od počátku XML a je hojně podporován téměř ve všech aplikacích. Pojďme si ale představit některé jeho nevýhody. DTD dokument není XML, ale používá vlastní jednoduchou syntaxi. Dále neumí pracovat se jmennými prostory, což je velký nedostatek při tvorbě rozsáhlých dokumentů. Zásadní nedostatek pro tvorbu datových dokumentů je ale fakt, že neumí definovat datové typy, které jsou velmi podstatné pro poslední úroveň validace dokumentu. S datovými typy totiž dokážeme ověřit nejen to, že dokument používá jen vymezené značky a ve správném pořadí, ale kontroluje se i fakt, zda se na daném místě nachází požadovaný datový typ. (Herout, 2007) Jazyk XML Schema odstraňuje všechny zmíněné nedostatky DTD. Zejména využívá jmenných prostorů a umožňuje definici datových typů pro lepší validaci dokumentu. Samotný soubor se schématem je také XML (přípona XSD). Přehled všech zabudovaných datových typů je k nahlédnutí v příloze A. Samozřejmostí je i tvorba vlastních datových typů, které vznikají zejména omezením nebo rozšířením některého ze zabudovaných datových typů. Další možností je snadná definice oboru hodnot. Jednou z nevýhod jazyka XML Schema je fakt, že zejména při popisu jednoduchých XML dokumentů je soubor XSD složitější a větší, než samotné XML, které je nositelem informace. Nicméně se zdá být jazyk XML Schema jedním z nejdůležitějších pro popis schémat XML a je také hojně využíván. Následuje jednoduchá ukázka XML souboru a jeho schématu (včetně vzájemného propojení) (Kosek, 2005): <jmeno> Josef <prijmeni> Chroustal
4.2
XML
21
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:simpleType name="pohlaviType"> <xs:restriction base="xs:string"> <xs:enumeration value="muž" /> <xs:enumeration value="žena" /> <xs:simpleType name="jmenoType"> <xs:restriction base="xs:string" /> <xs:simpleType name="prijmeniType"> <xs:restriction base="xs:string" /> <xs:complexType name="osobaType"> <xs:sequence> <xs:element name="jmeno" type="jmenoType" /> <xs:element name="prijmeni" type="prijmeniType" /> <xs:attribute name="pohlavi" type="pohlaviType" use="required" /> <xs:complexType name="databazeLidiType"> <xs:sequence> <xs:element name="osoba" type="osobaType" minOccurs="1" maxOccurs="unbounded" /> <xs:element name="databazeLidi" type="databazeLidiType" /> Vysvětlení představeného schématu je celkem snadné. Všechny datové typy v dokumentu jsou textové řetězce. Atribut pohlavi je povinný a může nabývat dvou hodnot – muž nebo žena. Přidání další osoby do dokumentu vyžaduje přesné dodržení pořadí elementů tak, jak je ukázáno u vzorové osoby. V souboru musí být uložena alespoň jedna osoba, horní mez je neohraničená. Uvedený příklad je i jasnou ukázkou toho, že dokument XSD popisující schéma může být mnohem rozsáhlejší a složitější než původní triviální XML dokument.
4.3
Java a XML
4.3
22
Java a XML
Pokud bychom z výše uvedeného popisu programovacího jazyka Java a značkovacího jazyka XML měli vybrat nějakou společnou vlastnost, pak je to jejich platformní nezávislost a přenositelnost. Herout (2007) tuto symbiózu popisuje frází: „Java poskytuje přenositelný kód, XML přenositelná data“. Jestliže použijeme XML soubor pro načtení dat do našeho programu, pak jako základní operaci potřebujeme získat XML elementy. K tomu účelu byly vytvořeny různé parsery, které automaticky rozdělí XML dokument na jednotlivé jeho části. Nemusíme tak ke XML přistupovat jako ke klasickému textovému souboru, značnou část práce provede zvolený parser za nás. Při výběru vhodného parseru se většinou rozhodujeme mezi dvěma přístupy ke zpracování XML dokumentu. Prvním je tzv. proudové čtení, které zpracovává soubor sekvenčně. Získané údaje tedy musíme buď okamžitě zpracovat, nebo je uložit do paměti pro budoucí využití. Tento způsob neumožňuje se při čtení souboru vracet. Výhodou je však rychlé načítání a malé nároky na paměť. Typickým představitelem parseru proudového čtení je SAX (Simple API for XML), který je součástí Java Core API. Druhým přístupem zpracovaní souboru XML je tzv. práce se stromovou reprezentací dokumentu. Základní rozdíl oproti proudovému čtení je ten, že parser tohoto typu uloží celý XML dokument do paměti počítače. Při práci se pak můžeme různě pohybovat po stromu, elementy zpracovávat podle potřeby. Příkladem parseru, který pracuje se stromovou strukturou dokumentu, je DOM (Document Object Model). Stejně jako předchozí SAX, tak i DOM je součástí Java Core API a není tedy potřeba žádné dodatečné instalace při jeho využití. (Herout, 2007) 4.3.1
JDOM
Jedná se o docela jednoduché open source rozhraní, které umožňuje reprezentovat XML dokument za pomoci objektů v Javě. Vytváří alternativu k předchozím DOM a SAX parserům, ačkoli JDOM oba dva integruje. Základem práce s JDOM je objekt třídy Document. Ten lze získat z libovolného XML souboru na základě událostí proudového čtení SAXu nebo z DOM stromové struktury. Příklad získání JDOM dokumentu ze SAX parseru, včetně validace oproti XML Schema (JDOM𝑇 𝑀 , 2013): File souborXML = new File("cesta/soubor.xml"); SAXBuilder sax = new SAXBuilder(XMLReaders.XSDVALIDATING); Document dokumentJDOM = sax.build(souborXML); Představený kód není ošetřený o výjimky, které mohou nastat např. při neexistenci načítaného souboru či chybné validaci oproti XSD. Po načtení XML souboru do paměti počítače (v podobě JDOM dokumentu) už můžeme přistupovat k jed-
4.3
Java a XML
23
notlivým jeho elementům. Příklad získání kořenového prvku dokumentu a seznamu všech jeho potomků: Element korenovyPrvek = dokumentJDOM.getRootElement(); List seznamPotomku = korenovyPrvek.getChildren(); Seznamem lze samozřejmě v cyklu procházet a získávat tak jednotlivé elementy. Třída Element obsahuje některé důležité metody jako např.: //vrátí hodnotu zvoleného atributu jako řetězec znaků element.getAttributeValue("nazevAtributu"); //vrátí vybraného potomka elementu element.getChild("nazevPotomka"); //vrátí textový obsah elementu element.getText(); //vrátí textový obsah elementu ošetřený o počáteční bílé znaky element.getTextTrim();
5
ANALÝZA SOUČASNÉHO STAVU
5
24
Analýza současného stavu
Analýza současného stavu se zaměří na dvě hlavní oblasti. První jsou dostupné nízko-úrovňové nástroje, které lze použít na jednoduché generování síťového provozu. Jejich nízká úroveň znamená, že jsou většinou zaměřeny jen na podporu jednoho nebo malé skupiny protokolů, které mají spolu logickou souvislost (např. pro příjem pošty lze využít jak protokolu POP3, tak IMAP). Pro budoucí komplexní generátor síťového provozu by tak mohly nalezené nástroje sloužit jako podpůrné aplikace, které budou generovat pakety daného protokolu. Další oblastí, kterou bude tato analýza zkoumat, jsou dostupné vědecké publikace. Ty ve svém řešení narazily na stejný problém nebo problém analogický. Jejich výsledek tak může být svým způsobem hodnotný pro řešení problému této diplomové práce. Součástí této kapitoly bude i metodika řešení.
5.1
Dostupné nízko-úrovňové nástroje na generování síťového provozu
Výsledný generátor síťového provozu má mj. jako jeden ze základních požadavků, aby byl schopen generovat provoz různých síťových protokolů a zároveň byl snadno rozšiřitelný o protokoly další. V této sekci práce bude představeno několik protokolů, které se na síti běžně objevují a jejich podpora v dalším vývoji generátoru by neměla být opomenuta. Otázkou pak zůstává, jak zajistit podporu těchto protokolů ve výsledném produktu? Jednou z možností je kompletní implementace ve zvoleném programovacím jazyce. Další variantou jsou právě nízko-úrovňové nástroje, které většinou slouží jako podpůrný mechanismus kontroly správného fungování síťových služeb. Ty pak mohou být použity jako jednoduché generátory provozu pro protokol, jehož služby na síti ověřují. 5.1.1
ICMP – Internet Message Control Protocol
Tento protokol se nachází v balíku protokolů IP. ICMP zprávy obsažené v IP paketu se používají pro přenesení informace o stavu sítě, nebo o její nesprávné funkci. V souvislosti s tvorbou generátoru síťového provozu je nejdůležitější podpora Echo Request funkce, pomocí které zjišťujeme konektivitu mezi dvěma hosty. (Javvin Technologies, 2005) Ping je asi nejrozšířenějším nástrojem síťového managementu, který je založen na ICMP Echo. Jeho implementace se implicitně nachází ve všech běžných operačních systémech. Tento nástroj odešle sérii paketů ICMP Echo request a od požadovaného hosta očekává ICMP Echo reply. Poté zobrazí základní statistiky jako je round-trip time11 či ztrátovost paketů. 11
Čas od odeslání request paketu až po přijetí příslušného reply paketu.
5.1
Dostupné nízko-úrovňové nástroje na generování síťového provozu
5.1.2
25
HTTP – Hypertext Transfer Protocol
Protokol aplikační vrstvy, který je založen na principu požadavek/odpověď. Jedná se pravděpodobně o nejvíce používaný protokol vůbec. Klient pošle na server svůj požadavek, který je v předem stanoveném formátu (např. chce v prohlížeči zobrazit nějakou webovou stránku). Server odpoví opět v předem stanoveném formátu, který mimo jiné obsahuje trojmístný stavový kód. (Javvin Technologies, 2005) Jedním z nástrojů na získávání souborů za pomoci protokolu HTTP je GNU Wget. Jedná se o volně dostupný software, který z příkazové řádky emuluje činnost uživatele a prohlížeče za pomoci jednoduchých příkazů. Existuje ve verzi jak pro Linux, tak Windows. (Free Software Foundation, 2011) 5.1.3
SMTP – Simple Mail Transfer Protocol
SMTP je protokol vytvořený na službě FTP, který umožňuje spolehlivý a účinný přenos elektronické pošty. Používá se buď při odesílání pošty od klientské aplikace (Mail User Agent) k poštovnímu serveru (Mail Transfer Agent), nebo k přeposílání emailu mezi jednotlivými servery (Mail Transfer Agents). E-mail se přeposílá, dokud nedorazí do cílové domény, kde za jeho doručení odpovídá už Mail Delivery Agent. (Javvin Technologies, 2005) Pro systémy Windows existuje nástroj Bmail, který z příkazové řádky pomocí jednotlivých voleb dokáže odeslat e-mail s využitím protokolu SMTP. Společně s freeware nástrojem mpack umí odesílat MIME zakódované přílohy. Nejdůležitější volby nástroje Bmail jsou: • -s jméno SMTP serveru • -p číslo portu (volitelné, jinak 25) • -t adresa odesílatele • -f adresa příjemce • -b tělo zprávy (pouze pokud se jedná o jednořádkovou zprávu) • -h generuje hlavičku (do těla zprávy umístí adresu odesílatele a příjemce) • -a předmět zprávy • -m soubor, který se použije jako tělo zprávy (např. nějaký log soubor) Povinné a nejdůležitější jsou pouze volby -s, -t a -f. Více příjemců zprávy definujeme tak, že mezi jednotlivé adresy vložíme interpunkční znaménko – čárku. (Peacock, 2007) Pro systémy Linux existuje skript v jazyce Perl smtp-cli, který poskytuje podobnou funkcionalitu jako dříve zmíněný Bmail pro Windows. Navíc umí implicitně přikládat MIME přílohy a poradí si i s TLS šifrováním a IPv6. Důležité volby tohoto nástroje (Ludvig, 2011):
5.1
Dostupné nízko-úrovňové nástroje na generování síťového provozu
26
• - -host=[:<port>] jméno nebo adresa SMTP serveru (volitelně číslo portu) • - -from adresa odesílatele • - -to adresa příjemce • - -subject předmět zprávy • - -body-plain= vytvoření těla zprávy za pomoci textu nebo souboru • - -attach=[<MIME/Type>] soubor, který má být připojen jako příloha • - -verbose umožňuje kontrolu prováděných operací výpisem na standardní výstup 5.1.4
POP3 – Post Office Protocol (version 3)
Protokol aplikační vrstvy, který umožňuje uživateli dynamický přístup ke své poštovní schránce na vzdáleném serveru. POP byl navržen tak, aby podporoval offline práci s daty, což znamená, že uživatel ze serveru stahuje všechny zprávy pokaždé, když se k němu připojí. Jakmile se jednou e-maily stáhnou ze serveru na počítač, jsou odsud většinou smazány. (Javvin Technologies, 2005) Pěkným příkladem nástroje pro práci s elektronickou poštou z příkazové řádky je Emia4Win. Jak už vyplývá z názvu, jedná se o software určený pro systémy Windows. Chování programu ovlivňujeme z příkazové řádky pomocí jednotlivých voleb, kde např. syntaxe pro získání zprávy za pomoci protokolu POP3 může vypadat takto: emia get /svr:[s] /port:[p] /id:[i] /pass:[pw] /a:message /msg:[n] /DEL:1. Jednotlivé volby pak znamenají: • s: adresa POP3 mail serveru • p: číslo portu (standardně 110) • i: uživatelské jméno k účtu • pw: heslo k účtu • n: číslo zprávy, která má být stažena • /a:message znamená typ akce, který má být vykonán (v našem případě stáhnutí zprávy) • /DEL:1 znamená, že po stažení bude zpráva ze serveru smazána Nástroj umí samozřejmě pracovat i s jinými protokoly, např. IMAP, který bude popsán níže. (Aiyadurai, 2004)
5.1
Dostupné nízko-úrovňové nástroje na generování síťového provozu
27
Podobným nástrojem pro systémy Linux je getmail. Činnost programu lze ovlivňovat jednoduchým konfiguračním souborem /.getmail/getmailrc, který pro přijímání zpráv pomocí POP3 může vypadat následovně (Cazabon, 2009): # Prvni povinna cast -- definujeme odkud a jak budou zpravy stahovany. [retriever] type = SimplePOP3Retriever server = pop3.nejaka_domena.com port = 110 username = uzivatel password = heslo # Druha povinna cast, kde definujeme kam budou zpravy ukladany. [destination] type = Maildir path = ~/mail/ # Nepovinna cast pro dalsi volby. [options] # Po stazeni budou zpravy ze serveru smazany. delete = true # Stahne ze serveru pouze nove zpravy. read_all = false 5.1.5
IMAP – Internet Message Access Protocol
IMAP je dalším protokolem určeným pro přístup k elektronické poště, ale na rozdíl od protokolu POP umí pracovat i v tzv. online módu. Tím je myšleno následující: klient se připojí ke vzdálenému serveru. Zůstává však k němu připojen po celou dobu, nejen během stahování nové pošty. Při prohlížení složky jsou stahovány pouze důležité informace (např. hlavičky zpráv). Zbytek se stáhne až když si chce uživatel danou zprávu přečíst. Podporuje i další možnosti vzdálené správy jako je práce se složkami, přesouvání zpráv apod. (Javvin Technologies, 2005) Pro práci s elektronickou poštou za pomoci protokolu IMAP využijeme na systému Windows již dříve zmiňovaný Emia4Win. Syntaxe pro stažení zprávy bude oproti POP3 mírně odlišná: emia imap /svr:[s] /port:[p] /id:[i] /pass:[pw] /box:[b] /a:message /msg:[n] /DEL:1. Přibyl zde jeden parametr /box:[b], kterým určíme jméno schránky, ze které chceme poštu stáhnout (standardně INBOX). (Aiyadurai, 2004) Na systémech Linux využijeme getmail, jehož konfigurační soubor je však také potřeba trochu poupravit (Cazabon, 2009): # Prvni povinna cast -- definujeme odkud a jak budou zpravy stahovany. [retriever]
5.1
Dostupné nízko-úrovňové nástroje na generování síťového provozu
28
type = SimpleIMAPRetriever server = imap.nejaka_domena.com port = 143 mailboxes = INBOX username = uzivatel password = heslo # Druha povinna cast, kde definujeme kam budou zpravy ukladany. [destination] type = Maildir path = ~/mail/ # Nepovinna cast pro dalsi volby. [options] # Po stazeni budou zpravy ze serveru smazany. delete = true # Stahne ze serveru pouze nove zpravy. read_all = false 5.1.6
SIP – Session Initiation Protocol
Tento protokol umožňuje ustanovit, modifikovat a ukončit multimediální spojení, nejčastěji internetové telefonické hovory VoIP. Používá se pro signalizaci a pro kompletní multimediální přenos spolupracuje s jinými protokoly, jako např. RTP, který zajišťuje samotný přenos dat. Zprávy protokolu SIP mohou být odeslány přes transportní protokoly TCP nebo UDP a svojí strukturou připomínají zprávy protokolu HTTP. (Javvin Technologies, 2005) Pro UNIXové platformy existuje nástroj SIPp. Jedná se o testovácí nástroj, respektive síťový generátor protokolu SIP. Je tu možnost využít jej i na systémech Windows, pokud SIPp zkompilujeme pod nástrojem Cygwin12 . Faktem zůstává, že se jedná o velmi mocný nástroj. Umožňuje simulovat provoz až několika tisíců volajících agentů přes VoIP. Základní balík obsahuje předinstalované scénáře komunikace, které pomáhají lépe generátor pochopit a naučit se psát scénáře vlastní. Nástroj nabízí také některé pokročilé vlastnosti, jako je např. podpora IPv6, TLS, SIP autentizace apod. Součástí je i zobrazení online statistik o běžících hovorech. (Gayraud – Jacques, 2010) 5.1.7
RTP – Real-Time Transport Protocol
Jak už bylo zmíněno výše, pro samotný přenos multimediálních dat v reálném čase (nejčastěji VoIP) se využívá právě protokolu RTP. Ten obvykle pracuje na vrcholu transportního protokolu UDP, ačkoli může pracovat i nad jinými protokoly. Sám 12
http://www.cygwin.com/
5.1
Dostupné nízko-úrovňové nástroje na generování síťového provozu
29
o sobě neposkytuje žádné mechanismy pro včasné doručení apod., ale spoléhá na služby nižší vrstvy (např. QoS – konkrétně model DSCP na 3. vrstvě TCP/IP). (Javvin Technologies, 2005) Dříve zmiňovaný nástroj SIPp umí také odesílat multimediální soubory (audio, video) pomocí transportního protokolu RTP. Jak už však bylo řečeno výše, nástroj je až příliš komplexní a jeho využití jako podpůrné aplikace pro vyvíjený síťový generátor jsou zde sporné. Zejména v případě implementace protokolu RTP se nabízí možnost využít spíše některé z nativních knihoven Javy pro práci se síťovými aplikacemi13 . (Gayraud – Jacques, 2010) 5.1.8
TELNET – Terminal emulation protocol of TCP/IP
Z názvu je patrné, že tento protokol emuluje terminál v prostředí TCP/IP. Tím je umožněno se vzdáleně připojit k síťovému prvku. K vytvoření spojení mezi klientem a serverem využívá transportního protokolu TCP, kdy si nejprve mezi sebou vyjednají určitá nastavení. Poté může klient ovládat vzdálený prvek prostřednictvím Network Virtual Terminal (virtuální síťový terminál), což je imaginární zařízení, které poskytuje standardní rozhraní pro různé typy zařízení. Komunikace prostřednictvím protokolu TELNET není nijak šifrována. (Javvin Technologies, 2005) Abychom mohli realizovat spojení mezi dvěma uzly v síti za pomoci protokolu TELNET, je potřeba mít nainstalovaný nějaký telnet klient a na vzdáleném uzlu telnet server. Novější verze systému Windows sice telnet klient obsahují, ale není implicitně nainstalován. Po instalaci se spouští v terminálu příkazem telnet, což je obdobné v systémech Linux. 5.1.9
FTP – File Transfer Protocol
Tento protokol umožňuje sdílení souborů mezi jednotlivými hosty v síti. Využívá dvou TCP spojení, kdy prvním putují příkazy od klienta k serveru a druhé slouží pro samotný přenos souborů. Syntaxe je velmi podobná jako u protokolu TELNET. Navíc jsou zde dva důležité příkazy put (pro vložení souboru na server) a get (pro stažení souboru ze serveru). (Javvin Technologies, 2005) Abychom mohli soubory na server umístit, nebo je z něj stáhnout, je potřeba mít nějakého FTP klienta, popřípadě nám k tomu postačí obyčejný prohlížeč. Podobně jako nástroj ping, tak i FTP klient je součástí většiny běžně používaných operačních systémů. V příkazovém řádku stačí zadat ftp a otevře se nám prostředí integrovaného FTP klienta. 5.1.10
TFTP – Trivial File Transfer Protocol
Jednoduchý protokol na přenos souborů, který je implementován na transportním protokolu UDP. Umí pouze soubory zapisovat nebo číst z/na server. Nepodporuje 13
Dostupné nízko-úrovňové nástroje na generování síťového provozu
30
také žádnou autentizaci uživatele. Neumí ani procházet adresářovou strukturou na serveru. (Javvin Technologies, 2005) Podobně jako u protokolu TELNET, tak i TFTP má v operačním systému Windows svého klienta. Ten však není implicitně nainstalován. Po dodatečné instalaci jej můžeme spustit příkazem tftp. Tento protokol a jeho klient je běžný i v systémech Linux. 5.1.11
SSH – Secure Shell Protocol
Protokol určený pro bezpečný vzdálený přístup a další práci přes nezabezpečenou síť, nejčastěji Internet. Hlavní výhodou oproti TELNETu je šifrované spojení. SSH se skládá ze 3 hlavních komponent. První je protokol transportní vrstvy, který zajišťuje autentizaci serveru a integritu přenášených dat. Volitelně může také provádět kompresi. Dále SSH obsahuje protokol pro autentizaci uživatele vůči serveru, která může být provedena různými způsoby. Jako třetí je zde protokol spojení, který na šifrovaném tunelu vytváří více logických kanálů pro komunikaci. (Javvin Technologies, 2005) Jedním z volně dostupných SSH klientů pro Windows je Plink (PuTTy Link). Spouští se z příkazové řádky a je obdobou Linuxového příkazu ssh. (Tatham, 2011) Na systémech Linux existuje volně dostupný balík OpenSSH, který je součástí většiny distribucí. Obsahuje jak SSH klienta, který se spouští už dříve zmiňovaným příkazem ssh, tak i SSH démona, který funguje jako server pro SSH klienty. (kolektiv autorů, 2003) 5.1.12
DNS – Domain Name System (Service) protocol
Používá se hlavně pro překlad doménového jména na IP adresu a naopak. Na protokolu a službách DNS serverů ale dnes závisí mnoho internetových služeb, jako je např. elektronická pošta. (Javvin Technologies, 2005) Pro testování činnosti a odstraňování potíží spojenými s DNS servery se v systému Linux používá nástroj nslookup. Spouští se stejnojmenným příkazem z příkazové řádky a lze ho tedy využít na generování běžného DNS provozu v síti. Systém Windows obsahuje stejnojmenný nástroj s podobnou funkcionalitou. (kolektiv autorů, 2003) 5.1.13
DHCP – Dynamic Host Configuration Protocol
Protokol umožňující síťovým administrátorům centrálně řídit a automaticky přidělovat hostům v síti IP adresu, masku sítě, výchozí bránu apod. Děje se tak na základě výpůjček od DHCP serveru. (Javvin Technologies, 2005) Pro Linux existuje nástroj dhcping, který umožňuje otestovat funkčnost DHCP serveru. Ten odešle na DHCP server request nebo inform paket a čeká na odpověď. Pro Windows byl vytvořen podobný nástroj s názvem dhcpcheck, který je ke stažení
5.2
Analýza publikací
31
na níže uvedené adrese: www.ks-soft.net/download/utils/dhcpcheck.zip. Dle vyjádření autora je již zmíněný nástroj volně šiřitelný pro nekomerční účely. 5.1.14
Shrnutí dostupných nástrojů
Byly zde představeny některé síťové protokoly, jež jsou hojně zastoupeny v běžném síťovém provozu. Ke každému protokolu byl pak nalezen jeden či dva nástroje, které by mohly sloužit jako jednoduché generátory provozu. Jestli však budou použity v řešení komplexního generátoru síťového provozu, je otázkou dalšího vývoje aplikace. U jednodušších protokolů je totiž vhodné zvážit jejich přímou implementaci prostřednictvím Java API knihoven. Všechny zde představené nástroje jsou shrnuty v tabulce 1.
5.2
Analýza publikací
Tato sekce diplomové práce si klade za cíl zanalyzovat dostupné publikace, které se zabývaly stejným problémem, nebo problémem analogickým. Nalezená řešení budou okomentována a jejich přínos zhodnocen vzhledem k řešení problému dané práce. Jedná se zejména o problematiku tvorby grafických uživatelských rozhraní v jazyce Java, a pak také o problematiku implementace síťových generátorů. Analýza byla provedena na základě závěrečných prací vysokých škol v ČR i zahraničí a článku ze zahraniční konference. Jako zdroje informací posloužily licencované databáze dostupné na MENDELU14 a veřejné internetové vyhledávače (zejména Google15 ). Jednotlivé publikace byly nalezeny za použití klíčových slov: Java grafické uživatelské rozhraní, generátor síťového provozu, Java GUI, simulace uživatele, Java graphical user interface, network traffic generator, user simulation, network traffic models. 5.2.1
Navázání na předchozí závěrečnou práci
Jak už bylo zmíněno dříve, tato práce úzce navazuje na diplomovou práci Ing. Petra Zacha z roku 2012. Kapitola Specifikace požadavků byla sepsána společně s tímto autorem a nadále je udržována spolupráce na výsledném produktu prostřednictvím konzultací. Zach (2012) položil základy budoucímu komplexnímu generátoru síťového provozu. Navrhl a implementoval jádro systému, které obstarává řízení vzdálených komponent generátoru a samotné generování síťového provozu koncovými stanicemi. Zároveň ve své práci řeší i sběr proběhlé komunikace. Pro návrh grafického uživatelského rozhraní generátoru poslouží i precizní analýza současného stavu, kterou autor ve své práci provedl. Shrnuje zde klady a zápory současných řešení generátorů síťového provozu s ohledem na požadavky Síťové laboratoře PEF MENDELU na tento produkt. V závěru analýzy současného stavu autor 14 15
Poznámka jednoduchý nástroj; v různých variacích se nachází na téměř každém OS jednoduchost, snadná obsluha společně s mpack odesílá MIME přílohy skript v jazyce Perl; podpora IPv6 a TLS šifrování obdoba getmail pro Linux komunikace prostřednictvím konfiguračního souboru viz výše viz výše podpora Windows až po zkompilování prostřednictvím Cygwin odesílá audio a video ve Windows nutno dodatečně doinstalovat ftp klient integrovaný do téměř každého OS ve Windows nutno dodatečně doinstalovat zjednodušená verze nástroje PuTTy pro příkazovou řádku součástí většiny distribucí testování činnosti DNS serverů odesílá DHCP requesty na server obdoba dhcping
5.2
Analýza publikací
33
zmiňuje, že žádný ze zkoumaných systémů není schopen splnit všechny podmínky, které byly stanoveny ve specifikaci požadavků. Proto dále navrhuje vlastní řešení, na které se snaží navázat tato diplomová práce. Pro tvorbu uživatelského rozhraní a komunikačního profilu je důležité pochopení jádra systému, které Zach (2012) navrhl do několika komponent (viz obrázek 2): • řídící prvek (Administrator – značeno A), • generátor (Sender – značeno S), • analyzátor (Capture – značeno C), • výpočet statistik (Statistics – značeno ST).
Obr. 2: Schéma komponent a jejich komunikace. Převzato od Zacha (2012)
5.2.2
Práce zaměřené na tvorbu GUI
Na Fakultě informatiky Masarykovy univerzity byl v roce 2008 vyvinut nástroj, který se zabývá stejnou tématikou – generování síťového provozu. Jeho název je Modulární tester síťových aplikací/spojení. Jádro generátoru bylo napsáno v jazyce C a jedná se o modulární aplikaci. Detailněji se o něm zmiňuje ve své práci Zach (2012). Kuba (2010) navrhl a implementoval grafické uživatelské rozhraní pro správu konfiguračních souborů výše zmiňovaného generátoru. Tyto soubory jsou ukládány ve formátu XML s pevně stanovenou strukturou. Ačkoli je výsledný produkt do značné míry odlišný, lze z práce získat znalosti jak dobře navrhnout a implementovat konfigurační soubor (v případě řešení této diplomové práce hovoříme o komunikačním profilu). Dále zde autor popisuje možnost zpracovávání XML souborů v jazyce Java.
5.3
Metodika řešení
34
Jedním z cílů této práce je i nastudování problematiky tvorby grafických uživatelských rozhraní. Analýza tohoto problému následuje v další kapitole. Kučera (2005) detailně rozebral jednu z možností tvorby GUI v Javě, tj. využití prostředí SWT (Standard Widget Toolkit) pro vývojové prostředí Eclipse. Jeho diplomová práce slouží jako cenný zdroj informací a doporučení právě pro tuto knihovnu. Avšak možností tvorby GUI v Javě je vícero. Další variantou je využití jazyka XML při definici nového rozhraní. Tímto se ve své diplomové práci zabývá Uličný (2006). Autor zde mimo jiné popisuje jednotlivé jazyky založené na XML, které byly vyvinuty za účelem návrhu GUI. Současně je detailněji srovnává mezi sebou a vyzdvihuje jejich klady a zápory. 5.2.3
Práce zaměřené na analýzu síťového provozu
Pokud chceme efektivně modelovat síťový provoz, je zapotřebí znát charakteristické datové toky. Obecně ve všech sítích existují různé typy uživatelů, jejichž činnost lze určitým zobecněním klasifikovat do tříd. Například uživatel zaměřený na prohlížení webu bude mít nejvíce HTTP síťového provozu a objem přenášených dat bude rozložený na jednotlivé časové úseky během dne. Nabízí se tedy možnost využití stereotypů chování uživatele při návrhu komunikačního profilu pro síťový generátor. Stereotypy uživatelů jsou tak jednou uvažovanou možností, jak vytvářet komunikační profil pro generátor síťového provozu, jehož realizací se zabývá tato diplomová práce. Zhang (2010) se ve své závěrečné práci zabývá zkoumáním chování uživatele připojeného k domácí počítačové síti a Internetu. Zaměřuje se na hledání skrytých vzorů v síťovém provozu, množství přenášených dat v závislosti na denní hodině apod. Využití autorem zjištěných informací může například sloužit k vytvoření stereotypů chování jednotlivců na síti. Uživatel generátoru síťového provozu pak nemusí definovat jednotlivé položky komunikačního profilu, ale využije již nadefinovaných stereotypů, které mají základ v objektivně nasbíraných datech. Na síťový provoz se však nemusíme dívat jen z pohledu uživatelů sítě. Neméně důležitou součástí celkového obrazu provozu v síti jsou i aplikace, které uživatelé používají. Augustin a Mellouk (2011) ve své práci zkoumají dvacet webových aplikací a vysvětlují diverzitu charakteristických vzorů v síťovém provozu, který je těmito aplikacemi generován. Při předpokladu využívání webových aplikací (např. Gmail16 pro poštu nebo YouTube17 ke sledování videa) poskytuje tato práce zajímavý pohled na to, jak generovat síťový provoz.
5.3
Metodika řešení
Pro dosažení cíle této diplomové práce bylo nutné specifikovat jasné požadavky na systém, které vycházejí z potřeb síťové laboratoře PEF MENDELU v Brně. Tyto 16 17
http://mail.google.com http://www.youtube.com
5.3
Metodika řešení
35
požadavky byly vypracovány společně s autorem softwarového jádra generátoru síťového provozu – Ing. Petrem Zachem ještě před vznikem této práce. Avšak později byly požadavky přepracovány tak, abychom získali aktuální pohled na systém a zároveň reflektovaly i budoucí vývoj nastroje. Při provádění revizí požadavků na systém byl vybrán jazyk XML jako prostředek pro ukládání aplikačních dat generátoru (topologie testované sítě, komunikační profil apod.). Ten totiž ze své povahy textového souboru umožňuje vytvářet a modifikovat data v jakémkoliv textovém editoru, bez nutnosti použití uživatelského rozhraní generátoru. Autor se tedy musel seznámit se samotnou technologií XML souborů a možnostmi jejich zpracování v Javě. Pro načítání a ukládání obsahu z/do XML souboru bylo vybráno rozhraní JDOM, jehož popis je uveden v kapitole Technologická východiska práce. Důvodem pro výběr tohoto rozhraní je, že práce s ním je snadná a má dostupnou velmi dobrou dokumentaci. Abychom mohli ověřovat správnost vytvořených XML souborů až na úrovni datových typů, musíme použít některého ze XML schémat. K tomuto bude využit jazyk XML Schema a součástí řešení bude i vhodně definovaný XSD dokument pro validaci. Před samotným návrhem a implementací grafického uživatelského rozhraní aplikace bude nutné v souladu se zadáním práce prostudovat možnosti tvorby těchto rozhraní v programovacím jazyce Java. Tato analýza bude sloužit jako přehled většiny nejpoužívanějších možností, které programátor při tvorbě GUI v Javě má. Poté bude následovat návrh uživatelského rozhraní a komunikačního profilu generátoru. Výsledkem budou tzv. wireframy všech důležitých oken aplikace. V případě komunikačního profilu bude výsledkem UML diagram tříd. Po vypracování těchto návrhů už bude možné navržená řešení implementovat a integrovat s komunikačním jádrem generátoru. Veškerá implementace a testování již hotové aplikace bude prováděna na operačním systému Windows 7. Použitím programovacího jazyka Java by však aplikace měla být použitelná i na systémech typu Linux a Mac OS. Posledním krokem k dosažení cíle práce bude zhodnocení výsledného projektu, včetně ekonomických aspektů a návrh budoucího rozvoje aplikace. Ekonomické zhodnocení bude provedeno z pohledu návratnosti investice do síťového generátoru ve firemním prostředí.
6
ANALÝZA MOŽNOSTí TVORBY GUI V JAZYCE JAVA
6
36
Analýza možností tvorby GUI v jazyce Java
Tato kapitola si klade za cíl zanalyzovat jednotlivé přístupy k tvorbě grafických uživatelských rozhraní (GUI) v jazyce Java. Zaměřuje se na tři hlavní směry: • Imperativní přístup, kdy programátor s využitím některé grafické knihovny napíše celé rozhraní ručně. • Drag and drop nástroje, se kterými uživatel jednoduše tvoří GUI pomocí myši a okamžitě vidí výsledek své práce. • Využití XML, kde programátor používá k popisu GUI speciálního jazyka založeného právě na XML.
6.1
Imperativní přístup tvorby GUI
Pravděpodobně nejstarší přístup pro tvorbu uživatelských rozhraní. GUI je vytvářeno pomocí příkazů ze zvoleného grafického prostředí. Nespornou výhodou pro programátora je fakt, že má veškerý kód pod svoji kontrolou. Pokud např. využije níže uvedené drag and drop nástroje, aplikace mu vygeneruje velké množství zdrojového kódu. Ten je pak často zbytečným, minimálně dělá výslednou aplikaci méně transparentní. Určitou nevýhodou se může zdát i fakt, že GUI vytvořené imperativním způsobem vyžaduje alespoň základní znalost programovacího jazyka a zvolené grafické knihovny. Jak už bylo naznačeno výše, kromě programovacího jazyka si potřebuje programátor zvolit ještě grafické prostředí či knihovnu. Java standardně obsahuje dvě grafická prostředí: AWT a Swing. Existují však i alternativy k těmto knihovnám, jako například SWT nebo SwingWT18 . Pokud hovoříme o grafických prostředích či knihovnách, často se zde objevuje anglický výraz widget. Widget je základní stavební kámen při tvorbě grafických uživatelských rozhraní. Umožňuje interakci s aplikací a operačním systémem, zobrazuje informace či slouží k seskupování dalších widgetů apod. Typickým příkladem widgetu je například tlačítko, pole pro zadání údajů, posuvník, vyskakovací okno, položka v menu apod. 6.1.1
AWT
Zkratka pochází z anglického výrazu Abstract Window Toolkit – nejstarší balík na podporu tvorby GUI v Javě. Obsahuje mimo jiné nativní komponenty uživatelských rozhraní, robustní model řízení událostí, nástroje pro grafiku apod. V současnosti je málo používaný, nahrazen komplexnějším prostředím Swing. (Oracle, 2011) Pro představu, jak imperativně vytvořit GUI, je zde ukázka implementace jednoduchého rozhraní s využitím grafické knihovny AWT (výsledek představeného kódu je zobrazen na obrázku 3): 18
http://swingwt.sourceforge.net/
6.1
Imperativní přístup tvorby GUI
import java.awt.*; public class HelloWorld extends Frame { public static void main(String argv[]) { //vytvoříme novou instanci okna aplikace new HelloWorld(); } //konstruktor okna public HelloWorld() { setTitle("Hello World in AWT"); //vytvoříme nové komponenty a přidáme je do okna TextField textFieldHello = new TextField("TextField"); add(textFieldHello, "North"); Button buttonHello = new Button("Button"); add(buttonHello, "South"); Label labelHello = new Label("Label"); add(labelHello, "East"); TextArea textAreaHello = new TextArea("TextArea"); add(textAreaHello, "West"); //nastavíme velikost okna a zobrazíme jej setSize(300, 200); setVisible(true); } }
Obr. 3: Vzhled AWT a Swing na OS Windows 7.
37
6.1
Imperativní přístup tvorby GUI
6.1.2
38
Swing
Swing vznikl jako náhrada za AWT, které neobsahovalo dostatečně mocné komponenty pro tvorbu složitých uživatelských rozhraní (jako jsou např. tabulky, stromové struktury apod.). Na rozdíl od AWT jsou widgety ve Swingu napsané pouze v Javě a tím pádem nezávislé na použitém operačním systému. Ačkoli jsou komponenty Swingu platformně nezávislé, umožňují použít nativní vzhled a pocit ovládání charakteristický pro daný OS. Druhá možnost je využít přenositelného vzhledu a chování, který dává aplikacím uniformní vzhled napříč různými systémy. Rozdíl ve vzhledu aplikace vytvořené v AWT a přenositelným vzhledem Swingu je demonstrován na obrázku 3. (Oracle, 2011) 6.1.3
SWT
Za zkratkou SWT se skrývá anglický název Standard Widget Toolkit. Jedná se o opensource grafickou knihovnu pro tvorbu uživatelských rozhraní v jazyce Java. Je používána na platformě Eclipse jako alternativa ke standardním grafickým balíkům AWT a Swing. Cílem této knihovny je poskytnout účinný a přenosný přístup k základním prvkům uživatelského rozhraní operačních systémů, na kterém je výsledná aplikace vytvářena. SWT je implementováno tak, aby poskytlo aplikacím nativní vzhled, který je pro každý operační systém charakteristický. Toto tvrzení je demonstrováno na obrázku 4, kde je stejná aplikace vytvořena v různých operačních systémech. Hlavními designovými cíli jsou vysoký výkon a nativní vzhled včetně pocitu s hlubokou platformní integrací. Nedílnou součástí je i rozšířitelnost – vytváření nových widgetů za pomoci čistého Java kódu. (The Eclipse Foundation, 2013)
Obr. 4: Vzhled SWT na různých platformách. Zdroj: http://eclipse.org/swt/
6.2
Drag and drop nástroje
6.1.4
39
Které grafické prostředí použít?
Odpověď na tuto otázku není zcela jednoznačná. Obecně se má za to, že AWT je technologicky zastaralé a pro mnohé operace nedostačující prostředí. Nelze jej však úplně zatracovat. Své místo má zejména u začínajících programátorů, kterým se může Swing zdát až příliš komplexním. Vždy je lepší se začátky naučit na jednodušším prostředí a postupem času přejít na složitější, např. již zmiňovaný Swing. Co se týče srovnání SWT a Swing, to už záleží jen na tom, co od výsledné aplikace požadujeme. Obě prostředí poskytují dostatečnou funkcionalitu, abychom mohli vyvinout aplikaci s plnohodnotným grafickým rozhraním. Swing bude na každém OS vypadat naprosto stejně, jelikož implementuje vlastní widgety. Naproti tomu SWT je pouze rozhraní k widgetům, které vytváří sám OS. U obou je samozřejmostí tvorba vlastních widgetů. Určitou výhodu však má Swing, jelikož je naprosto přenositelný na různé platformy. SWT je závislé na implementaci pro dané systémy, avšak jejich podpora je v současnosti dostatečná. Jako zajímavý kompromis se zdají být různá hybridní prostředí, jako je například SwingWT, o kterém byla zmínka v úvodu kapitoly. Jedná se o grafickou knihovnu, která poskytuje Swing API, ale widgety jsou vytvářeny nativně pro danou platformu ze SWT. V současnosti je však ve stádiu beta verze a ne vše funguje tak, jak by mělo.
6.2
Drag and drop nástroje
Drag and drop by se do češtiny dalo přeložit jako táhni a pusť nástroje. Jak už napovídá sám název, uživatelské rozhraní je vytvářeno jednoduše pomocí myši. Programátor si z palety dostupných elementů GUI vybere ten, který zrovna potřebuje a přetáhne si ho na pracovní plochu. Zde může opět s využitím myši měnit pozice jednotlivých elementů, jejich velikost, překrývání apod. Celá tato konstrukce umožňuje okamžitě vidět ukázku výsledného rozhraní. GUI je také vytvořeno velmi rychle, což může být výhodné zejména ve fázi návrhu, kdy programátor má pro zákazníka rychle hotový prototyp rozhraní. Společně pak mohou doladit nesrovnalosti, na které by se jinak přišlo až po zdlouhavém programování. Pro velkou oblíbenost těchto nástrojů hraje fakt, že programátor nemusí mít žádné velké znalosti práce v daném programovacím jazyce. Jak už bylo poznamenáno výše, vytvoření funkčního GUI je otázkou jen několika kliknutí. Veškerý potřebný kód vygeneruje nástroj sám. Drag and drop nástroje bývají součástí větších vývojových prostředí. Pro vývoj aplikací v jazyce Java se jako nejznámější jeví NetBeans IDE19 a Eclipse20 . NetBeans obsahují pro tvorbu uživatelských rozhraní Swing GUI Builder (Matisse), který je 19 20
http://netbeans.org/ http://www.eclipse.org/
6.2
Drag and drop nástroje
40
součástí standardní instalace prostředí. Pro Eclipse je velmi oblíbený plug-in s názvem WindowBuilder. 6.2.1
Swing GUI Builder (Matisse)
Jak už bylo předesláno výše, tento nástroj je součástí vývojového prostředí Netbeans IDE. S jeho pomocí lze snadno vytvářet profesionální uživatelská rozhraní tím, že potřebné komponenty přeneseme z palety na pracovní plátno. Nástroj se sám postará o správné zarovnání a mezery mezi komponentami. Pro generování výsledného zdrojového kódu umožňuje zvolit některá nastavení, jako například generování plných jmen tříd apod. Swing GUI Builder má předinstalovanou paletu Swing a AWT komponent, umožňuje však i přidávání komponent vlastních. Součástí je i pohodlné odstraňování chyb, kdy například můžeme vyhledat zdrojový kód komponenty podle vizuálního náhledu (nemusí se zdlouhavě procházet celý zdrojový kód ručně). (Oracle, 2013) Uživatelské rozhraní nástroje (příloha B) lze rozdělit do několika samostatných oblastí. Uprostřed plochy hlavního okna (červeně ohraničená oblast) se nachází pracovní plátno, kam můžeme přidávat jednotlivé komponenty a tím vytvářet GUI. Pomocí tlačítek lze libovolně přepínat mezi zdrojovým kódem vytvářeného rozhraní a návrhem (rozmístění komponent). Tyto přidáváme na pracovní plátno z palety, která se nachází v pravé horní části obrazovky (modré ohraničení). Komponenty, neboli již vysvětlované widgety, jsou v paletě organizovány do skupin podle jejich využití (kontejnery, widgety pro vstup uživatele apod.). V levé části okna (zelené ohraničení) nalezneme stromovou strukturu všech widgetů přidaných na pracovní plátno. Po klepnutí na některý z nich se zobrazí vlastnosti na panelu, který je umístěn v pravé dolní části pracovní plochy nástroje (žlutě ohraničená oblast). Tyto lze pak samozřejmě upravovat, nebo vrátit původní nastavení. Kromě vlastností komponent se zde nachází ještě záložka s událostmi (klepnutí myši na komponentu apod.). 6.2.2
WindowBuilder
Do značné míry je funkcionalitou i vzhledově podobný výše představenému Swing GUI Builderu. WindowBuilder je však implementován jako plug-in pro vývojové prostředí Eclipse. Od předchozího nástroje se dále liší podporovanými grafickými prostředími, jelikož je schopen vytvářet aplikace jak s využitím klasického Swingu, tak i SWT. (Google, Inc., 2012) Pokud se zaměříme na uživatelské rozhraní nástroje (příloha C), je konceptuálně dosti podobné Swing GUI Builderu. Pracovní plocha se dá opět rozdělit do několika oblastí, které mají obdobnou funkcionalitu (bylo popsáno výše).
6.3
Tvorba GUI s využitím XML
6.2.3
41
Swing GUI Builder vs. WindowBuilder
Rozhodnout, který ze dvou zde představených nástrojů na tvorbu GUI v Javě je lepší, se bude muset asi každý programátor sám. Pravděpodobně záleží jen na jeho subjektivních preferencích. Oba nástroje jsou totiž jak funkcionálně, tak i vzhledově dosti podobné, i když drobné rozdíly tu přeci jen jsou. V neposlední řadě je to také o volbě vývojového prostředí, kde někteří programátoři zarytě obhajují NetBeans (volba pak padá na Swing GUI Builder). Naopak ti druzí používají jen Eclipse (jejich volbou je tedy WindowBuilder). Swing GUI Builder je v současné době projektem společnosti Oracle, té samé společnosti, která vlastní i samotnou Javu. Je tedy jakousi logickou volbou používat nástroj přímo od společnosti, která vyvíjí i daný programovací jazyk. Uživatel nástroje pak může očekávat téměř okamžitou integraci nových služeb, jako je například podpora JavaFX21 . Na druhou stranu WindowBuilder má určitou výhodu v tom, že je opravdu plně obousměrný nástroj. Lze jednoduše upravovat výsledný kód a změny se okamžitě promítnou i do návrhové části. Nepoužívá totiž žádné XML ani další pomocné soubory. Generovaný kód je čistě Java.
6.3
Tvorba GUI s využitím XML
Při tvorbě rozsáhlých projektů se zdá být výhodné oddělení tříd uživatelského rozhraní od aplikační logiky. Bez větších zásahů pak dokážeme celou aplikaci převést na úplně jiný systém, např. z aplikace pro desktopy na aplikaci pro mobilní zařízení. Pokud zajdeme ještě dál a použijeme pro popis uživatelského rozhraní nějakou obecnou formu, stačí mít pro různé platformy stejnou nejen aplikační logiku, ale i popis samotného GUI. Pro migraci pak pouze zabezpečíme správnou interpretaci obecného zápisu. Právě zde přichází na řadu XML, které je už poměrně dlouhou dobu známo jako prostředek pro obecný zápis strukturovaných dat. Avšak zhruba před deseti lety přišlo i na masovější využití jazyka XML pro popis uživatelských rozhraní, např. s programovacím jazykem Java. Zprvu se zdálo, že rychle vytlačí klasické programování GUI ve Swing/AWT nebo SWT. Vznikaly různé speciální jazyky pro popis GUI v XML, jako je např XUL22 . Kromě XML jazyků byly potřeba i nástroje, které GUI popsané v obecné formě sestaví za běhu programu, nebo vygenerují kód příslušného programovacího jazyka. Jejich vývoj však začal postupem času upadat a v současné době situace vypadá tak, že jen málo z původně ambiciózních projektů je ve větší míře využíváno (ve spojitosti s Javou a desktop aplikacemi). 21 22
Jedná se o úsporný nástroj, který generuje Swing objekty z běžného XML dokumentu. Tento přístup však neumožňuje, abychom dokázali popsat uživatelské rozhraní ve formě, která je obecně použitelná i pro jiné platformy než je Swing v Javě. Pokud se na toto tvrzení podíváme z opačné stránky, přináší i určité výhody. Svým zaměřením pouze na Swing je SwiX𝑚𝑙 velmi malý a zároveň rychlý nástroj. Programátor, který je zvyklý pracovat se Swingem, se nemusí učit žádnou jinou syntaxi pro popis GUI v XML dokumentu. Umožňuje oddělit vlastní uživatelské rozhraní (popsané v XML) od aplikační logiky, která bude naprogramována v Javě. (Paulus, 2012) Na jednoduchém příkladu si ukážeme definici GUI za pomocí SwiX𝑚𝑙 . Nejdříve je potřeba vytvořit XML soubor, který obsahuje popis jednotlivých elementů výsledného rozhraní: <panel constraints="BorderLayout.CENTER"> <panel constraints="BorderLayout.SOUTH"> V konstruktoru třídy pak vytvoříme nový SwingEngine a zavoláme metodu render, která převezme námi vytvořený XML soubor s popisem uživatelského rozhraní (výsledek této činnosti je demonstrován na obrázku 5): new SwingEngine(this).render("xml/helloworld.xml").setVisible(true);
6.3.2
Luxor – XML UI Language (XUL) Toolkit
Luxor je volná implementace značkovacího jazyka XUL, který byl vyvinut společností Mozzila. Vznikly z něj zajímavé projekty jako je Thunderbird23 či Firefox24 a sa23 24
Obr. 5: Uživatelské rozhraní vytvořené pomocí nástroje SwiX𝑚𝑙 .
motný XUL má velmi dobrou dokumentaci se spoustou příkladů. Luxor se však od původního konceptu v určitých směrech odlišuje. Předně je zaměřen na jazyk Java. Ten se využívá pro náročné programování logiky a chování systému. Pro skriptování se doporučuje využívat Python (avšak může být přidána i podpora JavaScriptu). Samotná specifikace uživatelského rozhraní v jazyce XUL je velice snadná. Dosáhnout zajímavého výsledku je mnohem snazší, než napsat celé rozhraní čistě ručně. Následující příklad byl převzat ze stránek Luxoru a jasně tak demonstruje jednoduchost syntaxe (Luxor Foundation, 2005): Verze s využitím XUL -------------------<menuitem action="newApplication" label="New Application..." mnemonic="A" accel="control A" icon="newApplication" /> Stejná funkcionalita ve Swingu -----------------------------JMenuItem mi = new JMenuItem( "New Application..." ); mi.addActionListener( cmdNewApplication ); mi.setMnemonic( ’A’ ); mi.setAccelearator( KeyStroke.getKeystroke( "control A" ) ); mi.setIcon( new ImageIcon( "images/newApplication.gif" ) ); 6.3.3
E4/XWT
XML Window Toolkit (XWT) je framework určený pro tvorbu grafických uživatelských rozhraní ve vývojovém prostředí Eclipse. Řešení je opět postaveno na XML se všemi výhodami představenými výše. Zajímavé je zejména pro programátory, kteří mají zkušenosti s webovými technologiemi a designem. Nabízí například podporu externích CSS stylů. XWT je primárně určeno pro vývoj pod Eclipse. Z tohoto důvodu umožňuje v XML definovat widgety, které jsou součástí grafického prostředí SWT. Stejně jako
6.3
Tvorba GUI s využitím XML
44
předchozí nástroj SwiX𝑚𝑙 je tedy i XWT pevně svázán s určitou platformou, jejíž syntaxi musí programátor znát. (The Eclipse Foundation, 2012) Následující příklad demonstruje použití XWT při tvorbě triviálního rozhraní, jehož výsledek je zobrazen na obrázku 6. Rozhraní bylo vytvořeno ručně, avšak Eclipse umožňuje ve svém prostředí i využití myši. <Shell xmlns="http://www.eclipse.org/xwt/presentation" xmlns:x="http://www.eclipse.org/xwt" text="Hello World in XWT" size="540,280"> <Shell.layout> <Button text="Button in XWT" background="Aquamarine" /> <StyledText text="StyledText in XWT" background="LemonChiffon"> <StyledText.layoutData>
6.3.4
Shrnutí
V této sekci diplomové práce byly představeny tři různé přístupy k tvorbě GUI s využitím značkovacího jazyka XML. Prvním je SwiX𝑚𝑙 . Ten je pevně spjat s grafickým prostředím Swing a umožňuje vytvářet widgety prostřednictvím obyčejných
6.3
Tvorba GUI s využitím XML
45
Obr. 6: Uživatelské rozhraní vytvořené pomocí jazyka XWT v Eclipse.
XML dokumentů. Druhý nástroj Luxor je volnou implementací speciálně navrženého jazyka XUL pro popis uživatelských rohraní v XML. Dále je orientován na Javu a Python. Poslední zde představený nástroj – XWT – je pevně spjat s vývojovým prostředím Eclipse. Umožňuje tak vytvářet widgety grafického prostředí SWT. Pokud tyto tři nástroje budeme hodnotit z pohledu jednoduchosti použití, nejlepší se zdá být XWT. Je volně dostupný jako doplněk pro Eclipse a pokud nechceme, nemusíme výsledný XML soubor (respektive XWT) psát ručně. XWT je plně integrováno s Eclipse. Tudíž umožňuje jednotlivé widgety výsledného GUI natahat myší. Máme okamžitý náhled na budoucí rozhraní a současně můžeme nastavení widgetů upravovat ručně v XML kódu. Pokud tyto úpravy provádíme v Eclipse, promítá dokonce změny okamžitě do náhledu. Další výhodou pro XWT je i jeho neustálý vývoj a docela obstojná dokumentace na Internetu. Oproti tomu takový Luxor už dlouho nebyl aktualizován a ani s dostupnými informacemi na tom není zrovna nejlépe. Výhodou Luxoru je však jeho univerzálnost, jelikož XUL není spjat se Swingem ani se SWT. Uživatel nástroje proto nemusí znát práci v těchto grafických prostředích a s trochou cviku dokáže v XUL syntaxi vytvořit zajímavé uživatelské rozhraní. Pokud uvažujeme nad tvorbou GUI s využitím XML, nejvíce zajímavým a perspektivním projektem do budoucna se jeví XWT ve spolupráci s vývojovým prostředím Eclipse.
7
NÁVRH A POPIS IMPLEMENTACE
7 7.1
46
Návrh a popis implementace Návrh GUI síťového generátoru
Tato sekce se zabývá návrhem uživatelského rozhraní pro generátor síťového provozu. Testování sítě a s tím spojené generování provozu je proces, který by se dal zjednodušeně rozdělit do několika kroků: • definice testované topologie (kdo se bude testu aktivně účastnit), • definice komunikačního profilu (kdo, kam a kdy bude odesílat pakety), • spuštění testu nad komunikačním profilem, • vyhodnocení testu. Návrh aplikace bude z těchto kroků vycházet. Zamýšlený koncept organizuje pracovní plochu do několika záložek, které uživatele provedou procesem testování sítě za pomoci generátoru. 7.1.1
Úvodní obrazovka
Obrázek 7 představuje úvodní obrazovku aplikace. Kromě již zmiňovaných záložek má uživatel v jakémkoliv kroku přístupné hlavní menu nahoře, jehož funkcionalita bude vysvětlena později. Vespodu aplikace se nachází stavový řádek, který zobrazuje informace o aktuálním datu a čase (důležité pro tvorbu komunikačního profilu), informaci o tom, zda se jedná o již uložený projekt, nebo projekt nový a také IP adresu stroje, kde je aktivní modul Statistika. Hlavní pracovní plocha této obrazovky je rozdělena do dvou sekcí. První se dotazuje uživatele, zda chce vytvořit nový projekt, nebo otevřít již uložený projekt a pokračovat tak v rozdělané práci. Druhá sekce umožňuje nastavit vzhled aplikace. Podle specifikace požadavků jsou pro testování sítě pomocí síťového generátoru potřebné dva různé přístupy. Jedním je tzv. manuální režim, který zobrazuje data v klasickém tabulkovém provedení. Druhý režim je grafický, který umožňuje vizualizaci některých kroků při tvorbě testu, konkrétně definici topologie a komunikačního profilu. Grafický režim je vhodný zejména pro menší projekty, kde není rozsáhlá topologie testované sítě a komunikační profil se skládá jen z několika málo záznamů. Takovýto projekt je pak pro uživatele snazší vytvořit pomocí myši. Naopak při velkém projektu by grafický režim nedokázal uživateli dostatečně přehledně data vykreslit. Při zvolení grafického režimu může uživatel ještě zvolit mezi tím, zda chce graficky vytvářet jen topologii nebo komunikační profil, nebo zda chce mít obě záložky vizuální. Podrobnější popis obou režimů bude následovat níže.
7.1
Návrh GUI síťového generátoru
47
Obr. 7: Úvodní obrazovka aplikace.
7.1.2
Obrazovka pro tvorbu testované topologie
Tato obrazovka umožňuje uživateli definovat topologii sítě, na níž se má test vykonat. U každého uzlu je potřeba nastavit jeho název (hostname), IP adresu a moduly generátoru, které jsou na stroji spuštěné. Je zde přítomno i tlačítko, které umožňuje automatickou detekci uzlů na síti, včetně charakteristik vyjmenovaných výše. Uživatel tak nemusí zadávat topologii ručně, ale vše potřebné systém detekuje sám. Dále pak má uživatel možnost otestovat dostupnost uzlů, či celou topologii načíst ze souboru. Na obrázku 8 je verze této obrazovky v tzv. klasickém režimu. Obrázek 9 pak ukazuje tu samou obrazovku v režimu grafickém. Rozdíl mezi nimi je zřejmý na první pohled. Obě umožňují stejnou funkcionalitu, avšak klasický režim zobrazuje jednotlivé uzly na síti tabulkově, zatímco grafický režim vykresluje zjednodušený diagram topologie. Nastavení uzlu v grafickém režimu se pak definuje v samostatném dialogovém okně, které je přístupné po klepnutí na uzel. 7.1.3
Obrazovka pro definici komunikačního profilu
Na této obrazovce vytváří uživatel komunikační profil, což je seznam všech datových toků, které budou v rámci testu generovány. Uživatel zvolí zdroj komunikace (jeden či více uzlů v topologii, které obsahují komponentu Sender), cílového hosta a protokol, kterým spolu budou komunikovat. Dále zvolí startovní čas dané komunikace, počet opakování a prodlevu mezi jednotlivými opakováními.
7.1
Návrh GUI síťového generátoru
Obr. 8: Obrazovka pro vytvoření testované topologie.
Obr. 9: Obrazovka s možností grafické tvorby testované topologie.
48
7.1
Návrh GUI síťového generátoru
Obr. 10: Obrazovka pro tvorbu komunikačního profilu.
Obr. 11: Obrazovka s možností grafické tvorby komunikačního profilu.
49
7.1
Návrh GUI síťového generátoru
50
Pro zjednodušenou tvorbu komunikačního profilu může uživatel využívat stereotypů. Stereotyp je seznam již předdefinovaných datových toků, které jsou univerzálně použitelné na libovolné topologii25 . Uživatel zvolí jen zdrojového hosta a stereotyp, který na zvoleného odesílatele aplikuje. Cílový host je povětšinou nějaký server, na kterém běží nativní síťová služba podle protokolu, kterým chceme komunikovat. Toto tvrzení však nemusí platit vždy (např. u protokolu ICMP postačí, aby byl jako cílový host zvolen jakýkoliv počítač). Pokud chceme proběhlou komunikaci zachytit (důležité pro tvorbu přesných statistik), musí zde být navíc přítomna i komponenta Capture. Jako v případě tvorby testované topologie, tak i zde je možné zvolit mezi dvěma různými přístupy (režimy) pro tvorbu komunikačního profilu. Na obrázku 10 je zobrazen klasický přístup za pomoci vstupních formulářů vlevo a zobrazení vytvořených záznamů v tabulce vpravo. Grafický režim (obrázek 11) poskytuje stejnou funkcionalitu, avšak trochu odlišným způsobem. Základem této myšlenky je tzv. časová osa (dolní část obrazovky), na kterou se umisťují jednotlivé záznamy. Uživatel má před sebou seznam všech hostů, kteří mohou sloužit jako odesílatelé (komponenta Sender). Ze seznamu si jednoho hosta vybere a přetáhne ho na časovou osu do bodu, ve které má zamýšlená komunikace začít. Po umístění se zobrazí dialogové okno, které obsahuje vstupní formulář pro všechny další aspekty komunikace (např. cílový host, protokol či stereotyp apod.). 7.1.4
Dialogová okna pro správu stereotypů
Při vytváření komunikačního profilu může uživatel využívat již dříve zmiňovaných stereotypů. Na obrázku 12 jsou dialogová okna určená pro jejich správu. Na prvním okně může uživatel přidávat nové stereotypy, mazat stávající nebo si prohlížet detaily stereotypu – tzn. samotné datové toky, které ho tvoří. Dialogové okno s detailem stereotypu je znázorněno na obrázku 13. Druhé dialogové okno na obrázku 12 slouží k propojení již vytvořených stereotypů s aktuálně používanou topologií. Stereotyp je totiž sám o sobě definován obecně, aby mohl být použitelný na různých topologiích. Neříká přesně odkud a kam datový tok půjde, ale definuje pouze konkrétní typy komunikace (protokoly), které budou v rámci stereotypu používány. Uživatel si tedy může sám nadefinovat sadu obecných stereotypů, které budou univerzálně použitelné v různých testech a na různých topologiích. Při každé změně topologie ale musí vytvořit nové propojení stereotypů s aktuální topologií (viz obrázek 12, druhý dialog). 25
Toto tvrzení platí za předpokladu, že na zvolené topologii existují všechny služby, které jsou stereotypem využívány (např. server Apache pro korektní generování http provozu). Zároveň musí být splněna i podmínka správného nastavení systému.
7.1
Návrh GUI síťového generátoru
51
Obr. 12: Dialogová okna pro správu stereotypů.
Obr. 13: Dialogové okno s detailem stereotypu.
7.1.5
Obrazovka pro spuštění testu.
Po vytvoření topologie a komunikačního profilu následuje spuštění testu (obrázek 14). Uživatel vybere datum začátku testu a délku trvání. Pro orientaci je zobrazen i čas začátku, který je startovním časem prvního záznamu (z časového hlediska) v komunikačním profilu. Běžící test generuje logovací zprávy, např. o stavu komponent generátoru na síti. Ty jsou pak zobrazovány v pravé části obrazovky. Uživatel může tyto zprávy uložit do textové souboru, nebo je ze seznamu vymazat.
7.2
Návrh komunikačního profilu
52
Obr. 14: Obrazovka pro spuštění testu.
7.2
Návrh komunikačního profilu
V příloze D je na obrázku 20 zobrazen návrhový diagram tříd, který představuje komunikační profil generátoru. Jsou zde uvedeny i třídy, které umožňují uchovávat informace o topologii testované sítě. Základem topologie je třída Uzel, která obsahuje informace o názvu uzlu v síti (hostname), jeho IP adresu a komponenty, které jsou na něm dostupné. Komponenty jsou uchovávány prostřednictvím výčtového typu enum s názvem Komponenta, který může nabývat tří hodnot – Sender, Capture a Statistika. Samotný komunikační profil je třída KomProfil. Bude implementován jako Singleton (Jedináček), jelikož v rámci testu může existovat jen jedna jeho instance. Komunikační profil integruje seznam objektů třídy ZaznamProfil. Ta může být dvojího typu. Buď obsahuje záznam, který pochází z manuální tvorby (ručně definujeme odkud a kam půjde konkrétní datový tok), nebo je to záznam vytvořený prostřednictvím stereotypu. Třída ZaznamProfil je potomkem abstraktní třídy Zaznam. Z této třídy dědí ještě ZaznamStereotyp. Záznam ve stereotypu na rozdíl od záznamu v komunikačním profilu nepotřebuje znát cílového hosta a v proměnné protokol očekává samotnou instanci třídy Protokol. Naproti tomu záznam v komunikačním profilu očekává některého z potomků třídy Protokol (např. ProtokolHTTP). Důvod je prostý. Záznamy ve stereotypu musí být znovupoužitelné na jakékoli topologii. Vlastní propojení stereotypů s topologií bude řešeno na základě nastavení v uživatelském rozhraní nástroje.
7.3
Popis implementace
7.3
53
Popis implementace
V předchozích sekcích této kapitoly bylo navrženo uživatelské rozhraní a třídy komunikačního profilu. Dalším logickým krokem k dosažení cíle práce je tedy implementace navrhovaného řešení a jeho integrace s již vyvinutým jádrem systému. Jak už bylo předesláno dříve, vývoj probíhal v jazyce Java (JDK 1.7). Jako vývojové prostředí bylo vybráno NetBeans IDE verze 7.4. Práce s uloženými daty ve formě XML souborů je prováděna prostřednictvím knihovny JDOM verze 2.0.5, jejíž popis je uveden v kapitole Technologická východiska práce. 7.3.1
Implementace komunikačního profilu a jeho správy
Implementace komunikačního profilu proběhla přesně podle tříd, které jsou uvedeny v návrhu výše. Specifikace požadavků na systém však požaduje, aby bylo možné komunikační profil vytvářet i mimo aplikační prostředí generátoru. Z tohoto důvodu bylo vybráno XML jako prostředek pro uložení dat komunikačního profilu. Příloha E obsahuje XML schéma, které slouží k validaci souboru s uloženými záznamy komunikačního profilu. Schéma nám kontroluje např. správné zadání IP adresy (0-255.0-255.0-255.0-255) a u povinných atributů, zda nejsou elementy prázdné apod. Takto navržené schéma poskytuje dostatečně silnou ochranu před chybnými vstupy uživatele už při samotném vytváření dat mimo aplikační prostředí generátoru (pokud si samozřejmě uživatel sám dokument validuje). Pro lepší představu, jak má vypadat komunikační profil v nadefinovaném XML formátu, obsahuje příloha E i příklad takovéhoto souboru. Obsluha XML souborů v Javě byla implementována prostřednictvím knihovny JDOM. Například načtení komunikačního profilu je realizováno za pomoci objektu třídy KomProfilXMLReader. Ten při svém vzniku vyžaduje XML soubor, odkud má být profil načten, a také instanci uživatelského rozhraní aplikace. To z důvodu, abychom mohli vytvářet různá dialogová okna s informacemi o načítaném souboru v prostředí třídy KomProfilXMLReader, ale zobrazovala se v hlavním okně aplikace. Samotné načtení komunikačního profilu probíhá v metodě zpracuj(). Pokud v průběhu zpracování souboru dojde k nějaké chybě, metoda vrátí false a přeruší svůj průběh. Jestliže proběhne vše v pořádku, můžeme zavolat metodu getZaznamy(), která vrací seznam všech načtených záznamů – komunikační profil. Následuje názorná ukázka načtení komunikačního profilu aplikací. // vytvoreni noveho objektu KomProfilXMLReader KomProfilXMLReader nactiP = new KomProfilXMLReader(xmlFile, this); // volani metody, dalsi kroky jsou podmineny uspesnym zpracovanim if (nactiP.zpracuj()) { // ziskani nactenych zaznamu a prirazeni do Singletonu profil profil.setZaznamy(nactiP.getZaznamy()); .... // dalsi prace s profilem, napr. zobrazeni v tabulce apod. }
7.3
Popis implementace
7.3.2
54
Integrace vytvořeného řešení s jádrem generátoru
Jádro generátoru bylo navrženo a implementováno jako distribuovaný systém – jednotlivé komponenty mohou být separované na různých uzlech v síti a vzdáleně spolu komunikují. Schéma komponent a možné komunikace mezi nimi je zobrazeno na obrázku 2. Aby bylo možné přijímat zachycenou komunikaci ve formě souborů *.pcap, je nutné při spuštění aplikace vytvořit objekt třídy TCPServerPCAP1 a spustit jej jako nové vlákno. Tímto budeme mít po celou dobu běhu aplikaci přístupný TCP server, který bude naslouchat na smluveném portu (6787). Komponenty Capture po ukončení odchytu odešlou zachycenou komunikaci právě na tento server. Obdobná je situace v případě odesílání logů komponentami. Tentokrát však nebudeme vytvářet TCP server, ale postačí nám UDP (port 9999). Jako nové vlákno spustíme objekt třídy LogServerUDP. Před samotným spuštěním testu je nutné provést několik operací. Musíme všem komponentám Capture rozeslat řídící instrukce a komunikační profil transformovat na objekt třídy CP, který agreguje objekty třídy DilciCP. Ty je možné odesílat komponentám Sender po síti a nakonec tyto dílčí profily rozeslat se všemi jejich záznamy jednotlivým Senderům. //vytvoreni noveho vlakna pro kazdou komponentu Capture zvlast Thread klientCapture = new TCPClient1(delkaTestu, zacatekTestu, packetSize, ipStatistika, ipCapture, portCapture) { @Override public void run() { try { sendToCapture(); } catch (Exception ex) { // ... zpracovani vyjimky } }; //spusteni vlakna s TCP klientem klientCapture.start(); Výše uvedená část kódu je jádrem metody, která zajišťuje odeslání řídících instrukcí na komponentu Capture. Tuto metodu je nutné volat cyklicky pro každý uzel zvlášť a vyžaduje jeho správnou IP adresu. Vytváříme objekt třídy TCPClient1, který obsahuje dva konstruktory: public TCPClient1(int durat, Date startDate, int sizeLim, String IPstat, String IPCap, int portCaptureServer) public TCPClient1(DilciCP instrukce, int portSenderu) Nás v tuto chvíli zajímá první konstruktor k vytvoření TCP klienta, který bude odesílat řídící instrukce na zvolený uzel v síti s komponentou Capture. Vytvoření
7.3
Popis implementace
55
objektu vyžaduje délku trvání odchytu paketů, startovní čas, velikost zachycených dat26 , IP adresu uzlu s komponentou statistika, IP adresu uzlu, na který pokyny odesíláme a konečně port (implicitně je to 6790). Při vytváření nového objektu je ještě nutné překrýt metodu run(), která je volána po spuštění vlákna. Jedním z důvodů, proč není tato metoda překryta přímo ve zdrojovém kódu třídy TCPClient1, je ten, že lze tuto třídu využít dvojím způsobem, viz dva různé konstruktory výše. Druhý důvod je možnost zpracování výjimek až na úrovni uživatelského rozhraní (metoda sendToCapture() výjimky nezpracovává, ale jen je zachycuje a posílá výše), což by v samostatné metodě run() nebylo možné. Druhý typ konstruktoru třídy TCPClient1 využijeme při vytváření TCP klienta, který má na starost odeslání všech záznamů v dílčím profilu na určený uzel s komponentou Sender. Konstruktor vyžaduje objekt třídy DilciCP, který získáme cyklickým procházením seznamem všech dílčích profilů a cílový port (implicitní hodnota portu pro Sender je 6789). Seznam dílčích profilů získáme jednoduchým voláním metody getDilciProfily() nad objektem třídy CP. Vytvoření nového klienta poté probíhá obdobně jako v předchozím případě, jen metodu run() překryjeme jiným způsobem – konkrétně voláme metodu send(). 7.3.3
Implementace uživatelského rozhraní a běh aplikace
Na základě navržených wireframů bylo implementováno uživatelské rozhraní generátoru. K implementaci byla vybrána standardní knihovna Swing, jejíž popis je uveden v předchozí kapitole. Oproti návrhům neproběhly žádné velké změny. Jen pro lepší orientaci uživatele v prostředí aplikace byla veškerá funkční tlačítka doplněna o vhodné barevné ikony, jak je např. vidět na úvodní obrazovce aplikace (viz obrázek 21). Nutno ještě podotknout, že veškeré zde popisované obrazovky se nachází v příloze F. Pro jednoznačné určení konkrétní obrazovky budou tedy uváděna jen čísla obrázků. Aplikace byla navržena tak, aby co nejvíce zamezila chybám ve vstupu uživatele a pomohla mu zadat správné údaje. Všude tam, kde to bylo možné, jsou na místě vstupních údajů rozmístěny komponenty JComboBox s předdefinovaným seznamem možností. Pro všechny číselné a časové údaje byly použity komponenty JSpinner, které mají nadefinovaný obor hodnot a chybný vstup od uživatele je tak prakticky vyloučen. Rozmístění těchto komponent můžeme vidět např. na záložce s definicí komunikačního profilu (viz obrázek 22). V některých případech však nebylo možné těchto komponent využít a uživatel musí zadat požadované údaje do klasického textového pole – komponenty JTextField. Aby se předešlo chybným vstupům i v případě těchto textových polí, obsahuje aplikace tzv. tooltips, které se zobrazí při najetí myši na danou komponentu. Uživatel dostane informaci např. o povinnosti uvedení vybraného údaje, včetně krát26 Generátor zde pracuje s myšlenkou, že není potřeba zachytávat pakety v plné velikosti, ale pro zjištění všech potřebných údajů postačí jen jeho část. Takovéto ořezávání oceníme zejména při přenášení velkých paketů po síti.
7.3
Popis implementace
56
kého textového popisu (viz obrázek 23). Tooltips obsahují i jiné komponenty, kde může být požadovaný vstup pro nezasvěceného uživatele obtížněji pochopitelný. Ačkoliv byla aplikace navržena a implementována s filozofií minimalizace chybných vstupů od uživatele, úplně vždy se jim vyhnout nelze. Typickým příkladem se zdá být načítání souboru s aplikačními daty. Zde může obecně docházet k různým typům chyb. My se zaměříme především na ty, které vznikají načítáním komunikačního profilu ze XML souborů. Před otevřením souboru aplikace nejdříve kontroluje, zda je soubor validní podle schématu, který byl představen výše. Už v této fázi mohou nastat v zásadě tři typy chyb – nepůjde otevřít XML Schema soubor pro validaci, komunikační profil v XML otevřít taktéž nepůjde, či nebude validní. Pokud však bude všechno v pořádku, aplikace pokračuje v načítání profilu. Soubor ale může obsahovat stále chyby, které nebylo možné pouhou validací odhalit, např. cesta k MP3 souboru pro RTP streamování je neplatná apod. Posledním typem chyb, které zde mohou vzniknout, je absence nebo nekompletnost testované topologie. Každou IP adresu, kterou použijeme v záznamu komunikačního profilu, musíme mít přidanou v topologii jako uzel. Ukázka chybového hlášení při načítání komunikačního profilu je zobrazena na obrázku 24. Implementované řešení samozřejmě ošetřuje všechny typy chyb, které zde byly představeny. Výsledná aplikace generátoru síťového provozu byla kompletně lokalizována do českého jazyka, včetně všech varovných/informativních hlášek a dialogových oken pro načítání/ukládání z/do souboru. Právě pro ukládání a načítání bylo nutné všechny instance třídy JFileChooser upravit pomocí třídy UIManager, konkrétně její metody put. Příklad takto upraveného dialogového okna je demonstrován na obrázku 25.
8
EKONOMICKÉ ZHODNOCENí PRÁCE
8
57
Ekonomické zhodnocení práce
Ekonomické zhodnocení by mělo být součástí všech technických projektů. Návratnost vložených prostředků do projektu je často klíčovým faktorem pro rozhodnutí, zda navrhované řešení reálně nasadit či nikoliv. Zach (2012) popisuje jako optimální variantu pro nasazení generátoru síťového provozu v praxi využití režijní tzv. out-of-band sítě. Příklad tohoto řešení je demonstrován na obrázku 15. Testování pak není ovlivněno žádnou režijní komunikací, která je potřebná např. pro odesílání řídících signálů na jednotlivé komponenty systému. To však s sebou nese zvýšené náklady na realizaci projektu, jelikož je potřeba počítat i s náklady na režijní síť.
Obr. 15: Nasazení generátoru s využitím režijní sítě. Převzato od Zacha (2012)
8.1
Náklady na režijní out-of-band síť
Jak je zřejmé z obrázku 15, náklady na režijní síť jsou ovlivněny samotnou konfigurací testované sítě. Důležitou roli zde hraje počet uzlů v síti a použité technologie, např. značka výrobce serverů. Mějme tedy modelový případ, kdy testovaná síť obsahuje 30 uzlů, které tvoří obyčejné desktop stanice uživatelů a jeden server HP ProLiant, který poskytuje síťové služby. Náklady na režijní síť pak budou tvořit zejména přídavné síťové adaptéry pro všechny uzly v síti, adaptér pro server, switch s potřebným počtem portů a volitelný počítač. Ten bude sloužit jako řídící stanice pro generátor a bude ovládat všechny uzly, které jsou do testu zapojeny. Shrnutí nákladů této varianty jsou zobrazeny v tabulce 2. Celkové náklady na komponenty režijní out-of-band sítě tedy tvoří 22 700,- Kč. Na vybrané komponenty nebyly kladeny žádné vysoké nároky, jelikož budou obsluhovat jen režijní komunikaci, včetně logování komponent. Například vybraný switch
8.2
58
Ekonomický přínos síťového generátoru
Tab. 2: Náklady na realizaci zvolené režijní sítě.
Položka Počet (ks) TP-LINK TG-3468 30 HP NC360T PCI-E Dual Port 1 TP-LINK TL-SF1048 1 Volitelný počítač 1 Celkem
Cena za ks 200,4 700,2 000,10 000,-
Cena celkem 6 000,4 700,2 000,10 000,22 700,-
nemusí splňovat požadavky velké datové propustnosti, ale postačí fakt, že má dostatečný počet portů pro všechny uzly v testované síti.
8.2
Ekonomický přínos síťového generátoru
Generátory síťového provozu se dají v praxi využít pro testování počítačové sítě. Vyjádřit úplně exaktně ekonomický přínos tedy není snadné. Generátory nejsou přímo určeny ke zvýšení tržeb podniku. Ekonomický přínos se však dá vyjádřit i jako úspora času síťového specialisty, který může takto získaný čas věnovat na řešení jiných problémů v podnikové síti. Například síťový specialista má zavést nová pravidla pro firewall, aby reflektovaly aktuální požadavky na bezpečnostní politiku firemní počítačové sítě. Nejprve vytvoří pravidla pro firewall, která následně implementuje buď na testovací síti, nebo produkční (avšak mimo reálný provoz, např. v noci). Za pomoci generátoru pak namodeluje síťový provoz, který fungování pravidel firewallu ověří. Tímto způsobem může pravidla doladit až na úroveň, kdy budou bezpečně použitelná v běžném provozu. Nebude poté muset řešit situace, kdy uživatel X nemá přístup k firemnímu serveru Y, i když by ho mít měl.
8.3
Návratnost investice do síťového generátoru
Doba návratnosti, nebo-li doba splacení (anglicky payback period) je období, za které se nám vrátí původní náklady na investici. Kromě investičních nákladů tedy potřebujeme znát ještě peněžní příjmy (čistý cash flow) za období, pro které chceme dobu návratnosti spočítat. Matematicky můžeme toto tvrzení vyjádřit pomocí vzorce (Synek a kol., 2007): 𝐷𝑜𝑏𝑎 𝑛á𝑣𝑟𝑎𝑡𝑛𝑜𝑠𝑡𝑖 =
𝑛á𝑘𝑙𝑎𝑑𝑦 𝑛𝑎 𝑖𝑛𝑣𝑒𝑠𝑡𝑖𝑐𝑖 . 𝑐𝑎𝑠ℎ 𝑓 𝑙𝑜𝑤 𝑧𝑎 𝑑𝑎𝑛é 𝑜𝑏𝑑𝑜𝑏í
(1)
Podle údajů Českého statistického úřadu průměrná měsíční hrubá mzda odborného zaměstnance v IT za rok 2012 činí 47 342,- Kč (viz obrázek 16). Pokud k tomuto číslu připočteme ještě povinné odvody ve výši 34 %, dostaneme měsíční mzdové náklady na zaměstnance ve výši 63 439,- Kč. Průměrně můžeme počítat se
8.3
Návratnost investice do síťového generátoru
59
Obr. 16: Průměrná hrubá měsíční mzda IT odborníků v ČR. Převzato od ČSÚ, Strukturální mzdová statistika (2012)
175 odpracovanými hodinami v měsíci. Mzdové náklady na jednu hodinu práce pak zaokrouhleně vychází na 360,- Kč. Nasazení generátoru síťového provozu v praxi však s sebou nese provozní náklady, jako je např. čas potřebný na tvorbu testu, elektrická energie apod. Tyto náklady byly stanoveny na 800,- Kč měsíčně. Pokud odhadneme měsíční úsporu času síťového specialisty, můžeme spočítat dobu návratnosti podle vzorce, který byl představen výše. Po dosazení tedy dostaneme: 22 700 . = 10, 91 𝑚ě𝑠í𝑐𝑒. (2) 8 * 360 − 800 Za předpokladu, že zaměstnanec uspoří nasazením síťového generátoru 8 hodin svého času za měsíc, bude doba návratnosti do tohoto řešení necelých 11 měsíců. Pokud navíc přihlédneme k trendu zvyšování mezd v oblasti IT (viz obrázek 16), bude ekonomický přínos generátoru pro firmu v budoucnu nadále stoupat. 𝐷𝑜𝑏𝑎 𝑛á𝑣𝑟𝑎𝑡𝑛𝑜𝑠𝑡𝑖 =
9
DISKUZE A MOŽNOSTI DALŠíHO ROZVOJE
9
60
Diskuze a možnosti dalšího rozvoje
Tato kapitola se zaměřuje na vyhodnocení realizovaného nástroje, který byl navržen a implementován na základě specifikace požadavků. Systém byl však specifikován velmi komplexně, a tak je součástí i návrh budoucího rozvoje, který bude i nadále všechny stanovené požadavky respektovat.
9.1
Vyhodnocení realizovaného řešení
Vytvořený generátor síťového provozu je díky využití programovacího jazyka Java platformně nezávislé řešení. Měl by být tedy schopen nasazení na jakékoliv TCP/IP síti, kde koncové uzly mají nainstalováno prostředí Java JRE. V případě použití komponenty Capture ještě požaduje instalaci multiplatformního nástroje Wireshark (více o distribuované architektuře generátoru a popisu softwarového jádra viz Zach (2012)). Nástroj umožňuje vytvářet aplikační data (topologie testované sítě, komunikační profil apod.) mimo uživatelské rozhraní systému. Této funkcionality bylo dosaženo prostřednictvím značkovacího jazyka XML, který byl vybrán pro ukládání těchto dat. Samotné XML však poskytuje až moc velkou volnost, a tak byl mimo jiné vytvořen ještě XML Schema dokument (*.xsd), který zavádí závazná pravidla pro tvorbu komunikačního profilu mimo prostředí systému. To s sebou přináší i určitou nevýhodu tohoto řešení – při tvorbě nového profilu mimo aplikaci se uživatel musí seznámit i s příslušným XSD dokumentem a jeho pravidly. Uživatelské rozhraní bylo implementováno podle návrhu, který vychází ze specifikace požadavků. Návrh obsahuje i obrazovky, které podporují grafické vytváření testované topologie a komunikačního profilu, včetně topologického diagramu. Tato funkcionalita ale nebyla v rámci této diplomové práce implementována. Návrhy těchto obrazovek však mohou být využity jako dobrý základ při řešení této problematiky v budoucím rozvoji nástroje.
9.2
Návrh budoucího rozvoje
Už při revizi požadavků na systém, které jsou uvedeny v kapitole Specifikace požadavků, se počítalo s dalším vývojem nástroje, např. v rámci dalších závěrečných prací. Cílem tak bylo specifikovat komplexní systém, který intuitivním způsobem provede uživatele procesem testování sítě za pomoci softwarového generátoru síťového provozu. Pokud bychom měli vyzvednout pár směrů dalšího vývoje, pak je to zejména možnost automatické detekce uzlů v síti a jejich vykreslování do topologického diagramu. Příklad této funkcionality byl navržen už při návrhu grafického uživatelského rozhraní systému a je demonstrován na obrázku 9. Při realizaci bude nutné nastudovat nejen problematiku vykreslování diagramů a manipulace s jejich komponentami, ale zejména analyzovat možnosti skenování sítě na různých platformách a získávání
9.2
Návrh budoucího rozvoje
61
náležitých informací o uzlech, jako jsou např. spuštěné služby pro potřebu detekce existence aktivních modulů generátoru. Další oblastí možného vývoje nástroje je zpracovávání odchycených dat a jejich analýza. Toto by se mělo dít na komponentě Statistika, která poté odešle data na komponentu Administrativa. Jedná se tedy o další krok v distribuované architektuře generátoru převedením jednotlivých činností na různé uzly v síti tak, aby každý dělal jen svoji specifickou činnost. V současné době je komponenta Statistika implementována jako samostatné vlákno, které je pevnou součástí komponenty Administrativa a stará se jen o přijímání a ukládání souborů s odchyceným provozem (*.pcap).
10
10
ZÁVĚR
62
Závěr
Tato diplomová práce se zabývala problematikou tvorby uživatelského rozhraní a komunikačního profilu pro softwarové jádro generátoru síťového provozu. Nejprve byla provedena analýza dostupných nízko-úrovňových nástrojů na generování síťového provozu. Tato analýza byla vypracována ještě před vytvořením jádra generátoru. Měla být pomocným nástrojem při rozhodování, zda tyto nástroje použít jako podpůrné aplikace, které generují pakety daného protokolu, nebo zda-li není výhodnější tyto protokoly samostatně implementovat. Podpora některých protokolů, které byly v této analýze představeny, není prozatím v generátoru dostupná, a tak může být tato analýza vhodná i pro řešitele případného dalšího rozvoje nástroje. Před návrhem a implementací byla prostudována problematika tvorby uživatelských rozhraní v jazyce Java. Na základě specifikace požadavků (a její pozdější revize), která byla vypracována společně s autorem softwarového jádra generátoru – Ing. Petrem Zachem, bylo navrženo vlastní řešení uživatelského rozhraní a komunikačního profilu. Toto řešení bylo následně implementováno a integrováno s již vytvořeným výkonným jádrem. Na závěr bylo provedeno ekonomické zhodnocení a navrženy směry dalšího rozvoje nástroje. Generátor je ve své současné podobě schopen za pomoci grafického uživatelského rozhraní vytvářet komunikační profily a spouštět nad nimi jednotlivé testy. Díky technologii XML a vhodně definovanému XML Schema souboru pro validaci (příloha E) je uživatel schopen vytvářet komunikační profil i relativně bezpečně mimo aplikační prostředí systému. Samotné zpracování XML souborů aplikací bylo implementováno prostřednictvím volně dostupné knihovny JDOM. Aby mohl být generátor využíván jako opravdu komplexní nástroj pro testování sítě, bude jej nutné ještě dále rozvíjet, zejména v oblasti zpracovávání statistik.
11
11
LITERATURA
63
Literatura
Augustin, B. – Mellouk, A. On Traffic Patterns of HTTP Applications. Global Telecommunications Conference (GLOBECOM 2011), 2011 IEEE. ISSN 1930529X. Aiyadurai, J. ::SYSTEM-ENGINE:: Mail-Ware – Emia4win Documentation [online]. 25.11.2004 [cit. 22.10.2011]. Dostupné na: . Biron, P. V. – Malhorta A. XML Schema Part 2: Datatypes Second Edition [online]. W3C. 28.10.2004 [cit. 05.03.2012]. Dostupné na: . Cazabon, Ch. getmail documentation (version 4) [online]. 2009 [cit. 22.10.2011]. Dostupné na: . Český statistický úřad Informační ekonomika v číslech : 2012 : Česká republika a svět. Praha: ČSÚ, 2012. ISBN 978-80-250-2314-3. Free Software Foundation, Inc. GNU Wget [online]. 12.08.2011 [cit. 20.10.2011]. Dostupné na: . Gayraud, R. – Jacques, O. Welcome to SIPp [online]. 25.10.2010 [cit. 24.10.2011]. Dostupné na: . Google, Inc. WindowBuilder User Guide – Java Developer Tools – Google Developers [online]. 27.03.2012 [cit. 05.03.2013]. Dostupné na: . Groothuis, E. DHCPING man-page [online]. 26.01.2002 [cit. 27.10.2011]. Dostupné na: . Herout, P. Java a XML. České Budějovice: KOPP, 2007. ISBN 978-80-7232-3074. Herout, P. Učebnice jazyka Java. 5. vydání. České Budějovice: KOPP, 2010. ISBN 978-80-7232-398-2. Javvin Technologies Network Protocols Handbook. Saratoga CA: Javvin Technologies Inc., 2005. ISBN 0-9740945-2-8. JDOM𝑇 𝑀 JDOM: FAQ [online]. 28.04.2013 [cit. 27.10.2013]. Dostupné na: . kolektiv autorů Linux – Dokumentační projekt. Brno: Computer Press, 2003. ISBN 80-7226-761-2.
11
LITERATURA
64
Kosek, J. XML pro každého podrobný průvodce. Praha: Grada Publishing, 2000. ISBN 80-7169-860-1. Kosek, J. XML schémata [online]. 18.08.2005 [cit. 27.10.2011]. Dostupné na: . Kuba, T. Konfigurace síťových testů. Brno, 2010. Bakalářská práce. Masarykova univerzita. Kučera, P. Tvorba grafického uživatelského rozhraní v jazyce Java. Brno, 2005. Diplomová práce. Masarykova univerzita. Ludvig, M. smtp-cli – command line SMTP client [online]. 02.09.2011 [cit. 21.10.2011]. Dostupné na: . Luxor Foundation Luxor – XML UI Language (XUL) Toolkit [online]. 2005 [cit. 11.03.2013]. Dostupné na: . Oracle Abstract Window Toolkit (AWT) [online]. 2011 [cit. 05.03.2013]. Dostupné na: . Oracle javax.swing (Java Platform SE 6) [online]. 30.11.2011 [cit. 05.03.2013]. Dostupné na: . Oracle NetBeans IDE – Swing GUI Builder (Matisse) Features [online]. 2013 [cit. 05.03.2013]. Dostupné na: . Paulus, W. SWIXML – Generate javax.swing at runtime based on XML descriptors [online]. 2012 [cit. 11.03.2013]. Dostupné na: . Peacock, C. Command Line SMTP Mailer for Windows [online]. 06.04.2007 [cit. 21.10.2011]. Dostupné na: . Synek, M. a kol. Manažerská ekonomika. 4., aktualizované a rozšířené vydání. Praha: Grada Publishing, 2007. ISBN 978-80-247-1992-4. Tatham, S. Using the command-line connection tool Plink [online]. 12.07.2011 [cit. 25.10.2011]. Dostupné na: . The Eclipse Foundation E4/XWT – Eclipsepedia [online]. 06.06.2012 [cit. 12.03.2013]. Dostupné na: .
11
LITERATURA
65
The Eclipse Foundation FAQ What is SWT? – Eclipsepedia [online]. 2013 [cit. 04.03.2013]. Dostupné na: . Uličný, M. Vizuální editor pro návrh GUI. Brno, 2006. Diplomová práce. Masarykova univerzita. Zach, P. Návrh komunikačního jádra generátoru síťového provozu. Brno, 2012. Diplomová práce. Mendelova univerzita v Brně. Zhang, Y. Residential Network Traffic and User Behavior Analysis. Stockholm, 2010. Master of Science Thesis. KTH, School of Information and Communication Technology (ICT).
Přílohy
A
A
SCHÉMA HIERARCHIE DATOVÝCH TYPŮ XML SCHEMA
Schéma hierarchie datových typů XML Schema
Obr. 17: Hierarchie datových typů jazyka XML Schema. Převzato od Biron a Malhorta, specifikace W3C (2004)
67
B
B
GUI DRAG AND DROP NÁSTROJE SWING GUI BUILDER (MATISSE)
68
GUI drag and drop nástroje Swing GUI Builder (Matisse)
Obr. 18: Hlavní okno nástroje Swing GUI Builder (Matisse). Zdroj: http://netbeans.org/images_www/v7/1/screenshots/gui-builder.png
C
C
GUI DRAG AND DROP NÁSTROJE WINDOWBUILDER
GUI drag and drop nástroje WindowBuilder
Obr. 19: Hlavní okno nástroje WindowBuilder. Zdroj: https://developers.google.com/java-dev-tools/wbpro/userinterface/
