Žilinská univerzita v Žiline Elektrotechnická fakulta Katedra telekomunikácií. Programy pre komunikáciu v sieti ITKR.

Žilinská univerzita v Žiline Elektrotechnická fakulta Katedra telekomunikácií Programy pre komunikáciu v sieti ITKR Miroslav Markovič 2007

Programy pre komunikáciu v sieti ITKR DIPLOMOVÁ PRÁCA MIROSLAV MARKOVIČ ŽILINSKÁ UNIVERZITA V ŽILINE Elektrotechnická fakulta Katedra telekomunikácií Študijný odbor: TELEKOMUNIKÁCIE Vedúci diplomovej práce: doc. Ing. Ladislav Schwartz, PhD. Stupeň kvalifikácie: inžinier (Ing.) Dátum odovzdania diplomovej práce: 18.05.2007 ŽILINA 2007

ANOTAČNÝ ZÁZNAM ŽILINSKÁ UNIVERZITA V ŽILINE, ELEKTROTECHNICKÁ FAKULTA KATEDRA TELEKOMUNIKÁCIÍ ANOTAČNÝ ZÁZNAM DIPLOMOVÁ PRÁCA Meno a priezvisko: Miroslav Markovič Akademický rok: 2006/2007 Názov práce: Programy pre komunikáciu v sieti ITKR ELEKTROTECHNICKÁ FAKULTA KATEDRA TELEKOMUNIKÁCIÍ Počet strán: 36 Počet obrázkov: 29 Počet tabuliek: 3 Počet grafov: 0 Počet príloh: 16 Počet použ. lit.: 13 Anotácia v slovenskom jazyku: Diplomová práca sa zaoberá návrhom programového vybavenia pre komunikáciu v sieti ITKR. Programové vybavenie riadiaceho centra RCDS slúži ako server pre všetky užívateľské stanice EUB. Komunikácia prebieha v smere RCDS k EUB (výzva) a od EUB k RCDS (odpoveď). Prístupová metóda je zmenená s CSMA/CD na centralizované riadenie. RCDS sa skladá s databázy PostgreSql a komunikačného programu naprogramovaného v JAVE. EUB obsahuje len program napísaný v programovacom jazyku JAVA. Anotácia v anglickom (nemeckom) jazyku: Diploma work consist from suggestion of programmatic for communication in net ITKR. Programmatic consist from central management RCDS, which serve as server for all users station EUB. Communication is run direction from RCDS (call) to EUB (response). Media Access was change from CSMA/CD to centralize management. RCDS consist from database PostgreSql and communication program programmed in JAVA. EUB consist only from communication program programmed in JAVA. ŽILINSKÁ UNIVERZITA V ŽILINE I

ANOTAČNÝ ZÁZNAM Kľúčové slová: ITKR, komunikácia, UDP, JAVA, socket, centralizované riadenie, databáza, PostgreSql Vedúci diplomovej práce: doc. Ing. Ladislav Schwartz, PhD. Recenzent: Ing. Peter Kortiš, PhD. Dátum odovzdania práce: 18. máj 2007 ŽILINSKÁ UNIVERZITA V ŽILINE I

OBSAH OBSAH Anotačný záznam Diplomová práca... I Obsah...IVI Zoznam obrázkov a tabuliek...iii Zoznam príloh... IV Zoznam skratiek a symbolov...iii Slovník pojmov... VI Poďakovanie...VII 1 Úvod... 1 2 Cieľ riešení... 1 3 Jadro diplomovej práce... 2 3.1 Teoretická časť... 2 3.1.1 OSI model... 2 3.1.2 User Datagram Protocol (UDP)... 3 3.1.3 Porty v UDP... 5 3.1.4 IPv4... 5 3.1.5 IPv6... 6 3.1.6 CSMA/CD... 7 3.1.7 Ethernet... 8 3.1.8 Centralizované riadenie... 9 3.1.9 JAVA... 9 3.1.10 ITKR... 10 3.2 Riešenie diplomovej práce... 11 3.2.1 Navrhnuté riešenie centralizovaného riadenia pre ITKR... 11 3.2.2 Formát riadiacej hlavičky... 12 3.2.3 Riadenie EUB pomocou RCDS... 15 3.2.4 Prenos dát v sieti ITKR EUB -> RCDS... 17 3.2.5 Prenos dát v sieti ITKR EUB->RCDS->EUB... 18 3.2.6 Výpočet hodnôt pre pole Control v hlavičke centralizovaného riadenia.. 19 3.2.7 Prideľovanie priority... 19 3.2.8 Popis vývojového diagramu SpustiClient.java (EUB)... 20 3.2.9 Popis vývojového diagramu Spusti.java... 21 3.2.10 Popis vývojového diagramu SendServer.java... 22 3.2.11 Popis vývojového diagramu pre Zoznam.java... 23 3.2.12 Popis vývojového diagramu pre metódu setiptime v triede Zoznam.java23 3.2.13 Popis vývojového diagramu pre metódu OverExistenciu... 23 3.2.14 Popis vývojového diagramu Control.java... 23 3.2.15 Popis vývojového diagramu pre metódu IntToByte... 24 3.2.16 Popis vývojového diagramu pre metódu ByteToInt... 25 3.2.17 Popis vývojového diagramu pre metódu setssp... 25 3.2.18 Popis vývojového diagramu pre metódu setsdp... 25 3.2.19 Popis vývojového diagramu pre metódu setl... 25 3.2.20 Popis vývojového diagramu pre metódu setc... 26 3.2.21 Popis vývojového diagramu metódy setcrc... 26 3.2.22 Popis vývojového diagramu metódy Overenie... 26 3.2.23 Popis vývojového diagramu metódy setheader... 27 ŽILINSKÁ UNIVERZITA V ŽILINE II

OBSAH 3.2.24 Popis vývojového diagramu metódy setheaderdata... 27 3.2.25 Popis ovládania server aplikácie... 27 3.2.26 Inštalácia programového vybavenia pre RCDS... 31 3.2.27 Inštalácia programového vybavenia pre EUB... 32 4 Technicko-ekonomické zhodnotenie... 32 5 Záver... 34 Použitá literatúra... 35 ŽILINSKÁ UNIVERZITA V ŽILINE II

ZOZNAM OBRÁZKOV A TABULIEK ZOZNAM OBRÁZKOV A TABULIEK Obr. 1 Obr. 1.1 Obr. 1.2 Obr. 1.3 Obr. 1.4 Obr. 1.5a Obr. 1.5b Obr. 2.1 Obr. 2.2 Obr. 2.3 Obr. 2.4 Obr. 2.5 Obr. 2.6 Obr. 3.1a Obr. 3.1b Obr. 3.1c Obr. 3.2a Obr. 3.2b Obr. 3.3a Obr. 3.3b Obr. 3.4a Obr. 3.4b Obr. 3.5 Tab. č. 3.1 Obr. 3.7a Obr. 3.7b Obr. 3.8 Obr. 3.9 Obr. 3.10 Obr. 3.11 Tab. 5.1 Tab. 5.2 Enkapsulácia UDP hlavička Formát hlavičky IPv4 Formát hlavičky IPv6 Princíp CSMA /CD Štruktúra Ehternet framu Princíp centralizovaného riadenia Princíp zapojenia ITKR siete Formát riadiacej hlavičky Kombinácia možných formátov Štruktúra IP paketov v sieti ITKR a veľkosti hlavičiek Vkladanie bitov centralizovaného riadenia do IP paketu Príklad vyplnenia hlavičky centralizovaného riadenia Vysielanie príkazu F1V1 Neúspešný pokus prenosu F1V1, vyslanie F1V2 Neúspešný prenos F1V1,F2V2 pokračovanie na ďalšiu stanicu EUB prvá odpoveď F101 na výzvu F1V1 EUB druhá odpoveď F102 na výzvu F1V1 Odpoveď od EUB až na druhú výzvu F1V2 Výzva aj odpoveď až na druhý krát Prenos dát s EUB do RCDS (napr. príkaz pre SQL databázu) Opakovaný prenos dát s EUB do RCDS Princíp výmeny dát v sieti ITKR Pridelené hodnoty a ich označovanie Žiadosť o pridelenie priority a jej kladné vyhovenie Žiadosť o prioritu je zamietnuté Grafická aplikácia Server Grafické pozadie Server aplikácie pri chybnom zadaní IP adresy Ukážka chybne zadanej hodnoty oneskorenia Chybné zadanie počtu klientov a upozornenie na túto skutočnosť Rôzne varianty programového vybavenia Výpočet cien rôznych variantov ŽILINSKÁ UNIVERZITA V ŽILINE III

ZOZNAM PRÍLOH ZOZNAM PRÍLOH Vývojový diagram č. 1 Vývojový diagram k súboru Control.java Vývojový diagram č. 2 Vývojový diagram k metóde ByteToInt v Control.java Vývojový diagram č. 3 Vývojový diagram k metóde IntToByte v Control.java Vývojový diagram č. 4 Vývojový diagram k metóde Overenie v Control.java Vývojový diagram č. 5 Vývojový diagram k metóde setheader v Control.java Vývojový diagram č. 6 Vývojový diagram k metóde setheaderdata v Control.java Vývojový diagram č. 7 Vývojový diagram k súboru SendServer.java Vývojový diagram č. 8 Vývojový diagram k metóde setc v Control.java Vývojový diagram č. 9 Vývojový diagram k metóde setcrc v Control.java Vývojový diagram č. 10 Vývojový diagram k metóde setl v Control.java Vývojový diagram č. 11 Vývojový diagram k metóde setsdp v Control.java Vývojový diagram č. 12 Vývojový diagram k metóde setssp v Control.java Vývojový diagram č. 13 Vývojový diagram k súboru Spusticlient.java Vývojový diagram č. 14 Vývojový diagram k súboru Spusti.java Vývojový diagram č. 15 Vývojový diagram k súboru Zoznam.java Príloha č. 16 CD obsahujúce zdrojové kódy a spustiteľné programy ŽILINSKÁ UNIVERZITA V ŽILINE IV

ZOZNAM SKRATIEK A SYMBOLOV ZOZNAM SKRATIEK A SYMBOLOV IpTV Internet protocol television IP Internet protocol PC Personal computer VoIP Voice over IP TV Television VoD Video on demand RCDS Riadiace centrum domovej siete EUB Koncová používateľská stanica SDK Software Development Kit J2EE Java 2 Enterprise Edition CSMA/CD Carrier Sense Multiple Access With Collision Detection OSI Open Systems Interconnection Reference Model MAC Media Access Control LLC Logical Link Control TCP Transmission Control Protocol UDP User Datagram Protocol TCP/IP Transmision Control Protocol (TCP) a Internet Protocol (IP) SMTP Simple Mail Transfer Protocol FTP File Transfer Protocol NFS Network File System DNS Domain Name System SNMP Simple Network Management Protocol RTP Real-time Transport Protocol IANA Internet Assigned Numbers Authority IPv4 Internet Protocol version 4 IPv6 Internet Protocol version 6 ITKR Systémy pre interaktívne televízne káblové rozvody H-IP Hlavička IP paketu H-UDP Hlavička UDP paketu SSP Secondar Source Port SDP Secondar Destination Port ŽILINSKÁ UNIVERZITA V ŽILINE V

ZOZNAM SKRATIEK A SYMBOLOV C L Ch CRC16 SQL OS GUI Riadiace pole pre centralizované riadenie Dĺžka hlavičky centralizovaného riadenia aj dát Checksum Cyclic Redundancy Check Structured Query Language Operačný systém Graphical User Interface ŽILINSKÁ UNIVERZITA V ŽILINE V

SLOVNÍK POJMOV SLOVNÍK POJMOV IpTV Televízia cez Internet protokol IP Internetový protokol PC Osobní počítač VoIP Hlas cez Internetový protokol TV Televízia VoD Video na požiadanie RCDS Riadiace centrum domovej siete EUB Koncová používateľská stanica SDK Vývojový balík J2EE Java 2 Enterprise Edition CSMA/CD Kolízna prístupová metóda OSI Otvorený systém prepájania MAC Riadenie prístupu k médiu LLC Logická linková kontrola SMTP Jednoduchý protokol pre prenos mailov FTP Protokol prenosu súborov NFS Sieťový súborový systém SNMP Jednoduchý sieťový správcovský protokol IPv4 Internet Protocol verzia 4 IPv6 Internet Protocol verzia 6 ITKR Systémy pre interaktívne televízne káblové rozvody H-IP Hlavička IP paketu H-UDP Hlavička UDP paketu SSP Hlavička centralizovaného riadenia SDP Hlavička centralizovaného riadenia C Riadiace pole pre centralizované riadenie L Dĺžka hlavičky centralizovaného riadenia aj dát Ch Kontrolný súčet OS Operačný systém GUI Grafické užívateľské prostredie ŽILINSKÁ UNIVERZITA V ŽILINE VI

POĎAKOVANIE POĎAKOVANIE Rád by som sa poďakoval mojím rodičom a celej rodine, ktorý ma podporovali počas celého štúdia na vysokej škole. Taktiež by som rád poďakoval vedúcemu diplomovej práce doc. Ing. Ladislavovi Schwartzovi, PhD. Táto práca je riešená v rámci nasledujúcich výskumných úloh: 1. projekt VEGA číslo 1/2043/05 "Systémy pre interaktívnu káblovú televíziu - ITKR". ŽILINSKÁ UNIVERZITA V ŽILINE VII

1 ÚVOD Téma diplomovej práce je súčasťou projektu VEGA číslo 1/2043/05 "Systémy pre interaktívnu káblovú televíziu - ITKR". V súčasnosti sa nepoužíva žiadna technológia, ktorá by prenášala IpTV po káblových televíznych rozvodoch. Momentálne sa využíva prenos IP paketov spolu s analógovým obrazom. Toto je docielené tým, že celé spektrum, ktoré sa v minulosti používalo len na prenos video obrazu je rozdelené. Jedná časť prenáša obraz v analógovej forme a druhá prenos IP paketov. Na toto je potrebný prispôsobovací prvok, ktorý na strane siete zlúči na jeden prenosový kábel štandardný video obraz spolu s IP paketami. Na strane užívateľa je potrebný prvok, ktorý oddelí video signál od IP paketov. Tento prvok na strane užívateľa sa nazýva set-up box. Na prenos IP paketov po káblovej sieti je potrebný aj káblový modem, pomocou ktorého počítač komunikuje s iným PC v internete resp. serverom. V súčasnosti môžeme tiež pozorovať, že káblový operátori prevádzkujú okrem bežnej analógovej televízie a internetu aj novší produkt. Ide o VoIP cez káblové rozvody. Avšak TV obraz je stále analógový bez interaktívnych prvkov a bez možnosti výberu vlastného filmu resp. relácie. 2 CIEĽ RIEŠENÍ Cieľom tejto diplomovej práce je pridať interaktivitu do pasívnej televízie, ktorá sa prenáša cez káblové rozvody. Či už pôjde o VoD, hudbu na požiadanie, hlasovanie do rôznych relácii a pod. Ako vyplýva zo zadania mojou úlohou je napísať komunikačné programy, ktoré budú realizovať zadanú požiadavku. Ako programovací jazyk bola zvolená JAVA. Treba realizovať program ako pre RCDS tak aj pre EUB. RCDS sa tiež dá nazvať akoby serverom, na ktorom bude spustený vytvorený java program. Server ďalej bude obsahovať sieťovú kartu (Ethernet adaptér),rozhranie pre pripojenie na káblové televízne rozvody, operačný systém (Windows alebo Linux). Musí mať nainštalovaný databázový systém (PostgreSql) a samozrejme podporu Javi. EUB je koncová používateľská stanica. Táto musí obsahovať rozhranie pre pripojenie na káblové televízne rozvody, sieťovú kartu, ktorá sa bude pripájať do počítača (v prípade záujmu do rozbočovača alebo smerovača ak je v domácnosti viacero počítačov, ktoré sa budú pripájať do siete internet). Operačný systém Windows alebo Linux. Nainštalovaná ŽILINSKÁ UNIVERZITA V ŽILINE 1

podpora pre Java aplikácie a spustený vytvorený java program. Ako programové vybavenie pre naprogramovanie som si zvolil Eclipse a NetBeans. Tieto vývojové programy sú voľne šíriteľné. Ako SDK som zvolil J2EE. Aby bola zabezpečená kvalita služieb a priority musel som zmeniť prístupovú metódu s CSMA/CD, ktorá je štandardne používaná na ethernete, na metódu centralizovaných výziev. Takto môžeme zabezpečiť aj cez Ethernet, že každá stanica si bude môcť rezervovať dané pásmo pre svoje potreby, čo by cez CSMA/CD nebolo možné. 3 JADRO DIPLOMOVEJ PRÁCE 3.1 Teoretická časť 3.1.1 OSI model Používa sa ako opis návrhu štruktúry komunikačných a počítačových protokolov. Obsahuje 7 vrstiev [1]. Každá s týchto vrstiev plní svoju funkciu pričom môže využívať funkcie nižších vrstiev. Svoju funkciu naopak poskytuje vrstvám, ktoré sú nad ňou. Cieľom vytvorenia tohto modelu je, že celá štruktúra sa rozdelí do menších celkov. Každá časť sa následne navrhuje a vytvára samostatne. Nakoniec sa pospája a vytvorí sa tým fungovanie celej siete resp. systému. Výhodou tohto modelu je hlavne to, že každú vrstvu môže navrhnúť iná firma. Keď sa dodrží interpretovanie dát a rozhranie, ktoré komunikuje s touto vrstvou môžu ju využívať aj iné firmy. Vrstvy môžu byť interpretované hardvérovo, softvérovo alebo ich kombináciou. Spodné dve vrstvy sú obyčajne implementované hardvérovo. Ďalšie vrstvy sú implementované skôr softvérovo. 1. Fyzická vrstva do tejto vrstvy patria fyzické komponenty ako napr. káble, konektory. Táto vrstva tiež definuje elektrické a fyzikálne špecifikácie napr. moduláciu, riešenie konfliktov. Na tejto vrstve pracujú tiež sieťové prvky ako sú napr. huby a opakovače. Na fyzickej vrstve sa prenášajú bity. 2. Spojová vrstva zabezpečuje prenos dát t.j. ponúka vyššej vrstve logické spojenia kde je výskyt chyby veľmi malý. Adresovanie na tejto vrstve je pomocou fyzickej adresy MAC. Spojovacie protokoly na tejto vrstve môžu byť napr. HDLC, ADCCP alebo pre systém s prepínaním paketov LLC. Sieťové ŽILINSKÁ UNIVERZITA V ŽILINE 2

prvky, ktoré pracujú na tejto vrstve sú prepínače (switch) a bridge (mosty). Na spojovacej vrstve sa prenášajú rámce. 3. Sieťová vrstva umožňuje vytvoriť spojenie cez sieť, smerovanie, segmentáciu, kontrolu chýb. Na tejto vrstve je logické adresovanie napr. v IP sieťach je to IP adresa. Na sieťovej vrstve pracujú smerovače a prenášajú sa pakety. 4. Transportná vrstva vytvára, riadi spojenie a ukončuje (spojenia typu koniec koniec). Transparentný prenos dát medzi koncovými bodmi. Kvalitatívne parametre tejto vrstvi : - priepustnosť - oneskorenie - chybovosť Na tejto vrstve sa prenášajú segmenty. Protokoly TCP a UDP. 5. Relačná vrstva správa dialógu medzi aplikačnými procesmi. Duplexná alebo polo duplexná komunikácia. Relačná vrstva ukončuje a nadväzuje TCP/IP relácie. Prenášajú sa dáta. 6. Prezentačná vrstva syntaktická reprezentácia pre siedmu vrstvu. Rôzne kódovanie a kryptovanie. Prenášajú sa dáta. 7. Aplikačná vrstva rozhranie medzi užívateľom a ďalšími vrstvami. Úlohy aplikačnej vrstvy sú napr. prenos informácii, požiadavky na kvalitu služby. V TCP/IP sieťach http, SMTP, FTP, NFS protokoly a ďalšie. 3.1.2 User Datagram Protocol (UDP) UDP [2] sa nachádza na 4. vrstve OSI modelu t.j. na transportnej vrstve. Tento protokol nie je bezpečný t.j. nekontroluje či prijaté dáta boli prenesené správne alebo neboli. Z toho vypláva, že ho nemožno použiť na prenášanie dát. Používa sa na prenos videa v reálnom čase, VoIP. Možno ho použiť aj na prenos dát avšak kontrolu musí zabezpečiť aplikácia. Na rozdiel od TCP UDP nevytvára ani spojenie. Datagram sa vyšle a o viac sa nestará. Naproti týmto nevýhodám sa používa, v aplikáciách iného druhu ako na prenos dát bolo spomenuté vyššie. UDP hlavička obsahuje len min. informácii oproti TCP, a preto cez UDP sa prenesie viac informácii. ŽILINSKÁ UNIVERZITA V ŽILINE 3

Segment 4.vrstva UDP hlavička Dáta s aplikácie Paket 3. vrstva IP hlavička UDP hlavička Dáta s aplikácie Obr. 1 Enkapsulácia Z Obr. 1. je možné vidieť,že ku dátam sa pridáva UDP hlavička a tým sa vytvorí segment. Celý tento segment sa ďalej enkapsuluje (zapuzdruje) do paketu. Toto sa deje na 3. vrstve. K segmentu sa pridáva IP hlavička. Paket sa ďalej posiela do 2. vrstvy kde sa k nemu pridáva frame hlavička a tým vznikne frame. Frame sa posiela do 1.vrstvy, kde sa pridajú potrebné bity a spolu s framom sa posielajú do média. 0 7 15 23 31 zdrojový port cieľový port dĺžka kontrolná suma Dáta Obr. 1.1 UDP hlavička Z Obr. 1.1 je vidieť, že UDP paket sa skladá so zdrojového portu (číslo portu s ktorého sa datagram posiela), s cieľového portu (číslo portu na ktorý sa posiela datagram ), s dĺžky ( dĺžka celého datagramu hlavička + dáta ) a s kontrolnej sumy ( kontrolná suma je len pre UDP hlavičku nie pre dáta!!! ). UDP hlavička má len 8 bytov oproti 30, ktoré má TCP hlavička. UDP sa používa pri rôznych aplikáciách napr. DNS, SNMP, NFS a tiež je podporované audio a video prenos. Táto podpora je vďaka protokolu RTP, ktorý je nad UDP. ŽILINSKÁ UNIVERZITA V ŽILINE 4

3.1.3 Porty v UDP Za prideľovanie čísel portov zodpovedá organizácia IANA. Táto organizácia rozdelila porty do týchto skupín [3] : - 0 1023 známe porty - 1024 49151 registrované porty - 49152 65535 privátne alebo dynamické porty Dodržiavanie tohto rozdelenia je len odporúčanie t.j. niekedy sa môžeme stretnúť, že programy používajú porty, ktoré sú registrované inými spoločnosťami alebo programami. 3.1.4 IPv4 IPv4 [4] je 4. verzia, ktorá sa stala prvou široko používanou verziou. Táto sa používa dodnes. IPv4 používa 32 bitové adresy. Z toho vyplýva, že maximálny počet adries, ktoré je možné adresovať je 4 294 967 296. Z tohto počtu je však veľmi veľa vyhradených pre zvláštne účely. Toto číslo je nedostatočné do budúcnosti, a preto sa začalo presadzovať nasadzovanie IPv6, ktorý má tento problém odstrániť. Obr. 1.2 Formát hlavičky IPv4 ŽILINSKÁ UNIVERZITA V ŽILINE 5

Adresovanie IPv4 Adresa [5] je reprezentovaná 4 číslicami v desiatkovej sústave. Keďže každá číslica má 8 bitov môže nadobúdať hodnotu od 0 po 255. Medzi číslami sú bodky takzvaný bodkový zápis. Poznáme 3 triedy privátnych adries : Trieda A : 10.0.0.0-10.255.255.255 Trieda B : 178.16.0.0-178.31.255.255 Trieda C : 192.168.0.0-192.168.255.255 3.1.5 IPv6 Tento štandard má nahradiť jeho predchodcu IPv4 [6]. Hlavným dôvodom je nedostatočný počet IP adries, ktorým disponovala verzia 4. V IPv6 je možné použiť 3,4 * 10 38 unikátnych adries čo je postačujúce do ďalekej budúcnosti. Ďalšími prínosmi v novej verzii je napr. mobilita, QoS, povinné zabezpečenie atď. Používa 128 bitovú adresu. Adresovanie IPv6 IPv6 sa skladá z dvoch častí. Prvých 64 bitov, ktoré určujú adresu siete a druhých 64 bitov, ktoré určujú adresu zariadenia. Táto druhá časť sa často generuje automaticky z MAC adresy. IP adresa sa zapisuje ako osem skupín po štyroch hexadecimálnych čísliciach. 2000:0A0B:0000:5C2D:100A:FF51:7334:1219 Obr. 1.3 Formát hlavičky IPv6 Paket pozostáva s dvoch častí: hlavičky a informačného poľa. Prvých 40 bajtov tvorí hlavička. Zdrojová aj cieľová adresa majú po 128 bitov. Značka toku 20 bit. Toto pole používa manažment QoS. Dáta môžu byť až 64KB. ŽILINSKÁ UNIVERZITA V ŽILINE 6

3.1.6 CSMA/CD Ehternet používa na prenos zdieľané médium, a preto je potrebná metóda, ktorá zabezpečí aby bol prenos po tomto médium možný. CSMA/CD [7] vykonáva v Ethernete tieto tri funkcie : - vysielanie a prijímanie dátových framov - dekódovanie dátových framov a ich kontrola, či majú správnu adresu pred tým ako ich pošle vyššej vrstve v OSI modely - detekovanie chýb vo vnútri framu alebo v sieti V prístupovej metóde CSMA/CD, sieťové zariadenie, ktoré má dáta na prenos najskôr počúva pred tým ako vyšle dáta do média. To znamená, že bod, ktorý chce posielať dáta najskôr detekuje či médium nie je zaneprázdnené t.j. či neprebieha iný prenos. Ak bod zistí, že prenosové médium nie je zaneprázdnené, vyšle svoje dáta a počúva či v tom istom okamihu nevysiela aj iný bod. Po úspešnom prenose vysielacie zariadenie sa vracia do posúvacieho bodu. Obr. 1.4 Princíp CSMA /CD 1.bod chce vysielať 2.je bod zaneprázdnený? 3.zostaví frame 4.štart vysielania 5.je kolízia? 6.vysielaj 7.bol prenos úspešný? 8.prenos ukončený 9.broadcast jam signál 10.pokus = pokus + 1 11.pokus > priveľa? 12.príliž veľa kolízii (ukončiť prenos) 13.počítanie algoritmu backoff 14.čakanie t µs ŽILINSKÁ UNIVERZITA V ŽILINE 7

3.1.7 Ethernet Ethernet alebo tiež IEEE 802.3 [8] je technológia založená na prenose rámcov pre LAN siete. Pracuje na prvej a druhej vrstve OSI modelu. Prvá vrstva definuje zapojenie vodičov a úrovne signálov. Druhá vrstva je rozdelená na dve pod vrstvy nazvané LLC ( Logical Link Control ) a MAC (Media Access Control ). MAC pod vrstva je nižšia s pod vrstiev na druhej vrstve OSI modelu a riadi prístup na médium. LLC pod vrstva je nad MAC pod vrstvou a má na starosti MAC adresáciu, riadenie toku dát, vytváranie rámcov a kontrolu chýb. MAC adresa je to identifikačné číslo sieťového adaptéra. Táto adresa je jedinečná na celom svete a prideľuje ju výrobca priamo do zariadenia. Je zložená s 12 miestneho hexadecimálneho čísla ( 48 bitov, pr. 0F:21:22:00:1C:FF ). P SFD DA SA L Data PAD FCS Obr. 1.5a Štruktúra Ehternet framu P - pole pre bitovú synchronizáciu 7 bitov SFD - príznak skutočného začiatku rámca 1 bit DA - cieľová MAC adresa 6 bitov SA - zdrojová MAC adresa 6 bitov L - dĺžka určujúca počet bitov v dátovom poli 2 bity DATA - dátová časť rámca pre pole LLC a vlastné dáta od 46 do 1500 bitov PAD - výplň pre dosiahnutie min. dĺžky rámca. Ak je menej ako 46 bit v dátovom poli tak musí byť pridaní PAD na koniec dát FCS - cyklické zabezpečenie rámca 4 bity ŽILINSKÁ UNIVERZITA V ŽILINE 8

3.1.8 Centralizované riadenie Centralizované riadenie v mojom prípade je založené na výzve serveru klientovi. Klient odpovedá iba na výzvy od serveru. Ak klient chce poslať dáta čaká kým ho server osloví a až po výzve klient môže odpovedať. V prípade ak klient nemá dáta na poslanie len odpovie serveru bez posielania dát. Týmto sa zabezpečí, že v jednom okamihu nemôžu nastať kolízie a celá prenosová kapacita média je k dispozícii na určitý čas. Hlavným bodom je server, na ktorom sú zhromaždené dáta, databázy, programy, ktoré vyžadujú klienti. Výhoda tohto riadenia je v tom, že server ponúka služby, ktoré klienti využívajú t.j. každý klient nemusí obsahovať kompletné vybavenie serveru. Týmto sa šetria prostriedky vynaložené na každého klienta. Nevýhoda u tohto riadenia je, že ak server vypadne celá časť, ktorú obsluhuje sa stane nedostupná a nefunkčná. Preto treba server zálohovať záložným serverom, ktorý v prípade výpadku primárneho serveru nahradí jeho funkčnosť a daná sieť neostane nefunkčná. Druhá možnosť ako nahradiť nefunkčný server je tá, že nadradený server dočasne nahradí nefunkčný server, ktorý riadi. Server Klient Klient Klient 3.1.9 JAVA Obr. 1.5b Princíp centralizovaného riadenia Objektovo orientovaný programovací jazyk [9], ktorý sa líši od ostatných programovacích jazykov ako napríklad C a C++ tým, že programy sa nekompilujú do strojového kódu ale do byte-code, ktorý nie je závislý na platforme. Preto ho možno použiť v rôznych operačných systémoch bez zmeny kódu a tiež sa nazýva multiplatformový programovací jazyk. Syntax jazyka vychádza s C a C++. Java sa začala používať v roku 1995, kde bola integrovaná do vtedy veľmi populárneho internetového prehliadača Netscape Navigátor. Bolo možné rozšíriť funkčnosť www stránok pomocou java appletov. Java applety sú programy napísané v Jave, ktoré sa sťahujú súčasne s www stránkou a programy sú spúšťané priamo v prehliadači. Prenositeľnosť nemôže byť ŽILINSKÁ UNIVERZITA V ŽILINE 9

s technických príčin 100%, vyvinulo sa niekoľko edícii Javy, ktoré sa líšia v malých rozdieloch [10,11]. J2SE ( java 2 standard edition ) aplikácie spustiteľné na počítačoch. Nezávisle na operačnom systéme (Linux, Windows, Unix, Mac OS a ďalšie ) Java applety - ide o programy naprogramované v jazyku Java, ktoré sa sťahujú a spúšťajú spoločne s www stránkou v prehliadači a tým rozširujú funkčnosť www stránok. Java Server Pages ( JSP ) umožňujú kombinovať html spolu s Java príkazmi. Na servery sa spracúvajú príkazy a generuje sa html kód. J2EE ( servlety ) služby, ktoré sú na www serveroch a ktoré generujú dynamické html stránky J2ME ( java 2 micro edition ) mobilná edícia, ktorá sa používa v mobiloch, pda a ďalších mobilných malých zariadeniach. 3.1.10 ITKR Interaktívne televízne káblové rozvody sú postavene na štandardných káblových rozvodoch, ktoré sú doplnené o interaktivitu ako napr. vyhľadávanie programov, sťahovanie filmov na požiadanie, hlasovanie on-line atď. Káblové rozvody sú zväčša tvorené dvoma prenosovými médiami. Optické vlákno, ktoré je použité ako hlavný rozvod pre core siete a koaxiálne káble, ktoré sú vedené priamo k užívateľom aby sa minimalizovali náklady. Káblové rozvody obsahujú velenie, kde sú sústredené servery resp. hardware ktorý je potrebný pre prenos video signálu a jeho spracovanie. V súčasnosti sa tieto káblové rozvody nepoužívajú len pre prenos video obrazu ale aj ako prenos IP paketov napr. internet resp. VoIP. Je možné, že daná prenosová kapacita sa rozdelí t.j. vytvoríme nový kanál, po ktorom sa nebude šíriť video obraz, ale budeme do tohto kanálu kódovať digitálny signál s PC. K tomuto je potrebný káblový modem na strane užívateľa a tiež na strane siete. Prenosové kapacity sa pohybujú v rozmedzí 30 až 40 Mbps pri 6Mhz kanály. Samozrejmosťou je súčasný prenos IP paketov ako aj káblovej televízie. Tento prenos zabezpečuje spliter, ktorý rozdeľuje resp. zlučuje rôzne kanály. Aby bolo možné pomocou káblových rozvodov pripojenie na internet, poskytovateľ káblovej televízie musí byť pripojený do siete internet t.j. musí mať brány, smerovače a ďalšie potrebne vybavenie. ŽILINSKÁ UNIVERZITA V ŽILINE 10

3.2 Riešenie diplomovej práce 3.2.1 Navrhnuté riešenie centralizovaného riadenia pre ITKR V centralizovanom riadení (Obr. 2.1 ) je potrebný server. V ITKR je tento Server nazvaný ako RCDS ( riadiace centrum domovej siete ). RCDS obsahuje programové vybavenie ako operačný systém (Windows alebo Linux ), databáza PostgreSql, súbory obsahujúce dáta pre EUB, Java runtime enviroment pre spustenie Java kódu a Server aplikácia na obsluhu EUB. EUB1 EUB2 EUB3 smerovač RCDS EUB 255 Obr. 2.1 Princíp zapojenia ITKR siete ŽILINSKÁ UNIVERZITA V ŽILINE 11

3.2.2 Formát riadiacej hlavičky 1 2 3 4 5 6 7 8 0 Formát 1 0 0 1 Formát 2 0 1 0 1. prenos 1 0 1 2. prenos (opakovaný) 1 1 0 Výzva 1 Odpoveď Obr. 2.2 Formát riadiacej hlavičky Obrázok 2.2 zobrazuje formát hlavičky. Prvý riadok označuje bity. Je možné vidieť, že riadiaca hlavička bude obsahovať 8 bitov. 1. bit - označuje, či v prenose ide o výzvu alebo odpoveď 2. bit - označuje formát hlavičky, formát 1 alebo formát 2. Formát 1 sa používa na výzvu a odpoveď, zatiaľ čo formát 2 sa používa na prenos 3. bit - označuje, či prenos je prvý resp. opakovaný 4.,5.,6. bity tvoria rezervu na ďalšie rozšírenie formátov 7.,8. bity označujú prioritu pričom : 0 0 - najnižšia priorita 1 1 - najvyššia priorita RCDS F1V F2D F1V F2D EUB F10 F10 F2D F2D Obr. 2.3 Kombinácia možných formátov ŽILINSKÁ UNIVERZITA V ŽILINE 12

0 7 15 23 31 Zdrojová IP adresa Cieľová IP adresa 00000000 protokol UDP dĺžka 96 bitov = 12 bytov IP hlavička Zdrojový port UDP dĺžka SSP Cieľový port Kontrola SDP 64 bitov = 8 bytov UDP hlavička Control Kontrola2 Dĺžka (H+D) Control Kontrola1 Dáta 72 bitov = 9 bytov UDP hlavička Dáta Obr. 2.4 Štruktúra IP paketu v sieti ITKR a veľkosti hlavičiek 1 2 3 4 5 6 7 8 0 Formát 1 0 0 1 Formát 2 0 1 0 1. prenos 1 0 1 2. prenos (opakovaný) 1 1 0 Výzva 1 Odpoveď H-IP H-UDP SSP SDP C L CH DATA Obr. 2.5 Vkladanie bitov centralizovaného riadenia do IP paketu ŽILINSKÁ UNIVERZITA V ŽILINE 13

H-IP - hlavička IP paketu H-UDP - hlavička UDP paketu SSP - Secondar Source Port (hlavička centralizovaného riadenia) SDP - Secondar Destination Port (hlavička centralizovaného riadenia) C - Riadiace pole pre centralizované riadenie L - Dĺžka hlavičky centralizovaného riadenia aj dát Ch - Checksum (kontrolný súčet) iba riadiacej hlavičky centralizovaného riadenia nie dát!!! 9 bytov hlavička + 4 byty dáta správa SSP SDP Control L CH DATA 2000 2001 1 1 0 000 00 13 X ahoj Odpoveď Formát 2 1. prenos Najnižšia priorita Obr. 2.6 Príklad vyplnenia hlavičky centralizovaného riadenia V poli SSP sa zadáva zdrojový sekundárny port t.j. port, na zdrojovom zariadení, na ktorom beží určitá služba. V poli SDP sa zadáva sekundárny cieľový port t.j. port, na ktorom beží vzdialená služba. Pole Control sa vyplňuje podľa potreby riadenia (pr. Obr. 2.6). Konkrétne vyplnenie hlavičky control podľa obr. 2.2. Pole L čiže dĺžka sa má vyplňovať automaticky, pričom sa berie do úvahy veľkosť hlavičky centralizovaného riadenia a dĺžka správy, ktorá je zapísaná v poli DATA. Pole CH sa tiež vypĺňa automaticky, kde sa počíta kontrolná suma CRC16 s hlavičky centralizovaného riadenia. Pole CH nekontroluje či boli správne prenesené dáta v DATA poli!!!. ŽILINSKÁ UNIVERZITA V ŽILINE 14

3.2.3 Riadenie EUB pomocou RCDS Na riadenie EUB pomocou RCDS sú vyhradené príkazy F1V1, F1V2. Príkaz F1V1 slúži na zistenie či sa v sieti nachádza daná EUB. Tento príkaz je smerovaný s RCDS do EUB (obr 3.1 a). Je to prvá výzva. Ak sa výzva stratí v sieti resp. stanica neodpovie do vopred stanoveného času vyšle sa druhá výzva F1V2 (obr 3.1 b). Ak ani po tejto druhej výzve EUB neodpovie pokladá sa za neprihlásenú a pokračuje sa na ďalšiu EUB (obr. 3.1c). F1V1 EUB1 smerovač RCDS Obr. 3.1a Vysielanie príkazu F1V1 F1V1 EUB1 smerovač F1V2 RCDS Obr. 3.1b Neúspešný pokus prenosu F1V1, vyslanie F1V2 F1V1, F1V2 EUB1 smerovač RCDS EUB2 Obr. 3.1c Neúspešný prenos F1V1,F2V2 pokračovanie na ďalšiu stanicu ŽILINSKÁ UNIVERZITA V ŽILINE 15

Ak sa oslovená EUB nachádza v sieti t.j. na EUB je spustená klient aplikácia v Jave, EUB odpovie signálom F101 (obr 3.2a) t.j. prvá odpoveď resp. signálom F102 (obr 2.2b) t.j. druhá odpoveď ak neprišlo potvrdenie od RCDS o správnom prijatí. F1V1 EUB1 smerovač RCDS F101 Obr. 3.2a EUB prvá odpoveď F101 na výzvu F1V1 F1V1 EUB1 smerovač RCDS F101 F102 Obr. 3.2b EUB druhá odpoveď F102 na výzvu F1V1 V prípade nekvalitného média, resp. preťaženej siete sa môže stať, že prenos bude reagovať až na druhé výzvy a druhé odpovede ako je zobrazené na obr. 3.3a a 3.3b. Ak by nastal takýto prípad treba vhodne nadimenzovať sieť pre daný počet užívateľov a služieb, ktoré budú na tejto sieti fungovať. ŽILINSKÁ UNIVERZITA V ŽILINE 16

F1V1 EUB1 smerovač RCDS F101 F1V2 Obr. 3.3a Odpoveď od EUB až na druhú výzvu F1V2 F1V2 F1V1 EUB1 smerovač RCDS F101 F102 Obr. 3.3b Výzva aj odpoveď až na druhý krát 3.2.4 Prenos dát v sieti ITKR EUB -> RCDS RCDS obvoláva EUB s výzvou F1V1 resp. F1V2. Ak EUB má dáta, ktoré chce poslať, tak EUB odpovie správou F2D1 (obr. 3.4a) resp. správou F2D2 (obr.3.4b). Ak EUB nemá dáta, tak sa vyšle F101 resp. pri druhom prenose F102 a RCDS pokračuje na ďalšiu EUB. ŽILINSKÁ UNIVERZITA V ŽILINE 17

F1V1 (F1V2) EUB1 smerovač RCDS F2D1 Obr. 3.4a Prenos dát s EUB do RCDS (napr. príkaz pre SQL databázu) F1V1 (F1V2) EUB1 smerovač RCDS F2D1 F2D2 Obr. 3.4b Opakovaný prenos dát s EUB do RCDS 3.2.5 Prenos dát v sieti ITKR EUB->RCDS->EUB Ako prvé RCDS obvolá stanicu výzvou F1V1 resp. opakovanou výzvou F1V2. EUB má dáta na prenos (príkaz na SQL databázu, ktorá je na RCDS). Po prijatí sa dáta v RCDS spracujú, vyšle sa požiadavka pre databázu a jej výsledok sa pošle do EUB. F1V1 (F1V2) EUB1 smerovač RCDS F2D1 (F2D2) príkaz na SQL F2D1 (F2D2) vyžiadané dáta F101 (F102) Obr. 3.5 Princíp výmeny dát v sieti ITKR ŽILINSKÁ UNIVERZITA V ŽILINE 18

3.2.6 Výpočet hodnôt pre pole Control v hlavičke centralizovaného riadenia Pre správnu činnosť prenosu dát a výziev je potrebné správne usporiadanie bitov v poli C hlavičky centralizovaného riadenia. Toto pole obsahuje 8 bitov, z ktorých každý plní určitú úlohu. Tab. č. 3.1 zobrazuje aké kombinácie môžu nastať pri riadení. Označenie Bin. Hodnota Dec. hodnota Hex. hodnota F1V1 00000000 0 0x00 F1V2 00100000 32 0x20 F101 10000000 128 0x80 F102 10100000 160 0xA0 F101p 10000001 129 0x81 F102p 10100001 161 0xA1 F2D1 01000000 64 0x40 F2D2 01100000 96 0x60 3.2.7 Prideľovanie priority Tab. č. 3.1 Pridelené hodnoty a ich označovanie O prioritu žiada EUB. RCDS pri výzve F1V1 resp. F1V2 vo svojom poli DATA posiela číslo možných priorít (obr 3.7a). Ak je toto číslo väčšie ako 0, EUB môže požiadať o prioritu t.j. vyšle SQL príkaz do databázy, že chce v zadanom čase rezervovať časť prenosového média (napr. VoD). Databáza obsahuje všetky požiadavky na rezerváciu časti prenosového média. Ak v danom okamihu už nie sú voľné prostriedky žiadosť o prioritu zamietne a navrhne užívateľovi najbližšiu možnú alternatívu. Túto môže užívateľ prijať alebo zamietnuť. Ak užívateľ súhlasí s navrhovaným časom v RCDS sa zníži číslo priority o jedna (až v danom čase) a EUB zaregistruje ako prioritnú t.j. túto stanicu bude obvolávať častejšie ako tie EUB, ktoré prioritu nemajú. EUB nemôže poslať príkazy F101p resp. F102p, ale len potvrdenie o prijatí F101 resp. F102(obr 3.7b). Priorita sa zruší v tom prípade, ak užívateľ zruší daný film resp. si posunie jeho pozeranie na iný čas. Podľa prenosového média a jeho prenosovej rýchlosti ŽILINSKÁ UNIVERZITA V ŽILINE 19

je zvolený počet súčasne VoD na 10 t.j. v danom čase nemôže prenášať viac ako 10 užívateľov prioritné služby. F1V1 (F1V2) pole DATA = 10 EUB1 smerovač RCDS SQL príkaz F101p (F102p) DATA = DATA - 1 Potvrdenie priority Obr. 3.7a Žiadosť o pridelenie priority a jej kladné vyhovenie F1V1 (F1V2) pole DATA = 0 EUB1 smerovač RCDS DATA = 0!!! F101 (F102) EUB už nemôže požiadať o prioritu, a preto vysiela už len F101 alebo F102 Obr. 3.7b Žiadosť o prioritu je zamietnuté 3.2.8 Popis vývojového diagramu SpustiClient.java (EUB) Trieda má za úlohu stáleho kontrolovania, či na danom porte neprijal paket (v mojom prípade cyklom while). Cyklus sa vykonáva ako vlákno t.j. môže byť spustených viacero takýchto úloh naraz na jednoprocesorovom počítači. V cykle sa vykonáva podmienka, či sa prijal paket, ak nie skáče sa na cyklus while. Ak je prijatý paket vykonáva sa ďalšia podmienka, či prijatý paket obsahuje dáta alebo ide o výzvu. V prípade dát sa nastaví Control hlavička na F1D1 a do poľa dáta sa vložia potrebné dáta. Po vyslaní dát sa kontroluje, či odpovedala daná stanica, ktorej sa posielali dáta alebo nie, ak nie vyšle sa ďalší paket Control hlavička sa nastaví na F1D2 a do poľa dáta sa nastavia dáta, ktoré sa ŽILINSKÁ UNIVERZITA V ŽILINE 20

vysielali prvýkrát. V prípade, ak prijatý paket nie sú dáta vyhodnocuje sa, či sa nežiada o prioritu. Ak áno vyšle sa paket s nastavením Control hlavičky na F101p a čaká sa na odpoveď. Ak odpoveď nepríde do stanoveného času opakovane sa vyšle paket s Control F102p. Ak v podmienke žiadosti o prioritu je záporne vyhodnotenie vyšle sa paket s Control F101, čo je len odpoveď, že klient je aktívny. Opäť sa čaká na vopred stanovený čas. Ak nepríde vyšle sa opätovne paket F102. 3.2.9 Popis vývojového diagramu Spusti.java V prvom kroku sa dynamicky vytvorí trieda send. Následne sa spustí vlákno, ktoré je riadiacim programom RCDS a riadi EUB stanice. V cykle, ktorý beží stále až kým sa nevypne program sa obvolávajú stanice EUB od 1 po 254 (odpovedia len aktívne stanice, neaktívne stanice neodpovedajú, využije sa tu timeout, ktorý sa predom nastaví). V podmienke sa skontroluje, či sa daná stanica nachádza v zozname IP adries. Ak nie pokračuje sa na ďalšiu stanicu. Ak sa však daná stanica nachádza v zozname vyšle sa príkaz F1V1, čo je výzva EUB od RCDS a čaká sa na odpoveď. V prípade vypršania časového limitu sa vyšle opakovaná správa F1V2 a opäť sa čaká na odpoveď od EUB. Ak ani po tejto výzve stanica neodpovie, pokladá sa za neaktívnu a pokračuje sa na ďalšiu stanicu. V prípade, že EUB odpovie t.j. RCDS prišla správa na prvú odpoveď, v podmienke sa testuje či bol prenos úspešný. Ak nie vyšle sa opakovaný paket s F1V2. Ak po opakovanej výzve prenos nebol úspešný, pokračuje sa na ďalšiu stanicu. Ak bol prenos správny v rozvetvenej podmienke sa určuje o akú požiadavku má EUB na RCDS. V tomto prípade môžu nastať tri prípady. EUB odpovie príkazom F101 t.j. len odpovie RCDS, že je aktívna ale nič nepožaduje. V prípade prijatého príkazu F2D1 resp. F2D2 dáta sa spracujú a RCDS vyšle dáta, ktoré si EUB vyžiadala hlavička Control bude nastavená na F2D1. Ak sa prenos nepodarí, vyšle sa opätovná správa s príkazom F2D2. V prípade, že prijatá správa je typu F101p resp. F102p, EUB žiada o prioritu. V podmienke sa skontroluje, či sú voľné priority, ak nie priorita sa nastaví na 0 a pošle sa EUB odpoveď so zápornou odpoveďou. V prípade, že RCDS má voľné priority nastaví ju danému EUB a počet voľných priorít vo svojom počítadle zmenší o 1. ŽILINSKÁ UNIVERZITA V ŽILINE 21

3.2.10 Popis vývojového diagramu SendServer.java Táto trieda sa používa na vysielanie paketov, či už od RCDS smerom k EUB alebo opačne. Pred samotným vysielaním treba nastaviť niekoľko parametrov aby bol prenos úspešný a paket sa dostal do správneho zariadenia na danej IP adrese a porte. Prvé čo treba nastaviť je IP adresa. Ta sa nastavuje metódou setipaddress a do parametrov sa zadáva IP adresa v štandardnom desiatkovom tvare (takzvaný bodkový zápis). Ďalej treba nastaviť UDP port (tento UDP port treba nastaviť rovnaký na vysielacej aj prijímacej strane aby bolo možné uskutočniť správny prenos). V ďalšom kroku treba nastaviť timeout (čas po ktorom keď nepríde odpoveď vyšle sa opakovaná správa). Nastavenie Control poľa sa zadáva osobitne. Pri vysielaní od RCDS sa môžu použiť len príkazy : F1V1, F1V2, F2D1, F2D2 a EUB môže nastaviť príkazy : F101, F102, F101p,F102p, F2D1,F2D2. Ako vidieť príkazy, majú svoje opodstatnenie nakoľko EUB pri riadení centralizovaných výziev nemôže poslať požiadavku na RCDS vo forme výzvy. RCDS nemôže poslať požiadavku na pridelenie priority, pretože RCDS ich prideľuje, o prioritu žiada len EUB. Ako posledné sa nastaví správa ( správa = dáta ). Toto boli nastavenia, ktoré sú potrebné aby nastavil užívateľ cez dialógové nastavovacie okno. Trieda sa spúšťa ako samostatné vlákno. Automaticky sa vyplní HeaderData ( zo vstupných zadaných hodnôt sa spoja dáta s hlavičkou pre ďalšie použitie). Vytvorí sa UDP paket s požadovanými parametrami a vyšle sa cez UDP socket. Trieda tiež automaticky zabezpečuje opakovaný prenos a následne vyplnenie poľa Control zo vstupných hodnôt t.j. ak sa vysielal paket s Control poľom F1V1 program vygeneruje nový paket, ktorý bude obsahovať všetky potrebné informácie z paketu predchádzajúceho iba pole Control sa zamení za F1V2. V prípade iného vstupného parametra poľa Control sa vygeneruje príslušný paket zodpovedajúci tomuto parametru. Pokiaľ sa ani druhý pokus po určitom čase nevydarí vyhlási sa chyba pri posielaní paketu užívateľovi (formou výpisu na konzolu, ktorú užívateľ štandardne nevidí ale môže si ju vyvolať z programu) alebo serveru a pokračuje sa na ďalšej inštrukcii. ŽILINSKÁ UNIVERZITA V ŽILINE 22

3.2.11 Popis vývojového diagramu pre Zoznam.java Táto trieda sa používa na ukladanie IP adresy a TimeOut danej EUB. Triedu využíva RCDS, aby vedela, ktoré EUB sú administrátorom zadané ako zaregistrované a majú sa obvolávať. EUB, ktoré nie sú v zozname sa neobvolávajú!. Trieda je tiež serializovaná t.j. dá sa uložiť do súboru a následne z neho aj späť do pamäte programu pre použitie. Trieda ďalej obsahuje metódy ako setiptime a overexistenciu. Tieto metódy sú popísane v kapitole 3.2.12 a 3.2.13. 3.2.12 Popis vývojového diagramu pre metódu setiptime v triede Zoznam.java Metóda používa cyklus a následne podmienku pre zistenie, ktoré je prvé voľné miesto pre obsadenie IP adresy a času zadané od administrátora. Je možné použiť 255 IP adries. Nakoľko však nemožno v IP sieťach použiť IP adresu 0 a 255, ktoré sú vyhradené pre označenie siete resp. broadcastu celkový počet klesne o 2. 3.2.13 Popis vývojového diagramu pre metódu OverExistenciu Táto metóda sa používa na overenie, či užívateľ s daným číslom sa nachádza v zozname. Použitá je podmienka. Po jej vyhodnotení sa vracia true alebo false. True ak sa položka s daným číslom nachádza v zozname a false ak sa položka so zadaným číslom v zozname nenachádza. 3.2.14 Popis vývojového diagramu Control.java V prvom kroku treba vytvoriť hlavičky, ktoré keď sa poskladajú tvoria pole Control. Hlavičku tvoria polia SSP, SDP, L, CH. Tieto menované polia majú dĺžku 2 byty (16 bitov). Výnimku v tomto tvorí pole C, ktoré má len 1 bajt (8 bitov). Pomocné pole HEADER obsahuje všetky spomínane polia. Pole dáta obsahuje 1471 bytov. ŽILINSKÁ UNIVERZITA V ŽILINE 23

Táto hodnota sa vypočíta ako : 1500 bytov max. MTU - 12 bytov IP hlavička - 8 bytov UDP hlavička - 9 bytov Control header ( riadenie centralizovaného riadenia ) 1471 bytov pre dáta, ktoré sa budú môcť prenášať na jeden krát cez IP protokol. Po deklarovaní rozmerov polí sa v ďalšom kroku nastavujú konštanty, ktoré boli vypočítané v kapitole 3.2.6 obr. 3.6. V ďalších krokoch sa vypĺňajú hodnoty SSP, SDP, C, CRC, L s čoho SSP a SDP sa vypĺňajú manuálne (pri každom prenose treba definovať zdrojový a cieľový sekundárny port). Nastavenie C (nastavujú sa s vopred definovaných konštánt v závislosti o aký prenos sa jedná). Pole L a CRC sa vyplňujú automaticky podľa dĺžky dát v dátovom poli a CRC sa počíta až keď sú vyplnené všetky polia hlavičky Control. Kontrolná suma sa počíta pomocou CRC-16 CCITT (generujúci polynóm je x 16 + x 12 + x 5 + 1). Ako už bolo spomenuté vyššie kontrolná suma sa robí len s hlavičky Control nie sú tam zahrnuté dáta!!!. Na konci sa vyplní pomocná premenná HeaderData, ktorá obsahuje dáta aj hlavičku. Toto pole sa celé vkladá do udp datagramu. Následne sa vyplnia polia potrebné pre UDP a celé sa enkapsuluje do IP paketu do poľa dáta. K dátam sa pridá IP hlavička a dostávame kompletný IP paket, ktorý sa posiela do siete. 3.2.15 Popis vývojového diagramu pre metódu IntToByte Metóda má vstupnú premennú p, čo môže byť ľubovoľná hodnota integer. Keďže chceme prekonvertovať hodnotu integer na byte potrebujeme pomocnú premennú byte o dĺžke 2 byty ( 16 bitov ). Spodných 8 bitov vymaskujeme (logický and) hodnotou 0xFF čo predstavuje zápis 1111 1111 v binárnej forme. Pomocnú premennú bitovo posunieme o 8 bitov v pravo ( pr. Ak hodnota p bola 0000 0000 1111 1111 po bytovom posune o 8 bitov vznikne 1111 1111 0000 00000. Následné novú hodnotu p maskujeme hornými 8 bitmi (log. and). Týmito krokmi sme dostali rozloženú hodnotu integer (16 bitov ) na horných 8 bitov a dolných 8 bitov hodnoty vstupnej premennej p. ŽILINSKÁ UNIVERZITA V ŽILINE 24

3.2.16 Popis vývojového diagramu pre metódu ByteToInt Metóda má vstupnú premennú pole bytov. Pre skonvertovanie pola byte na integer hodnotu potrebujeme dve pomocné premenné pom1 a pom2. Obom premenným priradíme počiatočnú hodnotu 0xFF. Čo opäť predstavuje hodnotu v binárnom tvare 1111 1111. Pomocnú premennú pom1 vymaskujeme (log. and) hodnotou b[1] čo predstavuje horných 8 bitov pôvodnej premennej v integeri. Pomocnú premennú pom1 vymaskujeme (log. and) hodnotou b[0] čo predstavuje dolných 8 bitov pôvodnej premennej integer. Aby sme dostali pôvodnú hodnotu v celku tak sa pomocné premenné spočítajú. 3.2.17 Popis vývojového diagramu pre metódu setssp Vstupná premenná je typu integer. Táto hodnota obsahuje číslo sekundárneho zdrojového portu. Ako prvé sa otestuje či je hodnota s intervalu <0;65535>. Hodnota musí byť s tohto intervalu kvôli tomu, že pole SSP ma dĺžku 2 byty t.j. max. hodnota je v rozmedzí od 0 po 65535. Vstupná hodnota sa musí previesť na byte hodnotu t.j. na horných 8 bitov a dolných 8 bitov, aby ju bolo možné vložiť do poľa SSP a následne do poľa HEADER a to nasledovné : HEADER[0] sa priradí spodných 8 bitov premennej SSP HEADER[1] sa priradí horných 8 bitov premennej SSP 3.2.18 Popis vývojového diagramu pre metódu setsdp Vstupná premenná je typu integer. Táto hodnota obsahuje číslo sekundárneho cieľového portu. Ako prvé sa otestuje či je hodnota s intervalu <0;65535>. Hodnota musí byť s tohto intervalu kvôli tomu, že pole SDP ma dĺžku 2 byty t.j. max. hodnota je v rozmedzí od 0 po 65535. Vstupná hodnota sa musí previesť na byte hodnotu t.j. na horných 8 bitov a dolných 8 bitov, aby ju bolo možné vložiť do poľa SDP a následne do poľa HEADER a to nasledovné : HEADER[2] sa priradí spodných 8 bitov premennej SDP HEADER[3] sa priradí horných 8 bitov premennej SDP 3.2.19 Popis vývojového diagramu pre metódu setl Vstupná premenná je typu integer. Táto hodnota obsahuje veľkosť dát v bytoch. Ako prvé sa otestuje či je hodnota s intervalu <0;65535>. Hodnota musí byť s tohto ŽILINSKÁ UNIVERZITA V ŽILINE 25

intervalu kvôli tomu, že pole L ma dĺžku 2 byty t.j. max. hodnota je v rozmedzí od 0 po 65535. Vstupná hodnota sa musí previesť na byte hodnotu t.j. na horných 8 bitov a dolných 8 bitov, aby ju bolo možné vložiť do poľa L a následne do poľa HEADER a to nasledovné : HEADER[5] sa priradí spodných 8 bitov premennej L HEADER[6] sa priradí horných 8 bitov premennej L 3.2.20 Popis vývojového diagramu pre metódu setc V tejto metóde sa len priradí vstupná hodnota metódy do premennej C a vyplní sa hlavička HEADER nasledovné : HEADER[4] sa priradí hodnota C, ktorá je typu byte 3.2.21 Popis vývojového diagramu metódy setcrc Táto metóda počíta kontrolnú sumu hlavičky Control. Vytvoríme objekt, ktorý je typu CRC16 (java obsahuje metódu na počítanie crc16). Vytvoríme pomocnú premennú pom, ktorá má 7 bytov (veľkosť SSP + SDP + C + L polia). Zresetuje sa počítadlo crc. Do pomocnej premennej pom sa vložia polia SSP, SDP, C a L. Následný cyklus obnovuje premennú v objekte crc16. Po skončení cyklu sa v premennej cr nachádza hodnota kontrolnej sumy. Táto sa ďalej prevedie na bytovú hodnotu pomocou metódy inttobyte a vyplní sa pole HEADER nasledovné : HEADER[7] sa pridelí spodných 8 bitov premennej cr HEADER[8] sa pridelí horných 8 bitov premennej cr 3.2.22 Popis vývojového diagramu metódy Overenie V prvom rade sa vytvoria pomocné premenné typu integer PrijateCh a OvereneCh. Obe tieto hodnoty sa nastavia na počiatočnú hodnotu 0. Do premennej PrijateCh sa priradí hodnota, ktorá dorazila v prijatom pakete. V ďalšom kroku sa počíta hodnota crc16 popísaná v kapitole 3.2.21, ale cr hodnota sa už nemusí prevádzať na typ byte, pretože hodnota PrijateCh už je typu integer. V podmienke sa skontroluje, či sa dané hodnoty zhodujú. Ak áno metóda vráti hodnotu true v prípade nezhody sa vráti hodnota false. ŽILINSKÁ UNIVERZITA V ŽILINE 26

3.2.23 Popis vývojového diagramu metódy setheader takto : Táto metóda nastaví kompletnú hlavičku so skôr zadaných hodnôt. A to SSP[0] = header[0]; SSP[1] = header[1]; SDP[0] = header[2]; SDP[1] = header[3]; C = header[4]; L[0] = header[5]; L[1] = header[6]; CH[0] = header[7]; CH[1] = header[8]; 3.2.24 Popis vývojového diagramu metódy setheaderdata Táto metóda môže mať dva rôzne vstupné parametre. Podľa toho sa vyberie, ktoré série príkazov sa budú vykonávať. Ak sú vstupné premenné head a dáta vytvorí sa pomocná premenná temp, ktorej dĺžka ja rovná súčtu head a dáta. Následne sa použije metóda arraycopy pomocou, ktorej sa zlúčia polia do jedného a to sa vloží do premennej HeadData. V prípade, ak bude len jedná vstupná hodnota headdata, postupuje sa opačne. Vstupná premenná obsahuje dve polia head aj dáta. Pomocou metódy arraycopy sa tieto rozdelia a nastaví sa premenná HEADER. 3.2.25 Popis ovládania server aplikácie Aplikácia sa skladá so štyroch častí (Obr. 3.8) a) Zoznam IP adries klienta b) Pridávanie nových IP adries c) Menu d) Server status ŽILINSKÁ UNIVERZITA V ŽILINE 27

Obr. 3.8 Grafická aplikácia Server a) Zoznam IP adries klienta V tejto časti sa zobrazuje kompletný zoznam pridaných IP adries a k ním prislúchajúci timeout ( čas, po ktorom sa pokladá stanica za nedosiahnuteľnú alebo stanica ktorá prijala chybne paket). Obsahuje hodnoty od 0 po 254 čo je maximálny počet prihlásených staníc EUB. Nepoužité a teda ani nezadané IP adresy sú v tomto zozname nazvané ako NULL nepoužitá. Na presun adries, ktoré nie je vidno sa používa posuvník. b) Pridávanie nových IP adries Časť na pridávanie nových klientov ( ich IP adresy a timeout ). Je rozdelená na dve časti. Prvá je na postupné zadávanie IP adries. Obsahuje päť políčok na zadávanie hodnôt. Štyri s nich sú pre zadanie IP adresy v desiatkovom bodkovom zápise. Prvé políčko pre zadávanie IP adresy môže nadobúdať len hodnoty s rozsahu 1 až 254. V prípade nesprávneho zadanie čísla alebo chybnej hodnoty sa políčko vyznačí červenou farbou (Obr. 3.9). To naznačuje, že daná hodnota nemôže byť použitá a treba ju opraviť, aby sa červené políčko zmenilo na biele. Druhé políčko pre zadávanie IP adresy môže nadobúdať hodnoty s rozsahu 0 až 255. Opäť ak sa políčko rozsvieti na červeno treba hodnotu zmeniť, aby sa vrátilo do bieleho podkladu. Tretie políčko môže tak isto ako druhé nadobúdať hodnoty od 0 až 255. V prípade, že je zadaná iná hodnota políčko sa ŽILINSKÁ UNIVERZITA V ŽILINE 28

rozsvieti na červeno a opäť treba hodnotu upraviť. Posledné so štyroch políčok môže nadobúdať hodnotu od 1 po 254 a to s toho dôvodu, že hodnota 0 by určovala sieť a hodnota 255 broadcast. Obr. 3.9 Grafické pozadie Server aplikácie pri chybnom zadaní IP adresy Piate políčko slúži na zadanie oneskorenia pre danú IP adresu t.j. pre dané EUB. Oneskorenie môže nadobudnúť hodnoty od 1 až 65535. (Obr. 3.9 a Obr. 3.8) ukazujú správne zadanú hodnotu oneskorenia. Primárne je nastavená na hodnotu 5 ms. Ak do políčka zadáme inú hodnotu ako je povolená, opäť sa vysvieti pozadie na červenú farbu (Obr. 3.10) a treba opraviť hodnotu tak aby bolo pozadie biele. Obr. 3.10 Ukážka chybne zadanej hodnoty oneskorenia ŽILINSKÁ UNIVERZITA V ŽILINE 29

Ak sú správne vyplnené všetky políčka v prvej časti a chceme zadávať IP adresy postupne stlačíme tlačítko Pridať klienta. Po tejto operácii za zapíšu údaje a automatický sa prepíše Zoznam IP adries klienta a tak isto nás upozorní na danú udalosť aj Server status. Druhá časť Pridávanie nových IP adries pozostáva s jedného tlačítka a s jedného políčka pre vpisovanie hodnôt. Tu treba upozorniť, že hodnota v tomto políčku môže nadobúdať hodnoty od 0. Horná hranica je obmedzená zadaním štvrtého políčka pre IP adresu. Vychádza to s adresácie IP sietí, že na poslednom mieste nemôže byť hodnota 0 ani 255. Po stlačení tlačítka Pridať klientov sa zobrazí hláška v Server status ako je vidno na Obr. 3.11 a vysvieti sa na červeno políčko pre zadávanie počtu klientov. Obr. 3.11 Chybné zadanie počtu klientov a upozornenie na túto skutočnosť c) Menu Tretia časť Menu obsahuje tlačítka pre otvorenie súboru, uloženie do súboru, spustenie serveru, zrušenie označených IP adries. Otvoriť so súboru slúži na načítanie nastavení, ktoré boli vopred uložené na disk. O tom, či údaje boli alebo neboli uložené svedčí súbor save.dat v hlavnom adresári, kde sú uložené spúšťacie súbory. Ak bola operácia úspešná v Server status sa zobrazí hláška. Uložiť do súboru je ďalšie tlačítko, ktoré dané nastavenia ukladá do súboru save.dat. Ak bola operácia úspešná opäť sa v Server status objaví hlásenie o uložení do súboru. Tlačítko Spusti server slúži na spustenie serveru t.j. prijímanie paketov, vysielanie výziev a požadovaných dát. Tlačítko Zruš označené IP sa používa v programe. Slúži na odstránenie nepotrebných ŽILINSKÁ UNIVERZITA V ŽILINE 30