Analýza súčasného stavu

tato stranka ma nasledujuce nedostatky:

• chyba diakritika
• chybaju cisla a nazvy obrazkov a referencie na obrazky v texte
• na niektorych miestach je vyjadrovanie mierne zovialne. vsetko je sice po technickej stranke zrozumitelne, ale miestami to posobi dojmom pracovnej verzie dokumentacie. predpokladam, ze tieto texty budu neskor pouzite aj v bakalarskej praci, a tam sa to uz nehodi.
• treba si dat pozor na preklepy a chybajuce ciarky, v bakalarke to bude posobit rusivo
• pozor na slovo 'uzivatel' - spravny tvar je 'pouzivatel'

po letmom pohlade na dalsie stranky konstatujem, ze nie len tato stranka ma spomenute nedostatky :)

Nastrojov na analyzu dat (nielen IPFIX) je v dnesnej dobe mnoho. Dokonca aj pre rozne implementacie protokolu ipfix existuje niekolko analyzerov ktory vsak narozdiel od tohto boli vyvijany v behovom prostredi java. Konecnym dosledkom tohom moze byt aj spomalenie procesu analyzy vplyvom virtualizacie behoveho prostredia. V dnesnej dobe sa to pri mensich projektoch da zanedbat z dosledku dostatocnej hardverovej vykonnosti, ale v komplexnych projektoch to moze dostatocne ovplyvnit vykonavanie a presnost vypoctov.

Tento projekt sa zameral na nedostatky hore spomenutych problemov a dal si za ulohu navhrnut univerzalny nastroj na spracovanie a prezenciu udajov. Kedze nastroj ma byt univerzalny, dalsim cielom je moznost prisposobit ho roznym podmienkam. To je zarucene modularitou. Ako poslednym nedostatkom ktory si za ulohu berie tento projekt je vylucenie nutnosti virtualneho behoveho prostredia a zarucit rychlost aj pri rozsiahlejsich vypoctoch.

Na realizovanie takejto myslienky boli vybrate nasledujuce technologie:

• objektovy orientovany navrh - modularita
• implementacia v c++ - vylucenie virtualneho behoveho prostredia + rychlost
• ncurses - rychlost uzivatelskeho rozhrania

Povodny navrh (pseudoobjektovy)

Povodny navrh analyzera bol prevazne stukturalne programovany pricom vyuzial iba vyhody oo pristupu (Uzavretost operacii a funkcii). Tento pristup bol sice funkcny, ale poskytoval iba jediny analyzacny proces, ktory dokazal analyzovat data a zobrazovat ich realtimovo. Postupnym nabalovanim systemu v case implementacie doslo ku situacii kedy sa sturkturalny pristup prestal vyhovovat.

Zobrazovacia cast systemu je postavena na kniznici ncurses, ktora rozsiruje moznosti konzolovych aplikacii smerom k interaktivite. Uz povodny navrh predpokladal vyuzitie vlakien pre interaktivne ovladanie aplikacie. Implementacne to nakoniec bolo riesene dvoma paralelnymi vlaknami, pricom jedno vlakno nazyvane tiez manazerske malo na starosti sledovanie udalosti klavesoveho vstupu. Druhe vlakno alebo tiez zobrazovacie sa staralo o vykreslovanie v urcitych casovych intervaloch. Tento pristup bol nakoniec brani v uvahu pri prerabani navrhu na objektovy model. Dalsou crtou ktoru mal povodny strukturalny navrh a bola zaradena aj do objektoveho modelu je rozdelenie systemu na tri samostatne procesy. Proces rodica ktory na seba prebera ulohu riadenia potomkov , pricom jeden potomok sluzi na zobrazovanie a druhy analyzu dat. V objektovom modely sa uloha rodica presunula do hlavnej treidy a obsluhy jednotlivych potomkov na seba prebrali triedy CCui a CIpfix. Datove toky medzi procesmi boli reprezentovane prenosom struktury (sablony) ktora davala datovy zaklad pre vykreslovanie hodnot. Prenos iba jednej struktury sa neskor ukazal, ako nepriatelny lebo pri pridavani novych modulov sa dana stuktura skomplikovala az natolko ze bolo treba riesit iny pristup. OOP pristup nakoniec pomohol plne izolovat sablonu od zavislosti na moduloch.

OOP navrh

Pohlad na cely system

Pohlad na UI subsystem

Pohlad na IPC subsystem

Pohlad na INPUT subsystem

Na obrazku je novy objektovy navrh systemu. System je tvoreny triedamy, ktore sa daju zaclenit do troch skupin. Skupina CUI (console user interface) ma nastarosti prezenciu analyzy nad ipfix protokolom. Skupina IPFIX ktora analyzuje protokol ipfix a skupina na medziprocesnu komunikaciu IPC (inter proces comunication).

CAnalyzer

Hlavna trieda spravujuca chod vsetkych casti ipfix analyzera. Jej ulohou je rozdelenie vykonavania programu do samostatnych procesov, ktore si sleduje a nasledne aj riadi. Po korektonom skonceni vykonavania vytvorenych procesov sa tato trieda postara o uvolneni prostriedkov ktore si rezervovala.

UI (User Interface)

Pri navrhu sa pocitalo s rosirenim uzivatelskeho rozhrania v buducnosti aj na graficke uzivatelske rohranie (GUI). Z toho dovodu je rohranim (interface) diktovane riadenie uzivatelskeho rozhrania z pohladu triedy CAnalyzer.

IUi

Interface (abstraktna trieda), ktore je abstrakciou funkcnosti uzivatelskej interakcie s programom.

CUI (Console user interface)

CUI podsystem ako uz bolo sponemute ma nastarosti prezentovanie analyzovanych dat. Momentalne navrh pocita len s konzolovym uzivatelskym rozhranim. Vyhody tohto rozhrania vyplivaju z vyhod konzolovych aplikacii. Rychlost ktora sa dosahuje pri pouzity konzolovej aplikacie je neporovnatelna s rychlostou grafickej aplikacie. Priamim dosledkom toho je aj nizsie vytazenie sieti pri prenose takychto informacii.

CCui

Tato trieda je konzolovou implementaciou uivatelskeho rozhrania. Trieda zohrava ulohu manazera ncurses okien, pricom okna ktore su pod jej spravou bezia nezavisle na sebe a su touto triedou len sychronizovane. V povodnom navrhu sa v tejto casti systemu vytvorili dva posixove vlakna pricom jedno bolo vlakno ktore sa staralo o interakciu uzivatela sa programom a jedno sluzilo na vykreslovanie okien. To ze vykreslovanie bolo umiestnene do jeneho vlakna a samotne ncurses okna mali moznost variabilnej obnovovacej frekvencie sposobovalo nutnost zaokruhlovania co sa ukazalo v niektorych pripadoch za nepriatelne. Pri objektovom navrhu sa takyto pristup vylucil a pocitalo sa s moznostou behu kazdeho okna , presnejsie funkcie ktora sa stara o vykreslovanie obsahu okna v samostatnom vlakne. V konecnom dosledku to umoznuje neviazane obnovovacie frekvencie okien. Na takyto navrh uz klasicke systemove funkcie pre vytvorenie posixoveho vlakna nestacili, preto bola navrhnuta trieda (CThread), ktora moze obalit inu triedu moznostou spustenia clenskej funkcie v posixovom vlakne. CThread bola zaradena do jadra koli viditelnosti pre kazdy subsystem.

CNcursesWin^?

Kniznica ncurses umoznuje vytvarat takzvane WINDOWS co je zakladna struktura s ktorou pracuje a ktora reprezentuje samostatne vykreslovanu cast obrazovky. Obalenim tejto stuktury o potrebne metody a atributy vznikla trieda CNcursesWin^?. Tato trieda je vseobecnejsim predpisom, ktory je sice pouzitelny, ale vyznam ziskava az pri generalizacii na specifickejsie okno. Pri generalizacii sa k tejto triede pridava aj datova zlozka ktora je zobrazovacou funkciou prezentovana pouzivatelovi. Koli behu tejto triedy (aj jej potomkov) v samostatnych vlaknach, je nutne dedenie aj od treidy CThread. Moduly z ktorych je subsystem vystavany su prave potomkami tejto triedy.

CMultiPasik^? informacie

Objektovym obalenim zdrojoveho kodu aplikacie "Pasik" vznikol komplexny modul vhodny pre zobrazovanie viacerych hodnot v roznych skupinach. Zaujimavym spojenim sa dosiahlo obrovske vyuzitie pri zobrazovani analyzovanych dat. Za zmienku stoji aj to ze pri migracii kodu, ktory bol strukturalny cisty C-eckovsky na kod ktory je prevazne objektovy (C++) bolo nutne pozmenit iba nazvy niektorych premennych, bez nejakeho velkeho zasahu do povodnej verzie.

CKeyboard (keyboarder)

Tato trieda vznikla pri implementacii ako nutnost spravovat vstup z klavesnice. Bez pouzitia tejto triedy v cui systeme je mozne spacovat klavesovy vstup iba v jednom okne. Kedze sa jedna o paralelny beh okien spolu s klavesnicou, vytvorilo sa v sprave triedy CCui nove vlakno ktore v ktorom objekt triedy CKeyboard spravuje vstup z klavesnice. Okno ktore sa zavazuje zakazdym spracovat dany znak, hned potom co sa objavi v cui sa musi najpr volanim metody CCui zaregistrovat pre keyboardera. CCui pri poziadavke na registraciu kavesoveho eventu prida "ziadatela" do svojho zasobnika. Keyboarder si uchovava strukturu o registrovanych znakoch pricom pri odchyteni klavesoveho vstupu vola klavesove prerusenie ziadatelskeho okna.

CRefresh (refresher)

CRefresh je trieda ktora spravuje systemove vlakno starajuce sa o vykreslovanie okien. Zdovodu nestability cui systemu pri volani kniznicnej funkcie pre vykreslenie okna vo viacerych vlaknach naraz, bolo nutne eliminovat tuto situaciu. Instancia triedy CRefresher je pod spravou cui pricom ona samotna spravuje poziadavky od okien na prekreslenie. Poziadavky su spracovavane sekvencne pricom je vyuzita fronta poziadaviek. Refresher pracuje s danou frekvenciou. Tato frekvenicia je volitelna, by default je nastavena na frekvenciu obnovovania 25Hz. Takyto postup ma za nasledok spracovanie stale len jednej poziadavky v dostatocnej interakcii.

CIpfix

Jeden z objektov riadeny analyzerom je aj objekt, ktory zbiera informacie a analyzuje ich.

CIpfix

Je implementaciou manazera objektov, ktore maju nastarosti ziskavanie informacii. V tejto problematike su to informacie ziskavane z protokal IPFIX.

CIpcManager^?

Je nastroj na riadenie a pracu s ipc objektami.