Fakulta elektrotechnická

České vysoké učení technické vpraze Fakulta elektrotechnická DIPLOMOVÁ PRÁCE Použití operačního systému Linux pro měřící aplikace Praha, květen 2007 Autor: Bohuslav Stalmach Vedoucí práce: Doc. Ing. Jaroslav Roztočil, CSc.

Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatněapoužil jsem pouze podklady uvedené vpřiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu 60 Zákona č.121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne podpis i

Poděkování Na tomto místě bychrád poděkoval především rodičům za podporu po celou dobu studia na ČVUT. Nemalé díky patřívedoucímu práce Doc. Ing. Jaroslavu Roztočilovi, CSc za jeho nesmírnou trpělivost a cenné přípomínky k diplomové práci. ii

Abstrakt Cílem diplomové práce bylo v jazyce C vyvinout multiplatformní software, který otestuje vlastnosti přenosové cesty IP sítí sdůrazem na ztrátovost paketů apřenosovou rychlost. Serverováčást je spustitelná podoperačním systémem Linux, klientská část pak pod systémy Linux a 32-bitovými Windows. Byl použit UDP protokol a to tak, aby bylo možné měřit i v sítích, které používají NAT/PAT techniky a to obou směrech. 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ázků viii 1 Úvod 1 1.1 UDP protokol................................. 1 1.1.1 Struktura paketu........................... 2 1.2 Výhody UDP protokolu při testování IPsítí................ 3 1.3 NAP/NAT................................... 3 2 Analýza 5 2.1 Požadavky na aplikaci............................ 5 2.1.1 Obecné................................ 5 2.1.2 Server................................. 5 2.1.3 Klient................................. 7 2.2 Design..................................... 8 2.2.1 Komunikační protokol........................ 8 2.2.2 Význam jednotlivých paketů..................... 9 2.2.3 Návrh aplikace............................ 10 2.2.3.1 Klient............................ 10 2.2.3.2 Server............................ 11 2.3 Technická poznámka............................. 12 2.4 Sít ová vrstva - tm sockets.h......................... 12 2.4.1 Nejnižší vrstva............................ 12 2.4.2 Servisní vrstva............................ 15 2.5 Časovač - timer.h............................... 18 2.6 Vstupní parametry - parser.h........................ 19 2.7 Seznam vstupních parametrů........................ 22 2.8 extractor.h................................... 23 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.............................. 25 2.13 Úpravy pro Windows............................. 26 3 Použití 27 3.1 useradd.................................... 30 3.2 tool.sh - ukázkový skript........................... 31 4 Kompilace 32 4.1 Linux..................................... 32 4.2 Windows.................................... 33 5 Závěr 34 Literatura 35 A CD s aplikací I vii

Seznam obrázků 1.1 Zapouzdření UDP datagramu........................ 1 1.2 UDP datagram................................ 2 1.3 NAT...................................... 4 2.1 Souběh požadavků v jednom bodě...................... 6 2.2 Standardní průběh 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 Úvod Vsoučasnédoběexistujeněkolik podobných aplikacíatovčetnězdrojových kódu mnohdy sotevřenou licencí. Všechny tyto aplikace však postrádají klíčové vlastnosti, které zadavatele vedly k požadavku na aplikaci zcela novou. Zásadní rozdíl je především v možnosti ověření uživatelů, kteřížádají otestovacídatový tok. Dalšízvelkých rozdílů je využití jen jednoho UDP portu na straně serveru, cožhlavnídůvod, proč jen nelze modifikovat již existující software. 1.1 UDP protokol Obrázek 1.1: Zapouzdření UDP datagramu UDP (User datagram protocol) je součástí sadyinternetových protokolů atvoříspolečně s TCP protokolem většinu internetové komunikace. Protokol je popsán v RFC 768 [7]. 1

1.1. UDP PROTOKOL KAPITOLA 1. ÚVOD UDP byl původně určen pro zasílání krátkých zpráv (datagramů)ajakotakový postrádá spolehlivost TCP. Mezi komunikujícími zařízeními se nevytváříspojení, čímž odpadárežie na vytvoření a udržování takovéhoto spojení. Díky těmto vlastnostem je UDP protokol vhodný pro aplikace, kde jde především o přenosovou rychlost a ztráta několika paketů nevede k zásadní ztrátě informace. Použivá se tedy pro aplikace, kde server na základě krátkých požadavků rozesílá velkákvantadatvelkému počtu klientů. UDP protokol podporuje zasílání zprávy všem počítačům na lokální síti (broadcast) a všem zájemcům o danou službu (multicast). Z toho důvodu UDP protokol nalezneme u aplikací prošíření audiovizuálních dat. Zrozšířených použití 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čka obshuje pouze čtyři části, z nichž dvě jsou volitelné. Obrázek 1.2: UDP datagram zdrojový portidentifikuje odesilatele a je použit, pokud očekáváme odpověd. Jdeonepovinný parametr. cílový portpodle tohoto portu se na cílovém počítači vybírá příslušná aplikace. Parametr je povinný. 2

1.2. VÝHODY UDP PROTOKOLU PŘI TESTOVÁNÍ IPSÍTÍKAPITOLA 1. ÚVOD délka 16 bitová hodnota, která obsahuje délku celého datagramu (včetně hlavičky) v bytech. Minimální délka je 8 bytů, což jevelikosthlavičky, kotrolní součet nepovinná hodnota pro kontrolu paketu. Ač nepovinná, většinou se používá. Kromě RFC 768 [7], je možno pro více informacínavštívit příslušnou stránku na Wikipedii [1], či do [11]. 1.2 Výhody UDP protokolu při testování IPsítí UDP protokol sám o sobě nezaručuje, že datagram dorazínamísto určení astejnětak nezaručuje, že datagramy dorazí vestejném pořadí, v jakém byly vyslány. V některých případech může dojít i ke zduplikování paketu uprostřed přenosové cesty. Aprávě výše uvedené vlastnosti lze s výhodou využít pro testování IPsítí. Pokud jsou na vysílací straně pakety označeny, lze na straně příjemce snadno zjistit, jestli se na přenosové cestě některý paket ztratil či zda došlo ke změně pořadípaketů. Tyto vlastnosti jsou velmi výhodné pro samotné měření, ale aplikace si musí samapřidat vlastní mechanismy, které zabezpečídoručenídůležitých zpráv. 1.3 NAP/NAT Network address translation (NAT) je technika vyvinutá vipv4sítích kvůli nedostatku IP adres. Hlavním využitím je připojení lokální sítě k Internetu přes jedinou veřejnou IP adresu tak, že při cestě datagramu z lokálního počítače router (gateway) nahradí zdrojovouadresusvouvlastní adresou, takže z pohledu cílového počítače tento komunikuje pouze s gateway. Dalšívýhodou je skrytí lokálních počítačůpřed vnějšísítí, které tak nejsou běžnými metodami přímo dostupné z Internetu a klesá takpravděpodobnost napadení počítače a snižuje se možnost vzdálené nákazy virem (červem). Omezením je pak nefunkčnost některých služeb či náročnost jejich konfigurace. Pokud použijeme Port Address Translation (PAT), router nahrazuje jednak IP adresu, jednak zdrojový port datagramu. Více v RFC 3022[10]. Je-li klient skryt pomocí některé zpředchozích technik před veřejnou sítí, server takovéhoto klienta nevidí. Teprvé poté, co klient zašle svůj datagram na server, vytvoří 3

1.3. NAP/NAT KAPITOLA 1. ÚVOD se v routerech na cestě patřičnésměrovací tabulky. Jedobrésiuvědomit, že port i adresa UDP paketu, který přichází naserversemůžou lišit od reálné adresy klienta. Je tedy zbytečné na aplikační úrovni vkládat na straně klienta adresu, nebot bude s velkou pravděpodobností přepsána. Jediné, co NAT zaručuje je, že pokud jsou vyslány z počítače za NATem pakety z jednoho zdrojového portu, budou se i zvnějšku jevit, že byly vyslány z jednoho portu, ačkoliv číslo portu se může na obou stranách lišit. Obrázek 1.3: NAT 4

Kapitola 2 Analýza 2.1 Požadavky na aplikaci 2.1.1 Obecné Zadání diplomovépráce poměrně přesně definujepožadavky na aplikaci. Při realizaci je již odpočátku nutné počítat s tím, že klientská část musí být zkompilovatelná -provozu schopná -jaknaoperačním systému Linux, tak na 32-bit verzích Microsoft Windows. Dalšípožadavek, který jenaprvní pohled skryt, je zaručená funkčnost aplikace i v sítích za NAT/PAT. Předpokládá se, že server je veřejně přístupný, kdežto klient je v síti neveřejných adres. 2.1.2 Server Zásadním požadavkem je nutnost použít na straně serveru pro komunikaci pouze jeden UDP port. Klasické klient UDP server aplikace, například TFTP použivající protokol stejného jména, který je definovám v RFC 1350 [9], fungují jinak. Server naslouchá na obecně známem portu (v případě TFTP je to port 69). Klient zašle datagram na tento 5

2.1. POŽADAVKY NA APLIKACI KAPITOLA 2. ANALÝZA port, server vytvořínovýsocketadalší komunikace s klientem probíhá jižpřes jiný UDP port. Tímto způsobem se obejde faktická neexistence dvoubodového spojeníznámeho z protokolu TCP, kdy přes jeden TCP port na straněserverumůže kumunikovat několik klientů vjedenokamžik. Ale jak již bylořečeno, tuto techniku nelze využít. Dalšíodlišností od existujících aplikacíjeověřeníuživatele, kterýžádáodatovýtokpomocíuživatelského jména a hesla. Jedině vpřípadě, že souhlasí obaúdaje se záznamy na serveru, je datový tok vyslán. Vzhledem k odstavci v sekci 1.3 je třeba zajistit, aby server správněčetl adresu příchozího paketu a mohl tak komunikovat s klinety za NAT/PAT. Obrázek 2.1: Souběh požadavků v jednom bodě Posledním požadavkem na server je použití reprezentativních datových toků pro testování linkové vrstvy a vlivu komprese na přenosové charakteristiky. Při tomto požadavku budou použity externí souboryrůzných obsahů (komprimované video, zip soubory, obrázky, text), jejichž obsahem budou pakety plněny. Na linkové vrstvě TCP/IP protokolu je totiž implementováno několik protokolů, kterédokáží komprimovat data, čímžsnižují velikost paketu a teoreticky zvyšují propustnost takové sítě. Je zřejmé, že například již vysoce zkomprimované MPEG video nebude při přenosu dále komprimováno, ale například u bitmapových obrázkůči textu dosáhne komprimační algoritmus zajímavých kompresních poměrů. Použitím různých reprezentativních datových tokůmůžeme ověřit funkčnost kompresních algoritmů napřenosové cestě. Z protokolů linkové vrstvy, které jsouschopny datové kompresejmenujmealespoň protokoly PPP, Frame Relay, High-Level Data Link Control (HDLC) a X.25. 6

2.1. POŽADAVKY NA APLIKACI KAPITOLA 2. ANALÝZA Kritickou částí aplikace bude časovač, který zaručí, že rozestupy mezi pakety budou odpovídat požadavku klienta. Musí být schopen správné funkce i při vysílání více datových toků různým klientům. Server bude schopen datové toky nejen vysílat, ale také přijímat datový tok od klienta a to bud samostatně v obou směrech, či v duálním režimu, kdy se postupně změřípřenosová cesta v obou směrech datovým tokem shodných parametrů. Je důležité zajistitvýměnu výsledků měření mezi serverem a klientem. 2.1.3 Klient Důležitým požadavkem, který vyplynul až vprůběhu řešení, je možnost použití klientské části aplikace v uživatelských skriptech. Je tedy potřeba, aby klient dokázal zpracovat požadavky z příkazovéřádky a aby takto bylo možno nastavit všechny požadavky na datový tok.vevšech žádostech o datový tokmusíbýt uveden uživatel a heslo. Heslo se zasílá v hash podobě -odtudplynepotřeba vybrat vhodnou hashovací funkci.uživatel může zadat datový tokv raw podobě - to jest velikost paketů a rozestup mezi nimi. Druhou možností je zadat datový tok jako definovanou přenosovou rychlost, která je doplněna bud informací o velikosti paketu či rozestupu mezi pakety. Ostatní parametry budou dopočítány. Další, výslovně zadané parametry, jsou typ výplně paketu a timeout pro komunikaci se serverem. Pro lepší funkci budou implementovány další parametry, které používá software iperf, kterýbylvminulostipoužíván zadavatelem. Po přijetídatového toku klient vyhodnocuje datovýtokzněkolika hledisek: ztrátovost paketů, změna pořadípaketů, přenosová rychlost, rozestupy mezi pakety, kolísání rozestupů (jitter). V normálním režimu vypisuje klient výsledky na standardní výstup, popřípadě do CSV souboru, což jevýhodné zejména při opakovaném měření. Klient dokáže datový tok nejen zpracovat, ale v případě duálního režimu i vyslat datový tok na server. 7

2.2. DESIGN KAPITOLA 2. ANALÝZA 2.2 Design 2.2.1 Komunikační protokol Klient a server mezi sebou komunikují pomoci UDP datagramů. Datagram obsahuje ID paketu, časovou značku a data. Podle ID paketu se datagramy dělí nadatové(id > 0) a pakety nesoucí informaci(id < 0). Tyto se dále dělí na pakety servisní (ACK, DEN, FIN, ERR) a reporty. Speciální paketsid = 0 (REQ) obsahuje žádost o datový tok a jako takový vždy zahajuje komunikaci. Na obrázku 2.2 je vidět standardní průběh komunikace se serverem. Pokud v průběhu komunikace vznikne chyba, je vyslán paket ERR, který obsahuje kód chyby. Obrázek 2.2: Standardní průběh komunikace Jelikož je UDP protokol nespolehlivý, je potřeba na aplikační úrovni zajistit ověření doručení servisních a informačních paketů. Nejjednoduším řešením je opakované zasílání po určitém časovém intervalu, dokud neobdržíme odpověd či pokud není překročen stanovený počet opakování. Princip je na obrázku 2.3. Protože klient i server mohou býti kompilovány na různých softwarových a hardwarových architekturách, není semožné spolehnout na to, že číselné hodnoty budou na obou 8

2.2. DESIGN KAPITOLA 2. ANALÝZA stranách interpretovány stejně například kvůli odlišnému pořadínejvyšších a nejnižších bytů. Čísla budou překódována do šestnáctkové soustavy (HEX) a zasílána jako text, kdy jeden znak bude mít jeden byte. Tímto se vyhneme potížím s pořadím bytů včíselné proměnné. Obrázek 2.3: Opakované vyslání paketu 2.2.2 Význam jednotlivých paketů REQ -request-prvnípaket,který klient posílánaserver.sloužíkověření uživatele azároveň k definování požadovaného datového toku. ACK - acknowledgement- potvrzuje, že paket byl přijat. V případě, že předchozí paket byl REQ, potvrzuje ověření uživatele. ERR - error - při zpracování požadavků vznikla chyba. V případě, že předchozí paket byl REQ, oznamuje paket, že uživatel nebyl korektně ověřen. DEN -dataend-předchozí datový paket byl poslední. Tento paket obsahuje také informaci o ID posledního vyslaného paketu, jinými slovy počet odeslaných paketů. FIN - finish - vysílací strana ukončuje komunikaci 9

2.2. DESIGN KAPITOLA 2. ANALÝZA 2.2.3 Návrh aplikace Server i klient sdílí většinu kódu, využívají stejné knihovny. Rozdíl je především v tom, že server je vícevláknový - využívá POSIXvláken operačního systému Linux. Vlákna jsou využita pouze pro vysílání datových tokůodserverusměrem ke klientovi. Příjem paketů se shodně na klientu i serveru zpracovává sekvenčně vhlavním vlákně. Vnásledujících odstavcích je bližšínávrh aplikace. Text se již nezabývá ověřováním přijetí paketů. 2.2.3.1 Klient Klient je spouštěn z příkazovéřádky. Načte uživatelem definované parametry a nezadané parametry doplní navýchozí hodnoty. Jelikož může být datový tok definován neuplnými parametry, klient zbýlé parametry dopočítá. S takto vypočtenými daty zašle REQ paket. Po obdrženípaketuackčeká napříchozídatový tok. Jelikož paketacksemůže po cestě ztratit, je zaslání paketu ACK v tomto případě nepovinné a klient přichozí datové pakety správně zpracuje i bez tohoto potvrzení. Po příchodu prvního datového paketu odměříčas. Dokud jsou ID paketů vetšínež nula, načte z hlavičky paketu časovou značku a vypočítá rozdíl oproti aktuálnímu času. Dále sleduje časový rozdíl oproti minulému paketu. Pokud se ID paketu nelišíodpředchozího ID právě od jedničku, započítá jejjako ztracený. Pokud je ID paketu nižšínežpředchozí ID, započítá jej jako paket mimo pořadí asnížípočet ztracených paketů. Jakmile klient obdrží paket DEN, který zároveň obsahuje informaci o posledním zaslaném ID paketu, vypočte přenosovou rychlost, průměrný rozestup mezi pakety, nejistotu rozestupů. V duálním režimu server po odeslání paketudenodešle paket REQ a klient tentokráte vysílá datovýtoksměrem k serveru. Po odeslaní paketu DEN klientem čeká klient na report ze serveru a poté ukončuje komunikaci. Podle požadavků uživatele pak tiskne formátovanou závěrečnou zprávu na standardní výstup, popřípadědocsv souboru pro pozdějšízpracování. Toto je poslední akce, program se ukončí. 10

2.2. DESIGN KAPITOLA 2. ANALÝZA 2.2.3.2 Server Po spuštění serverpřijímá požadavky na uživatelem definovaném portu. Při obdržení paketu s jiným než nulovým ID ověřínejdříve, jestli paket pocházíodověřeného uživatele. Pokud ne, paket je zahozen a dále nezpracováván. Paket s ID = 0 obsahuje uživatelské jméno a heslo, které jeověřeno proti seznamu uživatelů. Pokud je ověření vpořádku, server vytvořínovévlákno, kteréodešle paket ACK a po definovanéprodlevězačne vysílat požadovanýdatovýtok. Nazávěr odešle paket DEN, kterým signalizuje konec vysílání. Vpřípadě, že součástí požadavku na datovýtokbylažádost o duální režim, nevyřazuje server klienta ze seznamu ověřených klientů, ale odesílápaketreq.hlavnívlákno serveru mezitím zpracovává dalšípříchozípakety. Prokaždého klienta, který požádal o duální režim má server vytvořen záznam, do kterého ukládá informace o paketech. Po příchodu paketu DEN vyhodnotí datový tok a report zašle klientovi. Záznam je smazán a klient je ostraněn ze seznamu ověřených klientů. Autentizace platíjenproprávě 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ůležitější informace - spuštění serveru, vypnutí a neuspěšná autentizace včetně informací o klientovi, který sepokusilopřipojení. Do svého logu si server zapisuje stejné zprávy jako na výstup s tím, že výstup na obrazovku lze zakázat - tzv. tichý režim. Pokud server běží v konzoli, je možnéhoukončit stiskem kláves Ctrl+C, popřípadězasláním signálu SIGTERM, po jehožobdržení se server korektně ukončí. Server může být spuštěn takéjakosystémový démon (daemon) běžící na pozadí. Počet současně bežících serverů není omezen, v systémovém logu jsou jednotlivé zpravy odlišeny pomocí PID (process id). 11

2.3. TECHNICKÁ POZNÁMKA KAPITOLA 2. ANALÝZA 2.3 Technická poznámka Aplikace byla programována ve vývojovém prostředí KDevelop. Ke kompilaci byl použit balík nástrojůgccatojakvprostředí Linux, tak Windows. Jako programovací jazyk bylo zvolen jazyk C v jeho ANSI podobě atovčetně ANSI C formátování kódu. Z ANSI normy C90 nejsou dodrženy zejména formáty komentářů, nebot norma C90 neumožnuje použití komentářůc++stylutj.dvělomítka. 2.4 Sít ová vrstva - tm sockets.h Vcílových operačních systémech se k přístupu ke službám sítě používájí sockety,které v obou případech vychází zberkeley sockets API. Zatímco v případě Linuxu byla specifikace dodržena, v případě Microsoft Windows a jejich WinSock došlo k odchylkám. Obě implementace byly porovnány a nakonec byla vybrána množina funkcí, které jsoutéměř identické akód je tak přenositelný s minimálními zásahy v kódu jen s pomocí direktiv preprocesoru. Popis rozhraní socket najdeme například [3] a popis rozhraní WinSock pak [2]. 2.4.1 Nejnižšívrstva Základem každé komunikace je vytvoření socketu,přes který bude aplikace komunikovat svnějším světem. K tomu sloužívolání socket() int socket(int domain, int type, int protocol);,kterémávnašem případě podobu socket(af_inet, SOCK_DGRAM, 0); 12

2.4. SÍŤOVÁ VRSTVA - TM SOCKETS.H KAPITOLA 2. ANALÝZA Používáme totiž rodinuaf INET, datagramově orientovaný protokol SOCK DGRAM, což jevnašem případě UDP. Aby bylo přes socket možno přijímat datagramy, je potřeba ho svázat s konkrétním portem a sít ovým zařízením, k čemuž slouží funkce bind(). Bind je potřeba použít jak u klienta, tak u serveru, nebot oba přijímají datagramy. Pokud bychom chtěli jen odesílat, bind nenínutný. Je použit IP 4 protokol, ale počításeúpravou programu tak, abyt mohl být použit i na IP 6sítích. Pro vlastní odesílání ačtení jednotlivého datagramu jsou použity funkce readmsg(), recvmsg() respektive WSARecvFrom() a WSASendTo(), což jsou knihovní funkce definované vhlavičkových 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

2.4. SÍŤOVÁ VRSTVA - TM SOCKETS.H KAPITOLA 2. ANALÝZA int itolen, LPWSAOVERLAPPED lpoverlapped, LPWSAOVERLAPPED_COMPLETION_ROUTINE lpcompletionroutine ); Prvotní design aplikace původně počítal s použitím funkcí WSARecv() a WSASend(), které jsoutotožné s funkcemi v POSIXové implementaci. Přesto, že jsou tyto funkce v dokumentaci Microsoftu MSDN, je jich možno plně využít až voperačním systému Windows VISTA. Pro maximální použitelnost aplikace na starších Windows byly nakonec použity výše uvedené funkce za cenu rozdílu v kódu pro Windows a Linux. Aplikace zdaleka nevyužívá všechny možnosti, které tyto funkce programátorovi poskytují. Volání funkce vypadá jednoduše, více nám řekne pohled na strukturu msghdr. struct msghdr{ void *msg_name /* Optional address. */ socklen_t msg_namelen /* Size of address. */ struct iovec *msg_iov /* 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 iov_len; /* size of buffer */ }; Díky těmto funkcím je možné zapsatačíst více bufferů zároveň. Pointer *msg iov totiž může ukazovat na pole struktur iovec, jehoždélka je určena položkou msg iovlen. Struktura iovec pak obsahuje ukazatel na buffer a jeho délku. Při posílání paketuje 14

2.4. SÍŤOVÁ VRSTVA - TM SOCKETS.H KAPITOLA 2. ANALÝZA potřeba řádně vyplnit hlavičku *msg name, která vnašem případě ukazuje na strukturu sockaddr in, která definuje informace o adresátovi paketu. Pro většípřehlednost je připojen obrázek 2.4 vazeb mezi jednotlivými strukturami tak, jak je používá aplikace. Obrázek 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é zpředchozího textu, manipulace s nízkoúrovňovými funkcemi není jednoduchá, bylo tedy potřeba vytvořit obslužné funkce, které vyplní datové struktury azároveň zvýšípřehlednost kódu. Tyto funkce jsou definovány v hlavičkové souboru 15

2.4. SÍŤOVÁ VRSTVA - TM SOCKETS.H KAPITOLA 2. ANALÝZA tm sockets.h a implementovány v příslušné knihovně. Využijeme toho, že již při volání úvodní bind() funkce potřebujeme mít inicializovánu strukturu sockaddr in. Jelikož velikosti datových struktur známe také, použijeme jižuživatelskou funkci tm fill msghdr(), která vyplní vše potřebné. void tm_fill_msghdr(struct msghdr *hdr, struct iovec *iov, struct sockaddr_in *SA); Takto vyplněnou strukturu, na kterou ukazuje pointer *hdr, lze již předložit funkci sendmsg(), čímž bydošlo k odeslání prázdného paketu. Pro rozumné využití jepotřeba před odesláním doplnit ukazatele na datové struktury, které jsou celkem dvě. První je typu socket header t a druhá ukazuje na libovolná data, at už je to buffer pro výplň datového paketu, či jiná struktura. Pokud takový paketpřijme druhá strana, podle kontextu (a ID paketu) pozná, jaká dataočekávat a provede příslušné přetypování. Na samotném konci stojí funkce tm send data packet(), která pošle paket na definovanou adresu s příslušným obsahem. int send_data_packet(int sckt, struct msghdr *msg, int ID, void *data, int datalen,int flags); Příklad: funkce recvmsg vyplní strukturu, na kterou odkazuje ukazatel hdr a ta bude obsahovat informace o odesilateli. Chceme-li ihned odpovědět odesilateli, že něco není v pořádku, stačí zavolat send data pacet(sckr, hdr, -1, NULL, 0, 0). Funkce odešle paket s ID -1 (ERR) na adresu odesilatele. Požadovaný datový tok pak generujeme jednoduše tak, že v pravidelných intervalech zasíláme pakety dané velikosti. Knihovna obsahuje dalšípomocné funkce, ale ty nejsou důležité kpochopení fungování aplikace. Na úplném konci stojí funkce tm sendstream(), kterázužitkovává všechny dříve uvedené funkce k zaslání požadovaného datového toku. Ve struktuře req jsou obsaženy všechny parametry. Tato funkce počítástím, že může být v případěserveruvolána ve více vláknech. 16

2.4. SÍŤOVÁ VRSTVA - TM SOCKETS.H KAPITOLA 2. ANALÝZA int tm_sendstream(int serversocket,struct sockaddr_in *to, stream_request_t *req) Struktura sockaddr in je již známá, struktura stream request t je ukázána níže. typedef struct stream_request_ { char username[username_l]; char password[password_l]; char mode; // u... upload : client -> server // x... dual : 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ždý paket,který aplikace vysílá, obsahuje hlavičku typu packet header t,což je struktura typedef struct packet_header_ { int32_t id; // packet ID struct timeval timestamp; // time at packet s departure } 17

2.5. ČASOVAČ - TIMER.H KAPITOLA 2. ANALÝZA packet_header_t; timestamp obsahuje systémový čas v okamžiku odeslání paketu.jepotřeba si uvědomit, ža paket stráví nějakýčas v sít ovém subsystému jádra operačního systému, takže čas reálného odeslání paketu-tadyčasu, když paket opouští sít ovou kartu - se lišíodčasu v hlavičce paketu. Tento rozdíl může činit desítky mikrosekund. Hlavičkou se myslí hlavička packet header t přidaná na aplikační úrovni, nikoliv hlavička IP či UDP protokolu. Význam hodnoty ID paketu již bylpopsán, již stačí jen doplnit hodnoty tak, jak jsou definovány v hlavičkovém souboru tm sockets.h. #define REQ 0 #define DEN -2 #define ERR -1 #define ACK -3 #define FIN -5 2.5 Časovač -timer.h Na kvalitěčasovače přímo závisí kvalita generovaných datových tokůatudíž ipřesnost měření. Jelikožžádný ze standardních systémových časovačů nedosahuje požadovaného rozlišení apřesnosti, bylo nutné implementovat vlastní. Nejpřesnějšímetodouseukázala tzv. busy loop, čili smyčka, které je v cyklu, dokud není splněna daná podmínka - vypršel danýčas. Příklad busy loop: while(!isolder(&now,&future)) { gettimeofday(&now,null); } 18

2.6. VSTUPNÍ PARAMETRY - PARSER.H KAPITOLA 2. ANALÝZA Periodicky se odměřuje nastavený čas a smyčka se ukončíažposplnění podmínky. Tato metoda funguje výborně, pokud je generován pouze jeden datový tok. Smyčka totiž zcela logicky pohlcuje většinu výkonu procesoru a pokud je těchto smyček pušteno více najendou, dochází knepřesnostem. Tento důvod a také předpoklad, že pro většinu měřených datových toků bude čekacíčas poměrně vysoký, byl pro tyto vyššíčasy implementován dalšíčasovač, který při čekání nechává procesor odpočinout - využívá volání usleep(), což jeuspánívlákna na požadovaný počet mikrosekund. Tento časovač jeméně přesný, ale po zavadení korekce, kdy je porovnána nastavená askutečnáčekací doba, dosahuje dobrých výsledků. Následuje příklad debugovacího výpisu časovače 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ěřená hodnota, should... doporučené nastavení časovače pro další iteraci. Pokud jde o klienta, vždy je použita busy loop, v případě serveru jen pokud jde ovelmikrátké čekací časy. Pro dlouhé čekací doby je použita druhá metoda.časovač je implementován v knihovně timer, uživatelské funkce jsou definovány v hlavičkovém souboru timer.h. Knihovna dále obsahuje funkce pro práci s časem a strukturou timeval, kterou používají jako windows, tak linuxové knihovny. Pokud by nároky na přesnost byly vyšší, než jestandardní linuxové jádro schopno zajistit, lze použít některé ze speciálních realtime (RT) jader, popřípaděpřímo RT distribuci (například ELinos). 2.6 Vstupní parametry - parser.h Parametry jsou předávány z příkazové řádky. Na zpracování parametrů bylapoužita knihovna getopt respektive její nadstavbagetopt long. Tato knihovna je šířena pod 19

2.6. VSTUPNÍ PARAMETRY - PARSER.H KAPITOLA 2. ANALÝZA licencí GNU Lesser General Public License[4], která při dynamickém linkování nijakne- omezuje autorská práva autora aplikace, která tutoknihovnupoužívá. Pouze při statickém slinkování senavýslednou aplikaci automaticky vztahuje licence GPL a všechny právní aspekty z tohoto plynoucí. Knihovna umí jednoše pracovat s krátkými i dlouhými názvy parametrů, dále lze nastavit, zda-li má daný parametr povinnou hodnotu či nikoliv. Použití je velmi jednoduché - definice vstupních parametrů jezřejmá znásledujícího pří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říkladu vidíme všechny možnosti vstupních parametrů. Parametry --verbose a --brief nastavují hodnotu proměnné verbose flag. Parametr --server, -s jsou identické anepředpokládá sežádná další hodnota. Za parametrem --client či -c musí následovat hodnota. Knihovna tuto hodnotu nekontroluje, je potřeba ji dále ošetřit. Pomocí další knihovní funkce se prochází poleargumentů argv[], které obsahuje argumenty zpříkazovéřádky. Nad touto knihovnou je postavena uživatelská knihovna parser, která zpracovává vstupní parametry, provádí kontrolu správnosti parametrů - rozsahy, hodnoty. Pokud nejsou některé hodnoty nastaveny uživatelem, jsou použity výchozí hodnoty - napří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áhodou. Moderní ethernetové sítě majítotiž hodnotu MTU (Maximum transmission unit) 1500B. MTU je velikost paketu, který projdepřes sít ové zařízení (gateway, router, bridge...), aniž bybylippaket fragmentován - rozdělen na více částí, z nichž každá jemenši než MTU. Při fragmentaci se zvyšuje pravděpodobnost ztráty paketu, nebot při ztrátě jednézjehočástí je zahozen celý (platíjenvpřípadě UDP). Pokud od hodnoty MTU 1500B odečteme velikosti 20

2.6. VSTUPNÍ PARAMETRY - PARSER.H KAPITOLA 2. ANALÝZA hlaviček všech nižších protokolů, dostáváme se na hodnotu okolo 1450B - ne všechny hlavičky musí být v paketu přítomny. Hodnota 1450B je nejvyššímožná velikost paketu, který na standardní síti projde bez fragmentace. Minimální hodnotu MTU přenosové cesty lze zjistit tak, že v hlavičce IP protokolu nastavíme volbu DF (Don t Fragment). Každé zařízenínapřenosové cestě, jehož MTUjemenšínež velikost paketu tento paket namísto fragmentace skartuje a vyšle zpět ICMP zprávu ICMP Destination Unreachable (Datagram Too Big). Začneme-li na malé velikosti paketu a postupně jizvyšujeme, pak snadno nalezneme MTU celé trasy. Tato technika je přesněji popsána v [6]. Další funkcí knihovny je výpočet hodnot ze zadaných parametrů. Zadá-li například uživatel požadovaný datovýtokanicjiného, použije se výchozí velikost paketu (1450B) pro výpočet rozestupu mezi pakety. Server tak vždy dostává informace stejného typu a nemusí jižžádnédalšívýpočty provádět. Poslední důležitou funkcí knihovny je generování hash hodnoty ze zadaného hesla. Jak již bylořečeno, pokud to jen bylo možné, bylo dodrženy názvy parametrů testovacího software iperf[5]. Mnoho jich bylo vypuštěno, protože se týkaly jen protokolu TCP, další zabrali jejich místo, protože iperf některé vlastnosti vůbec nepodporuje. Obrázek 2.5: iperf - http://dast.nlanr.net/projects/iperf 21

2.7. SEZNAM VSTUPNÍCH PARAMETRŮ KAPITOLA 2. ANALÝZA 2.7 Seznam vstupních parametrů s l Popis -s --server serverový mód - -y --daemon daemon mód - -r --root exkluzivní mód - do ukončení aktuálního - měření budou ostatnížádosti odmítány. -c host - -client klientský mód - je potřeba zadat adresu serveru, - na který se má klient připojit. Po- kud není zadán port (-p - -port), použije se výchozí hodnota -i # - -interval interval, ve kterém jsou pravidelně vypisovány 0 reporty -l # --len velikost paketu v bytech 1450 -p # --port port, na kterém bežíserver 5000 -p # --port port, na který sepřipojuje klient 5000 -b # - -bandwidth datový tokvbytechzavteřinu 1Mbs -w # --win velikost příjímacího bufferu dle systému -B # - -bind sít ové zařízení, na kterém má aplikace naslouchat 1Mbs -d - -dualtest po přijetí dat za serveru vyšle klient svůj testovací - datovýtok -u - -upload měřenípouzevesměru klient - server - -n # --num počet paketů datového toku - -t # --time čas v sekundách - délka datového toku 10 -T # --tout čas v sekundách - timeout při komunikaci se 10 serverem -D # --delay čas v milissekundách - rozestup mezi pakety - -F fil --file jméno souboru pro reprezentativní datový - tok -C fil --file soubor, do kterého se má připojit CSV report - -a user - -username uživatelské jméno - -x pass - -password heslo - 22

2.8. EXTRACTOR.H KAPITOLA 2. ANALÝZA Příklad : [bob@bob src]$./udptool --server --port 15000 -B 147.32.104.83 2.8 extractor.h Tato knihovna obsahuje funkce, které z požadovaného souboru načítají data a tato kopírují do bufferu. Data se načítají postupně až ke konci souboru. Pokud je požadováno více dat, než zbývá do konce souboru, začne se znovu od začátku. 2.9 Hash - md5.h Pro hashovaní hesla byla použita hashovací funkce MD5 [8], kterou v knihovně md5 podle uvedeného RFC 1321 implementoval L. Peter Deutsch (ghost@aladdin.com) a dal ji volně kpoužití při zachování určitých podmínek, jako je například zmínka o autorovi a nezasahování dokódu. Sama funkce MD5 je již překonána, přesto pro naše použití postačuje. 2.10 Reporty - reporter.h Tento hlavičkový soubor popisuje funkce, které sepoužívají k vyhodnocování příchozích datových toků. Výsledný reportvpřípadě duálního módu zasílá server klientovi. Zastřešující funkce data stream eval() vyhodnocuje vlastní datový tok. Jako vstup sloužíukazatel 23

2.11. SERVER - TM SERVER.H KAPITOLA 2. ANALÝZA na hlavičku paketu - packet header t. Funkce vyhodnotí spoždění paketu, počítá ztracené pakety a pakety mimo pořadí. Hlavičkový soubordále definuje funkce na převod číselných proměnných na textový HEX formát. 2.11 Server - tm server.h Serverováčást aplikace je určena k provozu pouze na operačním systému Linux. Využívá vlákna dle POSIX specifikace pro zasílaní datových toků více klientům současně. Jelikož vláknu lze předat pouze obecný ukazatel (void *), obsahuje knihovna podpůrné datové struktury a funkce, které umožní předat vytvářenému vláknu informace o datovém toku. Pro každého klienta, žádajícího o testovací datový tok je tedy vytvořeno vlákno, na jehož výsledky ovšem hlavní vlákno nečeká. Vlákno samotné nepřijímá pakety od klienta. Místo toho kontroluje sdílené datové struktury, například seznam přijatých servisních paketů. Přístup ke sdíleným strukturám je řízen pomocímutexů. Vlákno po odeslání dat a paketu DEN čeká napaketack,poněm odesílá paket FIN a opět čeká naack. Server může obsluhovat teoreticky neomezený počet klientů, jediný limit je pamět a maximálnípočet současněspuštěných vláken, kterédovolí spustit operačnísystém. Pokud si odmyslíme vysílací vlákna, funguje čtecíčást serveru i klienta jako asychronní stavový automat, který jetaktován příchody paketů na socket. Automat každý paket vyhodnotí aprovedepříslušnou akci. Po ukončení akceseopět čeká napaket.uklientskéčásti akce blokuje, čili klient nemůže zpracovávat další paket. Server naopak každou složitějšíakci pouští vevlákně, takže téměř ihned může zpracovávat dalšípaket. 24

2.12. KLIENT - TM CLIENT.H KAPITOLA 2. ANALÝZA 2.12 Klient - tm client.h Vpředchozích částech byla činnost klientskéčásti aplikace popsána podrobněazimple- mentačního hlediska nepřidávánicnového. Tyto části aplikace jsou odděleny především proto, aby se zjednodušila kompilace pod oběma operačnimi systémy. Pokud by měl systém běžet jen pod operačním systémem Linux, nebylo by toto oddělení vůbec potřeba. Klientská část ma přeci jen jednu odlišnost a to je volitelný timeout, po jehož překročení bude spojení vyhodnoceno jako ztracené a klient ukončen. Obrázek 2.6: Snímek terminálu 25

2.13. ÚPRAVY PRO WINDOWS KAPITOLA 2. ANALÝZA 2.13 Úpravy pro Windows Jak již bylořečeno, pro kompilaci pod oběma systémy nebylo potřeba velké množství úprav. Při kompilaci je serverová část skryta, zbývají tedy jen rozdíly mezi knihovnami socket.h a winsock.h. Ačsezákladní funkce jmenují různě (viz strana 13-2.4.1), jejich funkce je podobná. Postup pro kompilaci pod operačním systémem Windows bude popsán vzávěrečných kapitolách. 26

Kapitola 3 Použití Aplikace je implementována, ukažme si její použití a chování v reálné situaci. Spust me serverovou aplikaci na linuxovém stroji pří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řipraven pro příjem požadavků odklientů. 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ůjezřejmý, přesto zopakujeme, co vlatně po programu žádáme. Program se má spustit v klientském módu a připojit se k serveru bežícímu na IP adrese 10.0.0.139. Mázaslatpožadavek na datovýtok,který bude obsahovat pakety velké 1900B. Uživatelské jméno je pak bob, heslo 453sdfs. Dále sdělujeme, že chceme každou vteřinu zobrazovat průběh měření. Server obdržel požadavek, klient byl úspěšně ověřen a datový tok tak mohl být zaslán. Podívejme se na klientskou obrazovku. 27

KAPITOLA 3. POUŽITÍ [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 Lost Total 00-01s 0.00 kb -0.00kBs 0.000ms 0 1 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

KAPITOLA 3. POUŽITÍ Speed : 488.216 kbs (499933 Bs) Posilam FIN ACK [bob@localhost src]$ V horní části obrazovky vidíme informace o požadovaném datovém toku, ve střední části průběžné výsledky měření a nakonec souhrné informace. Jelikož server i klient v tomto případěbežely na stejném stroji, žadný 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žme si, jak vypadá výstup aplikace na typické asymetrickésítí -vtomtopřípadě ADSL. ------------------------------------------ [Client -> Server] ------------------------------------------ Sent packets: 281 Recv packets: 279 Lost packets: 2 Pckt loss : 0.71 % Duplicated : 0 Out of order: 0 Jitter : 443 usec Avg delay : 14423 usec Avg ping : 587128 usec Duration : 4.010 s Transfered : 271 kb 29

3.1. USERADD KAPITOLA 3. POUŽITÍ Speed : 67.581 kbs (69326 Bs) ------------------------------------------ [Server -> Client] ------------------------------------------ Sent packets: 281 Recv packets: 138 Lost packets: 143 Pckt loss : 50.89 % Duplicated : 0 Out of order: 0 Jitter : 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, že na cestě server - klient se ztratilo 50 % paketů apřenosová rychlost byla 26 kb/s, což je 208kb/s, přičemž teoretická maximální rychlost linky byla 256kb/s. 3.1 useradd Součástí aplikacejenástroj useradd, kterýsloužíkpřidávání uživatelů. [bob@localhost useradd]$./useradd Usage useradd USER [filename] Aplikace jako paremetry přijímájméno uživatele, kterého přidáváme a cestu k souboru shesly. useradd nekontroluje již zapsanéuživatele, případné duplicity řešíuživatel. Jde 30

3.2. TOOL.SH - UKÁZKOVÝ SKRIPT KAPITOLA 3. POUŽITÍ oobyčejný textovýsoubor,kterýjemožno editovat v libovolném editoru a uživatele odstranit. Nástroj beží pod Linuxem i Windows. 3.2 tool.sh - ukázkový skript Jak již bylozmíněno v úvodu, byla aplikace navržena tak, aby se klient dal používat v uživatelských 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řipojí na IP adresu 10.0.0.139, port 10000 a bude posílat na server datový tok o rychlosti 400 000 bajtů za sekundu. Příkaz grep zajistí, že se nám vypíše pouze řá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ých kódů potřebujeme následující software: autoconf automake gcc Aplikace vyžaduje knihovnu libpthread.so, kterájeovšem součástí drtivévětšiny distribucí. Nejdřívejetřeba spustit skript configure apotéjižstačíjenmake popřípadě make all. Výsledné spusstilený binární souborudptool se nachází vadresáři src. 32

4.2. WINDOWS KAPITOLA 4. KOMPILACE 4.2 Windows Pro kompilaci ze zdrojových kódů potřebujeme balík nástrojů MinGW - Minimalist GNU for Windows(http://www.mingw.org/, který obsahuje všechny potřebnénástroje (čili ekvivalenty výše uvedených linuxových nástrojů) a knihovny. Úvodní krok je stejný - v konzoli MSYS spustíme configure. Nyníjepotřeba v soubotu src/makefile nahradit odkaz na knihovnu pthread (řetězec -lpthread) odkazem na knihovnu WinSock2 (-lws2 32). A nyní jižopět stačí make. 33

Kapitola 5 Závěr Při implementaci software, který bylcílem diplomové práce, docházelo k spřesňování požadavků. Výhodou jsou jasné požadavky a tím i mantinely, ve kterých jsem se pohyboval. Nevýhodou pak složitějšípřídávání nové funkčnosti, se kterou nebylo v návrhu od počátku počítáno. Většina požadavků bylasplněna, ale výsledky budou zřejméaž po delších zkušenostech zadavatele. Vytvořený software není naprostou novinkou, nebot vznikl na základě nespokojenosti s jinými aplikacemi, jejichž dobré vlastnosti měl převzít apřídat další, kterými v té doběexistující aplikace nedisponovaly. Počítám s tím, že při používání vyplynou dalšípožadavky a rád tuto aplikaci upravím tak, aby dál dobře sloužila svému účelu. 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říloha A CD s aplikací Ktéto práci je přiloženo CD, na kterém jsou uloženy zdrojové kódy, manuál a verze aplikace pro všechny podporované systémy - Windows řady 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ů dip tato práce ve formátu PDF I