Embed Size (px)
Citation preview
Aplikácia pre analýzu a spracovanie základných typovprotokolov komunikačných sietí
DIPLOMOVÁ PRÁCA
Bc. MICHAL PTAČIN
ŽILINSKÁ UNIVERZITA V ŽILINEElektrotechnická fakultaKatedra 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: 18. 5. 2007
ŽILINA 2007
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.
Ž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
Vedúci práce: Ing. Vladimír Pšenák
Recenzent práce :
Dátum odovzdania práce: 18.5.2007
OBSAH1. Úvod ..................................................................................................................................... 1 2. Referenčný model OSI (RM OSI) ......................................................................................... 2
2.1. Základné funkcie vrstiev RM OSI .................................................................................. 3 2.2. Popis a použitie vybraných protokolov jednotlivých vrstiev .......................................... 5
2.2.1.HDLC a PPP, protokoly linkovej vrstvy...................................................................52.2.2.IP, protokol sieťovej vrstvy.................................................................................... 112.2.3.TCP a UDP, protokoly transportnej vrstvy.............................................................172.2.4.FTP, protokol aplikačnej vrstvy..............................................................................23
3. UML (Unified Modeling Language) ................................................................................... 26 3.1. Diagramy UML ............................................................................................................. 27
3.1.1.Diagram tried ......................................................................................................... 283.1.2.Diagram objektov ...................................................................................................293.1.3.Diagram prípadov použitia..................................................................................... 303.1.4.Diagram stavov....................................................................................................... 313.1.5.Sekvenčný Diagram................................................................................................ 323.1.6.Diagram spolupráce................................................................................................ 333.1.7.Diagram aktivít....................................................................................................... 333.1.8.Diagram komponentov............................................................................................343.1.9.Diagram nasadenia..................................................................................................35
4. Distribuované objektové systémy ........................................................................................ 36 4.1. Základné črty a vlastnosti ............................................................................................. 36 4.2. CORBA ........................................................................................................................ 37
4.2.1.Štruktúra architektúry CORBA...............................................................................384.2.2.ORB (Object Request Broker)................................................................................ 404.2.3.IDL (Interface Definition Language)......................................................................404.2.4.DII (Dynamic Invocation Interface) a DSI (Dynamic Skeleton Interface).............404.2.5.GIOP (General Inter Orb Protocol).........................................................................414.2.6.IIOP (Internet Inter Orb Protocol).......................................................................... 424.2.7.Komunikácia v architektúre CORBA..................................................................... 42
5. Aplikácia pre analýzu log súborov ..................................................................................... 44 5.1. Používateľské rozhranie ............................................................................................... 44 5.2. Nastavenie a vzorová analýza ..................................................................................... 46
5.2.1.Analýza bez zadania filtračných podmienok.......................................................... 465.2.2.Analýza so zadanými filtračnými podmienkami.................................................... 475.2.3.Vzorová analýza .....................................................................................................50
5.3. Možnosti rozšírenia aplikácie a znovu použitie tried ................................................... 50 5.3.1.Možnosti rozšírenia aplikácie................................................................................. 515.3.2.Znovu použitie tried ...............................................................................................51
6. Záver .................................................................................................................................... 52
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]............................................ 16Tabuľka 2.2 Voliteľné položky [2].......................................................................................... 20Tabuľka 4.3 Správy protokolu GIOP vysielané klientom [12]................................................41Tabuľka 4.4 Správy protokolu GIOP vysielané serverom [12]............................................... 42Tabuľka 5.5 Štruktúra zadávania podmienok.......................................................................... 48
Obrázok 2.1 Vrstvy referenčného modelu OSI [1]....................................................................2Obrázok 2.2 Štruktúra rámca HDLC [2]....................................................................................6Obrázok 2.3 Štruktúra poľa I rámca [2].....................................................................................7Obrázok 2.4 Štruktúra poľa S rámca [2]....................................................................................7Obrázok 2.5 Pole U rámca [2]................................................................................................... 8Obrázok 2.6 Štruktúra rámca protokolu PPP [4]..................................................................... 10Obrázok 2.7 Štruktúra datagramu IP protokolu verzie 4. [6]................................................. 12Obrázok 2.8 Príznaky fragmentácie [2]................................................................................... 13Obrázok 2.9 Štruktúra datagramu IP protokolu verzie 6. [7].................................................. 15Obrázok 2.10 Štruktúra TCP segmentu [2]..............................................................................18Obrázok 2.11 Pole príznakov TCP segmentu [2].................................................................... 19Obrázok 2.12 Štruktúra UDP segmentu [2].............................................................................22Obrázok 3.13 Príklad použitia diagramu triedy [15]............................................................... 29Obrázok 3.14 Príklad použitia diagramu objektov [15]...........................................................30Obrázok 3.15 Príklad použitia diagramu prípadu použitia...................................................... 31Obrázok 3.16 Príklad použitia diagramu stavov [15].............................................................. 32Obrázok 3.17 Príklad použitia sekvenčného diagramu............................................................33Obrázok 3.18 Príklad diagramu spolupráce.............................................................................33Obrázok 3.19 Príklad diagramu aktivít [14]........................................................................... 34Obrázok 3.20 Príklad diagramu komponentov [14]................................................................ 34Obrázok 3.21 Príklad diagramu nasadenia [15].......................................................................35Obrázok 4.22 Moduly architektúry CORBA [11]................................................................... 38Obrázok 4.23 Volanie vzdialenej implementácie objektu [13].............................................. 42Obrázok 5.24 Užívateľské rozhranie aplikácie pre analýzu .log súborov............................... 45Obrázok 5.25 Príklad zadania podmienok............................................................................... 48Obrázok 5.26 Príklad zapísania viacerých podmienok v súbore............................................. 48 Obrázok 5.27 Výsledok analýzy pre jednotlivé podmienky a ich vyhodnotenie................... 49Obrázok 5.28 Súhrn správne a nesprávne vyhodnotených datagramov pre každú podmienku..................................................................................................................................................49
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 International Telephone and Telegraph Consultative Committee
Medzinárodná organizácia definujúca štandardy pre telefónne a telegrafické zariadenia
CORBA Common Object Request Broker Architecture
Prostriedok pre komunikáciu v distribuovanom heterogénnom prostredí
DCOM Distributed Component Object Model
Distribuovaný objektový model
DII Dynamic Invocation Interface Dynamické volanieDSI Dynamic Skeleton Interface Dynamicky vytvorená kostra
objektuDSL Digital Subscriber Line Digitálne účastnícke vedenieFDDI Fiber Distributed Data
InterfaceOptické distribuované dátové rozhranie
FTP File Transfer Protocol Protokol prenosu súborovGIOP General Inter ORB Protocol Všeobecný protokol zabezpečujúci
komunikáciu. medzi objektmi ORBHDLC High-Level Data Link Control Vysokoúrovňový protokol pre
riadenie dátového spojeniaHTTP Hypertext Transport Protocol Hypertextový prenosový protokolCHAP Challenge Handshake
Authentication ProtocolProtokol na overenie inicializačnej výzvy
ICMP Internet Control Message Protocol
Internetový kontrolný protokol, zasielajúci správy
IDL Interface Definition Language Jazyk pre definíciu rozhraniaIGMP Internet Group Management
ProtocolInternetový skupinový riadiaci protokol
IIOP Internet Inter-Orb Protocol Protokol zabezpečujúci komunikáciu. medzi objektmi ORB
internet protokolom
IP Internet Protocol Internetový protokolIPTV Internet Protocol Television Televízne vysielanie šírené internet
protokolomIPv6 Internet Protocol version 6 Internetový protokol verzia 6ISO International Organization for
StandardizationMedzinárodná organizácia pre štandardizáciu
ITUT International Telecommunications Union
Medzinárodná telekomunikačná únia
LAN Local Area Network Lokálna počítačová sieťLCP Link Control Protocol Linkový kontrolný protokolMAN 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ý protokolNetBIOS Network Basic Input/Output
SystemSystém firmy Microsoft umožňujúci pomenovanie zariadení v lokálnej sieti
NFS Network Filesystem Sieťový súborový systémOMG Object Management Group Zoskupenie objektovo -
orientovaných firiemORB Object Request Broker Sprostredkovateľ žiadostí objektuOSPF Open Shortest Path First Hierarchický smerovací algoritmusPAP Password Authentication
ProtocolProtokol overujúci pravosť hesla
PPP Point-to-Point Protocol Bod - bod protokolPPPoE PPP over Ethernet PPP cez EthernetQoS Quality of Service Kvalita službyRIP Routing Information Protocol Smerovací protokolRM OSI Reference Model Open
Systems InterconnectionReferenčný model pre prepojenie otvorených systémov
RMI Remote Method Invocation Vyvolanie vzdialenej metódyRTP Real-time Transport Protocol Protokol pre. prenos dát v reálnom
časeSDP Session Description Protocol Spojenie popisujúci protokol
SFTP Secure File Transfer ProtocolZabezpeč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 protokolTTL Time To Live Zostávajúca doba života datagramuUDP User Datagram Protocol Protokol pre datagramovú obsluhuUML Unified Modeling Language Zjednotený modelovací jazykUMTS Universal Mobile
Telecommunications SystemUniverzá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
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
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 BAplikačná vrstva <———> Aplikačná vrstva
Prezentačná vrstva <———> Prezentačná vrstvaRelačná vrstva <———> Relačná vrstva
Transportná vrstva <———> Transportná vrstvaSieťová vrstva <———> Sieťová vrstvaLinková vrstva <———> Linková vrstva Fyzická vrstva <———> Fyzická vrstva
Prenosové médiumObrá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
2.1. Základné funkcie vrstiev RM OSI
Fyzická vrstvaTá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á vrstvaZaisť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, 802.11 (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
protokol ICMP(Internet Control Message Protocol), riadiaci protokol IGMP (Internet Group
Management Protocol) a konvertujúci protokol ARP(Address Resolution Protocol) .
Transportná vrstvaTá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á vrstvaTato 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
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á vrstvaPomocou 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).
2.2. 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.
2.2.1. HDLC a PPP, protokoly linkovej vrstvy
HDLC (High-Level Data Link Control) protokolHDLC 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
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 F8 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
01111110 (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 01111110 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
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.
7 6 5 4 3 2 1 0 bitN (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.
7 6 5 4 3 2 1 0 bitN (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
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.
7 6 5 4 3 2 1 0 bitM 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
o DISC (Diconnect) - Požiadavka na ukončenie logického spojenia
o DM (Disconnect Mod) - Pozitívne potvrdenie príkazu DISC
o 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.
o 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
F A C P I FCS F1 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 11111111, č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 00000011
(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 8 - - - do b - - - , a určujú prislúchajúci kontrolný protokol sieťovej vrstvy NCP (Network
Control Protocol). Hodnoty v rozsahu od 0 - - - do 3 - - - ) 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 6 – 0057 [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
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í (0 – 1500 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.
2.2.2. 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
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 4 294 967 296 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.
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
Vers.4 bity
IHL 4 bity
Type of servis 8 bitov
Identification of IP- datagram 16 bitov
Total length16 bitov
Flags3 bity
TTL8 bitov
Protocol8 bitov
Header checksum16 bitov
Fragment offset 13 bitov
Source Address 32 bitov
Destination Address32 bitov
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 65535
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.
01bit
DF1bit
MF1bit
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
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
IPv4, ktorý podporuje „iba“ 4 miliardy (4×109) adries, zatiaľ, čo IPv6 podporuje až približne
3.4×1038 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 .
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 2.1 .
15
Traffic Class 8bitov Flow Label 20bitov
Hop Limit 8bitovNext Header 8bitovPayload Length 16bitov
Source Address 128 bitov
Destination Address 128bitov
Vers. 4bity
Kat. Klasifikácia dát0 nešpecifikované dáta1 prevádzka v pozadí (správy)2 automatická prevádzka (email)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 časeTabuľ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 65 535 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
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.
2.2.3. 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 2.10.
17
Options (optional)
Data
Obrázok 2.10 Štruktúra TCP segmentu [2]
Popis polí TCP segmentu
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
Sequence Number 32 bitov
Acknowledgment Number 32 bitov
Window16 bitov
Destination Port 16 bitovSource Port 16 bitov
Checksum 16 bitov Urgent Pointer 16 bitov
Reser. 4 bity
Data Off.4 bity
Flags8 bitov
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)
1 1 1 1 1 1 1 1 bitCWR 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
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 Popis0 1 Koniec voliteľných položiek1 1 Prázdny príkaz2 4 Max. veľkosť segmentu3 3 Činiteľ zmeny veľkosti okna4 2 Zákaz odstránenia5 premenná Odstrániť6 6 Echo7 6 Odpoveď na Echo8 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
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
• 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
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.
2.2.4. 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á email 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
Length 16 bitov Checksum 16 bitov
Destination Port 16 bitovSource Port 16 bitov
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ž
1023. 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
• 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
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
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 2.1.1.
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
• 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.
3.1.1. 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
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]
3.1.2. 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
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]
3.1.3. 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
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.
3.1.4. 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
Obrázok 3.16 Príklad použitia diagramu stavov [15]
3.1.5. 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
Obrázok 3.17 Príklad použitia sekvenčného diagramu
3.1.6. 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
3.1.7. 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
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]
3.1.8. 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
3.1.9. 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
4. Distribuované objektové systémyV 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).
4.1. 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
• Polymorfizmus a dedičnosť – možnosť využívať služby špecializovaných
objektov neznámych v čase prekladu.
4.2. 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
Nevýhody použitia architektúry CORBA:
• vysoké ceny pri vývoji, ktoré sú niekedy spôsobené licenčnými podmienkami
[13]
4.2.1. Š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
• 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
4.2.2. 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.
4.2.3. 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].
4.2.4. 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
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].
4.2.5. 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 :
KlientFormát správy Popis správy
Request vyvolanie metódy vzdialeného objektuCancel Request zrušenie predchádzajúcej požiadavky Locate Request zaistenie umiestnenia vzdialeného objektuMessage 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
ServerFormát správy Popis správy
Reply výsledok vyvolaniaLocate Reply indikuje, či server implementuje objekt, alebo predá volanie ďalej
Close Connection ukončenie spojeniaMessage 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]
4.2.6. 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].
4.2.7. 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
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
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 č.6.
5.1. 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
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
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.
5.2. 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
5.2.1. 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
• 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.
5.2.2. 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
Odos/Prijim
1.Datagram
PODMIENKA
2. Datagram
PODMIENKA Max. oneskorenie [ms]
47
Tabuľka 5.5 Štruktúra zadávania podmienok
[172.16.0.16] [stillAlive&!Response&!connection] [stillAliveResponse] 50Obrá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ý.
Obrázok 5.26 Príklad zapísania viacerých podmienok v súboreObjasnenie 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 (172.16.0.16) , 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
[172.16.0.16] [stillAlive&!Response&!connection] [stillAliveResponse] 50[172.16.0.6] [stillAlive&!Response&!connection] [stillAliveResponse] 145[172.16.0.7] [stillAlive&BaseBand&!Handler|!Response&connection] [stillAliveResponse] 4
spĺňa podmienku IP adresy (172.16.0.16) 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.
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, 478Podmienka 2 mala: 4 spravne vyhodnotenych paketov 3 casovo nespravne vyhodnotenych paketov na poziciach: 11, 233, 345 0 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
HLAVNA PODMIENKA 2Paket: 8 Z IP adresy: 172.16.0.6 S poodmienkou: [stillAlive&!Response&!connection]Paket: 10 Z IP adresy: 172.16.0.1 S podmienkou [stillAliveResponse] Rozdiel = 3.96299362 Dobre
HLAVNA PODMIENKA 3 Paket: 9 Z IP adresy: 172.16.0.7 S poodmienkou:[stillAlive&BaseBand&!Handler|!Response&connection] Paket: 11 Z IP adresy: 172.16.0.1 S podmienkou [stillAliveResponse] Rozdiel = 4.17304039 ZLE
HLAVNA PODMIENKA 1Paket: 12 Z IP adresy: 172.16.0.16 S poodmienkou: [stillAlive&!Response&!connection]Paket: 13 Z IP adresy: 172.16.0.1 S podmienkou [stillAliveResponse] Rozdiel = 1.09195709 Dobre
5.2.3. 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 5.2.2. 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á.
5.3. 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
5.3.1. 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..
5.3.2. 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
6. ZáverCiele 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
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, 2000 . ISBN 80-7226-193-2
[3] Point- to – Point Protocol.[online] .April 2007. [cit. 14-12-2006]. Dostupné na internete:
http://en.wikipedia.org/wiki/Point-to-Point_Protocol .
[4] The Point-to-Point Protocol (PPP). [online]. Jul 1994. [cit. 14-12-2006]. Dostupné na
internete: http://www.ietf.org/rfc/rfc1661.
[5] The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over
Point-to-Point Links. [online]. Maj 1992. [cit. 15-12-2006]. Dostupné na internete:
http://www.ietf.org/rfc/rfc1331.txt.
[6] INTERNET PROTOCOL. [online]. September 1981. [cit 3-1-2007]. Dostupné na
internete: http://www.ietf.org/rfc/rfc791.txt.
[7] Internet Protocol, Version 6 (IPv6) Specification. [online]. December 1998. [cit 5-1-
2007]. Dostupné na internete: http://www.ietf.org/rfc/rfc2460.txt.
[8] IPv6 Datagram Main Header Format. [online]. September 2005. [cit. 11-1-2007].
Dostupné na internete:
http://www.tcpipguide.com/free/t_IPv6DatagramMainHeaderFormat-2.htm.
[9] FILE TRANSFER PROTOCOL (FTP). [online]. Oktober 1994. [cit. 21-1-2007].
Dostupné na internete: http://www.w3.org/Protocols/rfc959/4_FileTransfer.html.
53
[10] TCP/IP komunikácia (server/klient) v OS Linux. [online]. Februar 2004. [cit. 30-1-
2007]. Dostupné na internete: http://www.flatulent.szm.sk/linux/ine.html .
[11] CORBA a distribuované systémy - Andrew S. Tanenbaum, Maarten van Steen.:
Distributed Systems: Principles and Paradigms, Prentice-Hall, 2002, ISBN: 0-13-
088893-8
[12] Common Object Request Broker Architecture: Core Specification. [online]. Marec
2004. [cit 23-3-2007]. Dostupné na internete: http://www.omg.org/docs/formal/04-03-
12.pdf .
[13] CORBA BASICS. [online]. Marec 2007. [cit 23-3-2007]. Dostupné na internete:
http://www.omg.org/gettingstarted/corbafaq.htm#WhatIsIt .
[14] Rastaocny K.,Objektovo Orientované Modelovanie – Podklady pre prednasky
s predmetu systemy s vysokou integritou. 2003. [cit 2-4-2007]. Dostupné na internete:
http://fel.uniza.sk/kris/4_rocnik/F_OOM_UML.pdf .
[15] UML 2.1 Tutorial. [online]. Oktober 2006. [15-4-2007]. Dostupné na internete:
http://www.sparxsystems.com.au/resources/uml2_tutorial/index.html .
54
Č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: 18.5.2007 .................................
podpis diplomanta
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.
Žilinská univerzita v ŽilineElektrotechnická fakultaKatedra 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
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.
P 1. Hexadecimálne hodnoty reprezentujúce protokoly skupiny 1 , 2 a 3.
Hex. Hodnota Názov protokoluc021 Link Control Protocol (LCP)c023 Password Authentication Protocol (PAP)c025 Link Quality Report
c223
Challenge Handshake Authentication Protocol
(CHAP)Tabuľka 1. Hexadecimálne hodnoty reprezentujúce protokoly skupiny 1.
Hexa
Hodnota Názov kontrolného protokolu8021 Internet Protocol Contr. Prot.
8023
OSI Network Layer Contr.
Prot.8025 Xerox NS IDP Contr.Prot.8027 DECnet Phase IV Contr. Prot.8029 Appletalk Contr. Prot.802b Novell IPX Contr. Prot.8035 Banyan Vines Contr. Prot.804d IBM SNA Contr. Prot.8057 IP V6 Contr. Prot.
Tabuľka 2. Hexadecimálne hodnoty reprezentujúce protokoly skupiny 2
Hexa
hodnota Názov protokolu0021 Internet Protokol0023 OSI Network Layer0025 Xerox NS IDP0027 DECnet Phase IV0029 Appletalk002b Novell IPX0035 Banyan Vines004d IBM SNA0057 IP v 600ff Rezervované
Tabuľka 3. Hexadecimálne hodnoty reprezentujúce protokoly skupiny 3
P2. Rozširujúce hlavičky IP protokolu verzie 6
Hex. Hodnota Dec. Hod. Protokol / Rozširujúca hlavička0 0 Informácia pre smerovače (Hop-by-Hop)1 1 ICMPv42 2 IGMPv44 4 IP v IP enkapsulácii6 6 TCP8 8 EGP11 17 UDP29 41 IPv62B 43 Smerovacia informácia (Routing ext.header)2C 44 Záhlavie fragmentu (Fragm. Ext.header)2E 46 Protokol RRP32 50 Bezpečnostná hlavička (Encaps. Security Header)33 51 Autentizačná hlavička (Authentiacation Header)3A 58 Protokol ICMP3B 59 Nenasleduje ďalšia hlavička3C 60 Iná voľba
P.3 Príklad analýzy log súboru
P4. Znovu použiteľná trieda naplnPaket
public class NaplnPaket {
/* vlastnosti objektu */
private int cisloPaketu;
private String prot2Vrstva;
private double absolutTime;
private int velkostPaketu;
private String prot3Vrstva;
private String ipAdresOdos = "";
private String ipAdresPri = "";
private String prot4Vrstva = "";
private String prot7Vrstva = "";
private String uzivatelData;
public NaplnPaket(int cisloPaketu, String prot2Vrstva, double absolutTime,
int velkostPaketu, String prot3Vrstva, String ipAdresOdos,
String ipAdresPri, String prot4Vrstva, String prot7Vrstva,
String uzivatelData) {
this.cisloPaketu = cisloPaketu;
this.prot2Vrstva = prot2Vrstva;
this.absolutTime = absolutTime;
this.velkostPaketu = velkostPaketu;
this.prot3Vrstva = prot3Vrstva;
this.ipAdresOdos = ipAdresOdos;
this.ipAdresPri = ipAdresPri;
this.prot4Vrstva = prot4Vrstva;
this.prot7Vrstva = prot7Vrstva;
this.uzivatelData = uzivatelData;
}
/* konstruktor prazdny */
public NaplnPaket() {
}
public void setCisloPaketu(int cisloPaketu) {
this.cisloPaketu = cisloPaketu;
}
public int getCisloPaketu() {
return this.cisloPaketu;
}
public void setProt2Vrstva(String prot2Vrstva) {
this.prot2Vrstva = prot2Vrstva;
}
public String getProt2Vrstva() {
return this.prot2Vrstva;
}
public void setAbsolutTime(double absolutTime) {
this.absolutTime = absolutTime;
}
public double getAbsolutTime() {
return this.absolutTime;
}
public void setVelkostPaketu(int velkostPaketu) {
this.velkostPaketu = velkostPaketu;
}
public int getVelkostPaketu() {
return this.velkostPaketu;
}
public void setProt3Vrstva(String prot3Vrstva) {
this.prot3Vrstva = prot3Vrstva;
}
public String getProt3Vrstva() {
return this.prot3Vrstva;
}
public void setIpAdresOdos(String ipAdresOdos) {
this.ipAdresOdos = ipAdresOdos;
}
public String getIpAdresOdos() {
return this.ipAdresOdos;
}
public void setIpAdresPri(String ipAdresPri) {
this.ipAdresPri = ipAdresPri;
}
public String getIpAdresPri() {
return this.ipAdresPri;
}
public void setProt4Vrstva(String prot4Vrstva) {
this.prot4Vrstva = prot4Vrstva;
}
public String getProt4Vrstva() {
return this.prot4Vrstva;
}
public void setProt7Vrstva(String prot7Vrstva) {
this.prot7Vrstva = prot7Vrstva;
}
public String getProt7Vrstva() {
return this.prot7Vrstva;
}
public void setUzivatelData(String uzivatelData) {
this.uzivatelData = uzivatelData;
}
public String getUzivatelData() {
return this.uzivatelData;
}
}
P 5. Výstup analýzy pre súbor shortCom.ioa a podmienky, pre ktoré bola analýza vykonaná
Súbor bol vyhodnocovaný vzhľadom na nasledujúce podmienky:
Vysledok analyzyHLAVNA PODMIENKA 2
Paket: 2 Z IP adresy: 172.16.0.6 S poodmienkou: [stillAlive&!Response&!connection]
Paket: 4 Z IP adresy: 172.16.0.1 S podmienkou [stillAliveResponse] Rozdiel = 4.3 Dobre
HLAVNA PODMIENKA 3
Paket: 3 Z IP adresy: 172.16.0.7 S poodmienkou: [stillAlive&BaseBand&!Handler|!Response&connection]
Paket: 5 Z IP adresy: 172.16.0.1 S podmienkou [stillAliveResponse] Rozdiel = 4.1 Dobre
HLAVNA PODMIENKA 1
Paket: 6 Z IP adresy: 172.16.0.16 S poodmienkou: [stillAlive&!Response&!connection]
Paket: 7 Z IP adresy: 172.16.0.1 S podmienkou [stillAliveResponse] Rozdiel = 1.0001 Dobre
HLAVNA PODMIENKA 2
Paket: 8 Z IP adresy: 172.16.0.6 S poodmienkou: [stillAlive&!Response&!connection]
Paket: 10 Z IP adresy: 172.16.0.1 S podmienkou [stillAliveResponse] Rozdiel = 3.9001 Dobre
HLAVNA PODMIENKA 3
Paket: 9 Z IP adresy: 172.16.0.7 S poodmienkou: [stillAlive&BaseBand&!Handler|!Response&connection]
Paket: 11 Z IP adresy: 172.16.0.1 S podmienkou [stillAliveResponse] Rozdiel = 4.1 Dobre
HLAVNA PODMIENKA 1
Paket: 12 Z IP adresy: 172.16.0.16 S poodmienkou: [stillAlive&!Response&!connection]
Paket: 13 Z IP adresy: 172.16.0.1 S podmienkou [stillAliveResponse] Rozdiel = 1.1001 Dobre
HLAVNA PODMIENKA 2
Paket: 15 Z IP adresy: 172.16.0.6 S poodmienkou: [stillAlive&!Response&!connection]
Paket: 17 Z IP adresy: 172.16.0.1 S podmienkou [stillAliveResponse] Rozdiel = 4.1001 Dobre
HLAVNA PODMIENKA 3
Paket: 16 Z IP adresy: 172.16.0.7 S poodmienkou: [stillAlive&BaseBand&!Handler|!
Response&connection]
Paket: 18 Z IP adresy: 172.16.0.1 S podmienkou [stillAliveResponse] Rozdiel = 4.2001 Zle
HLAVNA PODMIENKA 1
[172.16.0.16] [stillAlive&!Response&!connection] [stillAliveResponse] 5
[172.16.0.6] [stillAlive&!Response&!connection] [stillAliveResponse] 10[172.16.0.7] [stillAlive&BaseBand&!Handler|!Response&connection] [stillAliveResponse] 4.1
Paket: 24 Z IP adresy: 172.16.0.16 S poodmienkou: [stillAlive&!Response&!connection]
Paket: 25 Z IP adresy: 172.16.0.1 S podmienkou [stillAliveResponse] Rozdiel = 1.1001 Dobre
HLAVNA PODMIENKA 2
Paket: 31 Z IP adresy: 172.16.0.6 S poodmienkou: [stillAlive&!Response&!connection]
Paket: 33 Z IP adresy: 172.16.0.1 S podmienkou [stillAliveResponse] Rozdiel = 4.2001 Dobre
HLAVNA PODMIENKA 3
Paket: 32 Z IP adresy: 172.16.0.7 S poodmienkou: [stillAlive&BaseBand&!Handler|!
Response&connection]
Paket: 34 Z IP adresy: 172.16.0.1 S podmienkou [stillAliveResponse] Rozdiel = 4.4 Zle
------------------------------------------------------------------------------------
Sumár vyhodnocovaných podmienok
Podmienka 1 mala:
3 spravne vyhodnotenych paketov
0 casovo nespravne vyhodnotenych paketov na poziciach
0 paketov ktorym chybala odpoved na poziciach:
Podmienka 2 mala:
4 spravne vyhodnotenych paketov
0 casovo nespravne vyhodnotenych paketov na poziciach
0 paketov ktorym chybala odpoved na poziciach:
Podmienka 3 mala:
2 spravne vyhodnotenych paketov
2 casovo nespravne vyhodnotenych paketov na poziciach 18 , 34 ,
0 paketov ktorym chybala odpoved na poziciach:
P6. Zjednodušený diagram objektov aplikácie analyzujúcej log súbory s popisom
jednotlivých objektov
Popis objektov
GuiBean – rozhranie interagujúce s používateľom. Obsahuje tlačidlá, nadpisy, polia výpisu.
Analýza – výkonné jadro aplikácie, do ktorého vstupujú požiadavky používateľa,
analyzovaný súbor a podmienky pre filtráciu. Aplikácia na základe týchto
vstupov analyzuje log súbor. Výstupy aplikácie sú zobrazené v GuiBean
a zapísané do výstupných súborov pakety a analyza.
Log Súbor – analyzovaný súbor
flterLog – súbor obsahujúci podmienky filtrácie
pakety – výstupný súbor, do ktorého sú zapísané datagramy obsiahnuté v log súbore
analyza – výstupný súbor, do ktorého sú zapísané výsledky analýzy na základe
podmienok zo súboru filterLog.
![Diplomová práca - iam.fmph.uniba.sk€¦ · BRESTENSKÝ, Róbert: Matematické modelovanie popálenín kože [Diplomová práca]. Univerzita Komenského v Bratislave, Mlynská dolina,](https://img.pdfslide.tips/doc/110x75/5f096e827e708231d426ced1/diplomov-prca-iamfmphunibask-brestensk-rbert-matematick-modelovanie.jpg)
