Fakulta elektrotechnická

ˇ ´ ˇen´ı technick´ Cesk e vysok´ e uc e v Praze ´ Fakulta elektrotechnicka

´ PRACE ´ DIPLOMOVA Pouˇ zit´ı operaˇ cn´ıho syst´ emu Linux pro mˇ eˇ r´ıc´ı aplikace

Praha, kvˇ eten 2007

Autor: Bohuslav Stalmach

Vedouc´ı pr´ ace: Doc. Ing. Jaroslav Roztoˇ cil, CSc.

Prohl´ aˇsen´ı Prohlaˇsuji, ˇze jsem svou diplomovou práci vypracoval samostatnˇe a pouˇzil jsem pouze podklady uvedené v pˇriloˇzeném seznamu. Nemám závaˇzný d˚ uvod proti uˇzit´ı tohoto ˇskoln´ıho d´ıla ve smyslu § 60 Zákona ˇc.121/2000 Sb. , o právu autorském, o právech souvisej´ıc´ıch s právem autorským a o zmˇenˇe nˇekter´ ych zákon˚ u (autorsk´ y zákon).

V Praze dne podpis

i

Podˇ ekov´ an´ı Na tomto m´ıstˇe bych rád podˇekoval pˇredevˇs´ım rodiˇc˚ um za podporu po celou dobu ˇ studia na CVUT. Nemalé d´ıky patˇr´ı vedouc´ımu práce Doc. Ing. Jaroslavu Roztoˇcilovi, CSc za jeho nesm´ırnou trpˇelivost a cenné pˇr´ıpom´ınky k diplomové práci.

ii

Abstrakt C´ılem diplomové práce bylo v jazyce C vyvinout multiplatformn´ı software, kter´ y otestuje vlastnosti pˇrenosové cesty IP s´ıt´ı s d˚ urazem na ztrátovost paket˚ u a pˇrenosovou rychlost. Serverová ˇcást je spustitelná pod operaˇcn´ım systémem Linux, klientská ˇcást pak pod systémy Linux a 32-bitov´ ymi Windows. Byl pouˇzit UDP protokol a to tak, aby bylo moˇzné mˇeˇrit i v s´ıt´ıch, které pouˇz´ıvaj´ı NAT/PAT techniky a to obou smˇerech.

iii

Abstract Main goal of the project is to develop multiplatform software in C programming language that will test communication path characteristic of IP networks with emphasis to packet loss and transmission speed. Server part will run under Linux operating system, client part will run under Linux and 32-bit Windows. Software will use UDP protocol and it will be possible to measure networks that use NAT/PAT techniques in both directions.

iv

Tady bude zadán´ı

v

Obsah Seznam obr´ azk˚ u

viii

´ 1 Uvod

1

1.1

UDP protokol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.1.1

Struktura paketu . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2

V´ yhody UDP protokolu pˇri testován´ı IP s´ıt´ı . . . . . . . . . . . . . . . .

3

1.3

NAP/NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2 Anal´ yza 2.1

5

Poˇzadavky na aplikaci . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.1

Obecné

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.2

Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.3

Klient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.2.1

Komunikaˇcn´ı protokol . . . . . . . . . . . . . . . . . . . . . . . .

8

2.2.2

V´ yznam jednotliv´ ych paket˚ u . . . . . . . . . . . . . . . . . . . . .

9

2.2.3

Návrh aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.2.3.1

Klient . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.2.3.2

Server . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

Technická poznámka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . S´ıt’ová vrstva - tm sockets.h . . . . . . . . . . . . . . . . . . . . . . . . .

12 12

2.4.1

Nejniˇzˇs´ı vrstva . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12 15

2.5

2.4.2 Servisn´ı vrstva . . . . . . . . . . . . . . . . . . . . . . . . . . . . ˇ Casovaˇ c - timer.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.6

Vstupn´ı parametry - parser.h . . . . . . . . . . . . . . . . . . . . . . . .

19

2.7

Seznam vstupn´ıch parametr˚ u . . . . . . . . . . . . . . . . . . . . . . . .

22

2.8

extractor.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

2.2

2.3 2.4

vi

2.9

Hash - md5.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

2.10 Reporty - reporter.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

2.11 Server - tm server.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

2.12 Klient - tm client.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ 2.13 Upravy pro Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

3 Pouˇ zit´ı

26 27

3.1

useradd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

3.2

tool.sh - ukázkov´ y skript . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4 Kompilace

32

4.1

Linux

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

4.2

Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

5 Z´ avˇ er

34

Literatura

35

A CD s aplikac´ı

I

vii

Seznam obr´ azk˚ u 1.1

Zapouzdˇren´ı UDP datagramu . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

UDP datagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.3

NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1

Soubˇeh poˇzadavk˚ u v jednom bodˇe . . . . . . . . . . . . . . . . . . . . . .

6

2.2

Standardn´ı pr˚ ubˇeh komunikace . . . . . . . . . . . . . . . . . . . . . . .

8

2.3

Opakované vyslán´ı paketu . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.4

Vazby mezi strukturami msghdr, iovec a daty . . . . . . . . . . . . . . .

15

2.5

iperf - http://dast.nlanr.net/Projects/Iperf . . . . . . . . . . . . . . . . .

21

2.6

Sn´ımek terminálu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

viii

Kapitola 1 ´ Uvod V souˇcasné dobˇe existuje nˇekolik podobných aplikac´ı a to vˇcetnˇe zdrojov´ ych kódu mnohdy s otevˇrenou licenc´ı. Vˇsechny tyto aplikace vˇsak postrádaj´ı kl´ıˇcové vlastnosti, které zadavatele vedly k poˇzadavku na aplikaci zcela novou. Zásadn´ı rozd´ıl je pˇredevˇs´ım v moˇznosti ovˇeˇren´ı uˇzivatel˚ u, kteˇr´ı ˇzádaj´ı o testovac´ı datov´ y tok. Dalˇs´ı z velkých rozd´ıl˚ u je vyuˇzit´ı jen jednoho UDP portu na stranˇe serveru, coˇz hlavn´ı d˚ uvod, proˇc jen nelze modifikovat jiˇz existuj´ıc´ı software.

1.1

UDP protokol

Obr´ azek 1.1: Zapouzdˇren´ı UDP datagramu

UDP (User datagram protocol) je souˇcást´ı sady Internetov´ ych protokol˚ u a tvoˇr´ı spoleˇcnˇe s TCP protokolem vˇetˇsinu internetové komunikace. Protokol je popsán v RFC 768 [7]. 1

´ KAPITOLA 1. UVOD

1.1. UDP PROTOKOL

UDP byl p˚ uvodnˇe urˇcen pro zas´ılán´ı krátk´ ych zpráv (datagram˚ u) a jako takov´ y postrádá spolehlivost TCP. Mezi komunikuj´ıc´ımi zaˇr´ızen´ımi se nevytváˇr´ı spojen´ı, ˇc´ımˇz odpadá reˇzie na vytvoˇren´ı a udrˇzován´ı takovéhoto spojen´ı. D´ıky tˇemto vlastnostem je UDP protokol vhodn´ y pro aplikace, kde jde pˇredevˇs´ım o pˇrenosovou rychlost a ztráta nˇekolika paket˚ u nevede k zásadn´ı ztrátˇe informace. Pouˇzivá se tedy pro aplikace, kde server na základˇe krátk´ ych poˇzadavk˚ u rozes´ılá velká kvanta dat velkému poˇctu klient˚ u. UDP protokol podporuje zas´ılán´ı zprávy vˇsem poˇc´ıtaˇc˚ um na lokáln´ı s´ıti (broadcast) a vˇsem zájemc˚ um o danou sluˇzbu (multicast). Z toho d˚ uvodu UDP protokol nalezneme u aplikac´ı pro ˇs´ıˇren´ı audiovizuáln´ıch dat. Z rozˇs´ıˇrených pouˇzit´ı protokolu UDP jmenujme DNS (Domain Name System), TFTP (Trivial File System Protocol a z populárn´ıch pak VoIP telefonii. O protokolu TFTP bude zm´ınka v následuj´ıc´ım textu.

1.1.1

Struktura paketu

Na obrázku 1.2 je zobrazena struktura UDP paketu. UDP hlaviˇcka obshuje pouze ˇctyˇri ˇcásti, z nichˇz dvˇe jsou volitelné.

Obr´ azek 1.2: UDP datagram

zdrojov´ y port identifikuje odesilatele a je pouˇzit, pokud oˇcekáváme odpovˇed’. Jde o nepovinn´ y parametr. c´ılov´ y port podle tohoto portu se na c´ılovém poˇc´ıtaˇci vyb´ırá pˇr´ısluˇsná aplikace. Parametr je povinn´ y.

2

´ ˇ TESTOVAN ´ Í IP SÍTÍKAPITOLA 1. UVOD ´ 1.2. VYHODY UDP PROTOKOLU PRI d´ elka 16 bitová hodnota, která obsahuje délku celého datagramu (vˇcetnˇe hlaviˇcky) v bytech. Minimáln´ı délka je 8 byt˚ u, coˇz je velikost hlaviˇcky, kotroln´ı souˇ cet nepovinná hodnota pro kontrolu paketu. Aˇc nepovinná, vˇetˇsinou se pouˇz´ıvá. Kromˇe RFC 768 [7], je moˇzno pro v´ıce informac´ı navˇst´ıvit pˇr´ısluˇsnou stránku na Wikipedii [1], ˇci do [11].

1.2

V´ yhody UDP protokolu pˇ ri testov´ an´ı IP s´ıt´ı

UDP protokol sám o sobˇe nezaruˇcuje, ˇze datagram doraz´ı na m´ısto urˇcen´ı a stejnˇe tak nezaruˇcuje, ˇze datagramy doraz´ı ve stejném poˇrad´ı, v jakém byly vyslány. V nˇekterých pˇr´ıpadech m˚ uˇze doj´ıt i ke zduplikován´ı paketu uprostˇred pˇrenosové cesty. A právˇe výˇse uvedené vlastnosti lze s v´ yhodou vyuˇz´ıt pro testován´ı IP s´ıt´ı. Pokud jsou na vys´ılac´ı stranˇe pakety oznaˇceny, lze na stranˇe pˇr´ıjemce snadno zjistit, jestli se na pˇrenosové cestˇe nˇekter´ y paket ztratil ˇci zda doˇslo ke zmˇenˇe poˇrad´ı paket˚ u. Tyto vlastnosti jsou velmi v´ yhodné pro samotné mˇeˇren´ı, ale aplikace si mus´ı sama pˇridat vlastn´ı mechanismy, které zabezpeˇc´ı doruˇcen´ı d˚ uleˇzitých zpráv.

1.3

NAP/NAT

Network address translation (NAT) je technika vyvinutá v IPv 4 s´ıt´ıch kv˚ uli nedostatku IP adres. Hlavn´ım vyuˇzit´ım je pˇripojen´ı lokáln´ı s´ıtˇe k Internetu pˇres jedinou veˇrejnou IP adresu tak, ˇze pˇri cestˇe datagramu z lokáln´ıho poˇc´ıtaˇce router (gateway) nahrad´ı zdrojovou adresu svou vlastn´ı adresou, takˇze z pohledu c´ılového poˇc´ıtaˇce tento komunikuje pouze s gateway. Dalˇs´ı výhodou je skryt´ı lokáln´ıch poˇc´ıtaˇc˚ u pˇred vnˇejˇs´ı s´ıt´ı, které tak nejsou bˇeˇznými metodami pˇr´ımo dostupné z Internetu a klesá tak pravdˇepodobnost napaden´ı poˇc´ıtaˇce a sniˇzuje se moˇznost vzdálené nákazy virem (ˇcervem). Omezen´ım je pak nefunkˇcnost nˇekter´ ych sluˇzeb ˇci nároˇcnost jejich konfigurace. Pokud pouˇzijeme Port Address Translation (PAT), router nahrazuje jednak IP adresu, jednak zdrojov´ y port datagramu. V´ıce v RFC 3022[10]. Je-li klient skryt pomoc´ı nˇekteré z pˇredchoz´ıch technik pˇred veˇrejnou s´ıt´ı, server takovéhoto klienta nevid´ı. Teprvé poté, co klient zaˇsle sv˚ uj datagram na server, vytvoˇr´ı 3

´ KAPITOLA 1. UVOD

1.3. NAP/NAT

se v routerech na cestˇe patˇriˇcné smˇerovac´ı tabulky. Je dobré si uvˇedomit, ˇze port i adresa UDP paketu, který pˇricház´ı na server se m˚ uˇzou liˇsit od reálné adresy klienta. Je tedy zbyteˇcné na aplikaˇcn´ı u ´ rovni vkládat na stranˇe klienta adresu, nebot’ bude s velkou pravdˇepodobnost´ı pˇrepsána. Jediné, co NAT zaruˇcuje je, ˇze pokud jsou vyslány z poˇc´ıtaˇce za NATem pakety z jednoho zdrojového portu, budou se i zvnˇejˇsku jevit, ˇze byly vyslány z jednoho portu, aˇckoliv ˇc´ıslo portu se m˚ uˇze na obou stranách liˇsit.

Obr´ azek 1.3: NAT

4

Kapitola 2 Anal´ yza

2.1 2.1.1

Poˇ zadavky na aplikaci Obecn´ e

Zadán´ı diplomové práce pomˇernˇe pˇresnˇe definuje poˇzadavky na aplikaci. Pˇri realizaci je jiˇz od poˇcátku nutné poˇc´ıtat s t´ım, ˇze klientská ˇcást mus´ı být zkompilovatelná - provozu schopná - jak na operaˇcn´ım systému Linux, tak na 32-bit verz´ıch Microsoft Windows. Dalˇs´ı poˇzadavek, kter´ y je na prvn´ı pohled skryt, je zaruˇcená funkˇcnost aplikace i v s´ıt´ıch za NAT/PAT. Pˇredpokládá se, ˇze server je veˇrejnˇe pˇr´ıstupný, kdeˇzto klient je v s´ıti neveˇrejn´ ych adres.

2.1.2

Server

Zásadn´ım poˇzadavkem je nutnost pouˇz´ıt na stranˇe serveru pro komunikaci pouze jeden UDP port. Klasické klient UDP server aplikace, napˇr´ıklad TFTP pouˇzivaj´ıc´ı protokol stejného jména, který je definovám v RFC 1350 [9], funguj´ı jinak. Server naslouchá na obecnˇe známem portu (v pˇr´ıpadˇe TFTP je to port 69). Klient zaˇsle datagram na tento 5

ˇ 2.1. POZADAVKY NA APLIKACI

´ KAPITOLA 2. ANALYZA

port, server vytvoˇr´ı nov´ y socket a dalˇs´ı komunikace s klientem prob´ıhá jiˇz pˇres jiný UDP port. T´ımto zp˚ usobem se obejde faktická neexistence dvoubodového spojen´ı známeho z protokolu TCP, kdy pˇres jeden TCP port na stranˇe serveru m˚ uˇze kumunikovat nˇekolik klient˚ u v jeden okamˇzik. Ale jak jiˇz bylo ˇreˇceno, tuto techniku nelze vyuˇz´ıt. Dalˇs´ı odliˇsnost´ı od existuj´ıc´ıch aplikac´ı je ovˇeˇren´ı uˇzivatele, kter´ y ˇzádá o datov´ y tok pomoc´ı uˇzivatelského jména a hesla. Jedinˇe v pˇr´ıpadˇe, ˇze souhlas´ı oba u ´ daje se záznamy na serveru, je datov´ y tok vyslán. Vzhledem k odstavci v sekci 1.3 je tˇreba zajistit, aby server správnˇe ˇcetl adresu pˇr´ıchoz´ıho paketu a mohl tak komunikovat s klinety za NAT/PAT.

Obr´ azek 2.1: Soubˇeh poˇzadavk˚ u v jednom bodˇe

Posledn´ım poˇzadavkem na server je pouˇzit´ı reprezentativn´ıch datových tok˚ u pro testován´ı linkové vrstvy a vlivu komprese na pˇrenosové charakteristiky. Pˇri tomto poˇzadavku budou pouˇzity extern´ı soubory r˚ uzných obsah˚ u (komprimované video, zip soubory, obrázky, text), jejichˇz obsahem budou pakety plnˇeny. Na linkové vrstvˇe TCP/IP protokolu je totiˇz implementováno nˇekolik protokol˚ u, které dokáˇz´ı komprimovat data, ˇc´ımˇz sniˇzuj´ı velikost paketu a teoreticky zvyˇsuj´ı propustnost takové s´ıtˇe. Je zˇrejmé, ˇze napˇr´ıklad jiˇz vysoce zkomprimované MPEG video nebude pˇri pˇrenosu dále komprimováno, ale napˇr´ıklad u bitmapov´ ych obrázk˚ u ˇci textu dosáhne komprimaˇcn´ı algoritmus zaj´ımav´ ych kompresn´ıch pomˇer˚ u. Pouˇzit´ım r˚ uzných reprezentativn´ıch datových tok˚ u m˚ uˇzeme ovˇeˇrit funkˇcnost kompresn´ıch algoritm˚ u na pˇrenosové cestˇe. Z protokol˚ u linkové vrstvy, které jsou schopny datové komprese jmenujme alespoˇ n protokoly PPP, Frame Relay, High-Level Data Link Control (HDLC) a X.25. 6

ˇ 2.1. POZADAVKY NA APLIKACI


Kritickou ˇcást´ı aplikace bude ˇcasovaˇc, který zaruˇc´ı, ˇze rozestupy mezi pakety budou odpov´ıdat poˇzadavku klienta. Mus´ı být schopen správné funkce i pˇri vys´ılán´ı v´ıce datov´ ych tok˚ u r˚ uzným klient˚ um. Server bude schopen datové toky nejen vys´ılat, ale také pˇrij´ımat datov´ y tok od klienta a to bud’ samostatnˇe v obou smˇerech, ˇci v duáln´ım reˇzimu, kdy se postupnˇe zmˇeˇr´ı pˇrenosová cesta v obou smˇerech datovým tokem shodných parametr˚ u. Je d˚ uleˇzité zajistit v´ ymˇenu výsledk˚ u mˇeˇren´ı mezi serverem a klientem.

2.1.3

Klient

D˚ uleˇzitým poˇzadavkem, kter´ y vyplynul aˇz v pr˚ ubˇehu ˇreˇsen´ı, je moˇznost pouˇzit´ı klientské ˇcásti aplikace v uˇzivatelsk´ ych skriptech. Je tedy potˇreba, aby klient dokázal zpracovat poˇzadavky z pˇr´ıkazové ˇrádky a aby takto bylo moˇzno nastavit vˇsechny poˇzadavky na datov´ y tok. Ve vˇsech ˇzádostech o datov´ y tok mus´ı být uveden uˇzivatel a heslo. Heslo se zas´ılá v ”hash” podobˇe - odtud plyne potˇreba vybrat vhodnou hashovac´ı funkci. Uˇzivatel m˚ uˇze zadat datov´ y tok v ”raw” podobˇe - to jest velikost paket˚ u a rozestup mezi nimi. Druhou moˇznost´ı je zadat datov´ y tok jako definovanou pˇrenosovou rychlost, která je doplnˇena bud’ informac´ı o velikosti paketu ˇci rozestupu mezi pakety. Ostatn´ı parametry budou dopoˇc´ıtány. Dalˇs´ı, výslovnˇe zadané parametry, jsou typ v´ yplnˇe paketu a timeout pro komunikaci se serverem. Pro lepˇs´ı funkci budou implementovány dalˇs´ı parametry, které pouˇz´ıvá software iperf, kter´ y byl v minulosti pouˇz´ıván zadavatelem. Po pˇrijet´ı datového toku klient vyhodnocuje datov´ y tok z nˇekolika hledisek: ztrátovost paket˚ u, zmˇena poˇrad´ı paket˚ u, pˇrenosová rychlost, rozestupy mezi pakety, kol´ısán´ı rozestup˚ u (jitter). V normáln´ım reˇzimu vypisuje klient v´ ysledky na standardn´ı výstup, popˇr´ıpadˇe do CSV souboru, coˇz je výhodné zejména pˇri opakovaném mˇeˇren´ı. Klient dokáˇze datov´ y tok nejen zpracovat, ale v pˇr´ıpadˇe duáln´ıho reˇzimu i vyslat datov´ y tok na server.

7


2.2. DESIGN

2.2 2.2.1

Design Komunikaˇ cn´ı protokol

Klient a server mezi sebou komunikuj´ı pomoci UDP datagram˚ u. Datagram obsahuje ID paketu, ˇcasovou znaˇcku a data. Podle ID paketu se datagramy dˇel´ı na datové (ID > 0) a pakety nesouc´ı informaci (ID < 0). Tyto se dále dˇel´ı na pakety servisn´ı (ACK, DEN, FIN, ERR) a reporty. Speciáln´ı paket s ID = 0 (REQ) obsahuje ˇzádost o datov´ y tok a jako takov´ y vˇzdy zahajuje komunikaci. Na obrázku 2.2 je vidˇet standardn´ı pr˚ ubˇeh komunikace se serverem. Pokud v pr˚ ubˇehu komunikace vznikne chyba, je vyslán paket ERR, kter´ y obsahuje kód chyby.

Obr´ azek 2.2: Standardn´ı pr˚ ubˇeh komunikace

Jelikoˇz je UDP protokol nespolehliv´ y, je potˇreba na aplikaˇcn´ı u ´ rovni zajistit ovˇeˇren´ı doruˇcen´ı servisn´ıch a informaˇcn´ıch paket˚ u. Nejjednoduˇs´ım ˇreˇsen´ım je opakované zas´ılán´ı po urˇcitém ˇcasovém intervalu, dokud neobdrˇz´ıme odpovˇed’ ˇci pokud nen´ı pˇrekroˇcen stanoven´ y poˇcet opakován´ı. Princip je na obrázku 2.3. Protoˇze klient i server mohou býti kompilovány na r˚ uzn´ ych softwarov´ ych a hardwarov´ ych architekturách, nen´ı se moˇzné spolehnout na to, ˇze ˇc´ıselné hodnoty budou na obou 8


2.2. DESIGN

stranách interpretovány stejnˇe napˇr´ıklad kv˚ uli odliˇsnému poˇrad´ı nejvyˇsˇs´ıch a nejniˇzˇs´ıch ˇ byt˚ u. C´ısla budou pˇrekódována do ˇsestnáctkové soustavy (HEX) a zas´ılána jako text, kdy jeden znak bude m´ıt jeden byte. T´ımto se vyhneme pot´ıˇz´ım s poˇrad´ım byt˚ u v ˇc´ıselné promˇenné.

Obr´ azek 2.3: Opakované vyslán´ı paketu

2.2.2

V´ yznam jednotliv´ ych paket˚ u

• REQ - request - prvn´ı paket, kter´ y klient pos´ılá na server. Slouˇz´ı k ovˇeˇren´ı uˇzivatele a zároveˇ n k definován´ı poˇzadovaného datového toku. • ACK - acknowledgement- potvrzuje, ˇze paket byl pˇrijat. V pˇr´ıpadˇe, ˇze pˇredchoz´ı paket byl REQ, potvrzuje ovˇeˇren´ı uˇzivatele. • ERR - error - pˇri zpracován´ı poˇzadavk˚ u vznikla chyba. V pˇr´ıpadˇe, ˇze pˇredchoz´ı paket byl REQ, oznamuje paket, ˇze uˇzivatel nebyl korektnˇe ovˇeˇren. • DEN - data end - pˇredchoz´ı datov´ y paket byl posledn´ı. Tento paket obsahuje také informaci o ID posledn´ıho vyslaného paketu, jin´ ymi slovy poˇcet odeslan´ ych paket˚ u. • FIN - finish - vys´ılac´ı strana ukonˇcuje komunikaci

9


2.2. DESIGN

2.2.3

N´ avrh aplikace

Server i klient sd´ıl´ı vˇetˇsinu kódu, vyuˇz´ıvaj´ı stejné knihovny. Rozd´ıl je pˇredevˇs´ım v tom, ˇze server je v´ıcevláknov´ y - vyuˇz´ıvá POSIX vláken operaˇcn´ıho systému Linux. Vlákna jsou vyuˇzita pouze pro vys´ılán´ı datov´ ych tok˚ u od serveru smˇerem ke klientovi. Pˇr´ıjem paket˚ u se shodnˇe na klientu i serveru zpracovává sekvenˇcnˇe v hlavn´ım vláknˇe. V následuj´ıc´ıch odstavc´ıch je bliˇzˇs´ı návrh aplikace. Text se jiˇz nezabývá ovˇeˇrován´ım pˇrijet´ı paket˚ u.

2.2.3.1

Klient

Klient je spouˇstˇen z pˇr´ıkazové ˇrádky. Naˇcte uˇzivatelem definované parametry a nezadané parametry dopln´ı na v´ ychoz´ı hodnoty. Jelikoˇz m˚ uˇze b´ yt datov´ y tok definován neupln´ ymi parametry, klient zb´ ylé parametry dopoˇc´ıtá. S takto vypoˇctenými daty zaˇsle REQ paket. Po obdrˇzen´ı paketu ACK ˇceká na pˇr´ıchoz´ı datov´ y tok. Jelikoˇz paket ACK se m˚ uˇze po cestˇe ztratit, je zaslán´ı paketu ACK v tomto pˇr´ıpadˇe nepovinné a klient pˇrichoz´ı datové pakety správnˇe zpracuje i bez tohoto potvrzen´ı. Po pˇr´ıchodu prvn´ıho datového paketu odmˇeˇr´ı ˇcas. Dokud jsou ID paket˚ u vetˇs´ı neˇz nula, naˇcte z hlaviˇcky paketu ˇcasovou znaˇcku a vypoˇc´ıtá rozd´ıl oproti aktuáln´ımu ˇcasu. Dále sleduje ˇcasov´ y rozd´ıl oproti minulému paketu. Pokud se ID paketu neliˇs´ı od pˇredchoz´ıho ID právˇe od jedniˇcku, zapoˇc´ıtá jej jako ztracen´ y. Pokud je ID paketu niˇzˇs´ı neˇz pˇredchoz´ı ID, zapoˇc´ıtá jej jako paket mimo poˇrad´ı a sn´ıˇz´ı poˇcet ztracen´ ych paket˚ u. Jakmile klient obdrˇz´ı paket DEN, kter´ y zároveˇ n obsahuje informaci o posledn´ım zaslaném ID paketu, vypoˇcte pˇrenosovou rychlost, pr˚ umˇerný rozestup mezi pakety, nejistotu rozestup˚ u. V duáln´ım reˇzimu server po odeslán´ı paketu DEN odeˇsle paket REQ a klient tentokráte vys´ılá datov´ y tok smˇerem k serveru. Po odeslan´ı paketu DEN klientem ˇceká klient na report ze serveru a poté ukonˇcuje komunikaci. Podle poˇzadavk˚ u uˇzivatele pak tiskne formátovanou závˇereˇcnou zprávu na standardn´ı výstup, popˇr´ıpadˇe do CSV souboru pro pozdˇejˇs´ı zpracován´ı. Toto je posledn´ı akce, program se ukonˇc´ı.

10


2.2. DESIGN 2.2.3.2

Server

Po spuˇstˇen´ı server pˇrij´ımá poˇzadavky na uˇzivatelem definovaném portu. Pˇri obdrˇzen´ı paketu s jiným neˇz nulov´ ym ID ovˇeˇr´ı nejdˇr´ıve, jestli paket pocház´ı od ovˇeˇreného uˇzivatele. Pokud ne, paket je zahozen a dále nezpracováván. Paket s ID = 0 obsahuje uˇzivatelské jméno a heslo, které je ovˇeˇreno proti seznamu uˇzivatel˚ u. Pokud je ovˇeˇren´ı v poˇrádku, server vytvoˇr´ı nové vlákno, které odeˇsle paket ACK a po definované prodlevˇe zaˇcne vys´ılat poˇzadovan´ y datov´ y tok. Na závˇer odeˇsle paket DEN, kter´ ym signalizuje konec vys´ılán´ı. V pˇr´ıpadˇe, ˇze souˇcást´ı poˇzadavku na datov´ y tok byla ˇzádost o duáln´ı reˇzim, nevyˇrazuje server klienta ze seznamu ovˇeˇrených klient˚ u, ale odes´ılá paket REQ. Hlavn´ı vlákno serveru mezit´ım zpracovává dalˇs´ı pˇr´ıchoz´ı pakety. Pro kaˇzdého klienta, kter´ y poˇzádal o duáln´ı reˇzim má server vytvoˇren záznam, do kterého ukládá informace o paketech. Po pˇr´ıchodu paketu DEN vyhodnot´ı datov´ y tok a report zaˇsle klientovi. Záznam je smazán a klient je ostranˇen ze seznamu ovˇeˇrených klient˚ u. Autentizace plat´ı jen pro právˇe prob´ıhaj´ıc´ı datové toky. Na rozd´ıl od klienta zobrazuje server informace o svém stavu na standardn´ı výstup, do svého logu a do systémového logu. Do systémového logu jsou zapisovány pouze nejd˚ uleˇzitˇejˇs´ı informace - spuˇstˇen´ı serveru, vypnut´ı a neuspˇeˇsná autentizace vˇcetnˇe informac´ı o klientovi, kter´ y se pokusil o pˇripojen´ı. Do svého logu si server zapisuje stejné zprávy jako na v´ ystup s t´ım, ˇze výstup na obrazovku lze zakázat - tzv. tich´ y reˇzim. Pokud server bˇeˇz´ı v konzoli, je moˇzné ho ukonˇcit stiskem kláves Ctrl+C, popˇr´ıpadˇe zaslán´ım signálu SIGTERM, po jehoˇz obdrˇzen´ı se server korektnˇe ukonˇc´ı. Server m˚ uˇze být spuˇstˇen také jako systémov´ y démon (daemon) bˇeˇz´ıc´ı na pozad´ı. Poˇcet souˇcasnˇe beˇz´ıc´ıch server˚ u nen´ı omezen, v systémovém logu jsou jednotlivé zpravy odliˇseny pomoc´ı PID (process id).

11

´ POZNAMKA ´ 2.3. TECHNICKA

2.3


Technick´ a pozn´ amka

Aplikace byla programována ve v´ yvojovém prostˇred´ı KDevelop. Ke kompilaci byl pouˇzit bal´ık nástroj˚ u GCC a to jak v prostˇred´ı Linux, tak Windows. Jako programovac´ı jazyk bylo zvolen jazyk C v jeho ANSI podobˇe a to vˇcetnˇe ANSI C formátován´ı kódu. Z ANSI normy C90 nejsou dodrˇzeny zejména formáty komentáˇr˚ u, nebot’ norma C90 neumoˇznuje pouˇzit´ı komentáˇr˚ u C++ stylu tj. dvˇe lom´ıtka.

2.4

S´ıt’ov´ a vrstva - tm sockets.h

V c´ılov´ ych operaˇcn´ıch systémech se k pˇr´ıstupu ke sluˇzbám s´ıtˇe pouˇz´ıváj´ı sockety, které v obou pˇr´ıpadech vycház´ı z Berkeley sockets API. Zat´ımco v pˇr´ıpadˇe Linuxu byla specifikace dodrˇzena, v pˇr´ıpadˇe Microsoft Windows a jejich WinSock doˇslo k odchylkám. Obˇe implementace byly porovnány a nakonec byla vybrána mnoˇzina funkc´ı, které jsou témˇeˇr identické a kód je tak pˇrenositeln´ y s minimáln´ımi zásahy v kódu jen s pomoc´ı direktiv preprocesoru. Popis rozhran´ı socket najdeme napˇr´ıklad [3] a popis rozhran´ı WinSock pak [2].

2.4.1

Nejniˇ zˇ s´ı vrstva

Základem kaˇzdé komunikace je vytvoˇren´ı socketu, pˇres kter´ y bude aplikace komunikovat s vnˇejˇs´ım svˇetem. K tomu slouˇz´ı volán´ı socket()

int socket(int domain, int type, int protocol);

, které má v naˇsem pˇr´ıpadˇe podobu

socket(AF_INET, SOCK_DGRAM, 0); 12

ˇ ´ VRSTVA - TM SOCKETS.H 2.4. SÍTOV A


Pouˇz´ıváme totiˇz rodinu AF INET, datagramovˇe orientovan´ y protokol SOCK DGRAM, coˇz je v naˇsem pˇr´ıpadˇe UDP. Aby bylo pˇres socket moˇzno pˇrij´ımat datagramy, je potˇreba ho svázat s konkrétn´ım portem a s´ıt’ov´ ym zaˇr´ızen´ım, k ˇcemuˇz slouˇz´ı funkce bind(). Bind je potˇreba pouˇz´ıt jak u klienta, tak u serveru, nebot’ oba pˇrij´ımaj´ı datagramy. Pokud bychom chtˇeli jen odes´ılat, bind nen´ı nutn´ y. Je pouˇzit IP 4 protokol, ale poˇc´ıtá se u ´ pravou programu tak, abyt mohl b´ yt pouˇzit i na IP 6 s´ıt´ıch. Pro vlastn´ı odes´ılán´ı a ˇcten´ı jednotlivého datagramu jsou pouˇzity funkce readmsg(), recvmsg() respektive WSARecvFrom() a WSASendTo(), coˇz jsou knihovn´ı funkce definované v hlaviˇckov´ ych souborech socket.h (linux, unix) a WinSock2.h (windows).

/* socket */ ssize_t sendmsg (int socket, const struct msghdr *message, int flags); ssize_t recvmsg(int socket, struct msghdr *message, int flags);

/* WinSock */ int WSARecvFrom( SOCKET s, LPWSABUF lpBuffers, DWORD dwBufferCount, LPDWORD lpNumberOfBytesRecvd, LPDWORD lpFlags, struct sockaddr* lpFrom, LPINT lpFromlen, LPWSAOVERLAPPED lpOverlapped, LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine ); int WSASendTo( SOCKET s, LPWSABUF lpBuffers, DWORD dwBufferCount, LPDWORD lpNumberOfBytesSent, DWORD dwFlags, const struct sockaddr* lpTo, 13



int iToLen, LPWSAOVERLAPPED lpOverlapped, LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine );

Prvotn´ı design aplikace p˚ uvodnˇe poˇc´ıtal s pouˇzit´ım funkc´ı WSARecv() a WSASend(), které jsou totoˇzné s funkcemi v POSIXové implementaci. Pˇresto, ˇze jsou tyto funkce v dokumentaci Microsoftu MSDN, je jich moˇzno plnˇe vyuˇz´ıt aˇz v operaˇcn´ım systému Windows VISTA. Pro maximáln´ı pouˇzitelnost aplikace na starˇs´ıch Windows byly nakonec pouˇzity v´ yˇse uvedené funkce za cenu rozd´ılu v kódu pro Windows a Linux. Aplikace zdaleka nevyuˇz´ıvá vˇsechny moˇznosti, které tyto funkce programátorovi poskytuj´ı. Volán´ı funkce vypadá jednoduˇse, v´ıce nám ˇrekne pohled na strukturu msghdr.

struct msghdr{ void

*msg_name

socklen_t struct iovec

/* Optional address. */

msg_namelen *msg_iov

/* Size of address. */ /* Scatter/gather array.*/

int

msg_iovlen

/* Members in msg_iov.*/

void

*msg_control

/* Ancillary data; see below.*/

socklen_t

msg_controllen

/* Ancillary data buffer len.*/

int

msg_flags

/* Flags on received message*/

}; struct iovec{ void *iov_base;

/* starting address of the buffer */

size_t

/* size of buffer */

iov_len;

};

D´ıky tˇemto funkc´ım je moˇzné zapsat a ˇc´ıst v´ıce buffer˚ u zároveˇ n. Pointer *msg iov totiˇz m˚ uˇze ukazovat na pole struktur iovec, jehoˇz délka je urˇcena poloˇzkou msg iovlen. Struktura iovec pak obsahuje ukazatel na buffer a jeho délku. Pˇri pos´ılán´ı paketu je

14



potˇreba ˇrádnˇe vyplnit hlaviˇcku *msg name, která v naˇsem pˇr´ıpadˇe ukazuje na strukturu sockaddr in, která definuje informace o adresátovi paketu. Pro vˇetˇs´ı pˇrehlednost je pˇripojen obrázek 2.4 vazeb mezi jednotliv´ ymi strukturami tak, jak je pouˇz´ıvá aplikace.

Obr´ azek 2.4: Vazby mezi strukturami msghdr, iovec a daty

struct sockaddr_in { short

sin_family;

// e.g. AF_INET

unsigned short

sin_port;

// e.g. htons(3490)

struct in_addr

sin_addr;

// see struct in_addr, below

char

sin_zero[8];

// zero this if you want to

}; struct in_addr { unsigned long s_addr;

// load with inet_aton()

};

2.4.2

Servisn´ı vrstva

Jak je patrné z pˇredchoz´ıho textu, manipulace s n´ızko´ urovˇ nov´ ymi funkcemi nen´ı jednoduchá, bylo tedy potˇreba vytvoˇrit obsluˇzné funkce, které vypln´ı datové struktury a zároveˇ n zvýˇs´ı pˇrehlednost kódu. Tyto funkce jsou definovány v hlaviˇckové souboru 15



tm sockets.h a implementovány v pˇr´ısluˇsné knihovnˇe. Vyuˇzijeme toho, ˇze jiˇz pˇri volán´ı u ´ vodn´ı bind() funkce potˇrebujeme m´ıt inicializovánu strukturu sockaddr in. Jelikoˇz velikosti datov´ ych struktur známe také, pouˇzijeme jiˇz uˇzivatelskou funkci tm fill msghdr(), která vypln´ı vˇse potˇrebné.

void tm_fill_msghdr(struct msghdr *hdr, struct iovec *iov, struct sockaddr_in *SA);

Takto vyplnˇenou strukturu, na kterou ukazuje pointer *hdr, lze jiˇz pˇredloˇzit funkci sendmsg(), ˇc´ımˇz by doˇslo k odeslán´ı prázdného paketu. Pro rozumné vyuˇzit´ı je potˇreba pˇred odeslán´ım doplnit ukazatele na datové struktury, které jsou celkem dvˇe. Prvn´ı je typu socket header t a druhá ukazuje na libovolná data, at’ uˇz je to buffer pro výplˇ n datového paketu, ˇci jiná struktura. Pokud takov´ y paket pˇrijme druhá strana, podle kontextu (a ID paketu) pozná, jaká data oˇcekávat a provede pˇr´ısluˇsné pˇretypován´ı. Na samotném konci stoj´ı funkce tm send data packet(), která poˇsle paket na definovanou adresu s pˇr´ısluˇsným obsahem.

int send_data_packet(int sckt, struct msghdr *msg, int ID, void *data, int datalen,int flags);

Pˇr´ıklad: funkce recvmsg vypln´ı strukturu, na kterou odkazuje ukazatel hdr a ta bude obsahovat informace o odesilateli. Chceme-li ihned odpovˇedˇet odesilateli, ˇze nˇeco nen´ı v poˇrádku, staˇc´ı zavolat send data pacet(sckr, hdr, -1, NULL, 0, 0). Funkce odeˇsle paket s ID -1 (ERR) na adresu odesilatele. Poˇzadovan´ y datov´ y tok pak generujeme jednoduˇse tak, ˇze v pravideln´ ych intervalech zas´ıláme pakety dané velikosti. Knihovna obsahuje dalˇs´ı pomocné funkce, ale ty nejsou d˚ uleˇzité k pochopen´ı fungován´ı aplikace. Na u ´ plném konci stoj´ı funkce tm sendstream(), která zuˇzitkovává vˇsechny dˇr´ıve uvedené funkce k zaslán´ı poˇzadovaného datového toku. Ve struktuˇre req jsou obsaˇzeny vˇsechny parametry. Tato funkce poˇc´ıtá s t´ım, ˇze m˚ uˇze být v pˇr´ıpadˇe serveru volána ve v´ıce vláknech. 16



int tm_sendstream(int serverSocket,struct sockaddr_in *to, stream_request_t *req)

Struktura sockaddr in je jiˇz známá, struktura stream request t je ukázána n´ıˇze.

typedef struct stream_request_ { char username[USERNAME_L]; char password[PASSWORD_L]; char mode; // ’u’ ... upload // ’x’ ... dual

: client -> server : client <-> server

// ’d’ ... download : client <- server uint32_t

packet_size;

uint32_t

packet_delay;

uint32_t

packet_num; //number of packets to be sent

char packet_data; // 0... random data // f... file - filename must be specified char filename[FILENAME_L]; uint32_t bandwidth;

// in bytes per second

uint32_t

stream_dur; // if packet_num == 0 packet will be sent for stream_dur sec

uint32_t

stream_size; // if packet_num == 0 && stream_dur==0 stream_size bytes wi

char

single;

} stream_request_t;

Kaˇzdý paket, kter´ y aplikace vys´ılá, obsahuje hlaviˇcku typu packet header t, coˇz je struktura

typedef struct packet_header_ { int32_t id; // packet ID struct timeval timestamp; // time at packet’s departure } 17

ˇ ˇ - TIMER.H 2.5. CASOVA C


packet_header_t;

timestamp obsahuje systémov´ y ˇcas v okamˇziku odeslán´ı paketu. Je potˇreba si uvˇedomit, ˇza paket stráv´ı nˇejaký ˇcas v s´ıt’ovém subsystému jádra operaˇcn´ıho systému, takˇze ˇcas reálného odeslán´ı paketu - tady ˇcasu, kdyˇz paket opouˇst´ı s´ıt’ovou kartu - se liˇs´ı od ˇcasu v hlaviˇcce paketu. Tento rozd´ıl m˚ uˇze ˇcinit des´ıtky mikrosekund. Hlaviˇckou se mysl´ı hlaviˇcka packet header t pˇridaná na aplikaˇcn´ı u ´ rovni, nikoliv hlaviˇcka IP ˇci UDP protokolu. Význam hodnoty ID paketu jiˇz byl popsán, jiˇz staˇc´ı jen doplnit hodnoty tak, jak jsou definovány v hlaviˇckovém souboru tm sockets.h.

#define REQ 0 #define DEN -2 #define ERR -1 #define ACK -3 #define FIN -5

2.5

ˇ Casovaˇ c - timer.h

Na kvalitˇe ˇcasovaˇce pˇr´ımo závis´ı kvalita generovan´ ych datov´ ych tok˚ u a tud´ıˇz i pˇresnost mˇeˇren´ı. Jelikoˇz ˇzádn´ y ze standardn´ıch systémov´ ych ˇcasovaˇc˚ u nedosahuje poˇzadovaného rozliˇsen´ı a pˇresnosti, bylo nutné implementovat vlastn´ı. Nejpˇresnˇejˇs´ı metodou se ukázala tzv. busy loop, ˇcili smyˇcka, které je v cyklu, dokud’ nen´ı splnˇena daná podm´ınka - vyprˇsel dan´ y ˇcas. Pˇr´ıklad busy loop:

while(!isolder(&now,&future)) { gettimeofday(&now,NULL); }

18

2.6. VSTUPNÍ PARAMETRY - PARSER.H


Periodicky se odmˇeˇruje nastavený ˇcas a smyˇcka se ukonˇc´ı aˇz po splnˇen´ı podm´ınky. Tato metoda funguje v´ ybornˇe, pokud je generován pouze jeden datov´ y tok. Smyˇcka totiˇz zcela logicky pohlcuje vˇetˇsinu výkonu procesoru a pokud je tˇechto smyˇcek puˇsteno v´ıce najendou, docház´ı k nepˇresnostem. Tento d˚ uvod a také pˇredpoklad, ˇze pro vˇetˇsinu mˇeˇrených datov´ ych tok˚ u bude ˇcekac´ı ˇcas pomˇernˇe vysok´ y, byl pro tyto vyˇsˇs´ı ˇcasy implementován dalˇs´ı ˇcasovaˇc, který pˇri ˇcekán´ı nechává procesor odpoˇcinout - vyuˇz´ıvá volán´ı usleep(), coˇz je uspán´ı vlákna na poˇzadovan´ y poˇcet mikrosekund. Tento ˇcasovaˇc je ménˇe pˇresný, ale po zavaden´ı korekce, kdy je porovnána nastavená a skuteˇcná ˇcekac´ı doba, dosahuje dobrých výsledk˚ u. Následuje pˇr´ıklad debugovac´ıho v´ ypisu ˇcasovaˇce s autokorekc´ı.

set=8000 measure=8369 rozdil=-369 should=7631 set=7631 measure=8021 rozdil=21 should=7610 set=7610 measure=8001 rozdil=1 should=7609

Set ... nastavená hodnota, measure ... zmˇeˇrená hodnota, should ... doporuˇcené nastaven´ı ˇcasovaˇce pro dalˇs´ı iteraci. Pokud jde o klienta, vˇzdy je pouˇzita busy loop, v pˇr´ıpadˇe serveru jen pokud jde ˇ o velmi krátké ˇcekac´ı ˇcasy. Pro dlouhé ˇcekac´ı doby je pouˇzita druhá metoda. Casovaˇ c je implementován v knihovnˇe timer, uˇzivatelské funkce jsou definovány v hlaviˇckovém souboru timer.h. Knihovna dále obsahuje funkce pro práci s ˇcasem a strukturou timeval, kterou pouˇz´ıvaj´ı jako windows, tak linuxové knihovny. Pokud by nároky na pˇresnost byly vyˇsˇs´ı, neˇz je standardn´ı linuxové jádro schopno zajistit, lze pouˇz´ıt nˇekteré ze speciáln´ıch realtime (RT) jader, popˇr´ıpadˇe pˇr´ımo RT distribuci (napˇr´ıklad ELinos).

2.6

Vstupn´ı parametry - parser.h

Parametry jsou pˇredávány z pˇr´ıkazové ˇrádky. Na zpracován´ı parametr˚ u byla pouˇzita knihovna getopt respektive jej´ı nadstavba getopt long. Tato knihovna je ˇs´ıˇrena pod 19



licenc´ı GNU Lesser General Public License[4], která pˇri dynamickém linkován´ı nijak neomezuje autorská práva autora aplikace, která tuto knihovnu pouˇz´ıvá. Pouze pˇri statickém slinkován´ı se na výslednou aplikaci automaticky vztahuje licence GPL a vˇsechny právn´ı aspekty z tohoto plynouc´ı. Knihovna um´ı jednoˇse pracovat s krátk´ ymi i dlouh´ ymi názvy parametr˚ u, dále lze nastavit, zda-li má dan´ y parametr povinnou hodnotu ˇci nikoliv. Pouˇzit´ı je velmi jednoduché - definice vstupn´ıch parametr˚ u je zˇrejmá z následuj´ıc´ıho pˇr´ıkladu:

static struct option long_options[] = { /* These options set a flag. */ {"verbose", no_argument,

&verbose_flag, 1},

{"brief",

no_argument,

&verbose_flag, 0},

{"server",

no_argument,

0, ’s’},

{"client",

required_argument, 0, ’c’},

{0, 0, 0, 0} };

Na pˇr´ıkladu vid´ıme vˇsechny moˇznosti vstupn´ıch parametr˚ u. Parametry --verbose a --brief nastavuj´ı hodnotu promˇenné verbose flag. Parametr --server , -s jsou identické a nepˇredpokládá se ˇzádná dalˇs´ı hodnota. Za parametrem --client ˇci -c mus´ı následovat hodnota. Knihovna tuto hodnotu nekontroluje, je potˇreba ji dále oˇsetˇrit. Pomoc´ı dalˇs´ı knihovn´ı funkce se procház´ı pole argument˚ u argv[], které obsahuje argumenty z pˇr´ıkazové ˇrádky. Nad touto knihovnou je postavena uˇzivatelská knihovna parser, která zpracovává vstupn´ı parametry, provád´ı kontrolu spr´ avnosti parametr˚ u - rozsahy, hodnoty. Pokud nejsou nˇekteré hodnoty nastaveny uˇzivatelem, jsou pouˇzity v´ ychoz´ı hodnoty napˇr´ıklad velikost datového paketu (1450B), port (5000), s´ıt’ové rozhran´ı (INADDR ANY), délka datového toku (10s). Hodnota 1450B nen´ı zvolena n´ ahodou. Modern´ı ethernetové s´ıtˇe maj´ı totiˇz hodnotu MTU (Maximum transmission unit) 1500B. MTU je velikost paketu, kter´ y projde pˇres s´ıt’ové zaˇr´ızen´ı (gateway, router, bridge...), aniˇz by byl IP paket fragmentován - rozdˇelen na v´ıce ˇcást´ı, z nichˇz kaˇzdá je menˇsi neˇz MTU. Pˇri fragmentaci se zvyˇsuje pravdˇepodobnost ztráty paketu, nebot’ pˇri ztrátˇe jedné z jeho ˇcást´ı je zahozen celý (plat´ı jen v pˇr´ıpadˇe UDP). Pokud od hodnoty MTU 1500B odeˇcteme velikosti 20



hlaviˇcek vˇsech niˇzˇs´ıch protokol˚ u, dostáváme se na hodnotu okolo 1450B - ne vˇsechny hlaviˇcky mus´ı být v paketu pˇr´ıtomny. Hodnota 1450B je nejvyˇsˇs´ı moˇzná velikost paketu, kter´ y na standardn´ı s´ıti projde bez fragmentace. Minimáln´ı hodnotu MTU pˇrenosové cesty lze zjistit tak, ˇze v hlaviˇcce IP protokolu nastav´ıme volbu DF (Don’t Fragment). Kaˇzdé zaˇr´ızen´ı na pˇrenosové cestˇe, jehoˇz MTU je menˇs´ı neˇz velikost paketu tento paket nam´ısto fragmentace skartuje a vyˇsle zpˇet ICMP zprávu ICMP ”Destination Unreachable (Datagram Too Big)”. Zaˇcneme-li na malé velikosti paketu a postupnˇe ji zvyˇsujeme, pak snadno nalezneme MTU celé trasy. Tato technika je pˇresnˇeji popsána v [6]. Dalˇs´ı funkc´ı knihovny je výpoˇcet hodnot ze zadan´ ych parametr˚ u. Zadá-li napˇr´ıklad uˇzivatel poˇzadovan´ y datov´ y tok a nic jiného, pouˇzije se výchoz´ı velikost paketu (1450B) pro v´ ypoˇcet rozestupu mezi pakety. Server tak vˇzdy dostává informace stejného typu a nemus´ı jiˇz ˇzádné dalˇs´ı výpoˇcty provádˇet. Posledn´ı d˚ uleˇzitou funkc´ı knihovny je generován´ı hash hodnoty ze zadaného hesla. Jak jiˇz bylo ˇreˇceno, pokud to jen bylo moˇzné, bylo dodrˇzeny názvy parametr˚ u testovac´ıho software iperf[5]. Mnoho jich bylo vypuˇstˇeno, protoˇze se týkaly jen protokolu TCP, dalˇs´ı zabrali jejich m´ısto, protoˇze iperf nˇekteré vlastnosti v˚ ubec nepodporuje.

Obr´ azek 2.5: iperf - http://dast.nlanr.net/Projects/Iperf

21

˚ 2.7. SEZNAM VSTUPNÍCH PARAMETRU

2.7


Seznam vstupn´ıch parametr˚ u s

l

Popis

-s

- -server

serverov´ y mód

-

-y

- -daemon

daemon mód

-

-r

- -root

exkluzivn´ı mód - do ukonˇcen´ı aktuáln´ıho

-

mˇeˇren´ı budou ostatn´ı ˇzádosti odm´ıtány. -c host

- -client

klientský mód - je potˇreba zadat adresu ser-

-

veru, na kter´ y se má klient pˇripojit. Pokud nen´ı zadán port (-p - -port), pouˇzije se výchoz´ı hodnota -i #

- -interval

interval, ve kterém jsou pravidelnˇe vypi-

0

sovány reporty -l #

- -len

velikost paketu v bytech

1450

-p #

- -port

port, na kterém beˇz´ı server

5000

-p #

- -port

port, na kter´ y se pˇripojuje klient

5000

-b #

- -bandwidth

datov´ y tok v bytech za vteˇrinu

-w #

- -win

-B #

- -bind

velikost pˇr´ıj´ımac´ıho bufferu dle systému s´ıt’ové zaˇr´ızen´ı, na kterém má aplikace na1 Mbs

1 Mbs

slouchat -d

- -dualtest

po pˇrijet´ı dat za serveru vyˇsle klient sv˚ uj tes-

-

tovac´ı datov´ y tok -u

- -upload

mˇeˇren´ı pouze ve smˇeru klient -¿ server

-

-n #

- -num

poˇcet paket˚ u datového toku

-

-t #

- -time

ˇcas v sekundách - délka datového toku

10

-T #

- -tout

ˇcas v sekundách - timeout pˇri komunikaci se

10

serverem -D #

- -delay

ˇcas v milissekundách - rozestup mezi pakety

-

-F fil

- -file

jméno souboru pro reprezentativn´ı datov´ y

-

tok -C fil

- -file

soubor, do kterého se má pˇripojit CSV re-

-

port -a user

- -username

uˇzivatelské jméno

-

-x pass

- -password

heslo

22


2.8. EXTRACTOR.H Pˇr´ıklad :

[bob@bob src]$ ./udptool --server --port 15000 -B 147.32.104.83

2.8

extractor.h

Tato knihovna obsahuje funkce, které z poˇzadovaného souboru naˇc´ıtaj´ı data a tato kop´ıruj´ı do bufferu. Data se naˇc´ıtaj´ı postupnˇe aˇz ke konci souboru. Pokud je poˇzadováno v´ıce dat, neˇz zbývá do konce souboru, zaˇcne se znovu od zaˇcátku.

2.9

Hash - md5.h

Pro hashovan´ı hesla byla pouˇzita hashovac´ı funkce MD5 [8], kterou v knihovnˇe md5 podle uvedeného RFC 1321 implementoval L. Peter Deutsch ([email protected]) a dal ji volnˇe k pouˇzit´ı pˇri zachován´ı urˇcitých podm´ınek, jako je napˇr´ıklad zm´ınka o autorovi a nezasahován´ı do kódu. Sama funkce MD5 je jiˇz pˇrekonána, pˇresto pro naˇse pouˇzit´ı postaˇcuje.

2.10

Reporty - reporter.h

Tento hlaviˇckov´ y soubor popisuje funkce, které se pouˇz´ıvaj´ı k vyhodnocován´ı pˇr´ıchoz´ıch datov´ ych tok˚ u. Výsledn´ y report v pˇr´ıpadˇe duáln´ıho módu zas´ılá server klientovi. Zastˇreˇsuj´ıc´ı funkce data stream eval() vyhodnocuje vlastn´ı datov´ y tok. Jako vstup slouˇz´ı ukazatel

23


2.11. SERVER - TM SERVER.H

na hlaviˇcku paketu - packet header t. Funkce vyhodnot´ı spoˇzdˇen´ı paketu, poˇc´ıtá ztracené pakety a pakety mimo poˇrad´ı. Hlaviˇckov´ y soubor dále definuje funkce na pˇrevod ˇc´ıselných promˇenných na textov´ y HEX formát.

2.11

Server - tm server.h

Serverová ˇcást aplikace je urˇcena k provozu pouze na operaˇcn´ım systému Linux. Vyuˇz´ıvá vlákna dle POSIX specifikace pro zas´ılan´ı datov´ ych tok˚ u v´ıce klient˚ um souˇcasnˇe. Jelikoˇz vláknu lze pˇredat pouze obecný ukazatel (void *), obsahuje knihovna podp˚ urné datové struktury a funkce, které umoˇzn´ı pˇredat vytváˇrenému vláknu informace o datovém toku. Pro kaˇzdého klienta, ˇzádaj´ıc´ıho o testovac´ı datov´ y tok je tedy vytvoˇreno vlákno, na jehoˇz výsledky ovˇsem hlavn´ı vlákno neˇceká. Vlákno samotné nepˇrij´ımá pakety od klienta. M´ısto toho kontroluje sd´ılené datové struktury, napˇr´ıklad seznam pˇrijat´ ych servisn´ıch paket˚ u. Pˇr´ıstup ke sd´ıleným strukturám je ˇr´ızen pomoc´ı mutex˚ u. Vlákno po odeslán´ı dat a paketu DEN ˇceká na paket ACK, po nˇem odes´ılá paket FIN a opˇet ˇceká na ACK. Server m˚ uˇze obsluhovat teoreticky neomezený poˇcet klient˚ u, jediný limit je pamˇet’ a maximáln´ı poˇcet souˇcasnˇe spuˇstˇených vláken, které dovol´ı spustit operaˇcn´ı systém. Pokud si odmysl´ıme vys´ılac´ı vlákna, funguje ˇctec´ı ˇcást serveru i klienta jako asychronn´ı stavov´ y automat, který je taktován pˇr´ıchody paket˚ u na socket. Automat kaˇzdý paket vyhodnot´ı a provede pˇr´ısluˇsnou akci. Po ukonˇcen´ı akce se opˇet ˇceká na paket. U klientské ˇcásti akce blokuje, ˇcili klient nem˚ uˇze zpracovávat dalˇs´ı paket. Server naopak kaˇzdou sloˇzitˇejˇs´ı akci pouˇst´ı ve vláknˇe, takˇze témˇeˇr ihned m˚ uˇze zpracovávat dalˇs´ı paket.

24


2.12. KLIENT - TM CLIENT.H

2.12

Klient - tm client.h

V pˇredchoz´ıch ˇcástech byla ˇcinnost klientské ˇcásti aplikace popsána podrobnˇe a z implementaˇcn´ıho hlediska nepˇridává nic nového. Tyto ˇcásti aplikace jsou oddˇeleny pˇredevˇs´ım proto, aby se zjednoduˇsila kompilace pod obˇema operaˇcnimi systémy. Pokud by mˇel systém bˇeˇzet jen pod operaˇcn´ım systémem Linux, nebylo by toto oddˇelen´ı v˚ ubec potˇreba. Klientská ˇcást ma pˇreci jen jednu odliˇsnost a to je voliteln´ y timeout, po jehoˇz pˇrekroˇcen´ı bude spojen´ı vyhodnoceno jako ztracené a klient ukonˇcen.

Obr´ azek 2.6: Sn´ımek terminálu

25

´ 2.13. UPRAVY PRO WINDOWS

2.13


´ Upravy pro Windows

Jak jiˇz bylo ˇreˇceno, pro kompilaci pod obˇema systémy nebylo potˇreba velké mnoˇzstv´ı u ´ prav. Pˇri kompilaci je serverová ˇcást skryta, zb´ yvaj´ı tedy jen rozd´ıly mezi knihovnami socket.h a winsock.h. Aˇc se základn´ı funkce jmenuj´ı r˚ uznˇe (viz strana 13 - 2.4.1), jejich funkce je podobná. Postup pro kompilaci pod operaˇcn´ım systémem Windows bude popsán v závˇereˇcných kapitolách.

26

Kapitola 3 Pouˇ zit´ı

Aplikace je implementována, ukaˇzme si jej´ı pouˇzit´ı a chován´ı v reálné situaci. Spust’me serverovou aplikaci na linuxovém stroji pˇr´ıkazem

[bob@bob src]$ ./udptool --server --port 10000 -B 10.0.0.139

Server se spustil a naslouchá na rozhran´ı 147.32.104.83, portu 15000. Server je ted’ pˇripraven pro pˇr´ıjem poˇzadavk˚ u od klient˚ u. Spust’me tedy klient.

[bob@localhost src]$ ./udptool -c 10.0.0.139 -p 10000 -l 1900 -t 5 -i 1 --username bob --password threepo -t 5 -i 1

Význam parametr˚ u je zˇrejm´ y, pˇresto zopakujeme, co vlatnˇe po programu ˇzádáme. Program se má spustit v klientském módu a pˇripojit se k serveru beˇz´ıc´ımu na IP adrese 10.0.0.139. Má zaslat poˇzadavek na datov´ y tok, kter´ y bude obsahovat pakety velké 1900B. Uˇzivatelské jméno je pak bob, heslo 453sdfs. Dále sdˇelujeme, ˇze chceme kaˇzdou vteˇrinu zobrazovat pr˚ ubˇeh mˇeˇren´ı. Server obdrˇzel poˇzadavek, klient byl u ´spˇeˇsnˇe ovˇeˇren a datov´ y tok tak mohl b´ yt zaslán. Pod´ıvejme se na klientskou obrazovku. 27

ˇ Í KAPITOLA 3. POUZIT [bob@localhost src]$ ./udptool -c 10.0.0.139 -p 10000 --username bob --password threepo -l 1900 -t 5 -i 1 -----------------------------------------Connecting to 10.0.0.139:10000 Timeout set to 5 sec Request username

: bob

pckt size

: 1900

pckt delay : 3800 pckt data

: 0

bandwidth

: 500000

stream dur : 5 -----------------------------------------Interval

Transfered

Bandwidth

Jitter

00-01s

0.00 kB

-0.00kBs

0.000ms

0|

01-02s

491.00 kB

487.82kBs

0.015ms

0| 266

02-03s

981.00 kB

488.06kBs

0.015ms

0| 530

03-04s

1471.00 kB

488.14kBs

0.015ms

0| 794

04-05s

1961.00 kB

488.18kBs

0.015ms

0|1058

DEN from 10.0.0.139:10000 lastID=1317 -----------------------------------------[Server -> Client] -----------------------------------------Sent packets: 1317 Recv packets: 1317 Lost packets: 0 Pckt loss : 0.00 % Duplicated

: 0

Out of order: 0 Jitter

: 15 usec

Avg delay

: 3799 usec

Avg ping

: 15 usec

Duration

: 5.001 s

Transfered

: 2441 kB 28

Lost|Total 1

ˇ Í KAPITOLA 3. POUZIT Speed

: 488.216 kBs (499933 Bs)

Posilam FIN ACK [bob@localhost src]$

V horn´ı ˇcásti obrazovky vid´ıme informace o poˇzadovaném datovém toku, ve stˇredn´ı ˇcásti pr˚ ubˇeˇzné výsledky mˇeˇren´ı a nakonec souhrné informace. Jelikoˇz server i klient v tomto pˇr´ıpadˇe beˇzely na stejném stroji, ˇzadn´ y paket se neztratil. Log serveru pak vypadá takto:

06:40:49 bob udptool[2241]: Connection from 127.0.0.1:32788, bob - access granted 06:40:54 bob udptool[2241]: ACK from 127.0.0.1:32788 06:40:55 bob udptool[2241]: ACK from 127.0.0.1:32788 06:40:56 bob udptool[2241]: Client 127.0.0.1:32788 disconnected

Ukaˇzme si, jak vypadá v´ ystup aplikace na typické asymetrické s´ıt´ı - v tomto pˇr´ıpadˇe ADSL.

-----------------------------------------[Client -> Server] -----------------------------------------Sent packets: 281 Recv packets: 279 Lost packets: 2 Pckt loss : 0.71 % Duplicated

: 0


: 443 usec

Avg delay

: 14423 usec

Avg ping

: 587128 usec

Duration

: 4.010 s

Transfered

: 271 kB 29

ˇ Í KAPITOLA 3. POUZIT

3.1. USERADD Speed

: 67.581 kBs (69326 Bs)

-----------------------------------------[Server -> Client] -----------------------------------------Sent packets: 281 Recv packets: 138 Lost packets: 143 Pckt loss : 50.89 % Duplicated

: 0


: 12630 usec

Avg delay

: 37619 usec

Avg ping

: 569456 usec

Duration

: 5.154 s

Transfered

: 133 kB

Speed

: 25.959 kBs (26582 Bs)

Posilam FIN ACK

Vid´ıme, ˇze na cestˇe server - klient se ztratilo 50 % paket˚ u a pˇrenosová rychlost byla 26 kB/s, coˇz je 208kb/s, pˇriˇcemˇz teoretická maximáln´ı rychlost linky byla 256kb/s.

3.1

useradd

Souˇcást´ı aplikace je nástroj useradd, kter´ y slouˇz´ı k pˇridáván´ı uˇzivatel˚ u.

[bob@localhost useradd]$ ./useradd Usage useradd USER [filename]

Aplikace jako paremetry pˇrij´ımá jméno uˇzivatele, kterého pˇridáváme a cestu k souboru s hesly. useradd nekontroluje jiˇz zapsané uˇzivatele, pˇr´ıpadné duplicity ˇreˇs´ı uˇzivatel. Jde

30

´ ´ SKRIPT 3.2. TOOL.SH - UKAZKOV Y

ˇ Í KAPITOLA 3. POUZIT

o obyˇcejný textov´ y soubor, kter´ y je moˇzno editovat v libovolném editoru a uˇzivatele odstranit. Nástroj beˇz´ı pod Linuxem i Windows.

3.2

tool.sh - uk´ azkov´ y skript

Jak jiˇz bylo zm´ınˇeno v u ´ vodu, byla aplikace navrˇzena tak, aby se klient dal pouˇz´ıvat v uˇzivatelsk´ ych skriptech.

#!/bin/sh ./udptool -c $1 -p $2 -a bob -x threepo -b $3 -t 2 -u | grep Lost

Uvedený skript tool.sh spust’me s parametry 10.0.0.139 10000 40000. Klient se pˇripoj´ı na IP adresu 10.0.0.139, port 10000 a bude pos´ılat na server datov´ y tok o rychlosti 400 000 bajt˚ u za sekundu. Pˇr´ıkaz grep zajist´ı, ˇze se nám vyp´ıˇse pouze ˇrádek se ztracenými pakety.

[bob@localhost src]$ ./tool.sh 10.0.0.139 10000 40000 Lost packets: 15 Pckt loss : 26.45 % [bob@localhost src]$

31

Kapitola 4 Kompilace

4.1

Linux

Pro zkompilováni aplikace ze zdrojov´ ych kód˚ u potˇrebujeme následuj´ıc´ı software:

• autoconf • automake • gcc

Aplikace vyˇzaduje knihovnu libpthread.so, která je ovˇsem souˇcást´ı drtivé vˇetˇsiny distribuc´ı. Nejdˇr´ıve je tˇreba spustit skript configure a poté jiˇz staˇc´ı jen make popˇr´ıpadˇe make all. Výsledné spusstilený binárn´ı soubor udptool se nacház´ı v adresáˇri src.

32

4.2. WINDOWS

4.2

KAPITOLA 4. KOMPILACE

Windows

Pro kompilaci ze zdrojov´ ych kód˚ u potˇrebujeme bal´ık nástroj˚ u MinGW - Minimalist GNU for Windows(http://www.mingw.org/, kter´ y obsahuje vˇsechny potˇrebné nástroje (ˇcili ekvivalenty v´ yˇse uvedených linuxov´ ych nástroj˚ u) a knihovny. ´ Uvodn´ ı krok je stejn´ y - v konzoli MSYS spust´ıme configure. Nyn´ı je potˇreba v soubotu src/Makefile nahradit odkaz na knihovnu pthread (ˇretˇezec -lpthread) odkazem na knihovnu WinSock2 (-lws2 32). A nyn´ı jiˇz opˇet staˇc´ı make.

33

Kapitola 5 Z´ avˇ er

Pˇri implementaci software, kter´ y byl c´ılem diplomové práce, docházelo k spˇresˇ nován´ı poˇzadavk˚ u. Výhodou jsou jasné poˇzadavky a t´ım i mantinely, ve kter´ ych jsem se pohyboval. Nev´ yhodou pak sloˇzitˇejˇs´ı pˇr´ıdáván´ı nové funkˇcnosti, se kterou nebylo v návrhu od poˇcátku poˇc´ıtáno. Vˇetˇsina poˇzadavk˚ u byla splnˇena, ale v´ ysledky budou zˇrejmé aˇz po delˇs´ıch zkuˇsenostech zadavatele. Vytvoˇrený software nen´ı naprostou novinkou, nebot’ vznikl na základˇe nespokojenosti s jin´ ymi aplikacemi, jejichˇz dobré vlastnosti mˇel pˇrevz´ıt a pˇr´ıdat dalˇs´ı, kterými v té dobˇe existuj´ıc´ı aplikace nedisponovaly. Poˇc´ıtám s t´ım, ˇze pˇri pouˇz´ıván´ı vyplynou dalˇs´ı poˇzadavky a rád tuto aplikaci uprav´ım tak, aby dál dobˇre slouˇzila svému u ´ˇcelu.

34

Literatura

[1] User datagram protocol. http://en.wikipedia.org/wiki/User Datagram Protocol. [2] Winsock reference. http://msdn2.microsoft.com/en-us/library/ms741416.aspx. [3] sys/socket.h - internet protocol family. http://www.opengroup.org/pubs/online/ 7908799/xns/syssocket.h.html, 1997. [4] Gnu lesser general public license. http://www.gnu.org/licenses/lgpl.html, 1999. [5] Mark

Gates,

Ajay

Tirumala,

J.

D.

K.

G.

Iperf user docs.

http://dast.nlanr.net/Projects/Iperf/iperfdocs 1.7.0.php, 2003. [6] Mogul, J., and Deering, S. Path mtu discovery. RFC 1191 (1990). [7] Postel, J. User datagram protocol. RFC 768 (1980). [8] Rivest, R. The md5 message-digest algorithm. RFC 1321 . [9] Sollins, K. The tftp protocol (revision 2). RFC 1350 (1992). [10] Srisuresh, P., and Egevang, K. Traditional ip network address translator (traditional nat). RFC 3022 (1991). [11] Stevens, W. R. UNIX Network Programming: Networking APIs – Sockets and XTI, vol. 1. Prentice Hall;, 1997.

35

Pˇ r´ıloha A CD s aplikac´ı

K této práci je pˇriloˇzeno CD, na kterém jsou uloˇzeny zdrojové kódy, manuál a verze aplikace pro vˇsechny podporované systémy - Windows ˇrady NT (NT, 2000, XP) a Linux.

• bin win32 linux • src • data • dip

bin zkompilované spustitelné soubory win32 linux src zdrojové kódy data soubory pro otestován´ı reprezentativn´ıch datových tok˚ u dip tato práce ve formátu PDF I

Fakulta elektrotechnická

Recommend Documents