Aplikácia pre analýzu a spracovanie základných typov protokolov komunikačných sietí DIPLOMOVÁ PRÁCA. Bc. MICHAL PTAČIN

Transcription

1 Aplikácia pre analýzu a spracovanie základných typov protokolov komunikačných sietí DIPLOMOVÁ PRÁCA Bc. MICHAL PTAČIN ŽILINSKÁ UNIVERZITA V ŽILINE Elektrotechnická fakulta Katedra telekomunikácií Študijný odbor: TELEKOMUNIKÁCIE Vedúci diplomovej práce: Ing. Vladimír Pšenák Stupeň kvalifikácie: inžinier (Ing.) Dátum odovzdania diplomovej práce: ŽILINA 2007

2 ABSTRAKT Cieľom tejto práce je vytvoriť aplikáciu, ktorá analyzuje log súbory obsahujúce datagramovu komunikáciu. V teoretickej časti diplomovej práce je popísaný základ, z ktorého bolo vychádzané pri návrhu aplikácie. Teoretická časť obsahuje popis referenčného modelu jeho jednotlivých vrstvy z ktorých sa skladá a ich úlohy. Ďalej sú tu popísané vybrané protokoly niektorých vrstiev, modelovací jazyk UML a CORBA štandard. Praktická časť oboznamuje s používateľským rozhraním, nastaveniami vytvorenej aplikácie a s výsledkami aké je možné aplikáciou získať. ABSTRACT The aim of this diploma thesis is to create application, which analyzes log files of packet communication. In the theoretical part of this thesis is described base needed for creation of application. Theoretical part contains description of the reference model, its individual layers and their tasks. Further, there are described selected protocols of some layers, modeling language UML and CORBA standard. Practical part deals about user interface, settings of created application and about results which can be achieved by this application.

3 Žilinská univerzita v Žiline, Elektrotechnická fakulta, Katedra telekomunikácií ANOTAČNÝ ZÁZNAM - DIPLOMOVÁ PRÁCA Priezvisko, meno: Ptačin Michal školský rok: 2006 / 2007 Názov práce: Aplikácia pre analýzu a spracovanie základných typov protokolov komunikačných sietí Počet strán: 54 Počet obrázkov: 28 Počet tabuliek: 5 Počet grafov: 0 Počet príloh: 7 Použitá lit.: 15 Anotácia v slovenskom jazyku: Táto diplomová práca sa v teoretickej časti zaoberá popisom referenčného modelu OSI, vybranými protokolmi niektorých vrstiev, jazykom UML a CORBA štandardom. Praktická časť práce pozostáva z popisu, použitia a nastavenia vytvorenej aplikácie analyzujúcej log súbory. Anotácia v anglickom jazyku: The theoretical part of this diploma thesis is focused on description of the reference model OSI, selected protocols of some layers, language UML and CORBA standard. The practical part consists of description, usage and setting of created application which analyzes log files. Kľúčové slová: Referenčný model, HDLC, PPP, IP, TCP, UDP, FTP, GIOP, IIOP, UML, CORBA, analýza log súboru

4 Vedúci práce: Ing. Vladimír Pšenák Recenzent práce : Dátum odovzdania práce: OBSAH 1. Úvod Referenčný model OSI (RM OSI) Základné funkcie vrstiev RM OSI Popis a použitie vybraných protokolov jednotlivých vrstiev HDLC a PPP, protokoly linkovej vrstvy IP, protokol sieťovej vrstvy TCP a UDP, protokoly transportnej vrstvy FTP, protokol aplikačnej vrstvy UML (Unified Modeling Language) Diagramy UML Diagram tried Diagram objektov Diagram prípadov použitia Diagram stavov Sekvenčný Diagram Diagram spolupráce Diagram aktivít Diagram komponentov Diagram nasadenia Distribuované objektové systémy Základné črty a vlastnosti CORBA Štruktúra architektúry CORBA ORB (Object Request Broker) IDL (Interface Definition Language) DII (Dynamic Invocation Interface) a DSI (Dynamic Skeleton Interface) GIOP (General Inter Orb Protocol) IIOP (Internet Inter Orb Protocol) Komunikácia v architektúre CORBA Aplikácia pre analýzu log súborov Používateľské rozhranie Nastavenie a vzorová analýza Analýza bez zadania filtračných podmienok Analýza so zadanými filtračnými podmienkami Vzorová analýza Možnosti rozšírenia aplikácie a znovu použitie tried Možnosti rozšírenia aplikácie Znovu použitie tried Záver... 52

5 7. Zoznam použitej literatúry:...53 Zoznam obrázkov a tabuliek Tabuľka 2.1 Kategórie reprezentujúce typ prenášaných dát [2]...16 Tabuľka 2.2 Voliteľné položky [2]...20 Tabuľka 4.3 Správy protokolu GIOP vysielané klientom [12]...41 Tabuľka 4.4 Správy protokolu GIOP vysielané serverom [12] Tabuľka 5.5 Štruktúra zadávania podmienok Obrázok 2.1 Vrstvy referenčného modelu OSI [1]...2 Obrázok 2.2 Štruktúra rámca HDLC [2]...6 Obrázok 2.3 Štruktúra poľa I rámca [2]...7 Obrázok 2.4 Štruktúra poľa S rámca [2]...7 Obrázok 2.5 Pole U rámca [2]... 8 Obrázok 2.6 Štruktúra rámca protokolu PPP [4] Obrázok 2.7 Štruktúra datagramu IP protokolu verzie 4. [6] Obrázok 2.8 Príznaky fragmentácie [2] Obrázok 2.9 Štruktúra datagramu IP protokolu verzie 6. [7] Obrázok 2.10 Štruktúra TCP segmentu [2]...18 Obrázok 2.11 Pole príznakov TCP segmentu [2] Obrázok 2.12 Štruktúra UDP segmentu [2]...22 Obrázok 3.13 Príklad použitia diagramu triedy [15] Obrázok 3.14 Príklad použitia diagramu objektov [15]...30 Obrázok 3.15 Príklad použitia diagramu prípadu použitia Obrázok 3.16 Príklad použitia diagramu stavov [15] Obrázok 3.17 Príklad použitia sekvenčného diagramu...33 Obrázok 3.18 Príklad diagramu spolupráce...33 Obrázok 3.19 Príklad diagramu aktivít [14] Obrázok 3.20 Príklad diagramu komponentov [14] Obrázok 3.21 Príklad diagramu nasadenia [15]...35 Obrázok 4.22 Moduly architektúry CORBA [11] Obrázok 4.23 Volanie vzdialenej implementácie objektu [13] Obrázok 5.24 Užívateľské rozhranie aplikácie pre analýzu.log súborov Obrázok 5.25 Príklad zadania podmienok Obrázok 5.26 Príklad zapísania viacerých podmienok v súbore Obrázok 5.27 Výsledok analýzy pre jednotlivé podmienky a ich vyhodnotenie Obrázok 5.28 Súhrn správne a nesprávne vyhodnotených datagramov pre každú podmienku...49

6 ZOZNAM POUŽITÝCH SKRATIEK Skratka Anglický výraz Slovenský ekvivalent ARP Address Resolution Protocol Protokol konvertujúci IP adresu na fyzickú adresu ATM Asynchronous Transfer Mode Asynchrónny prenosový mód CCITT CORBA DCOM International Telephone and Telegraph Consultative Committee Common Object Request Broker Architecture Distributed Component Object Model Medzinárodná organizácia definujúca štandardy pre telefónne a telegrafické zariadenia Prostriedok pre komunikáciu v distribuovanom heterogénnom prostredí Distribuovaný objektový model DII Dynamic Invocation Interface Dynamické volanie DSI Dynamic Skeleton Interface Dynamicky vytvorená kostra objektu DSL Digital Subscriber Line Digitálne účastnícke vedenie FDDI Fiber Distributed Data Optické distribuované dátové Interface rozhranie FTP File Transfer Protocol Protokol prenosu súborov GIOP General Inter ORB Protocol Všeobecný protokol zabezpečujúci komunikáciu. medzi objektmi ORB HDLC High-Level Data Link Control Vysokoúrovňový protokol pre riadenie dátového spojenia HTTP Hypertext Transport Protocol Hypertextový prenosový protokol CHAP Challenge Handshake Authentication Protocol Protokol na overenie inicializačnej výzvy ICMP Internet Control Message Internetový kontrolný protokol, Protocol zasielajúci správy IDL Interface Definition Language Jazyk pre definíciu rozhrania IGMP Internet Group Management Protocol Internetový skupinový riadiaci protokol IIOP Internet Inter-Orb Protocol Protokol zabezpečujúci komunikáciu. medzi objektmi ORB

7 internet protokolom IP Internet Protocol Internetový protokol IPTV Internet Protocol Television Televízne vysielanie šírené internet protokolom IPv6 Internet Protocol version 6 Internetový protokol verzia 6 ISO ITUT International Organization for Standardization International Telecommunications Union Medzinárodná organizácia pre štandardizáciu Medzinárodná telekomunikačná únia LAN Local Area Network Lokálna počítačová sieť LCP Link Control Protocol Linkový kontrolný protokol MAN Metropolitan Area Network Mestská počítačová sieť MIME Multipurpose Internet Mail Extensions Špecifikácia pre pripojovanie iných než textových objektov k správam elektronickej pošty MTU Maximum Transmission Unit Maximálna veľkosť prepravovaného datagramu NCP Network Control Protocol Sieťový kontrolný protokol NetBIOS Network Basic Input/Output System Systém firmy Microsoft umožňujúci pomenovanie zariadení v lokálnej sieti NFS Network Filesystem Sieťový súborový systém OMG Object Management Group Zoskupenie objektovo - orientovaných firiem ORB Object Request Broker Sprostredkovateľ žiadostí objektu OSPF Open Shortest Path First Hierarchický smerovací algoritmus PAP Password Authentication Protokol overujúci pravosť hesla Protocol PPP Point-to-Point Protocol Bod - bod protokol PPPoE PPP over Ethernet PPP cez Ethernet QoS Quality of Service Kvalita služby RIP Routing Information Protocol Smerovací protokol RM OSI Reference Model Open Referenčný model pre prepojenie Systems Interconnection otvorených systémov RMI Remote Method Invocation Vyvolanie vzdialenej metódy RTP Real-time Transport Protocol Protokol pre. prenos dát v reálnom čase SDP Session Description Protocol Spojenie popisujúci protokol

8 SFTP Secure File Transfer Protocol Zabezpečený protokol pre prenos súborov SLIP Serial Line Internet Protocol Internetový protokol pre sériovú linku SNMP Simple Network Management Protocol Jednoduchý protokol na správu siete SSL Secure Socket Layer Protokol slúžiaci k zabezpečeniu bezpečnej komunikácie TCP Transmission Control Protocol Prenosový riadiaci protokol TTL Time To Live Zostávajúca doba života datagramu UDP User Datagram Protocol Protokol pre datagramovú obsluhu UML Unified Modeling Language Zjednotený modelovací jazyk UMTS Universal Mobile Telecommunications System Univerzálny pohyblivý telekomunikačný systém VoIP Voice over Internet Protocol Hlas prenášaný internet protokolom XDR external Data Representation Interpretácia externých dát

9 1. Úvod V období okolo roku 1970 s vývojom komunikačných sietí nastala potreba definovať jednotný štandard architektúry sieťou spojených systémov. Medzinárodná štandardizačná organizácia (ISO) a Medzinárodná organizácia definujúca štandardy pre telefónne a telegrafické zariadenia (CCITT) spojili svoje sily a v roku 1984 bol publikovaný štandard - Referenčný model pre prepojenie otvorených systémov RM OSI (Reference Model Open Systems Interconnection ), ktorý sa skladá zo 7 vrstiev. Je to súbor noriem, ktoré sú potrebné pre výmenu informácií medzi systémami. Pre komunikáciu medzi systémami sú využívané komunikačné protokoly. Protokol je súbor pravidiel, ktoré určujú syntax a sémantiku prenášaných dát. Každá vrstva má sadu protokolov, ktoré sú využívané v závislosti od služby aká je požadovaná. V teoretickej časti diplomovej práce je v druhej kapitole popísaný referenčný model jeho jednotlivé vrstvy z ktorých sa skladá a ich úlohy. Ďalším bodom tejto kapitoly je popis a štruktúra vybraných protokolov niektorých vrstiev. Nasledujúca kapitola je prídavkom k diplomovej práci a obsahuje krátke oboznámenie s modelovacím jazykom UML (Unified Modeling Language). Štvrtá kapitola je venovaná objektovému distribuovanému systému CORBA, jeho popisu a využitiu. Cieľom praktickej časti práce bolo vytvoriť aplikáciu pre analýzu a spracovanie log súborov. Táto aplikácia má uľahčiť analýzu zachytenej komunikácie medzi viacerými modulmi základňovej stanice v univerzálnej mobilnej telekomunikačnej sieti UMTS (Universal Mobile Telecommunication System). Pomocou programu Ethereal je zachytávaná datagramova komunikácia medzi modulmi a ukladaná do log súboru, ktorý je potom analyzovaný. Pri návrhu aplikácie sa vychádzalo zo štruktúry jednotlivých protokolov definovaných v teoretickej časti. Aplikácia má používateľské menu v ktorom je možné si zobraziť obsah log súboru, uskutočniť filtráciu na základe definovaných podmienok užívateľom a uloženie získaných výsledkov do súboru. Aplikácia je vytvorená v objektovo orientovanom programovacom jazyku Java. Keďže nové protokoly pribúdajú pomerne často, triedy aplikácie sú vytvorené tak aby boli ľahko doplniteľné. 1

10 2. Referenčný model OSI (RM OSI) V tejto kapitole diplomovej práce je popísaný RM OSI a je tu uvedená stručná charakteristika vrstiev, z ktorých sa skladá. V ďalšej podkapitole sú dopodrobna rozobrané vybrané protokoly niektorých vrstiev, ktoré boli určené v zadaní diplomovej prace. Referenčný model OSI model navrhla medzinárodná štandardizačná organizácia ISO (International Organization for Standardization). Je to na vrstvách založený abstraktný model týkajúci sa výmeny informácii medzi otvorenými systémami a ich prepojením. Model funkčne rozdeľuje protokoly do siedmich vrstiev s rôznymi funkciami ako je znázornené na obrázku 2.1. Každá vrstva má dve rozhrania, s nižšou a vyššou susediacou vrstvou, pričom najvyššia vrstva má rozhranie k používateľskému systému a najnižšia vrstva k prenosovému médiu. Každá vrstva poskytuje služby vrstve nad ňou a vyžaduje služby od vrstvy pod ňou.[1] Vrstvový protokol Otvorený systém A Otvorený systém B Aplikačná vrstva < > Aplikačná vrstva Prezentačná vrstva < > Prezentačná vrstva Relačná vrstva < > Relačná vrstva Transportná vrstva < > Transportná vrstva Sieťová vrstva < > Sieťová vrstva Linková vrstva < > Linková vrstva Fyzická vrstva < > Fyzická vrstva Prenosové médium Obrázok 2.1 Vrstvy referenčného modelu OSI [1] Pre komunikáciu medzi vrstvami dvoch otvorených systémov sú využité komunikačné protokoly, ktoré sprostredkovávajú výmenu dát medzi systémami. Jednotlivé vrstvy používajú rôzne typy protokolov v závislosti od funkcionality aká je požadovaná. V nasledujúcej podkapitole sú charakterizované všetky vrstvy RM OSI. 2

11 2.1. Základné funkcie vrstiev RM OSI Fyzická vrstva Táto vrstva zaisťuje prenos bitov z jedného zariadenia na druhé pomocou fyzického média, ktoré leží pod fyzickou vrstvou a nie je súčasťou OSI modelu. Ďalšími úlohami fyzickej vrstvy je elektrické a fyzické prispôsobenie na prenosové médium, aktivácia a deaktivácia prenosovej cesty a multiplexing, kde na jednom prenosovom médiu môže byť viacero logických spojení. Fyzická vrstva je závislá na výbere technológie siete (Ethernet, Asynchrónny prenosový mód ATM (Asynchronous Transfer Mode), Opticke distribuované dátové rozhranie FDDI (Fiber Distributed Data Interface)) ale protokolovo je nezávislá. Linková vrstva Zaisťuje prístup k zdieľanému prenosovému médiu a zabezpečuje adresáciu v jednom sieťovom segmente, v rámci ktorého musí mat jedinečnú fyzickú adresu. Ďalšími úlohami linkovej vrstvy je poskytovanie logických spojení vyššej vrstve, zabezpečenie prenášaných dát proti chybám, synchronizácia medzi vysielačom a prijímačom pomocou ohraničenia rámca (Flag).[1] Najznámejšie protokoly linkovej vrstvy sú: Ethernet, (WiFi), Token Ring, FDDI, ATM, Bod - bod protokol PPP(Point-to-Point Protocol), Vysoko úrovňový protokol pre riadenie dátového spojenia HDLC (High-level Data Link Control), protokol pre sériovú linku SLIP (Serial Line Internet Protocol). Sieťová vrstva Úlohou sieťovej vrstvy je prepojenie ľubovoľných terminálov nie len v rámci jednej sieti ale celosvetovo. K identifikácii volané ho terminálu je definovaná sieťová adresa. [1] Informácie od vyšších vrstiev sú balené do datagramov. Na základe sieťovej adresy sú datagramy prenášané do prislúchajúceho smeru. Sieťová vrstva ďalej zaisťuje výber vhodnej cesty cez medziľahlé uzly, segmentáciu/desegmentáciu, kontrolu toku dát a tiež postupný prenos jednotlivých datagramov po tejto trase od pôvodného odosielateľa až ku koncovému príjemcovi. [10] Nosným protokolom je internetový protokol IP(Internet Protocol) verzie 4 alebo 6 a na ňom sú založené ďalšie protokoly sieťovej vrstvy ako internetový kontrolný 3

12 protokol ICMP(Internet Control Message Protocol), riadiaci protokol IGMP (Internet Group Management Protocol) a konvertujúci protokol ARP(Address Resolution Protocol). Transportná vrstva Táto vrstva vytvára, riadi a ukončuje spojenie ako celok, pre prenos dát medzi navzájom komunikujúcimi stranami. [1] Ďalej zaisťuje spoľahlivosť a kvalitu prenosu akú požadujú vyššie vrstvy pomocou dvoch typov služieb: Spojovo orientovaná služba (connection-oriented). zaisťuje spoľahlivý prenos tak, že počas celej komunikácie je naviazané virtuálne spojenie. Strany si taktiež navzájom číslujú a potvrdzujú prijaté segmenty na základe čoho sú schopné odhaliť stratu segment a žiadať o opakovanie jeho prenosu. Nespojovo orientovaná služba (connectionless) slúži k jednoduchému odosielaniu dát. Nijako nezabezpečuje spoľahlivosť prenášaných dát a je na vyšších vrstvách ako zaistia spoľahlivosť prenosu. Hlavnými predstaviteľmi protokolov transportnej vrstvy sú prenosový riadiaci protokol TCP(Transmission Control Protocol) a protokol pre datagramovú obsluhu UDP(User Datagram Protocol). Relačná vrstva Úlohou tejto vrstvy je uskutočňovanie, udržovanie a rušenie relácií medzi koncovými účastníkmi. Pri nadväzovaní spojenia si táto vrstva vyžiada na transportnej vrstve vytvorenie spojenia, prostredníctvom ktorého potom prebieha komunikácia medzi účastníkmi relácie. Určuje taktiež druh komunikačného vzťahu, ktorý môže byť jednostranný, striedajúci sa alebo s rovnakým oprávnením. [1] Príkladom protokolov relačnej vrstvy je protokol umožňujúci pomenovanie zariadení v lokálnej sieti NetBIOS (Network Basic Input/Output System), spojenie popisujúci protokol SDP(Session Description Protocol). Prezentačná vrstva Tato vrstva sa zaoberá väzbou medzi syntaxou a sémantikou dát. [1] Rozličné systémy používajú rôzne kódy prezentácie znakových reťazcov, čísel s plávajúcou čiarkou apod. Prezentačná vrstva zabezpečuje prevod dátových štruktúr medzi syntaxou použitou na príslušnom systéme a všeobecnou syntaxou. Ďalšou funkciou prezentačnej vrstvy je 4

13 konverzia prenášaných dát do formátu zrozumiteľného pre prijímacie zariadenie (šifrovanie/dešifrovanie, kompresia).[1] Príkladom protokolov prezentačnej vrstvy je špecifikácia pre pripojovanie iných než textových objektov k správam elektronickej pošty MIME (Multipurpose Internet Mail Extensions ), interpretácia externých dát XDR (external Data Representation), protokol slúžiaci k zabezpečeniu bezpečnej komunikácie SSL (Secure Socket Layer). Aplikačná vrstva Pomocou aplikačnej vrstvy môžu užívatelia alebo aplikácie bežiace na danom zariadení vidieť výsledky služieb zaisťovaných všetkými predchádzajúcimi vrstvami. Dáta vytvárané užívateľom sú prenášané programom v jeho internom formáte a sú kódované do štandardného protokolu, ktorý je potom spracovaný nižšími vrstvami a transportovaný sieťou k adresátovi. Aplikačná vrstva ďalej musí zabezpečovať prenos informácii, identifikovanie komunikačného partnera, určenie pripravenosti ku komunikácii, požiadavky na potrebné prevádzkové prostriedky a požiadavky na kvalitu služby. [1] Príkladom protokolov aplikačnej vrstvy sú: hypertextový prenosový protokol HTTP (Hypertext Transport Protocol), protokol prenosu súborov FTP (File Transfer Protocol), Telnet, sieťový súborový systém NFS (Network Filesystem), protokol pre prenos dát v reálnom čase RTP (Real-time Transport Protocol) Popis a použitie vybraných protokolov jednotlivých vrstiev V nasledujúcich podkapitolách sú bližšie špecifikované vybrané protokoly linkovej, sieťovej, transportnej a aplikačnej vrstvy. Sú to protokoly HDLC a PPP linkovej vrstvy, IP sieťovej vrstvy, TCP a UDP transportnej vrstvy a FTP aplikačnej vrstvy HDLC a PPP, protokoly linkovej vrstvy HDLC (High-Level Data Link Control) protokol HDLC je bitovo orientovaný synchrónny protokol linkovej (dátovej) vrstvy vyvinutý Medzinárodnou štandardizačnou organizáciou ISO. Hlavnou úlohou HDLC protokolu pri prenose informácií je detekcia chýb a riadenie toku dát. Je veľmi rozšírený, pretože podporuje polo duplexnú a plne duplexnú prevádzku, ďalej podporuje spojovo ako 5

14 i nespojovo orientovanú službu a prepojenia typu bod-bod, bod viacej bodov. Procedúry v HDLC sú navrhnuté tak aby zabezpečili transparentný synchrónny prenos dát. Na obr.2.2, je znázornená štruktúra rámca HDLC. F A C I FCS F 8 bitov 8 bitov 8 alebo 16 bitov Premenlivá dĺžka 16 alebo 32 bitov 8 bitov Obrázok 2.2 Štruktúra rámca HDLC [2] Popis polí rámca HDLC F (Flag) - Dĺžka návestnej značky je 8 bitov a jeho štruktúra je definovaná nasledovne (0x7e). Každý rámec na linkovej vrstve musí začínať aj končiť touto značkou. Ak nasledujú dva rámce za sebou je potrebné len jedno ohraničenie, ktoré pre predchádzajúci blok je koncovým a súčasne je začiatočným pre nasledujúci rámec. Poradie bitov zodpovedajúce návestnej značke sa nesmie vyskytovať v prenášanom dátovom toku, pretože by mohlo byť nesprávne vyhodnotené ako ohraničenie rámca. Ak v prenášanej správe sa vyskytne sekvencia a nie je to návestná značka, je použité dopĺňanie bitu do tejto sekvencie (bit stuffing), aby prijímač rozoznal danú sekvenciu od návestnej značky. Ak vysielač detekuje, že bude posielať 5 za sebou idúcich jednotiek vloží za ne bit hodnoty 0, aby predišiel tomu že prijímač bude túto sekvenciu považovať za návestnú značku. Na prijímacej strane prijímacia stanica preverí prichádzajúci rámec. Ak nájde 5 za sebou idúcich 1 pozerá na ďalší bit. Ak je 0, vyberie ho preč. Návestné značky sú vysielané aj v takom prípade, ak nie sú k dispozícii žiadne dáta na prenos, čím sa zabezpečuje, že linka ostáva aktívna. A (Address) - Dĺžka adresného poľa je 8 bitov. Adresa identifikuje vysielaciu alebo prijímaciu stanicu, ktoré komunikujú medzi sebou. Rozlišujeme adresné pole príkazu (Command) a odpovede (Response). Príkaz vždy obsahuje adresu stanice, pre ktorú je určený a oznámenie obsahuje vždy vlastnú adresu, adresu príkazcu. C (Control) - Dĺžka kontrolného poľa je 8 alebo 16 bitov. Označuje typ rámca, typ príkazu a oznámenia. Mód, kedy je použitých 16 bitov je nazývaný rozšírený a umožňuje použiť 6

15 očíslovanie rámcov v rozsahu od 0-127, pričom ak sa táto hodnota presiahne začína sa počítať opäť od 0. Mód pre číslovanie rámcov, kedy sú použité 3 bity je rozsah od 0-8 a platí rovnaké pravidlo že po prekročení sa začína opäť počítať od 0. Rozlišujú sa tri typy HDLC rámcov I, S, U: I rámce transportujú (viď obr. 2.3) dáta vrstvy 3 a taktiež môžu prenášať aj niektoré riadiace informácie, ako napríklad potvrdenie prijatých rámcov bit N (R) P N (S) 0 Obrázok 2.3 Štruktúra poľa I rámca [2] N(R) je vysielacie poradové číslo a N(S) je prijímacie poradové číslo rámca. Ak je P (Poll) bit nastavený na hodnotu 1 tak vysielacia stanica vyžaduje potvrdenie práve vyslaného bloku pomocou S rámca s F(Final) = 1. Ak je P bit rovný 0 tak prijímacia stanica môže tento rámec potvrdiť buď S alebo I blokom. [1] S rámce (viď obr. 2.4) slúžia k riadeniu komunikácie. Potvrdzuje správne prijaté rámce, nesie príkazy alebo odpovede, ktoré oznamujú ďalší postup bit N (R) P/F S S 0 1 Obrázok 2.4 Štruktúra poľa S rámca [2] S rámec obsahuje prijímacie poradové číslo N(R), bit P/F, a dva S bity. Bit P/F (Poll/Final Výzva/Koniec) slúži na vytvorenie dialógu medzi komunikujúcimi stranami. Hlavná stanica používa P=1, čím vyzýva podriadenú stanicu na odpoveď. Podriadená stanica odpovedá na P bit prenosom dát s F= 1. F bit môže byť využitý v NRM (spomenuté nižšie) ako signál ukončujúci spojenie s podriadenou stanicou. Ak v S príkaze bit P = 0, príslušnej odpovedi na tento príkaz musí byť F = 0. [1] Bity S na pozícii 3 a 2, reprezentujú jeden z nasledujúcich príkazov resp. odpovedí: 7

16 o RR (Receiver Ready) Prijímacia stanica informuje vysielaciu stanicu, že je pripravená prijímať I rámce a taktiež môže byť vyslaná ako potvrdenie čísla správne prijatého rámca. Taktiež môže byť vyslaný ako správa signalizujúca, že linka je voľná. o RNR (Receiver Not Ready) Prijímacia stanica informuje vysielaciu stanicu, že prijímač z neznámeho dôvodu nie je schopný prijímať I- rámce. Zároveň však potvrdzuje doposiaľ prijaté rámce. o REJ (Reject) Prijímacia stanica informuje, že v prijatom rámci sa vyskytli chyby a žiada o opätovné vyslanie rámca. [2] U rámce (viď obr. 2.5) nie sú číslované a preto ich prenos nie je zabezpečený. Sú použité na výstavbu, rozpad logického spojenia medzi vrstvami 2, nastavenie módu prenosu bit M M M P/F M M 1 1 Obrázok 2.5 Pole U rámca [2] P/F bit má rovnaký význam ako pri vyššie uvedenom S rámci. Pomocou M bitov určujeme viacero funkcií aké môže U rámec reprezentovať. Ako príklad uvediem niektoré z nich: o SNRM (Set Normal Response Mode) Nastaví linku do normálneho módu, v ktorom môže len hlavná stanica iniciovať dátový prenos od iných podriadených staníc. o SNRME (Set Normal Response Mode Extended)- Nastaví linku do NRM módu s rozšíreným riadiacim poľom. o SABM (Set Asynchronous Mode) Tento príkaz nastaví linku do ABM módu s osembitovým riadiacim poľom. o SABME (Set Asynchronous Mode) Príkaz nastaví linku do módu s rozšíreným riadiacim poľom, t.zn.16 bitov. o UA (Unnumbered Acknowledgment) Táto správa je využitá pri nečíslovanom potvrdzovaní príkazov SABM, SABME, SNRM, SNRME a DISC. 8

17 o o o o DISC (Diconnect) - Požiadavka na ukončenie logického spojenia DM (Disconnect Mod) - Pozitívne potvrdenie príkazu DISC XID (Exchange Station Identification) - Príkazy a odpovede tohto druhu sú použité pri úvodnej výmene informácií medzi komunikujúcimi stanicami. Napr. akej veľkosti bude použitý kontrolný súčet. UI (Unnumbered Information) - Používa sa na prenos nečíslovaných dátových rámcov, ktoré môžu obsahovať na počiatku dátového poľa špecifikáciu prenášaného protokolu vyššej vrstvy. [2] I (Information) Dĺžka informačného poľa je premenlivá, alebo vôbec nie je toto pole použité. Obsahuje prenášané dáta z vrstvy 3. Toto pole je obsiahnuté len vtedy ak v kontrolnom poli je prenášaný I blok. FCS (Frame Check Sequence) - Dĺžka tohto pola je 16 alebo 32 bitov. Obsahuje kontrolný súčet, pomocou ktorého určujeme či bol daný rámec prijatý bezchybne. Ako bolo spomenuté v úvode podkapitoly, veľkosť (16 alebo 32 bitov) kontrolného súčtu si dohovoria komunikujúce stanice na začiatku pomocou príkazu XID. PPP (Point-to-Point Protocol) PPP bol vyvinutý z už vyššie spomenutého protokolu HDLC. Preberá od neho niektoré funkcie a zároveň pridáva niektoré nové. Podporuje duplexnú prevádzku bod-bod, synchrónny i asynchrónny prenos, pevné a komutované spoje, autentifikáciu a taktiež umožňuje prenos viacerých sieťových protokolov než HDLC. Môže spájať počítače využívajúc sériový kábel, telefónnu linku, rádiové linky alebo optické vlákno. Poskytovatelia internetu využívajú PPP ako protokol pre prístup do internetu pripojením dial-up alebo jeho zapúzdrenou formou PPP cez Ethernet PPPoE (PPP over Ethernet), ktorá je často používaná ako prístup pri pripojení do internetu pomocou digitálneho účastníckeho vedenia DSL(Digital Subscriber Line). [3] Hlavným rozdielom oproti HDLC, ako môžeme vidieť na obr. 2.6,je použitie 2 bytového poľa P, ktoré slúži k identifikácii prenášaného sieťového protokolu. 9

18 F A C P I FCS F 1 byt 1 byt 1 byt 1 alebo 2 byty Premenlivá dĺžka 2 alebo 3 byty 1byt Obrázok 2.6 Štruktúra rámca protokolu PPP [4] Popis polí rámca PPP F (Flag), FCS (Frame Check Sequence) obe tieto polia plnia rovnakú funkciu ako v protokole HDLC. A (Address) Adresa je 1 bytová a je vytvorená zo sekvencie , čo je štandardná broadcast adresa. PPP neprideľuje staniciam individuálne adresy. [5] C (Control) - Kontrolné pole je dĺžky 1 byte a je vytvorené zo sekvencie (hexadecimálne 0x03) čo predstavuje nečíslované informačné správy, v ktorých bit P/F je nastavený na 0. P (Protocol) Protokolové pole je 2 bytové a jeho hodnota identifikuje aký protokol je zapuzdrený v informačnom poli rámca. Tieto protokoly môžme rozdeliť do troch skupín: 1. Protokoly pre naviazanie, ukončenie spojenia, testovanie linky a autentifikáciu (viď príloha č.1. Tabuľka 1). 2. Kontrolné protokoly pre konfiguráciu prislúchajúceho sieťového protokolu. 3. Sieťové protokoly. V prílohe číslo 1. sú taktiež zobrazené tabuľky 2 a 3, ktoré znázorňujú vybrané protokoly skupiny 2 a skupiny 3. Hexadecimálne hodnoty protokolov skupiny 2 sú v rozsahu od do b - - -, a určujú prislúchajúci kontrolný protokol sieťovej vrstvy NCP (Network Control Protocol). Hodnoty v rozsahu od do ) určujú sieťový protokol, ktorý bude prenášaný v dátových rámcoch. Ako môžme vidieť, každý kontrolný protokol korešponduje so svojím sieťovým protokolom. Líšia sa len počiatočnou číslicou 8 respektíve 0. Napríklad: IPv6 Control Protocol 8057 a jeho sieťový protokol IP v [5] Aby bolo možné zostaviť spojenie medzi dvoma bodmi na linke, na ktorej je využitý PPP protokol, musia obe koncové stanice, ako prvé vyslať konfiguračné datagramy linkového kontrolného protokolu LCP (Link Control Protocol), pomocou ktorých sa dohodnú 10

19 na dĺžke rámca, aký autentizačný protokol bude použitý, kompresii dát, atď. Ak sú už stanice dohodnuté na príslušných detailoch spojenia, jedna alebo obe stanice sa navzájom autentifikujú (preukážu, že sú to naozaj oni). Pri autentizácii LCP prenáša dáta, ktoré neskôr použijú autentizačné protokoly ako napr.: Protokol overujúci pravosť hesla PAP (Password Authentication Protocol), vzájomný overovací protokol CHAP (Challenge Handshake Authentication Protocol). Počas konfigurovania linky a ani počas autentizácie nesmú byť prenášané žiadne datagramy sieťovej vrstvy, lebo v takom prípade budú odstránené. [2] V prípade, že konfigurácia i autentizácia prebehla úspešne prichádzajú na rad protokoly skupiny 2. Kontrolné protokoly (NCP) musia otvoriť linku pre svoj sieťový protokol, ktorý má byť na nej použitý. Ak NCP otvoril linku tak za pomoci protokolu PPP bude prenášaný jeho prislúchajúci sieťový protokol. Na linke môže byť prenášaných viacero sieťových protokolov súčasne ale každý z nich si musí za pomoci svojho NCP otvoriť linku. Pri ukončení spojenia sa prenášajú len LCP datagramy a všetky ostatné sú odstránené. I (Information) - Dĺžka informačného poľa je premenlivá v rozmedzí ( bytov). Obsahuje datagram protokolu, ktorý je špecifikovaný v protokolovom poli. Prednastavená maximálna dĺžka informačného poľa je 1500 bytov, ale komunikujúce stanice sa môžu dohodnúť na inej väčšej dĺžke. Ak dáta nesené v poli sú menšie než 1500 bytov môže byť k nim byť pridaná výplň a je na danom protokole vyňať ju z užitočných dát IP, protokol sieťovej vrstvy IP (Internet Protocol) je hlavným protokolom sieťovej vrstvy a tvorí základný kameň Internetu. Slúži na prepojenie rôznych typov sietí (LAN, MAN) do jednej kooperujúcej siete: Internetu. Vytvorenie IP protokolu sledovalo jeden hlavný ciel: možnosť, aby dva zariadenia, ktoré komunikujú cez celosvetovú sieť internet mohli byť navzájom jednoznačné identifikovateľné - mali jedinečnú adresu. IP protokol má dve hlavné úlohy: Prvou je poskytovať nespojovo orientovanú službu s negarantovanou kvalitou spojenia. Druhou úlohou IP je rozdelenie (vysielacia strana) a spojenie(prijímacia strana) datagramov na takú veľkosť, ktorú podporuje linková vrstva. Táto veľkosť sa taktiež nazýva MTU (Maximum Transmission Unit). 11

20 IP protokol verzie 4 (IPv4) Na obrázku 2.7 je zobrazená štruktúra datagramu IP protokolu verzie 4. Je prvou široko používanou verziou a tvorí základ väčšej časti súčasného Internetu. IPv4 používa 32-bitové adresy, čo obmedzuje adresný priestor na jedinečných adries, z ktorých časť je vyhradených pre zvláštne účely ako lokálne siete alebo multicastové adresy, čo redukuje počet adries použiteľných ako verejné internetové adresy. Riešením tohto problému je použitie IPv6 opísaného neskôr. Vers. 4 bity IHL 4 bity Type of servis 8 bitov Total length 16 bitov Identification of IP- datagram 16 bitov Flags 3 bity Fragment offset 13 bitov TTL 8 bitov Protocol 8 bitov Source Address 32 bitov Destination Address 32 bitov Header checksum 16 bitov Options (+ padding) Data (variable) Obrázok 2.7 Štruktúra datagramu IP protokolu verzie 4. [6] Popis polí IP datagramu Vers. (Version) Verzia IP protokolu je 4 bitová. Udáva verziu IP protokolu, ktorá môže byť v súčasnosti 4 alebo 6. Avšak verzia 6 má inú štruktúru datagramu (viď. ďalej). IHL (Internet Header Length) Dĺžka hlavičky datagramu je 4 bity. Udáva 32 bitové slová, ktoré určuje veľkosť hlavičky v násobku štyroch bajtov. Minimálna veľkosť hlavičky je teda 5 (5 x 4 =20 bytov) a maximálna veľkosť 15 (15 x 4 = 60 bytov). 12

21 Type of service Typ služby je 8 bitové pole, ktoré zatiaľ nenašlo veľké uplatnenie. V začiatkoch, toto pole malo slúžiť na identifikáciu služby a ako sa bude s daným datagramom zaobchádzať v uzloch, napr. aby mal čo najnižšie oneskorenie, vysokú spoľahlivosť prenosu atď. Momentálne, štandardizačné organizácie ako CCITT pracujú nad tým ako čo najlepšie využiť týchto 8 bitov. Total length- Celková dĺžka IP datagramu je veľkosti 16 bitov a vyjadruje celkovú dĺžku IP datagramu v bajtoch. Keďže pole je 16 bitové tak maximálna dĺžka datagramu je bajtov. Identification of IP datagram Identifikačná hodnota je veľkosti 16 bitov. Každému datagramu je priradená hodnota, ktorá sa cely čas nemení. Za pomoci nej sú na strane prijímateľa identifikované fragmenty jedného datagramu. Flags Príznak fragmentácie je 3 bitové slovo (viď obr. 2.8), ktoré je použité pre kontrolu a identifikáciu fragmentov. 0 1bit DF 1bit MF 1bit Obrázok 2.8 Príznaky fragmentácie [2] Prvý bit je vždy 0. DF- (Dont Fragmentation) Zákaz fragmentácie MF- (More Fragments) Viacej fragmentov Ak je DF bit nastavený na 1 tak je fragmentácia zakázaná, ak 0 tak fragmentácia je možná. Bit MF určuje či je prislúchajúci fragment IP datagramu posledný alebo nasledujú za nim ďalšie fragmenty. Ak je MF=0 tak je to posledný fragment IP datagramu ináč je nastavený na 1. Fragment ofset Pozícia fragmentu je 13 bitové pole a indikuje pozíciu fragmentu od začiatku datagramu. Toto umožňuje prijímaču správne rekonštruovať datagramu do pôvodného stavu ako bol vyslaný. 13

22 TTL(Time To Live) Pole doby životnosti datagramu je dĺžky 8 bitov. Toto pole zamedzuje nekonečnému sa šíreniu datagramu sieťou. Vysielacia strana nastaví v tomto poli explicitne určenú hodnotu a každý smerovač cez, ktorý datagram prechádza zníži túto hodnotu o 1. V prípade ak smerovač zistí, že už nie je možné znížiť hodnotu TTL, tento datagram sa zahadzuje a odosielateľovi, za pomoci protokolu ICMP, sa oznámi, že datagram bol zahodený. Protocol Toto 8 bitové pole protokolu identifikuje protokol vyššej vrstvy, ktorý bude využívať IP datagram k svojmu prenosu. Header Checksum Pole kontrolného súčtu hlavičky IP datagramu je dĺžky 16 bitov. Pri prechode datagramu smerovačom sa mení hodnota TTL z čoho vyplýva, že sa mení aj hlavička IP datagramu a v závislosti na tom musí byť taktiež prepočítané pole kontrolného súčtu. Source Address 32 bitové pole adresy odosielateľa datagramu. Destination Address 32 bitové pole adresy prijímateľa datagramu. Option Pole voliteľných položiek. Je využívané len v malej miere a smerovače sú spravidla nakonfigurované tak, že datagramy obsahujúce voliteľné pole bývajú zahadzované. [2] Data Dátové pole nesie dáta protokolov transportnej vrstvy (TCP, UDP, atď.)alebo pomocných protokolov sieťovej vrstvy (ICMP, IGMP). Toto pole nie je súčasťou hlavičky IP datagramu, z čoho vyplýva, že sa nezapočítava do kontrolného súčtu. IP protokol verzie 6 (IPv6) Hlavným dôvodom vytvorenia IPv6 bol nedostatok adresného priestoru, obzvlášť v husto obývaných krajinách Ázie ako sú India a Čína. IPv6 má nahradiť predchádzajúci štandard 14

23 IPv4, ktorý podporuje iba 4 miliardy ( ) adries, zatiaľ, čo IPv6 podporuje až približne adries. Toto bolo dosiahnuté zmenou dĺžky sieťovej adresy z 32 na 128 bitov. Ďalším prínosom je podpora mobility, lepšia kvalita služby QoS(Quality of Service), povinné zabezpečenie a ďalšie možnosti. S prihliadnutím na tieto vlastnosti, datagram v IPv6 bol vytvorený tak aby záhlavie datagramu bolo čo najmenšie a to len s najzákladnejším obsahom. Zriedka využívané časti datagramu z IPv4 boli presunuté do tzv. rozširujúcich hlavičiek v IPv6. Ide najmä o položky potrebné k fragmentácii datagramu, ktoré boli v každom IPv4 datagrame. Pre základné záhlavie bola stanovená pevná veľkosť, takže položka veľkosť hlavičky (IHL) bola vynechaná a taktiež pri dnešnej nízkej chybovosti a vysokej priepustnosti liniek, stratilo opodstatnenie pole kontroly súčet (Header Checksum). Dĺžka základnej hlavičky je vždy 40B, z ktorej až 32B je vyhradených pre adresy (2x16B). Štruktúra datagramu IPv6 je znázornená na nasledujúcom obrázku 2.9. Vers. 4bity Traffic Class 8bitov Flow Label 20bitov Payload Length 16bitov Next Header 8bitov Hop Limit 8bitov Source Address 128 bitov Destination Address 128bitov Obrázok 2.9 Štruktúra datagramu IP protokolu verzie 6. [7] Vers. (Version) 4 bitové pole. Udáva verziu IP protokolu, ktorá je v tomto prípade 6. T.C. (Traffic Class) Pole triedy dát je 8 bitové. Umožňuje špecifikovať prenášané dáta do 15 kategórii a podľa toho postupovať napr. pri zahltení siete. Tieto kategórie sú popísané v nižšie uvedenej tabuľke

24 Kat. Klasifikácia dát 0 nešpecifikované dáta 1 prevádzka v pozadí (správy) 2 automatická prevádzka ( ) 3 Rezervované 4 užívateľom uskutočňované prenosy (FTP, NFS) 5 Rezervované 6 interaktívna prevádzka (telnet) 7 riadenie siete (smerovacie protokoly, SNMP) 8-15 prenosy v reálnom čase Tabuľka 2.1 Kategórie reprezentujúce typ prenášaných dát [2] Kategórie 0 7 špecifikujú normálnu prevádzku. V kategóriách 8 15 sú špecifikované prenosy v reálnom čase, pričom tu platí pravidlo, že datagramy z nižšej kategórie majú nižšiu prioritu a pri zahltení siete budú zahodené skôr. Flow Label Identifikácia toku dát je 24 bitové pole. Každému dátovému toku je priradená hodnota v rozsahu od 0 po 0xFFFFFF. Takto identifikovanému dátovému toku, ak si to vyžaduje, môže byť pridelená vyššia kvalita služby alebo prenos v reálnom čase. Ďalšou možnosťou využitia môže byť: ak takýto dátový tok s cieľovou IP adresou je v smerovači vyslaný do prislúchajúceho smeru, tento sa zapamätá a následne ďalšie datagramy s tým istým identifikačným číslom toku sú už priamo posielané do smeru, ktorý je uložený v pamäti. Payload Length Dĺžka poľa prenášaných dát je 16 bitov veľká. Pole udáva dĺžku dát v bytoch bez hlavičky datagramu. Ak však datagram obsahuje aj pole ďalšia hlavička (uvedené nižšie) tak toto je započítané do tejto dĺžky. Keďže pole je 16 bitové, veľkosť prenášaných dát môže byť maximálne bytov. Next Header Ďalšia hlavička je pole dĺžky 8 bitov. Je to jedna z najvýznamnejších položiek, ktoré boli pridane do IP verzie 6 oproti verzii 4. Pole ďalšia hlavička v základnom záhlaví ukazuje aký typ dát ( aká hlavička ) nasleduje za základným záhlavím. Teoreticky môže ukazovať už na TCP segment alebo iný protokol vyššej vrstvy. Avšak môže taktiež ukazovať na ďalšiu rozširujúcu hlavičku IP protokolu. [2] Ak poukazuje na ďalšiu rozširujúcu hlavičku tak aj táto má pole ďalšia hlavička, ktorá ukazuje na ďalšiu hlavičku 16

25 atď. Napríklad rozširujúca hlavička Smerovacia informácia umožňuje predpísať datagramu prechodové uzly, ktorými má v zadanom poradí prejsť a zároveň slúži aj ako záznam adries uzlov, ktorými datagram prešiel. Typy rozširujúcich hlavičiek sú uvedené v tabuľke v prílohe č. 2 [8]. Hop Limit Pole počet skokov je 8 bitové čo umožňuje nastaviť maximálny počet skokov na 255. Vysielacia strana nastaví limit počtu skokov na určitú hodnotu a každý smerovač v ceste, ktorým datagram prechádza ju zníži o 1. Keď hodnota poľa dosiahne hodnotu 0 datagram je zahadzovaný. Source Address 128 bitové pole adresy odosielateľa datagramu. Destination Address 128 bitové pole adresy možného prijímateľa datagramu TCP a UDP, protokoly transportnej vrstvy TCP (Transmission Control Protocol) TCP je v súčasnej do najviac využívaným protokolom transportnej vrstvy, ktorý poskytuje spojovo orientovanú službu. Vytvára plne duplexný virtuálny okruh medzi dvoma aplikáciami a zaručuje, že dáta odoslané z jedného konca spojenia budú prijaté prijímacou stranou v rovnakom poradí a bez chýbajúcich častí. Keďže prenášané segmenty sú číslované prijímacia strana dokáže opätovne požiadať o poslanie chýbajúcich alebo poškodených segmentov. TCP segment je transportovaný pomocou IP na danú IP adresu. Tu bežia jednotlivé aplikácie, ktorým sú priradené jednotlivé porty. Každý TCP segment taktiež pozostáva z čísla portu na základe, ktorého operačný systém rozpozná ktorej aplikácii ho má predať. Štruktúra TCP segmentu je zobrazená na nasledujúcom obrázku

26 Source Port 16 bitov Destination Port 16 bitov Sequence Number 32 bitov Acknowledgment Number 32 bitov Data Off. 4 bity Reser. 4 bity Flags 8 bitov Window 16 bitov Checksum 16 bitov Urgent Pointer 16 bitov Options (optional) Data Popis polí TCP segmentu Obrázok 2.10 Štruktúra TCP segmentu [2] Source Port Toto 16 bitové pole identifikuje zdrojový port odosielateľa. Destination Port 16 bitové pole identifikujúce cieľový port príjemcu TCP segmentu. Seguence Number Poradové číslo vysielaného bajtu je pole dĺžky 32 bitov. Určuje poradové číslo prvého vysielaného bajtu TCP segmentu. Číslovanie nezačína od 0 ale od náhodne zvoleného čísla. Toto náhodné číslo je generované vždy keď je nastavený bit SYN (viď. Flags). Acknowledgment Number Poradové číslo prijatého bajtu je pole dĺžky 32 bitov. Určuje číslo nasledujúceho bajtu, ktorý je príjemca pripravený prijať a zároveň potvrdzuje správne prijatie všetkých segmentov až do poradového čísla prijatého bajtu mínus jedna. [2] Data Offset Pole dĺžky 4 bity vyjadruje dĺžku TCP hlavičky, ktorá je udávaná v násobku 4. Minimálna veľkosť hlavičky je 5 (5 x 4 =20 bytov) a maximálna veľkosť 15 (15 x 4 = 60 bytov). 18

27 Reserve Momentálne 4 bitové pole, ktoré je rezervované pre budúce použitie. Flags Pola príznakov je 8 bitov dlhé. Každý bit reprezentuje jeden príznak (obr. 2.11) bit CWR ECE URG ACK PSH RST SYN FIN Obrázok 2.11 Pole príznakov TCP segmentu [2] CWR (Congestion Window Reduced) Príznak CWR je nastavený vysielacou stranou a indikuje, že TCP segment má nastavený ECE bit (viď. nižšie). ECE (Explicit Congestion notification Echo) indikuje, že spolupracujúca strana podporuje ECN(Explicit Congestion Notification) počas nadviazania spojenia. URG (Urgent) indikuje, že TCP segment nesie súrne dáta. ACK (Acknowledgmet) indikuje platnosť poľa Acknowledgment Number. Tento príznak je nastavený vo všetkých segmentoch okrem prvého. PSH (Push) indikuje prenos aplikačných dát, ktoré má príjemca predať aplikácii. RST (Reset) indikuje odmietnutie TCP spojenia SYN (Synchronize) indikuje začiatok nového číslovania TCP segmentov. Segment, ktorý má nastavené SYN prenáša poradové číslo prvého odosielaného bajtu. FIN (Finsih) indikuje ukončenie odosielania dát. Window Pole dĺžky 16 bitov vyjadruje o koľko môže byť zvýšené poradové číslo prijatého bajtu, aby bolo príjemcom akceptované. Checksum Kontrolný súčet TCP segmentu je dĺžky 16 bitov. Počíta sa z TCP segmentu a niektorých položiek IP hlavičky (adresa odosielateľa a prijímateľa). Ak dáta, ktoré majú byť zarátané do kontrolného súčtu sú nepárne, v takom prípade je k nim pridaná výplň do 16 bitov. Výplň je vytvorená z núl a je pridaná za pole voliteľnej výplne. 19

28 Urgent Pointer Pole ukazovateľa súrnych dát je dĺžky 16 bitov. Toto pole môže byť prezentované iba v prípade ak je nastavený príznak URG (viď. Flags ). Ak pripočítame tento ukazovateľ k číslu odosielaného bajtu tak táto hodnota poukazuje na koniec úseku naliehavých dát. Option Pole voliteľných položiek môže byť maximálne 40 bytov dlhé. V tabuľke 2.2 sú uvedené niektoré voľby možných voliteľných výplní. Identif. Dĺžka Popis 0 1 Koniec voliteľných položiek 1 1 Prázdny príkaz 2 4 Max. veľkosť segmentu 3 3 Činiteľ zmeny veľkosti okna 4 2 Zákaz odstránenia 5 premenná Odstrániť 6 6 Echo 7 6 Odpoveď na Echo 8 10 Časová značka Tabuľka 2.2 Voliteľné položky [2] Data Toto pole nie je súčasťou hlavičky TCP segmentu. Prenáša akýkoľvek protokol vyššej vrstvy. Nadviazania, prenos dát a ukončenie spojenia TCP protokolom Ako už bolo na začiatku uvedené, TCP poskytuje spojovo orientovanú službu. To znamená, že obe komunikujúce strany medzi sebou nadviažu logické spojenie a až potom je možné prenášať dáta. Taktiež musia mať mechanizmus pre potvrdzovanie, znovu vyžiadanie stratených alebo poškodených segmentov atď. Nadviazanie spojenia Klient je strana, ktorá chce nadviazať spojenie a serverom strana, ktorá očakáva spojenie. Serverom je určená strana, ktorá čaká na prichádzajúce spojenie (pasívne počúva) na danom porte od klienta, ktorý chce začať komunikáciu. Nadviazanie komunikáciu so serverom je uskutočňované v troch fázach (tzv. 3-way handshake)[2] : 20

29 1. Klient vygeneruje náhodné poradové číslo vysielaného bajtu max. dĺžky 32 bitov a nastaví príznak SYN. Takto vytvorený segment je vyslaný serveru čím sa otvára aktívna komunikácia. 2. Ako odpoveď vyšle server segment s nastavenými príznakmi ACK a SYN. 3. Napokon klient odpovedá príznakmi SYN a ACK. Stav nadväzovaní spojenia je stav servera a klienta charakterizovaný, stavom spojenia Server môže byť v stave: LISTEN sever počúva a je pripravený na spojenie s klientom SYN-RECEIVED server prijal od klienta TCP segment s nastaveným príznakom SYN Klient môže byť v stave: SYN- SENT klient odoslal TCP segment s nastaveným príznakom SYN Prenos dát Pokiaľ je vybudované spojenie medzi klientom a serverom, na základe toho, že je to plne duplexné spojenie, môžu obe strany súčasne vysielať dáta. Ak jedna strana nemá dáta k vysielaniu, tak potvrdzuje prijaté segmenty. Keď je spojenie nadviazané server aj klient sú v stave ESTABLISHED. Ukončenie spojenia Ukončiť spojenie môže uskutočniť ktorákoľvek z komunikujúcich strán. Ak jedna zo strán chce ukončiť spojenie, vyšle segment s nastaveným príznakom FIN a už nemôže odosielať žiadne segmenty s príznakom PSH(prenášať aplikačné dáta). Druhá strana tento segment musí akceptovať ale stále môže prenášať dáta. Takéto spojenie sa nazýva polo-uzatvorené (half close). Celkové uzatvorenie spojenia nastane ak druhá strana vyšle segment s príznakom FIN a dostane na ňu odpoveď ACK. Pri ukončení spojenia môžu nastať stavy: FIN-WAIT1 jedna zo strán odoslala všetky dáta a nastaví príznak FIN, že chce uzatvoriť spojenie 21

30 FIN-WAIT2 stav keď jedna strana vyslala segment s príznakom FIN a čaká na príjem FIN segmentu od náprotivnej strany. CLOSE-WAIT strana prijala segment s príznakom FIN a potvrdzuje ho príznakom ACK CLOSING - strana čaká na potvrdenie ukončenia spojenia LAST-ACK druhá strana odoslala všetky dáta a signalizuje celkové ukončenie spojenia TIME-WAIT v tomto stave sa nachádza strana keď je vyslaný posledný potvrdzujúci segment o ukončení spojenia. Tento ukončujúci segment už nie je potvrdzovaný a preto strana ostáva určitý čas v stave TIME-WAIT. CLOSED Druhá strana prijala potvrdenie ukončenia spojenia a prechádza do stavu CLOSED. Strana, ktorá vysielala potvrdenie o ukončení spojenia prejde do stavu CLOSED až po uplynutí času v stave TIME-WAIT UDP (Used Datagram Protocol) UDP je ďalším veľmi dobre známym transportným protokolom. UDP naproti TCP nevytvára virtuálne spojenia, ale poskytuje nespojovo orientovanú službu. Vysielacia strana po vyslaní UDP datagramu sa oň viac nestará. Nijako neoznačuje datagramy, z čoho vyplýva že na prijímacej strane môžu prísť v rôznom poradí alebo môže dôjsť k strate bez toho, aby to bolo signalizované a je na protokoloch vyšších vrstiev zabezpečenie spojenia. Bez overovania a potvrdzovania príchodu datagramu je UDP rýchlejší a efektívnejší než TCP. Z pohľadu spoľahlivosti je využiteľný v aplikáciách kde sú prípustné straty alebo ich kompenzácia. Napríklad televízne vysielanie šírené internet protokolom IPTV (Internet Protocol Television) alebo hlas prenášaný za pomoci IP protokolu VoIP (Voice over IP). Na obrázku 2.12 je znázornená štruktúra UDP segmentu a ako môžme vidieť, potvrdzuje hore zmienené fakty, že neobsahuje viacero polí a je oveľa jednoduchšia než štruktúra TCP segmentu. 22

31 Source Port 16 bitov Length 16 bitov Destination Port 16 bitov Checksum 16 bitov Data Obrázok 2.12 Štruktúra UDP segmentu [2] Source Port Toto 16 bitové pole identifikuje zdrojový port odosielateľa. Destination Port 16 bitové pole identifikujúce cieľový port príjemcu UDP datagramu. Length Pole dĺžky datagramu je veľké 16 bitov. Vyjadruje veľkosť hlavičky a dát datagramu. Checksum Kontrolný súčet je počítaný obdobne ako pri TCP (viď. TCP) avšak nie je povinný. Ak nie je uvedený pole je vyplnené nulami. Data Pole nie je súčasťou hlavičky. Prenáša protokol vyššej vrstvy FTP, protokol aplikačnej vrstvy FTP (File Transfer Protocol) FTP je protokolom aplikačnej vrstvy využívajúci výhradne TCP protokol. Slúži na prenos súborov medzi počítačmi v rámci Internetu alebo intranetu. Používateľ (klient) na jednom počítači môže prenášať súbory alebo vykonávať príkazy na vzdialenom počítači (server). Na pripojenie k serveru je potrebné konto, ktoré zahŕňa užívateľské meno a heslo. Na vytvorenie konta je potrebná registrácia u prevádzkovateľa FTP servera. Niektoré servery sú tzv. anonymné a nevyžadujú registráciu. Typické meno na prihlásenie sa je anonymous alebo ftp. Ako heslo je požadovaná adresa. Počas spojenia môže klient vykonávať na serveri rôzne operácie (ak má na to oprávnenie) ako napríklad: pridávať a sťahovať dáta, odstraňovať premenovávať súbory zo servera, atď. Pre prenos je potrebné vytvoriť dve spojenia. Jedno pre prenos príkazov 23

32 a odpovedí a druhé spojenie pre prenos dát. Na strane FTP servera je spustený program, ktorý zabezpečí že sa javí ako sever. Tento vždy očakáva prichádzajúce spojenia od FTP klientov na porte 21. Ak klient nadväzuje spojenie dotazuje sa na tento port a vytvorí sa kontrolný kanál, ktorým budú prenášané príkazy v oboch smeroch. Kontrolný kanál je aktívny počas celej doby spojenia. Prenosový mód dátového kanála Pre prenos dát je nutný dátový kanál. Jeho inicializácia môže byť uskutočnená dvomi spôsobmi: aktívnym alebo pasívnym módom: Aktívny mód - klient otvorí náhodný port, ktorého číslo však musí byť väčšie než Vyšle serveru číslo tohto portu kontrolným kanálom a očakáva spojenie od servera. Server vytvorí dátový kanál pričom bude využitý port 20 na strane servera a náhodný port (väčší než 1023) na strane klienta. Pasívny mód - klient vyšle kontrolným kanálom príkaz na pasívne otvorenie komunikácie (PASV). Na to server otvorí náhodný port(väčší než 1023). Toto číslo portu pošle kontrolným kanálom klientovi a čaká na spojenie od klienta. Klient otvorí dátový kanál na čísle portu, ktoré obdržal od serveru a na jednom zo svojich portov (číslo je väčšie než 1023). Reprezentácia dát Na prenos dát v dátovom kanály môže byť použitých viacero spôsobov reprezentácie dát. Najčastejšie sú používané tieto dva spôsoby módy: ASCII a Binárny mód: ASCII mód - každé písmeno,číslica alebo znak je reprezentované jeho prislúchajúcim znakom ASCII. Avšak tento mód je vhodný na prenos textových súborov lebo ASCII využíva 7 bitov a dáta ako napríklad obrázky alebo hudba využívajú 8 bitov z čoho je zrejme že pri prenose by došlo k strate jedného bitu čo by znamenalo poškodenie súboru. Pre vyriešenie tohto problému môžme použiť buď EBCDIC (Extended Binary Coded Decimal Interchange Code) mód, ktorý využíva 8 bitov alebo binárnu reprezentáciu dát. 24

33 Binárny mód - vysielacia strana posiela celý súbor bit za bitom a prijímateľ ukladá tento prúd bitov do súboru. Ako východiskový mód využíva väčšina FTP klientov ASCII mód. Príkazy kontrolného kanála Kontrolným kanálom sú vysielané príkazy, ktoré je možné rozdeliť do troch skupín. Príkazy riadenia prístupu: USER klient posiela užívateľské meno PASS klient posiela užívateľské heslo ACCT klient posiela informácie o užívateľskom účte CWD - zmena aktuálneho adresára CDUP - zmena aktuálneho adresára o úroveň vyššie QUIT klient alebo server inicializuje ukončenie spojenia Príkazy nastavujúce parametre prenosu: PORT - klient posiela číslo portu, na ktorom bude očakávať dátové spojenie. PASV klient žiada server o pasívne spojenie. TYPE - určuje typ reprezentácie dát. Pomocné príkazy: RETR inicializuje prenos daného súboru zo servera. STORE inicializuje prenos daného súboru na server RNFR, RNTO - premenovanie súboru DELE - zmazanie súboru MKD - vytvorenie nového adresára RMD - zmazanie adresára ABORT - zrušenie posledného príkazu PWD zisti aktuálny pracovný adresár servera 25

34 LIST ak za príkazom nasleduje názov súboru server odpovie informáciami o tomto súbore. Ak je to adresár získa sa jeho výpis. Pre získanie zoznamu je potrebné vytvoriť dátové spojenie. NLST server vráti klientovi zoznam súborov alebo adresárov bez žiadnych iných doplňujúcich informácii. SYST zistí systém bežiaci na FTP serveri [9] 26

35 3. UML (Unified Modeling Language) Metodika softwarového inžinierstva predstavuje súbor prezentačných techník a metodických postupov, ktoré podporujú systematický vývoj a údržbu programového diela. Metodiky sa preto môžu odlišovať prezentačnými technikami (zápisom), metodickými postupmi (proces) a dostupnými nástrojmi. Každá metodika priniesla niečo nového, zvyčajne však aj nový zápis. Toto bolo dôvodom snahy o zjednotenie vyjadrovania. Rôzne spoločnosti sa snažili vytvoriť vlastné návrhy ale až zoskupenie objektovo orientovaných spoločností OMG (Object Management Group) vydalo štandard pod označením UML 1.1. Súčasná verzia má označenie UML UML je vytváraný s úmyslom ako univerzálny štandard pre záznam, konštrukciu, vizualizáciu a dokumentáciu artefaktov softwarových systémov. [14] Cieľmi UML je: poskytnúť používateľom expresívny vizuálny modelovací jazyk aby mohli vyvíjať rozumné modely poskytnúť možnosť rozšíriteľnosti a špecializáciu mechanizmov pre rozšírenie hlavného konceptu byť nezávislý od rôznych programovacích jazykov a vývojových procesov poskytnúť formálnu bázu pre pochopenie modelovacieho jazyka povzbudiť rast nástrojov pre (objektovo orientovaný) OO trh podporovať vysoko úrovňové koncepty ako spolupráca, rámcové štruktúry, zákonitosti a komponenty integrovať najlepšie postupy 3.1. Diagramy UML Jazyk UML sa skladá z množstva grafických prvkov, ktoré je možno kombinovať navzájom a vytvárať dvojrozmerné diagramy. Jednotlivé grafické prvky môžu byť vzájomne prepojené, čím je vyjadrený vzťah medzi nimi. Toto grafické znázornenie definuje určitý typ diagramu. V UML 2.1 je možné definovať 13 typov diagramov, z ktorých v nasledujúcej časti bude popísaných najpoužívanejších 9. Sú to: 27

36 diagramy triedy a objektu (class diagrams, object diagrams) popisujú statickú štruktúru systému, znázorňujú dátový model systému od návrhu až po implementáciu diagram prípadov použitia (use case diagrams) dokumentujú možné prípady použitia systému a udalosti, na ktoré musí systém reagovať sekvenčný diagram (sequence diagrams) popisuje scenár priebehu určitej činnosti v systéme diagram spolupráce (collaboration diagrams) zobrazuje komunikáciu spolupracujúcich objektov, možné stavy a prechody medzi nimi diagram aktivít (activity diagrams) popisuje priebeh aktivít procesu alebo činnosti diagram komponentov (component diagrams) popisujú rozdelenie výsledného systému na funkčné celky (komponenty) a definuje náplň jednotlivých komponent diagram nasadenia (deployment diagrams) popisuje umiestenie funkčných celkov (komponent) na výpočtové uzly informačného systému [15] Diagramy je možné rozdeliť do troch systémových modelov: Statické - diagramy tried, diagramy spolupráce, diagramy komponent a diagram nasadenia Funkčné - diagramy aktivít, scenáre udalostí a diagramy spolupráce Dynamické - dokumentujú stavové diagramy, diagramy spolupráce a diagramy aktivít Použitie diagramov v jednotlivých fázach vývoja je dané príslušnou metodikou, ale je možné povedať, že v rámci analýzy zadania sa využívajú diagramy tried, diagramy aktivít, a stavové diagramy. Pre fázu návrhu sú použité diagramy tried, diagramy spolupráce, diagramy aktivít, diagramy komponent a diagramy nasadenia. Vo fáze realizácie sa používajú diagramy tried, diagramy komponent a diagramy nasadenia Diagram tried Triedy predstavujú spoločné vlastnosti sady objektov. Reprezentujú kategórie z prirodzeného sveta, ktoré sú popísané svojimi vlastnosťami, a správaním (operáciami). Na obrázku 3.1 je znázornená trieda Trojuholník, ktorá má vlastnosti ako dĺžka, výška alebo 28

37 obvod. Tieto vlastnosti môžu mať nastavenú i počiatočnú hodnotu. V ďalšom poli sú uvedené operácie, ktoré môže trieda vykonávať zobraz(), odstran() atď. Symboly uvedené pred jednotlivými vlastnosťami alebo operáciami označujú viditeľnosť daného prvku: + prvok je verejný (public) prvok je súkromný (private) # prvok je chránený (protected) Ak existuje previazanosť medzi triedami je potrebné ju vyznačiť čiarou s príslušnou asociáciou. Obrázok 3.13 Príklad použitia diagramu triedy [15] Diagram objektov Objekt je pojem s presne definovanými hranicami a významom a je popísaný: identitou, stavom a chovaním: Stav objektu je jedna z možných podôb, v ktorých sa objekt môže nachádzať. Stav objektu sa môže meniť a je definovaný sadou vlastností ako sú atribúty a vzťahy. Chovanie určuje ako objekt reaguje na žiadosti iných objektov a popisuje, čo všetko môže objekt vykonávať. Chovanie je implementované sadou operácii (metódami). Identita znamená, že každý objekt je jedinečný 29

38 Objekt diagram je považovaný za špeciálny prípad diagramu tried. Objektové diagramy používajú podskupiny elementov diagramov tried aby zdôraznili vzťah medzi inštanciami tried v určitom čase. Takýto diagram objektov je znázornený na obrázku 3.2. Obrázok 3.14 Príklad použitia diagramu objektov [15] Diagram prípadov použitia Model prípadu použitia slúži pre základné vymedzenie hraníc medzi systémom a jeho okolím. Model je zložený: aktér (actor) je to ktokoľvek alebo čokoľvek mimo systému alebo spolupracujúci systém hranice systému (system boundary) - určené hranice systému prípad použitia (use case) dokumentácia udalostí, na ktorú musí systém reagovať komunikácia - väzba medzi aktérom a prípadom použitia (aktér komunikuje so systémom na danom prípade). Diagram prípadu použitia je znázornený na nasledujúcom obrázku (3.3). 30

39 Obrázok 3.15 Príklad použitia diagramu prípadu použitia Pri vytváraní modelu prípadu použitia treba brat na zreteľ, že ešte existujú sekundárny aktéri, (užívateľské úlohy, spolupracujúce systémy), pre ktorých nie je systém určený, ale sú preň nutný. Smer komunikácie je vyznačovaný orientovanými šípkami Diagram stavov Stavové diagramy slúžia k popisu dynamického správania sa systému. V stavovom diagrame sú definované možné stavy, možné prechody medzi stavmi, udalosti, ktoré prechody vyvolávajú, podmienky prechodov a akcie, ktoré s prechodmi súvisia. Stavový diagram je možné použiť pre popis dynamiky objektu, pre popis metódy (ak je známy algoritmus), pre popis protokolu (vrátane protokolu o styku užívateľa so systémom). Takýto stavový diagram je znázornený na obrázku 3.4. Jednotlivé stavy sú znázornené ako obdĺžniky s oblými rohmi. Počiatočný stav je znázornený ako čierny kruh. Aby bolo možné prejsť z jedného stavu do ďalšieho je potrebná nejaká udalosť (stlačenie tlačidla, uplynutie času).táto udalosť je nazývaná aktivácia (Trigger). Po aktivácii môže nasledovať takzvaná stráž (Guard), čo je výraz vyhodnocovaný na základe atribútov objektu a udalostí. Za aktiváciou a strážou nasleduje akcia, čiže činnosť ak sú podmienky prechodu splnené. Časti aktivácia, stráž a akcia nie sú povinné. 31

40 Obrázok 3.16 Príklad použitia diagramu stavov [15] Sekvenčný Diagram Diagram sekvencií predstavuje takisto dynamické správanie sa systému. Dokumentuje spoluprácu účastníkov na určitej činnosti. Dôraz je zvlášť kladený na časovú zložku komunikácie. Sú vhodné pre popis systémov kde prebieha komunikácia s používateľom. Ukážka sekvenčného diagramu je na obrázku 3.5. Objekty alebo účastníci sú znázornený ako obdĺžnik s príslušným menom. Správy ktoré sú posielané sú znázornené ako šípky. Správy môžu byť synchrónne (koniec šípky je vyfarbený) alebo asynchrónne (koniec šípky je nevyfarbený). Správy sú znázornené plnými čiarami a odpovede prerušovanými. 32

41 Obrázok 3.17 Príklad použitia sekvenčného diagramu Diagram spolupráce Podobne ako pri diagrame činností vyjadruje diagram spolupráce súčinnosť objektov pri riešení úlohy a je zdôraznený komunikačný aspekt, pričom čas je vyjadrený číslovaním (viď obr. 3.6.). Vedľa asociačnej čiary sa kreslí šípka smerujúca k cieľovému objektu s názvom správy. Popisujú objekty a správy, ktoré si posielajú pri riešení úlohy. Sú vhodné pre popis spolupráce objektov pri návrhu komunikácie. Obrázok 3.18 Príklad diagramu spolupráce Diagram aktivít Diagram aktivít je variantom stavových diagramov, kde sú okrem stavov používané i aktivity. Ak sa systém nachádza v nejakom stave, je prechod do iného stavu vyvolaný nejakou vnútornou udalosťou. Pri tomto type diagramu na rozdiel od diagramu stavu je 33

42 prechod vyvolaný ukončením aktivity. Používajú sa pre dokumentáciu tried, metód. Môžu obsahovať symbol rozhodovania ako je znázornené na obrázku 3.7. Obrázok 3.19 Príklad diagramu aktivít [14] Diagram komponentov Tento diagram zobrazuje vzťahy medzi softwarovými komponentmi, vrátane zdrojových kódov, binárnych knižníc a spustiteľných programov. Komponent je implementácia jednej alebo viacerých tried a môžu komunikovať s ostatnými komponentmi. Má špecifikáciu, čo uskutočňuje, implementáciu a spustiteľný binárny kód. Znázornenie diagramu komponentov a ich vzťahu je na nasledujúcom obrázku 3.8. Obrázok 3.20 Príklad diagramu komponentov [14] 34

43 Diagram nasadenia Tento diagram predstavuje fyzickú architektúru systému. Môže však zobrazovať i softwarové prvky, ktoré sú umiestnené na danej fyzickej architektúre. Ako príklad diagramu nasadenia je na obrázku 3.9. zobrazený diagram lokálnej siete. Obrázok 3.21 Príklad diagramu nasadenia [15] 35

44 4. Distribuované objektové systémy V tejto kapitole je uvedená základná charakteristika distribuovaných objektových systémov, ich základné vlastnosti, popis, význam a použitie CORBA štandardu a komunikácia medzi distribuovanými objektmi. Ako sa zdokonaľovali počítačové siete, postupy v programovaní a klesala cena výpočtového výkonu, začala rásť požiadavka na vytvorenie systému rozdeleného do viacerých nezávislých, vzájomne prepojených a komunikujúcich uzlov, ktoré sa zvonku javia ako jednotný integrovaný systém. Z počiatku bola v prevažnej miere využívaná architektúra klient/server, ale so zväčšujúcim sa záujmom o objektovo orientovaný vývoj programov sa začínajú využívať distribuované objektové systémy. Najznámejšie technológie na vytvorenie distribuovaného systému sú vyvolanie vzdialenej metódy RMI (Remote Method Invocation), distribuovaný objektový model DCOM (Distributed extension of the Component Object Model) a CORBA (Common Object Request Broker Architecture) Základné črty a vlastnosti Každý distribuovaný objektový systém by mal spĺňať nasledujúce vlastnosti, ktoré vyplývajú z jeho funkčnosti a objektového prístupu: Transparentnosť- užívateľ by nemal poznať, že využívané prostriedky sú lokálne alebo vzdialené. Zdieľanie prostriedkov - systém by mal umožňovať viacerým aplikáciám zdieľať systémové prostriedky (hardware, dáta). Odolnosť voči chybám - systém by mal mať schopnosť detekovať chyby a pokračovať v práci aj v takom prípade ak sa jedna jeho súčasť distribuovaného systému stane nedostupnou. Otvorenosť - špecifikácia systému a všetky jeho rozhrania sú verejne známe. Zapuzdrenie - umožňuje nezávislý vývoj jednotlivých objektov na iných objektoch, bez toho aby muselo byť známe, akým spôsobom pracujú. Vývoj sa uskutočňuje na základe dopredu stanoveného rozhrania jednotlivých objektov. 36

45 Polymorfizmus a dedičnosť možnosť využívať služby špecializovaných objektov neznámych v čase prekladu CORBA CORBA je štandard vyvíjaný skupinou OMG (Object Management Group), ktorá zahŕňa viac ako 800 spoločností a ktorej hlavným cieľom je vytváranie modelov a štandardov v oblasti distribuovaných systémov [13]. CORBA je dodávateľsky nezávislá architektúra a infraštruktúra, ktorú využívajú zariadenia na prácu cez sieť. Ponúka, nezávislosť na platforme a nezávislosť na programovacom jazyku. Nezávislosť na platforme znamená, že CORBA aplikácie môžu komunikovať s akoukoľvek platformou, pre ktorú existuje implementácia ORB(Object Broker Request). Nezávislosť na jazyku znamená, že implementácia klienta i servera môže byť napísaná v akomkoľvek jazyku pre ktorý existuje kompilátor z jazyka pre definíciu rozhraní IDL (Interface Definition Language) do tohto jazyka. IDL môže byť generované z prvkov, z ktorých je vytvorený príslušný UML model (viď. Kapitola 3.). Výhody použitia architektúry CORBA: nezávislosť na operačnom systéme nezávislosť na hardwari nezávislosť na jazyku robustnosť rozhranie distribuovanej časti je popísané jazykom IDL, odpadá písanie deklarácii v konkrétnom jazyku použitie všeobecného protokolu zabezpečujúceho komunikáciu medzi objektmi ORB GIOP (General Inter Orb Protocol), nad ktorým môže stáť ľubovoľný spojovo orientovaný transportný protokol špecializované verzie, napríklad CORBA pracujúca v reálnom čase podpora dynamického zistenia dostupnosti objektov až za behu aplikácie existencia mnohých implementácii od rôznych výrobcov s bezproblémovou komunikáciou neustály vývoj 37

46 Nevýhody použitia architektúry CORBA: vysoké ceny pri vývoji, ktoré sú niekedy spôsobené licenčnými podmienkami [13] Štruktúra architektúry CORBA Každá distribuovaná aplikácia, nie len v architektúre CORBA, je rozdelená na dve časti: klientsku časť a serverovú časť. Vzájomne medzi sebou komunikujú cez datagramovú sieť pomocou protokolov GIOP alebo IIOP (Internet Inter Orb Protocol). Obe časti sa ďalej skladajú z jednotlivých modulov. Na nasledujúcom obrázku 4.1. sú znázornené najhlavnejšie moduly. Obrázok 4.22 Moduly architektúry CORBA [11] Klientska časť pozostáva z [11]: Aplikácia klienta je program využívajúci vzdialené objekty. Pre použitie služieb vzdialeného objektu musí poznať jednoznačnú adresu objektu a rozhranie objektu a to buď v dobe prekladu alebo za chodu programu, tzv. (dynamické volanie). 38

47 Statické IDL Proxy poskytuje statické rozhranie na volanie objektov a definuje ako klient vyvolá zodpovedajúci servis na serveri. Dynamic Invocaton Interface(DII) umožňuje klientovi používať rozhranie, ku ktorému získa prístup až počas behu programu. ORB klienta sprostredkováva objektové komunikačné služby čím umožňuje objektom transparentne vysielať požiadavky a prijímať odpovede od iných objektov. ORB rozhranie - obsahuje niekoľko aplikačných rozhraní pre lokálne služby slúžiace aplikáciám Lokálny operačný systém operačný systém bežiaci na danom zariadení. Serverová časť pozostáva z [11]: Implementácia objektu - je kód objektu implementujúci vzdialené rozhranie (službu). Objektový adaptér - prijíma volanie serverových objektov, zabezpečuje ich aktiváciu, odovzdáva im riadenie, ruší neaktívne objekty a zabezpečuje správu referencií objektov Skeleton (kostra objektu) - prevezme správu vyslanú klientom od ORB a vyberie z nej identifikáciu danej operácie spolu s parametrami potrebnými na vyvolanie metódy Dynamic skeleton interface - je obdobou DII na strane servera, ide o dynamicky vytvorenú kostru objektu. ORB servera rovnaká úloha ako v klientskej časti ORB rozhranie rovnaká úloha ako v klientskej časti Lokálny operačný systém operačný systém bežiaci na danom zariadení Sieťovú časť tvoria [11]: GIOP a IIOP protokoly spájajúce klientsku a serverovú časť, ktoré môžu komunikovať nad ľubovoľným transportným protokolom. 39

48 ORB (Object Request Broker) ORB je základnou stavebnou jednotkou technológie CORBA. Tvorí jadro na, ktorom sú postavené komponenty vyšších úrovní. Je to softwarový prostriedok, ktorý zaisťuje komunikáciu medzi objektmi. Jeho základnou úlohou je vytvorenie spojenia medzi komponentmi aplikácie a zabezpečenie predania požiadaviek na ich rozhranie. Táto požiadavka musí zabezpečiť určenie umiestnenia cieľového objektu (aké metódy objektu sú volané, hodnoty parametrov), poslanie žiadosti k objektu a vrátenie odozvy späť k pôvodcovi volania (klientovi). Ďalšou dôležitou úlohou je taktiež zaistenie nezávislosti komunikácie na platforme. Všetky parametre sú pred poslaním upravené do formátu nezávislého na platforme. Po ich prijatí sú naopak z tohto nezávislého formátu prevedené do tvaru akceptovateľného cieľovou platformou IDL (Interface Definition Language) Ďalším nemenej dôležitým prvkom CORBY je jazyk pre definovanie rozhrania IDL (Interface Definition Language). Nie je to programovací jazyk, aj keď jeho syntax je vo veľkej miere podobná C++ alebo Jave. Popis vytvorený týmto jazykom poskytuje platformovo nezávislý popis samotných rozhraní a nie implementácií daných objektov. Pomocou IDL príslušná implementácia objektu oznámi klientovi, ktoré operácie ponúka a ako ich je možné vyvolať. Objekty CORBY sú mapované do rôznych programovacích jazykov, z čoho vyplýva že ak je definované rozhranie objektu v IDL, je možné zvoliť si ľubovoľný programovací jazyk, pre ktorý existuje podpora IDL. A v prípade použitia konkrétneho objektu, je možné použiť ľubovoľný programovací jazyk na jeho vzdialené požiadanie [11] DII (Dynamic Invocation Interface) a DSI (Dynamic Skeleton Interface) Pre zaistenie komunikácie medzi serverom a klientom sú využité dva moduly. Na strane klienta je to časť DII a na strane servera DSI. Tieto komponenty sú obsiahnuté povinne v každej implementácii. V prípade DII návrh umožňuje dynamicky za chodu aplikácie vyvolávať metódy na rozhraní distribuovaného objektu, ktorý nebol známy v dobe 40

49 prekladu. Pri DSI je situácia podobná, avšak táto časť bude volanie spracovávať a operácie, ktoré bude môcť vyvolať budú zisťované až za chodu aplikácie. DSI model sa prevažne využíva na premostenie jednotlivých distribuovaných objektových systémov [11] GIOP (General Inter Orb Protocol) GIOP špecifikuje prenosový syntax a formát sprav pre komunikáciu medzi ORB objektmi. Bol vytvorený s úmyslom, aby bol čo najjednoduchší. Obsahuje minimum doplnkových protokolových vrstiev potrebných pre prenos CORBA správ medzi ORB. Tento protokol je určený pre komunikáciu nad spojovo orientovanou transportnou službou. Jeho výhodou je, že implementácia každého ORB-u musí poznať iba jeden protokol, bez toho aby sa musela zaoberať sieťovou štruktúrou. Nad všeobecným formátom sa následne budujú ďalšie protokoly, ktoré už úzko spolupracujú s konkrétnymi transportnými protokolmi, príkladom je IIOP [11]. GIOP je charakterizovaný nasledujúcimi prvkami: CDR (Common Data Representation) je prenosový syntax, ktorý mapuje IDL dátové typy do nízko úrovňovej reprezentácie aby mohli byť prenášané medzi ORB-ami. TA (Transport Assumptions) popisuje veľkosť prenášaného pásma potrebného na prenos GIOP správ a taktiež popisuje riadenie spojenia. Formát prenášaných správ, ktoré môžu byť transportované medzi objektmi. V tabuľke 3.1 sú uvedené vybrané správy. Správy protokolu GIOP, ktoré môže posielať klient sú uvedené v tabuľke 4.1 : Klient Formát správy Popis správy Request vyvolanie metódy vzdialeného objektu Cancel Request zrušenie predchádzajúcej požiadavky Locate Request zaistenie umiestnenia vzdialeného objektu Message Error reakcia na predchádzajúcu správu Tabuľka 4.3 Správy protokolu GIOP vysielané klientom [12] Správy protokolu GIOP, ktoré môže posielať server sú uvedené v tabuľke 4.2 : 41

50 Server Formát správy Popis správy Reply výsledok vyvolania Locate Reply indikuje, či server implementuje objekt, alebo predá volanie ďalej Close Connection ukončenie spojenia Message Error reakcia na predchádzajúcu správu (zlý formát, neznáma správa) Tabuľka 4.4 Správy protokolu GIOP vysielané serverom [12] IIOP (Internet Inter Orb Protocol) IIOP je určený výlučne pre TCP/IP zatiaľ čo GIOP môže byť využitý nad ľubovoľnou spojovo orientovanou transportnou službou. IIOP popisuje, ako sa majú správy GIOP prenášať nad TCP/IP. Jeho účelom je zaistiť to, že klient bude schopný komunikovať so serverom naprogramovaným pomocou iného ORB a inej distribúcie [12] Komunikácia v architektúre CORBA Komunikácia v CORBA architektúre, je znázornená na obrázku 4.2. Klient na zariadeni1 má lokálnu aj vzdialenú implementáciu objektu. Ďalší postup bude zameraný na volanie vzdialenej implementácie objektu umiestnenej na zariadení 2. Obrázok 4.23 Volanie vzdialenej implementácie objektu [13] Ako vidieť na obrázku, ORB môže rozoznať z objektovej referencie, či sa jedná o objekt vzdialený alebo nie, klient toto nemôže. V objektovej referencii ktorú má klient nie je nič, čo by identifikovalo umiestnenie cieľového objektu a týmto je zabezpečená transparentnosť umiestnenia CORBA. 42

51 Všetky volania, či sa jedná o lokálne alebo vzdialené sú postupované zástupnému objektu nazývanému zvyšok (Stub).Tento ich ďalej postupuje ORB-u, ktorý zisťuje či objektová referencia je lokálna alebo vzdialená. V prípade,že referencia je vzdialená ORB zabezpečuje zabalenie správy do formy vhodnej pre prenos po sieti a predá ju ORB-u servera, ktorý uskutoční prevod parametrov do formy vhodnej pre platformu servera. ORB ďalej predá správu zástupnému objektu na strane serveru,tzv. kostre (Skeleton). Tento z nej vyberie identifikáciu danej operácie spolu s parametrami potrebnými na vyvolanie metódy, pretransformuje volanie a parametre na požadovaný formát a vyvolá danú metódu objektu. Po ukončení volania metódy vzdialeného objektu pretransformuje kostra výsledky alebo chyby volania a pošle ich klientovi naspäť prostredníctvom ORB-u. 43

52 5. Aplikácia pre analýzu log súborov Pre tvorbu aplikácie analyzujúcej zachytenú komunikáciu v log súbore som si vybral objektovo orientovaný programovací jazyk JAVA a to z dôvodu, že aplikácie vyvíjané v tomto jazyku sú nezávislé na operačnom systéme a architektúre. K spusteniu programu je potrebné aby bol na danej platforme nainštalovaný správny virtuálny stroj. Ako vývojové prostredie som použil prostredie ECLIPSE. Je to voľne šíriteľné integrované vývojové prostredie, ktoré je ďalej možné rozširovať za pomoci rôznych prídavných modulov. Aplikácia bola vytvorená za účelom rýchleho nájdenia chyby v dlhých log súboroch. Výsledná aplikácia je skomprimovaná do súboru Analyzer.jar, ktorý je priamo spustiteľný. Jednou z úloh vytvorenej aplikácie je analyzovanie dát uložených v log súbore. Tieto dáta obsahujú zachytenú komunikáciu medzi viacerými komunikačnými modulmi, z ktorých je zložená základňová stanica v sieti UMTS. Tieto moduly sú založené na CORBA architektúre a medzi sebou si posielajú rôzne informačné správy pomocou GIOP protokolu. Hlavný modul posiela správy svojim podriadeným modulom, ktoré sú mu povinné odpovedať v určitom stanovenom čase. Ak tento stanovený čas prekročia je to vyhodnotené ako chyba. Ďalšou úlohou aplikácie je na základe užívateľom stanovených podmienok nájsť požiadavku hlavného modulu, k nemu prislúchajúcu odpoveď a vyhodnotenie, či čas medzi požiadavkou a odpoveďou spĺňa stanovenú podmienku. Ako základ pre návrh aplikácie bol vytvorený zjednodušený diagram objektov v jazyku UML. Tento diagram a popis jednotlivých objektov, z ktorých sa skladá je znázornený v prílohe č Používateľské rozhranie Užívateľské rozhranie aplikácie môžme vidieť na obrázku 5.1. Je veľmi jednoduché a užívateľ má k dispozícii prvky, ktoré majú nasledujúcu funkčnosť: 44

53 Obrázok 5.24 Užívateľské rozhranie aplikácie pre analýzu.log súborov Pole výpisu V tomto poli je zobrazená analýza súboru a podmienok analýzy. Pole načítaných podmienok Pole v ktorom je možné načítať užívateľské podmienky definované v súbore filterlog.log alebo ich editácia a následné uloženie. Filtruj Tlačidlo Filtruj slúži pre užívateľa na vyfiltrovanie datagramov v ktorých sa nachádza reťazec zadaný v poli pre zadanie reťazca pre filtráciu. Otvor súbor Po stlačení tohto tlačidla sa zobrazí adresárová štruktúra zariadenia a je možné vybrať súbor pre analýzu. Nastavenie Po stlačení tohto tlačidla sa ako prvé zobrazí okno, do ktorého je potrebné napísať názov súboru kde bude ukladaná analýza log súboru. V prípade ak sa už v danom adresári takýto súbor nachádza je možné ho prepísať alebo zvoliť iný názov súboru. V ďalšom okne je potrebné nastaviť súbor, do ktorého 45

54 budú zapisované výsledky filtrácie na základe podmienok uvedených v súbore filterlog.log. Načítaj Slúži na načítanie podmienok definovaných v súbore filterlog.log Ulož Po stlačení tohto tlačidla budú zmeny prevedené v užívateľských podmienkach uložené do súboru filterlog.log. Koniec Po stlačení tohto tlačidla sa otvorí okno pre potvrdenie ukončenia aplikácie. Ak užívateľ stlačí Yes aplikácia sa ukončí ak No aplikácia beží ďalej Nastavenie a vzorová analýza V tejto podkapitole bude uvedený vzorový príklad analýzy log súboru. Je možné si vybrať z dvoch možností: analýza bez udania filtračných podmienok analýza so zadanými filtračnými podmienkami Analýza bez zadania filtračných podmienok Pri tejto analýze budú zobrazené datagramy, z ktorých je zložený log súbor. Výsledky analýzy budú zobrazené v poli výpisu (viď príloha 3.) a taktiež sa zapíšu do prednastaveného súboru pakety.log umiestneného v tom istom adresári ako celá aplikácia alebo si môže užívateľ sám definovať názov výstupného súboru a to v Nastaveniach. Do tohto výstupného súboru budú zapísané výsledky analýzy, kde si ich môže užívateľ neskôr pozrieť. V prípade ak veľkosť analyzovaného súboru je väčšia ako 8MB je výstupná analýza zapisovaná len do prednastaveného súboru alebo užívateľom definovaného súboru v Nastaveniach. Je to uskutočnené z dôvodu šetrenia operačnej pamäte zariadenia a urýchlenia analýzy. V prílohe číslo 3. je príklad analýzy log súboru. Výpis jedného datagramu obsahuje nasledovné položky: Cislo paketu určuje, koľkí v poradí je daný datagram. Cas prichodu paketu určuje čas príchodu daného datagramu v závislosti od času referenčného datagramu, ktorým je prvý datagram. Velkost paketu určuje koľko bytov obsahuje daný datagram. 46

55 Linkovy protokol určuje aký linkový protokol je použitý na linkovej vrstve. Sietovy protokol určuje aký sieťový protokol je použitý na sieťovej vrstve. IP adr. Odosielatela určuje IP adresu z ktorej bol daný datagram odoslaný. IP adr. Prijimatela určuje IP adresu pre koho je datagram určený. Transportny protokol určuje použitý transportný protokol. Protokol najvyssej vrstvy určuje protokol použitý na najvyššej vrstve, ktorá je v datagrame využitá. Uzivatelske data sú to dáta, ktoré prenáša protokol najvyššej vrstvy, prevedené do podoby zrozumiteľnej užívateľovi. V poli podmienok sú načítané podmienky, ktoré si definoval užívateľ. V tomto type analýzy nie sú použite. Užívateľ ďalej môže analýzu filtrovať zadaním reťazca do pola Zadaj retazec pre filter. Po potvrdení tlačidlom Filtruj sa zobrazia len tie datagramy, ktoré obsahujú zadaný reťazec Analýza so zadanými filtračnými podmienkami Hlavným rozdielom v porovnaní s predchádzajúcou analýzou je,že v analýze s podmienkami je potrebné definovať súbor s podmienkami, ktoré majú presne stanovenú štruktúru, ktorá je zobrazená v tabuľke 5.1 a ako príklad na obrázku 5.2. Na základe týchto podmienok je možné filtrovať len datagramy, ktoré obsahujú užívateľské dáta. Súbor s podmienkami je bežný editovateľný textový súbor. Pre činnosť aplikácie musí byť tento súbor uložený v adresári kde sa nachádza aplikácia a jeho názov musí byť filterlog.log. Je však možné napísať tieto podmienky priamo do pola nacitancyh podmienok a stlačiť tlačidlo Ulozit. Týmto sa vytvorí príslušný súbor filterlog, do ktorého sa uložia napísané podmienky. V tomto súbore môže byť definované väčšie množstvo podmienok(viď. Obr.: 5.3) Taktiež sú tu analyzované datagramy ukladané do súboru pakety.log a analýza podmienok je ukladaná do súboru analyza.log v adresári aplikácie. Ip adresa 1.Datagram 2. Datagram Odos/Prijim PODMIENKA PODMIENKA Max. oneskorenie [ms] 47

56 Tabuľka 5.5 Štruktúra zadávania podmienok [ ] [stillalive&!response&!connection] [stillaliveresponse] 50 Obrázok 5.25 Príklad zadania podmienok Jednotlivé časti podmienok musia byť medzi sebou oddelené medzerou a uzatvorené v hranatých zátvorkách. Štruktúra zadávanej podmienky sa skladá z týchto častí: Ip adresa Odos/Prijim je to adresa, ktorú musí mať datagram v poli IP adr. Odosielatela alebo IP adr. Prijimatela, aby spĺňal podmienku. 1.Datagram PODMIENKA je to podmienka, ktorú musí spĺňať datagram aby bol považovaný za žiadosť, na ktorú je očakávaná odpoveď. Túto podmienku musia taktiež spĺňať užívateľské dáta obsiahnuté v datagrame, ktorý vyhovuje podmienke Ip adresa. Táto podmienka môže byť zložená z viacerých subpodmienok, a ich výskyt v datagrame je určený pomocou logických operátorov súčin ( & ), súčet ( ) a negácia (!) 2. Datagram PODMIENKA je to podmienka, ktorú musí spĺňať datagram aby bol považovaný za odpoveď na vyslanú žiadosť. Túto podmienku musia taktiež spĺňať užívateľské dáta obsiahnuté v datagrame, ktorá vyhovuje podmienke Ip adresa. Je zložená len s jednej podmienky a nie je možné v nej používať logické operátory. Max. oneskorenie [ms] je to oneskorenie, ktoré je maximálne prípustné medzi datagramom spĺňajúcim podmienku pre 1.Datagram a datagramom spĺňajúcim podmienku pre 2. Datagram.. Ak je táto hodnota prekročená celkový výsledok podmienky je označený za chybný. [ ] [stillalive&!response&!connection] [stillaliveresponse] 50 [ ] [stillalive&!response&!connection] [stillaliveresponse] 145 [ ] [stillalive&baseband&!handler!response&connection] [stillaliveresponse] 4 Obrázok 5.26 Príklad zapísania viacerých podmienok v súbore Objasnenie významu podmienok Na obrázku 5.3 sú znázornené tri hlavné podmienky, ktoré budú vyhodnocované v log súbore. Vysvetlenie bude venované prvej z nich. Podmienka je chápaná nasledovne: Ak v log súbore bude nájdený datagram, ktorý má IP adresu odosielateľa alebo prijímateľa zhodnú s IP adresou definovanou v podmienke ( ), tak používateľské dáta sú kontrolované či vyhovujú podmienke (stillalive&!response&!connection). Ak vyhovujú tejto podmienke tak číslo a čas príchodu tohto datagramu sú uložené a je hľadaný datagram, ktorý 48

57 spĺňa podmienku IP adresy ( ) a podmienku (stillaliveresponse). Ak je nájdený takýto datagram jeho čas príchodu je odpočítaný od uloženého datagramu. Tento čas je porovnávaný s časom maximálneho oneskorenia (50). V prípade ak je tento čas menší je všetko v poriadku. V prípade ak je čas väčší než max. oneskorenie alebo sú nájdené dva datagramy, ktoré spĺňajú podmienku (stillalive&!response&!connection) a zároveň nemajú odpoveď je výsledok označený za chybný. Na obrázku 5.4 je znázornený výsledok analýzy a na obrázku 5.5 súhrn všetkých správne a nesprávne vyhodnotených datagramov pre každú podmienku. HLAVNA PODMIENKA 2 Paket: 8 Z IP adresy: S poodmienkou: [stillalive&!response&!connection] Paket: 10 Z IP adresy: S podmienkou [stillaliveresponse] Rozdiel = Dobre HLAVNA PODMIENKA 3 Paket: 9 Z IP adresy: S poodmienkou:[stillalive&baseband&!handler!response&connection] Paket: 11 Z IP adresy: S podmienkou [stillaliveresponse] Rozdiel = ZLE HLAVNA PODMIENKA 1 Paket: 12 Z IP adresy: S poodmienkou: [stillalive&!response&!connection] Paket: 13 Z IP adresy: S podmienkou [stillaliveresponse] Rozdiel = Dobre Obrázok 5.27 Výsledok analýzy pre jednotlivé podmienky a ich vyhodnotenie Podmienka 1 mala: 5 spravne vyhodnotenych paketov 2 casovo nespravne vyhodnotenych paketov na poziciach 15, 472, 1 paket ktoremu chybala odpoved na poziciach: 466, Podmienka 2 mala: 4 spravne vyhodnotenych paketov 0 casovo nespravne vyhodnotenych paketov na poziciach 2 paketov ktorym chybala odpoved na poziciach: 456, 478 Podmienka 2 mala: 4 spravne vyhodnotenych paketov 3 casovo nespravne vyhodnotenych paketov na poziciach: 11, 233, paketov ktorym chybala odpoved na poziciach: Obrázok 5.28 Súhrn správne a nesprávne vyhodnotených datagramov pre každú podmienku 49

58 Vzorová analýza Ako prvé si je potrebné zadefinovať podmienky, pre ktoré chceme aby bola analýza uskutočnená. Pre štruktúru podmienky viď kapitolu Tieto podmienky zapíšeme do poľa načítaných podmienok a stlačíme tlačidlo Ulozit. Otvoríme aplikáciu, v nastaveniach si môžme zadefinovať vlastné súbory pre výstup datagramov obsiahnutých v log súbore a pre výstup analyzovaných podmienok. Ak si tieto súbory nedefinujeme sú použité prednastavené: pakety.log a analyza.log. Vyberieme si log súbor pre analýzu. V prípade ak je analyzovaný súbor menší než 8MB výpis datagramov a splnených podmienok prebehne do poľa výpisu a taktiež do prislúchajúcich súborov. Ak je súbor väčší než 8MB do poľa výpisu sú zobrazené len splnené podmienky a datagramy sú vypísané len do súboru. Výsledky analýz sú zobrazené na obrázkoch 5.4 a 5.5. Podmienky, ktoré sú chybné sú odsadené, aby boli okamžite viditeľné. V prílohe číslo 5. sú zobrazené výstupy analýzy súboru komunikacia.ioa umiestneného na CD, ktoré je súčasťou prílohy číslo 7. Taktiež je tam možné nájsť súbor filterlog s podmienkami podľa ktorých bola analýza uskutočnená Možnosti rozšírenia aplikácie a znovu použitie tried Vytvorená aplikácia nie je určená k zachytávaniu datagramovej komunikácie medzi modulmi, ale k analýze už zachytených datagramov. Plne spĺňa požiadavky, ktoré boli stanovené v zadaní diplomovej práce: dokáže načítať súbor umiestnený na lokálnom alebo sieťovom disku. Má používateľské rozhranie, v ktorom si môže užívateľ definovať vlastné výstupné súbory do ktorých budú zaznamenávané výsledky analýzy. Môže si definovať filtračné podmienky, na základe ktorých budú zobrazené len tie datagramy, ktoré vyhovujú tejto podmienke. Ďalšou možnosťou ako analyzovať súbor je definovanie podmienok v textovom súbore, z ktorého budú načítané a v závislosti na nich uskutočnená analýza log súboru. V neposlednom rade veľkou výhodou tejto aplikácie je ľahká modifikovateľnosť programového kódu zabezpečená objektovo orientovaným prístupom a okomentovaním každej z metód. 50

59 Možnosti rozšírenia aplikácie Z hľadiska jej ďalšieho rozšírenia by bolo vhodné upraviť aplikáciu tak aby priamo odchytávala datagramovu komunikáciu v reálnom čase, dokázala by ju analyzovať podľa zadaných podmienky a vyhodnotiť. Týmto by bol ušetrený čas, ktorý je potrebný aplikácii na načítanie datagramov obsiahnutých v súbore. Tento čas pri súboroch veľkých niekoľko GB, môže byť až niekoľko hodín. Taktiež by bolo vhodné dopracovať komprimáciu zobrazovaného obsahu, aby bolo možné zobraziť väčšie súbory. Ďalej by bolo vhodné optimalizovať veľkosť zabraného miesta v operačnej pamäti a prístupu aplikácie na disk Znovu použitie tried Keďže pri implementácii aplikácie bol využitý objektovo orientovaný prístup programovania, boli vytvorené aj znova použiteľné triedy. Jednou z nich je trieda naplnpaket (viď príloha. č.4), v ktorej je definovaná väčšina základných vlastností datagramu (protokoly vrstiev, IP adresy). Je možné z nej čítať a zapisovať pomocou nastavovacích a čítacích metód. Zdrojový kód triedy naplnpaket je umiestnený prílohe č.4. Ďalšou triedou, ktorá je znovu použiteľná za určitých podmienok je trieda Linkova_A_Sietova. Táto trieda dekóduje jednotlivé položky datagramu ako sú: linkový protokol, veľkosť a čas príchodu datagramu, sieťový protokol a IP adresy. Výstupom triedy sú reťazce reprezentujúce jednotlivé položky. Vstupnými údajmi jednotlivých metód triedy sú polia typu integer, ktoré obsahujú načítané byty z log súboru. Taktiež ďalšie triedy je možné za určitých podmienok a po menších úpravách využiť pri implementácii iných podobných aplikácii. 51

60 6. Záver Ciele práce sú rozdelené do dvoch častí. Prvá časť je teoretická. Pojednáva o vybraných protokoloch spadajúcich pod jednotlivé vrstvy referenčného modelu a popisuje CORBA štandard. Druhá časť je praktická. Táto popisuje vytvorenú aplikáciu, ktorá analyzuje datagramovu komunikáciu. Protokol linkovej vrstvy HDLC bol základ, na ktorom bol postavený protokol PPP, ktorý je využívaný ako protokol pre prístup do internetu. Protokol IP je pevným základom, na ktorom sú postavené terajšie siete. Jeho verzia číslo 4 pre nedostatok adries začína byť pomaly nahradzovaná verziou 6, ktorá prináša nové prvky ako podporu mobility, lepšiu kvalitu služby, atď. S nástupom poskytovania hlasových služieb založených na IP protokole začína byť väčšmi využívaný transportný protokol UDP, ktorý nekladie také veľké výpočtové nároky na užívateľské zariadenia. TCP protokol je využívaný v službách, ktoré vyžadujú vytvorenie spojenia a poskytuje vyššiu kvalitu služby než UDP. Protokol GIOP sa taktiež začína dostávať do popredia ako sprostredkovateľ prenosu medzi objektmi distribuovaných systémov v architektúre CORBA. FTP je veľmi rozšíreným protokol pre prenos súborov avšak neposkytuje zabezpečenie mena a hesla a preto je lepšie použiť jeho zabezpečenú formu SFTP (Secure FTP). Vytvorená aplikácia má jednoduché používateľské rozhranie a umožňuje zobrazenie jednotlivých datagramov, z ktorých sa skladá log súbor. Je možné filtrovať zobrazené datagramy zadaním reťazca do príslušného poľa. Ďalej je možné definovať podmienky, ktoré spĺňujú predpísaný formát a na základe nich vykonať analýzu log súboru. Pri implementácii bola vytvorená univerzálna trieda naplnpaket, ktorá má vlastnosti komunikačného datagramu a taktiež je jednoducho doplniteľná o nové možnosti. Táto trieda môže byť využitá pri vývoji podobných aplikácií. 52

61 7. Zoznam použitej literatúry: [1] Blunár K., Diviš Z.: Telekomunikačné siete, EDIS, Žilina, 2000 [2] Dostálek L., Kabelová A..: Velký průvodce protokoly TCP/IP a systémem DNS, Computer Press, Praha, ISBN [3] Point- to Point Protocol.[online].April [cit ]. Dostupné na internete: [4] The Point-to-Point Protocol (PPP). [online]. Jul [cit ]. Dostupné na internete: [5] The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links. [online]. Maj [cit ]. Dostupné na internete: [6] INTERNET PROTOCOL. [online]. September [cit ]. Dostupné na internete: [7] Internet Protocol, Version 6 (IPv6) Specification. [online]. December [cit ]. Dostupné na internete: [8] IPv6 Datagram Main Header Format. [online]. September [cit ]. Dostupné na internete: [9] FILE TRANSFER PROTOCOL (FTP). [online]. Oktober [cit ]. Dostupné na internete: 53

62 [10] TCP/IP komunikácia (server/klient) v OS Linux. [online]. Februar [cit ]. Dostupné na internete: [11] CORBA a distribuované systémy - Andrew S. Tanenbaum, Maarten van Steen.: Distributed Systems: Principles and Paradigms, Prentice-Hall, 2002, ISBN: [12] Common Object Request Broker Architecture: Core Specification. [online]. Marec [cit ]. Dostupné na internete: 12.pdf. [13] CORBA BASICS. [online]. Marec [cit ]. Dostupné na internete: [14] Rastaocny K.,Objektovo Orientované Modelovanie Podklady pre prednasky s predmetu systemy s vysokou integritou [cit ]. Dostupné na internete: [15] UML 2.1 Tutorial. [online]. Oktober [ ]. Dostupné na internete: 54

63 Čestné vyhlásenie Prehlasujem, že som zadanú diplomovú prácu vypracoval samostatne, pod odborným vedením vedúceho diplomovej práce Ing. Vladimíra Pšenáka a používal som len literatúru v práci uvedenú. Súhlasím so zapožičiavaním diplomovej práce. V Žiline, dňa: podpis diplomanta

64 Poďakovanie Touto cestou chcem poďakovať, všetkým ktorí mi pri tvorbe diplomovej práce pomohli, hlavne vedúcemu diplomovej práce Ing. Vladimírovi Pšenákovi za jeho cenné rady, pripomienky, dôležité informácie a pomoc pri vypracovaní diplomovej práce. Veľká vďaka patrí taktiež mojím rodičom za ich veľkú podporu a porozumenie počas celého štúdiu. Ešte raz Ďakujem.

65 Žilinská univerzita v Žiline Elektrotechnická fakulta Katedra telekomunikácií Aplikácia pre analýzu a spracovanie základných typov protokolov komunikačných sietí Prílohová časť Bc. Michal Ptačin 2007

66 P1. Hexadecimálne hodnoty reprezentujúce protokoly skupiny 1, 2 a 3. P2. Rozširujúce hlavičky IP protokolu verzie 6. P3. Príklad analýzy log súboru. P4. Znovu použiteľná trieda naplnpaket. P5. Výstup analýzy pre súbor shortcom.ioa a podmienky, pre ktoré bola analýza vykonaná. P6. Zjednodušený diagram objektov aplikácie analyzujúcej log súbory s popisom jednotlivých objektov P7. CD obsahujúce aplikáciu, log súbor a súbor s podmienkami.

67 P 1. Hexadecimálne hodnoty reprezentujúce protokoly skupiny 1, 2 a 3. Hex. Hodnota Názov protokolu c021 Link Control Protocol (LCP) c023 Password Authentication Protocol (PAP) c025 Link Quality Report Challenge Handshake Authentication Protocol c223 (CHAP) Tabuľka 1. Hexadecimálne hodnoty reprezentujúce protokoly skupiny 1. Hexa Hodnota Názov kontrolného protokolu 8021 Internet Protocol Contr. Prot. OSI Network Layer Contr Prot Xerox NS IDP Contr.Prot DECnet Phase IV Contr. Prot Appletalk Contr. Prot. 802b Novell IPX Contr. Prot Banyan Vines Contr. Prot. 804d IBM SNA Contr. Prot IP V6 Contr. Prot. Tabuľka 2. Hexadecimálne hodnoty reprezentujúce protokoly skupiny 2

68 Hexa hodnota Názov protokolu 0021 Internet Protokol 0023 OSI Network Layer 0025 Xerox NS IDP 0027 DECnet Phase IV 0029 Appletalk 002b Novell IPX 0035 Banyan Vines 004d IBM SNA 0057 IP v 6 00ff Rezervované Tabuľka 3. Hexadecimálne hodnoty reprezentujúce protokoly skupiny 3

69 P2. Rozširujúce hlavičky IP protokolu verzie 6 Hex. Hodnota Dec. Hod. Protokol / Rozširujúca hlavička 0 0 Informácia pre smerovače (Hop-by-Hop) 1 1 ICMPv4 2 2 IGMPv4 4 4 IP v IP enkapsulácii 6 6 TCP 8 8 EGP UDP IPv6 2B 43 Smerovacia informácia (Routing ext.header) 2C 44 Záhlavie fragmentu (Fragm. Ext.header) 2E 46 Protokol RRP Bezpečnostná hlavička (Encaps. Security Header) Autentizačná hlavička (Authentiacation Header) 3A 58 Protokol ICMP 3B 59 Nenasleduje ďalšia hlavička 3C 60 Iná voľba

70 P.3 Príklad analýzy log súboru