Cluster pro Virtual Reality Universal Toolkit

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Bakalářská práce

Cluster pro Virtual Reality Universal Toolkit Jiří Slivárich

Vedoucí práce: Ing. Jan Kubr

Studijní program: Softwarové technologie a management bakalářský Studijní obor: Softwarové inženýrství květen 2013

Cluster pro Virtual Reality Universal Toolkit

Jiří Slivárich

ii


Jiří Slivárich

Poděkování

Tímto děkuji vedoucímu této bakalářské práce Ing. Janu Kubrovi a panu Ing. Antonínu Míškovi, Ph.D. za jejich cenné rady, které umožnily vypracování této bakalářské práce. Také bych chtěl poděkovat svým rodičům a přítelkyni za trpělivost, kterou se mnou měli během vypracování této bakalářské práce. iii


Jiří Slivárich

iv


Jiří Slivárich

Prohlášení

Prohlašuji, že jsem bakalářskou práci vypracoval samostatně na základě uvedených pramenů (projekty, softwarové zdroje apod.) a uvedené literatury. Nemám námitky proti použití tohoto školního díla ve smyslu §60 zákona č. 121/2000 Sb., o autorských právech a právech souvisejících, ve smyslu pozdějších znění tohoto zákona.

V Praze dne ……………

………………………........... Jiří Slivárich

v


Jiří Slivárich

vi


Jiří Slivárich

ABSTRAKT V první části této práce jsou analyzovány požadavky na komunikaci v modulu Cluster prostředí Virtual Reality Universal Toolkit (VRUT). Následně je analyzováno současné řešení komunikace v tomto modulu. V druhé části práce jsou vypracovány návrhy vylepšení týkajících se usnadnění používání Clusteru a optimalizace datových toků. V poslední části je popsán návrh vylepšení implementace, který byl následně implementován do modulu.

ABSTRACT In this work there are analyzed requirements of communication in Cluster module in Virtual Reality Universal Toolkit environment. There is also analysis of current solution of communication in this module. In the second part of this work there are proposals of improvements regarding to facilitate the use of Cluster and proposals of optimization data streams. In the last part of this work, there are described suggestions of implementation improvements which were later added into the module.

Klíčová slova Virtual Reality Universal Toolkit, Cluster, modul, datové toky, komunikace v clusteru Key words Virtual Reality Universal Toolkit, Cluster, module, data streams, communication in cluster

vii


Jiří Slivárich

viii


Jiří Slivárich

Obsah

SEZNAM ILUSTRACÍ...................................................................................XI SEZNAM TABULEK....................................................................................XIII ÚVOD......................................................................................................... 1 1 VIRTUAL REALITY UNIVERSAL TOOLKIT (VRUT)..........................................3

1.1 CO

JE

VRUT............................................................................................................ 3

1.2 ZÁKLADNÍ

POPIS SOFTWAROVÉHO NÁVRHU

1.3 CHOVÁNÍ

MODULU APLIKACE

VRUTU..........................................................3

VRUT..............................................................................4

1.4 MODUL CLUSTER...................................................................................................... 5 2 ANALÝZA POŽADAVKŮ NA KOMUNIKACI V CLUSTERU PROSTŘEDÍ VRUT.......7

2.1 ZÁKLADNÍ

POŽADAVKY NA KOMUNIKACI..........................................................................7

2.2 PŘIZPŮSOBENÍ

UŽIVATELI

...........................................................................................8

2.2.1 Jednoduché rozvržení konfiguračních komponent..........................................9 2.2.2 Libovolné pořadí spuštění klientů a serveru.................................................10 2.2.3 Automatická konfigurace pomocí konfiguračního souboru...........................10 2.3 STABILNÍ

A RYCHLÁ KOMUNIKACE................................................................................10

2.3.1 Rychlá komunikace mezi klientem a serverem bez zpožďování...................11 2.3.2 Stabilní bezeztrátová komunikace...............................................................11 2.3.3 Předcházení pozastavování komunikace......................................................12 3 ANALÝZA STÁVAJÍCÍ IMPLEMENTACE MODULU CLUSTER.............................13

3.1 ZÁKLADNÍ

INFORMACE O MODULU

CLUSTER..................................................................13

3.2 ZÁKLADNÍ

TŘÍDY MODULU A JEJICH ÚČEL.......................................................................13

3.2.1 Třída Cluster................................................................................................. 13 3.2.2 Třída NetworkController...............................................................................14 3.2.3 Třídy pro zpracování packetů.......................................................................15 3.2.4 Třída VrutPacket...........................................................................................15 3.2.5 Třída SocketInterface...................................................................................15

ix


Jiří Slivárich

3.2.6 Třída PacketStack.........................................................................................16 3.3 PRŮBĚH

KOMUNIKACE............................................................................................... 16

3.3.1 Zahájení komunikace – založení clusteru.....................................................16 3.3.2 Přenos zpráv (událostí) v založeném clusteru..............................................20 3.4 UŽIVATELSKÁ

PRÁCE S

CLUSTEREM.............................................................................20

4 NÁVRHY ZMĚN V IMPLEMENTACI A JEJICH REALIZACE...............................25

4.1 ZMĚNY

VHODNÉ K IMPLEMENTACI................................................................................25

4.2 ZASÍLÁNÍ

TESTOVACÍCH ZPRÁV...................................................................................26

4.2.1 Analýza zasílání...........................................................................................26 4.2.2 Implementace řešení...................................................................................27 4.3 PŘIDÁNÍ

SPOLEHLIVÉHO MULTICASTU...........................................................................29

4.3.1 Analýza změn v současné implementaci.....................................................29 4.3.2 Implementace potvrzovaného multicastu....................................................33 5 TESTOVÁNÍ............................................................................................37

5.1 TESTOVACÍ

PROSTŘEDÍ............................................................................................. 37

5.2 POSTUP

TESTOVÁNÍ.................................................................................................. 38

5.3 POTÍŽE

ZJIŠTĚNÉ PŘI TESTOVÁNÍ.................................................................................39

5.4 VÝSLEDKY

TESTOVÁNÍ............................................................................................... 40

6 ZÁVĚR...................................................................................................43 SEZNAM POUŽITÝCH ZDROJŮ.....................................................................45 SEZNAM POUŽITÝCH ZKRATEK...................................................................47 PŘÍLOHA A INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA.....................................49

INSTALACE POPIS

A SPUŠTĚNÍ................................................................................................... 49

UŽIVATELSKÉHO ROZHRANÍ.....................................................................................49

PŘÍLOHA B STRUKTURA OBSAHU PŘILOŽENÉHO CD....................................51

x


Jiří Slivárich

Seznam ilustrací Ilustrace 1: Nevhodné rozvržení ovládacích komponent aplikace.........................................9 Ilustrace 2: Hierarchie tříd NetworkController....................................................................14 Ilustrace 3: Hierarchie tříd SocketInterface..........................................................................16 Ilustrace 4: Uživatelské rozhraní modulu Cluster ...............................................................17 Ilustrace 5: Ukázka konfiguračního souboru........................................................................18 Ilustrace 6: Rozdíl mezi multicastem a unicastem...............................................................19 Ilustrace 7: Čas příjmu pomocí PGM multicastu.................................................................40 Ilustrace 8: Čas příjmu UDP packetů...................................................................................41

xi


Jiří Slivárich

xii


Jiří Slivárich

Seznam tabulek Tabulka 1: Tabulka typů modulů aplikace VRUT..................................................................4 Tabulka 2: Ovládací prvky modulu Cluster.........................................................................23 Tabulka 3: Porovnání kritérií vlastního a cizího řešení........................................................30 Tabulka 4: Porovnání knihoven dostupných na internetu....................................................31 Tabulka 5: Vyhodnocení porovnání dostupných řešení........................................................32 Tabulka 6: Přehled konfigurací testovacích PC...................................................................38

xiii


Jiří Slivárich

xiv


Jiří Slivárich

Úvod Virtual Reality Universal Toolkit (nadále pouze VRUT) je softwarový projekt, který vznikl spoluprací Katedry počítačové grafiky a interakce ČVUT FEL a firmy Škoda Auto a.s. Hlavní úlohou tohoto projektu je zobrazení grafických dat pomocí nejrůznějších projekčních zařízení, které je možno připojit k počítači (monitor, projektor,…). Důležitou vlastností aplikace je její modulárnost, což znamená, že lze její funkce přidávat a rozšiřovat pomocí modulů, které jsou na aplikaci relativně nezávislé. V úvodu práce se věnuji seznámení s aplikací VRUT, její architekturou a základními požadavky na tvorbu modulu. Zároveň zde popisuji, co je modul Cluster a jaký je jeho účel. Dalších kapitoly obsahují analýzu požadavků kladených na síťový cluster ve smyslu, ve kterém je následně využit v aplikaci typu VRUT. Následně analyzuji stávající implementaci modulu Cluster, který se stará o komunikaci více počítačů v rámci clusteru. Tento modul umožňuje komunikaci a simultánní zobrazování stejných dat více počítači najednou. Komunikace mezi počítači probíhá pomocí TCP/IP protokolu a je nutná její naprosto přesná synchronizace s pokud možno nulovými zpožděními. V závěrečné části této práce navrhuji a popisuji změny, které jsem v modulu Cluster provedl v rámci zlepšení vlastností síťové komunikace.

1


Jiří Slivárich

2


Jiří Slivárich

1 VIRTUAL REALITY UNIVERSAL TOOLKIT (VRUT) V této části práce chci vysvětlit, co je aplikace VRUT. Následně rozebírám modulární návrh VRUTu, který zajišťuje jeho snadnou rozšířitelnost. Závěr kapitoly je tvořen popisem chování modulu aplikace VRUT a stručným popisem modulu Cluster, kterému jsou věnovány následující kapitoly této práce.

1.1 Co je VRUT VRUT je softwarové řešení, které vzniklo ve spolupráci Katedry počítačové grafiky a interakce Fakulty elektrotechnické v Praze se společností Škoda Auto a.s. Tento software umožňuje zobrazit grafická data, která dostane jako vstupní data, na zobrazovacím zařízení připojené k počítači. Aplikace umožňuje zobrazovat statická data jako obrazy, stejně tak je ale schopná renderovat složité 3D scény a umožňuje interakci s nimi. Více informací o systému VRUT lze nalézt v dokumentaci, která je přílohou této bakalářské práce.

1.2 Základní popis softwarového návrhu VRUTu VRUT je navržen a implementován jako modulární aplikace, což znamená, že základem aplikace je funkčně relativně jednoduché jádro, ke kterému jsou připojeny moduly (pluginy), které jeho funkcionalitu zásadně rozšiřují. VRUT je aplikace, u které je tento návrh více než vítán. Nabízí totiž velmi snadnou rozšiřitelnost aplikace o nové funkce. Nezávislost hlavní aplikace na modulech přináší možnost používat pouze ty moduly, které jsou v dané situaci potřebné a zbylé nechat vypnuté. Tento přístup umožňuje také aktualizaci pouze jednotlivých modulů bez nutnosti zasahovat do jádra či jiných modulů. Stačí, aby moduly splňovaly základní požadavky, pro napojení na jádro aplikace. Zároveň toto řešení umožňuje šetřit zdroje jako operační paměť 3


Jiří Slivárich

a vytížení procesoru, což je pro aplikaci, která dovoluje renderování složitých scén a manipulaci s nimi velice užitečné. Jedinou nevýhodou tohoto přístupu je větší režie na straně hlavní aplikace, při komunikaci s moduly a při komunikaci modulů mezi sebou.

1.3 Chování modulu aplikace VRUT Po spuštění aplikace se v konzoli zobrazí dostupné moduly k zavedení. Moduly aplikace VRUT jsou dynamické knihovny, jejichž funkcionalita je uživateli poskytnuta až po jejich zavolání. Po spuštění modulu dojde k zobrazení jeho ovládacích komponent, díky kterým lze upravit nastavení a chování modulu. Moduly, stejně jako celá aplikace, jsou napsány v C++ a využívají dědičnosti. Každý modul je tedy potomkem třídy Modul a po jeho spuštění se modul spustí ve vlastním vlákně. Moduly pro VRUT můžeme rozdělit do několika kategorií viz Tabulka 1.

Typ modulu

Využití

Příklady z aplikace

I/O Moduly

Moduly pro načítání dat pro scénu

IOFHS, IOOBJ, IOVRML, …

ze souborů. Moduly pro Podporu HW

Moduly pro práci se zařízeními

C3DConnexion, Cluster, CarHW, ...

Moduly pro Úpravu scény

Tyto moduly umožňují upravit

MaterialEditor, SceneGraph,

načtenou scénu pro potřeby

TreeEditor, ...

uživatele Moduly Interakce Renderovací moduly

Moduly pro interakci uživatele se

VehicleSimulator,

scénou

TrackingManipulator

Moduly, které se starají o

RenderGL, Shadow_maps,

renderování scény na výstupní

RayTracer

zařízení

Tabulka 1: Tabulka typů modulů aplikace VRUT 4


Jiří Slivárich

1.4 Modul Cluster V příštích kapitolách bude stěžejní modul Cluster, proto zde popíši k čemu slouží. Cluster je modul, který umožňuje, jak jeho anglický název napovídá, podporu spuštění aplikace v clusteru. Každý počítač v clusteru musí mít spuštěnou aplikaci VRUT se zavedeným modulem Cluster. Základem práce v clusteru je princip Client-server. Jedna instance aplikace běží jako server a ostatní běží v režimu client. Po úspěšném spojení klientů se serverem distribuuje serverová instance data scény klientům a ti je následně synchronizovaně zobrazují. Klient i server využívají stejné knihovny modulu Cluster, což znamená, že tato knihovna obsahuje implementaci obou stran. Modul je třívláknový. Dvě vlákna slouží k rozebrání a sestavení zprávy a třetí slouží k jejich posílání po síti. Komunikace je realizována pomocí UDP packetů. Kanál sloužící ke zpětné komunikaci je realizován pomocí TCP spojení.

5


Jiří Slivárich

6


Jiří Slivárich

2 Analýza požadavků na komunikaci v clusteru prostředí VRUT V úvodu kapitoly uvádím základní požadavky na komunikaci v clusteru prostředí VRUT. Dále detailněji popisuji vlastnosti modulu, které jsou dle mého názoru důležité.

2.1 Základní požadavky na komunikaci VRUT je ve všech ohledech velmi specifická aplikace, která má na komunikaci v clusteru dosti náročné požadavky. Nejdůležitější z výčtu základních požadavků je stabilní, rychlá a pokud možno bezeztrátová komunikace mezi počítači v Clusteru. Bezchybnost komunikace se po softwarové stránce určitě dá ovlivnit, ale velmi důležitý je i aspekt hardwarový, kvalita sítě totiž ovlivňuje komunikaci nezanedbatelnou měrou. Další velmi důležitý aspekt je uživatelská přívětivost. I když se může zdát, že VRUT tuto stránku poněkud zanedbává a jeho ovládání nepatří mezi nejpřívětivější, tak by uživatel určitě neměl strávit velké množství času nastavováním clusteru. V principu by se mělo jednat o níže uvedenou sekvenci kroků: 1. Spuštění modulu na klientech a serveru 2. Nastavení základních parametrů 3. Navázání komunikace client-server 4. Odeslání scény do clusteru Po této sekvenci kroků by se již uživatel neměl o nic starat. Modul by měl nadále všechno obstarávat sám. Samozřejmě uživatel může cluster zastavit, změnit parametry, změnit počet klientů nebo například odeslat jinou scénu. V této kapitole se tedy zaměřím na hlubší analýzu výše popsaných požadavků z obecného hlediska. Nebudu se zabývat současnou implementací a řešením, to popíši až 7


Jiří Slivárich

v kapitole další. Jelikož je v zadání práce zmíněno usnadnění užívání jako první, tak začnu tím.

2.2 Přizpůsobení uživateli Ačkoliv se v případě VRUTu jedná o aplikaci, která je určena do technického a vývojového prostředí, tak stále platí, že ji budou používat lidé, kteří nemusí znát principy fungování client-server architektury. To po nich asi ani nikdo nechce. Uživatel by měl přijít k počítači, spustit aplikaci a intuitivně se základními znalostmi aplikace být schopen spustit cluster. Neměl by se starat o to, který počítač již běží, zda běží v server či klientském módu. Nepotřebuje se zabývat jasným pořadím spouštění aplikace na jednotlivých strojích. VRUT není aplikace, jejíž účelem je poznávat principy fungování clusteru. VRUT je především propracovaný nástroj na renderování komplexních 3D scén a manipulaci s nimi. Síťový cluster je v tomto případě přidaná hodnota, ale pro uživatele to není stěžejní funkcionalita, se kterou by se měl dlouho potýkat. V několika stručných bodech zde uvedu funkční požadavky na clusterovou aplikaci, které souvisí se snadným ovládáním: •

Možnost spuštění klientů a serveru v libovolném pořadí

•

Jednoduché rozvržení konfiguračních komponent s jasnými popisky

•

Možnost automatické konfigurace pomocí konfiguračního souboru

Ačkoliv se může zdát, že výše zmíněné body jsou pouze maličkosti, pro uživatele, který aplikaci používá mohou být velkou výhodou.

8


Jiří Slivárich

2.2.1 Jednoduché rozvržení konfiguračních komponent Pro uživatele jakékoliv aplikace je nejjednodušší, když ji může nainstalovat, spustit a začít ji naplno využívat. To ale u aplikací podobných VRUTu nelze tak snadno aplikovat. Zde se totiž jedná o aplikaci, u které je nutné nastavit poměrně velký počet parametrů, aby dělala přesně to, co po ní uživatel požaduje. Je ale nanejvýše vhodné, aby nastavení modulů, které se přímo nestarají o scénu bylo pokud možno jednoduché. Na ilustraci 1 je vidět, jak by rozhodně rozvržení komponent vypadat nemělo.

Ilustrace 1: Nevhodné rozvržení ovládacích komponent aplikace Aplikace, jejíž nastavení je vidět na ilustraci výše, sice nabízí mnoho možností nastavení, ale pokud by uživatel měl dostat za úkol něco rychle nastavit, tak by mu rozvržení komponent práci rozhodně neusnadnilo.

9


Jiří Slivárich

2.2.2 Libovolné pořadí spuštění klientů a serveru Tato možnost je také velmi důležitá pro ulehčení práce s clusterem. Lidem, kteří aplikaci používají, by nikdo neměl vysvětlovat, že se nejdříve spustí všichni klienti a následně se teprve spustí server, který si následně všechny klienty najde a spojí se s nimi. Minimálně by bylo vhodné umožnit i opačný postup. Tím je myšleno spustit server, který bude čekat, až se k němu připojí klienti. Po zajištění kroků nezbytných pro úspěšnou komunikaci již musí být snadné odeslat scénu na klienty.

2.2.3 Automatická konfigurace pomocí konfiguračního souboru Při opakovaném nastavování stejné konfigurace klientů je nanejvýš vhodnou možností využití nějakého druhu konfiguračních souborů, které uchovají již použité a vyladěné nastavení. Velkou výhodou je zavést tuto funkcionalitu pro zjednodušení uživatelského rozhraní a zvýšení automatizace práce s modulem.

2.3 Stabilní a rychlá komunikace Cluster je podle definice skupina počítačů propojených pomocí sítě, které vykonávají podobnou funkci. Navenek se tyto počítače chovají jako jeden a většinou plní jeden úkol paralelně. Toto o clusteru aplikace VRUT příliš neplatí. Zde se totiž jedná o skupinu počítačů spojených pomocí sítě, ale tyto nejsou spojeny za účelem paralelního zpracování jedné složité úlohy. Cluster aplikace VRUT vystupuje jako distributor scény, kterou si každý z počítačů následně zpracuje a zobrazí sám.

10


Jiří Slivárich

Požadavky na komunikaci v clusteru jsou: •

Rychlá(optimalizovaná) komunikace mezi klienty a serverem

•

Eliminace zpoždění distribuce scény

•

Zamezit zastavování distribuce v nečekaných situacích

V následujících podkapitolách detailněji popíši výše zmíněné požadavky, které byly získány z dokumentace projektu a během konzultací s autorem aplikace.

2.3.1 Rychlá komunikace mezi klientem a serverem bez zpožďování Nezávisle na současné implementaci je v takovémto druhu softwaru důležité, aby komunikace byla rychlá, pokud možno bezeztrátová a probíhala naprosto synchronizovaně. Pokud by docházelo ke zpožďování byť jen u jednoho klienta, tak se scéna bude vykreslovat asynchronně a to by mělo na výsledek špatný vliv. Lze akceptovat určitá zpožďování, ale ta se nesmějí dostat nad hranici, kdy stále dochází k tzv. setrvačnosti zrakového vjemu. Lidské oko dokáže vnímat obraz jako souvislý pouze pokud jsou související snímky (i na více zařízeních) zobrazovány v rámci cca 1/7 vteřiny. Pokud by však došlo k několika špatným synchronizacím a obrazy by se odchýlily o více než tento interval, lidské oko by již dokázalo vnímat nesrovnalosti v obraze.

2.3.2 Stabilní bezeztrátová komunikace Při způsobu jakým má být scéna v Clusteru distribuována je důležité, aby komunikace probíhala stabilně a všechna data byla doručena na klienty. Pokud by došlo ke ztrátě jakéhokoliv packetu na síti, je nutné, aby tento byl odeslán znovu. Toto je při hromadné distribuci scény užívané Clusterem dosti obtížné. Je nutné zavést určitý druh potvrzované komunikace, kdy klient při výpadku packetu o tomto informuje server, který packet odešle znovu, aby data byla kompletní.

11


Jiří Slivárich

2.3.3 Předcházení pozastavování komunikace Další záležitost, která rozhodně není požadována, respektive je v podstatě vyloučena, je pozastavení scény v důsledku pozastavení komunikace. Pokud nedojde přímo k zastavení distribuce na požadavek uživatele, tak by vše mělo probíhat tak, jak bylo nastaveno. Může dojít například k chybě v komunikaci mezi serverem a klientem, která není ošetřena a k následnému zastavení komunikace jako celku. To povede k zastavení celé projekce scény. Rozhodně je proto důležité, aby byly ošetřeny na úrovni softwaru všechny možné neočekávané problémy v komunikaci. Hardwarové nedostatky je však softwarovou cestou velmi složité eliminovat.

12


Jiří Slivárich

3 Analýza stávající implementace modulu Cluster Kapitola popisuje základní informace o stávající implementaci modulu Cluster. Popisuje jeho základní třídy a průběh komunikace, který je v současné době v aplikaci VRUT využíván.

3.1 Základní informace o modulu Cluster Stávající implementace modulu Cluster je funkčním prvkem, který zajišťuje komunikaci VRUTu v clusteru více počítačů. Stejně jako celá aplikace je i Cluster napsán v jazyce C++ a využívá přítomnosti frameworku wxWidgets, který tvoří GUI modulu stejně jako celé aplikace a zajišťuje například i práci se soubory nebo vlákny. wxWidgets je knihovna pro C++ a další programovací jazyky, která umožňuje vývojáři vytvářet aplikace pro různé operační systémy a architektury od desktopových systému až po systémy určené pro mobilní zařízení.

3.2 Základní třídy modulu a jejich účel 3.2.1 Třída Cluster Třída Cluster je základní třídou současné implementace tohoto modulu. Tato třída se stará o komunikaci s jádrem aplikace pomocí eventů (událostí). Tyto eventy třída Cluster nadále distribuuje na všechny klienty v rámci clusteru. Událostí, které třída Cluster implementuje je mnoho, jedná se v podstatě o všechny události systému, které nějakým způsobem manipulují se scénou. V konstruktoru této třídy vzniká také celé uživatelské rozhraní a registrují se listenery pro všechny možné druhy událostí, které přišly z jádra aplikace. 13


Jiří Slivárich

3.2.2 Třída NetworkController Tato třída se stará o samotnou komunikaci mezi počítači. Principiálně přijme data (binární, textová nebo numerická), která má odeslat a podle aktuálního stavu fronty buď data rovnou odesílá nebo je zařadí na její konec. Její pomocné třídy dále dělí data události do UDP packetů, které po multicastu odešle na všechny klienty. Klientská část načítá data ze sítě opět po packetech, pomocné třídy poskládají packety zpět do podoby dat respektive událostí a tato data jsou odeslána dále hlavní třídě, která je odesílá do jádra klientské instance k renderování. Zpětná komunikace se serverem je realizována pomocí TCP packetů. Touto cestou je tvořeno například potvrzování během navazování komunikace mezi serverem a klientem. Funkcionalita třídy NetworkController zahrnuje i navázání samotné komunikace. V aktuálním stavu není podstatné, která z instancí je spuštěna jako první. K tomuto slouží konfigurační soubor, který obsahuje seznam klientů. Až po spojení serveru se všemi klienty může dojít k distribuci scény, která má být renderována. Na ilustraci 2 lze vidět, jaká je hierarchie tříd v souboru NetworkController.cpp.

Ilustrace 2: Hierarchie tříd NetworkController

14


Jiří Slivárich

3.2.3 Třídy pro zpracování packetů Pro zpracování packetů, které byly přijaty po síti, existuje v systému několik tříd takzvaných parserů. V nynější verzi to jsou třídy ClusterParser, ClusterRapidParser a ClusterTCPParser. Tyto třídy mají jeden společný úkol. Z packetů, které jim přišly po síti, skládají zpět události, které se posílají jádru na zpracování. V tomto případě se nejvíce zapojuje třída ClusterParser, která obsahuje soupis všech událostí, které jádro podporuje, a které jdou z přijatých packetů složit. Pokud z packetů byla složena neplatná událost, tak je vypsána do konzole chybová hláška a jádru není nic předáno.

3.2.4 Třída VrutPacket Třída VrutPacket je reprezentace packetu, který je posílán po síti. Každý packet má hlavičku (header), která obsahuje základní metadata packetu, kterými jsou například typ události, ID packetu a velikost datové složky packetu. Dále obsahuje položku data (content), která obsahuje data přenášená packetem.

3.2.5 Třída SocketInterface Tento interface je velice důležitý, protože ho implementují třídy, které se starají o spojení mezi klientem a serverem. Je univerzální jak pro dopřednou UDP komunikaci, která probíhá jako multicast, tak i pro zpětné potvrzování pomocí TCP protokolu. Na ilustraci 3 je vidět jaká je hierarchie tříd, které tento interface implementují.

15


Jiří Slivárich

Ilustrace 3: Hierarchie tříd SocketInterface

3.2.6 Třída PacketStack Třída PacketStack je implementací haldy, která je důležitá pro odesílání packetů po síti. NetworkController ji využívá k uložení neodeslaných packetů. Pokud je PacketStack prázdný, tak se packety rovnou odesílají, pokud v něm již nějaké packety jsou, tak se z haldy berou a řadí se do fronty k odeslání.

3.3 Průběh komunikace V této kapitole popíšu, jakým způsobem je realizována samotná komunikace v rámci Clusteru. Průběh komunikace rozdělím do dvou kroků: •

Zahájení komunikace – založení clusteru

•

Přenos zpráv (událostí) v založeném clusteru

3.3.1 Zahájení komunikace – založení clusteru Základem zahájení komunikace v Clusteru je navázání komunikace mezi serverem a klienty. Po spuštění aplikace se zadáním příkazu „runmodule cluster“ do konzole, která se nachází ve spodní části okna (viz Ilustrace 4), zavede modul Cluster a následně se zobrazí jeho uživatelské rozhraní, pomocí nějž lze modul ovládat.

16


Jiří Slivárich

Ilustrace 4: Uživatelské rozhraní modulu Cluster

Cluster se automaticky spustí v klientském režimu, což je dáno aktuálním implementací modulu. Instance klienta opakovaně v implementaci specifikovaných intervalech vysílá do sítě pomocí multicastu zprávu, že je dostupná k navázání komunikace se serverem. Jak již bylo popsáno výše, jedna z instancí musí být v režimu server. Přepnutí do tohoto režimu se provádí pomocí přepínače distributeEvents na hodnotu 1 - Server. Po načtení informací z konfiguračního XML souboru získá serverová instance seznam klientů ve formě jmen počítačů v sítí. Ukázku z tohoto konfiguračního souboru je vidět na ilustraci 5. Při startu vyšle serverová instance do sítě helloPacket, což je zpráva, kterou server dává 17


Jiří Slivárich

najevo, že je na síti. Na tuto zprávu očekává odpověď od klientů. Zmíněnou zprávu vysílá server i případě, kdy obdrží ze sítě informaci o nové klientské instanci, kterou identifikuje podle seznamu počítačů v konfiguračním souboru. Následně se pokusí s klientem o takzvaný handshake, při kterém dojde k navázání komunikace mezi těmito počítači.

Ilustrace 5: Ukázka konfiguračního souboru

K potvrzení navázání komunikace mezi klientem a serverem se využívá TCP kanál, přes který proběhne zbytek handshaku. Multicast je jedním z mnoha způsobů šíření dat po síti. Jedná o rozesílání dat všem zařízením v síti, která jsou členy určité skupiny. Tato skupina se nazývá multicastová skupina. Standardně je komunikace v síti řešená unicastem, kdy počítač zasílá data jednomu specifickému stroji v síti. Opakem unicastu je anycast, kdy jsou data posílána všem zařízením v síti nezávisle na tom, zda jsou pro tato zařízení určena či nikoliv. Na

18


Jiří Slivárich

ilustraci 6 je znázorněn rozdíl mezi multicastem a unicastem. Ten spočívá v tom, že data posílaná přes multicast, jsou ze zdroje vyslána pouze jednou a až na směrovačích jsou zduplikována a rozeslána ostatním členům skupiny. Pokud bychom chtěli tuto komunikaci řešit unicastem, museli bychom ze zdroje data posílat právě tolikrát, kolik je příjemců na síti.

Ilustrace 6: Rozdíl mezi multicastem a unicastem

Z použití multicastu vyplývá hlavní výhoda pro komunikaci v clusteru. Data jsou efektivněji hromadně rozesílána a zároveň doručována jen strojům, které jsou určitým způsobem specifické, a to svou multicastovou skupinou. Navazování komunikace mezi serverem a klienty je dokončené, když jsou všichni klienti přítomni. Nyní nastává čas na distribuci scény a práci s ní.

19


Jiří Slivárich

3.3.2 Přenos zpráv (událostí) v založeném clusteru Po vyřešení navázání komunikace přebírají úlohu posluchači (listenery), kteří zjišťují typ události, kterou jádro serveru posílá a podle toho její data nechají rozebrat vhodně do UDP packetů a ty následně pošlou po multicastu ke klientům. Klienti čekají na packety, které následně skládají zpět do použitelných dat a posílají jádru ke zpracování. Tyto packety nemusí přicházet ve správném pořadí. K rozpoznání zprávy slouží instance třída ClusterParser zmíněné v kapitole 3.2.3, která vezme pomocí metody Read z instance třídy NetworkController data z Packetů. Jakmile je složená celá zpráva, tak je odeslána pomocí metody PostToKernel jádru klientské aplikace k renderování popřípadě jinému zpracování. V této části komunikace může docházet k jednomu z nežádoucích jevů, který v samotném řešení multicastu není ošetřen. Jedná se o situaci, kdy klient neoznámí serveru, že mu nějaký packet nebyl doručen. Pokud se totiž stane, že nějaký paket nedorazí ke svému příjemci respektive klientovi, tak o tom klient nedá serveru žádným způsobem vědět, a ten nadále posílá data. Zmíněná nedokonalost je jedno z míst, které musí být ošetřeno. Implementací spolehlivého multicastu je vytvořen zpětný potvrzovací kanál, kterým dá klient najevo, že určitý packet neobdržel a žádá o jeho opětovné zaslání. Nejedná se o standardní potvrzování každého doručeného packetu pomocí packetu ACK, ale o odeslaní packetu NAK na server, který informuje o nedoručení příchozího packetu. Blíže se tématu spolehlivého multicastu věnuji v kapitole 4.

3.4 Uživatelská práce s Clusterem Z uživatelského pohledu je práce s aplikací jednoduchá. Poté, co aplikace úspěšně naváže komunikaci pomocí Clusteru, se může uživatel soustředit pouze na ovládání scény na serveru. Možné je i přidání další scény, kterou bude Cluster přenášet.

20


Jiří Slivárich

V současné implementaci nelze za běhu přidat dalšího klienta. Jelikož by muselo dojít k opětovnému odeslání celé scény tomuto klientovi, a to je v době, kdy již probíhá aktivní renderování a ovládání scény, nereálné. I zmíněná záležitost by měla být v budoucnu řešena, ale komplexnost a časová náročnost takové úlohy je nad rámec této bakalářské práce. V tabulce 2 se nachází seznam ovládacích prvků a popis jejich funkcí. Uživatelské rozhraní je vyobrazeno na ilustraci 4.

21


Jiří Slivárich

Popisek ovládacího prvku (typ)

Popis funkce

sceneID (rozevírací nabídka)

V této nabídce si uživatel zvolí scénu, kterou chce do clusteru odeslat

ConfigurationTable (tabulka s

Tabulka, která zobrazuje konfigurace načtené ze

možností výběru řádků)

souboru ClusterConfig.xml. Tato konfigurace ovlivňuje zobrazení scény na jednotlivých klientech. Toto je aplikováno při zavolání metody renderScene, pokud jsou vybrány zatržítkem na začátku řádku.

StopCluster (tlačítko)

Po stisknutí tohoto tlačítka se pošle na klienty zpráva CPT_EXIT, která zastaví probíhající komunikaci v clusteru.

reloadConfiguration (tlačítko)

Toto tlačítko znovu načte souboru ClusterConfig.xml a aktualizuje pomocí něj tabulku ConfigurationTable

LocalPort (vstupní pole)

Pomocí tohoto pole se nastavuje port, na kterém bude probíhat komunikace.

BufferSize (vstupní pole)

Nastavení velikosti bufferu – změna tohoto pole nyní nemění nic na vlastnostech komunikace, protože není dokončena implementace.

SendScene (tlačítko)

Toto tlačítko odešle celou scénu (scéna, materiály, obrázky, geometrie i uzly), která je zvolena v sceneID na klienty

DistributeEvents (rozevírací nabídka) Tato nabídka v sobě drží všechny možnosti, jak se může daná instance chovat. Obsahuje tedy hodnoty Client, Server a TCPServer CarpetsTable (tabulka)

Zde je zobrazen seznam tzv. létajících koberců, které jsou definovány podle zvolené

22


Jiří Slivárich

configrationTable. V podstatě se jedná o parametry jako vzdálenost očí a nebo napojení na tracking. Toto pole umožňuje zasílat příkazy interpreteru ClientCommand (vstupní pole)

klientům. V podstatě se jedná o vzdálenou konzoli

PacketTimeout (vstupní pole)

V tomto poli se nastavuje časový limit pro přijetí potvrzení o doručení packetů na klienta. Pokud je tento čas překročen server odesílá packet znovu

Tabulka 2: Ovládací prvky modulu Cluster

23


Jiří Slivárich

24


Jiří Slivárich

4 Návrhy změn v implementaci a jejich realizace Na začátku této kapitoly se zaměřuji na popsání změn vhodných k implementaci, které dle mého názoru mají velký potenciál k dalšímu využití během vylepšování modulu Cluster. Dále odůvodňuji jednotlivé změny a popisuji jejich realizaci.

4.1 Změny vhodné k implementaci Aplikace takové velikosti a s takto specifickým způsobem využití, jako je VRUT respektive jeho modul Cluster, má potenciál k velkému množství úprav a vylepšení. V průběhu konzultací s vedoucím mé práce a s panem Ing. Antonínem Míškem, Ph.D. ze společnosti Škoda Auto a.s. jsme diskutovali několik možných úprav stávající implementace modulu Cluster. V této práci se chci věnovat dvěma změnám, které jsou funkčně svázány a během konzultací jedna vyplynula z druhé. První změnou je implementace podpory zasílání testovacích zpráv, které by umožnily testovat komunikaci v modulu Cluster. Podpora takové funkcionality umožňuje odstínění komunikace a jejího testování od potřeby přenášená data dále zpracovávat. Druhou změnou je přidání dalšího způsobu komunikace. Tím bude vedle stávajícího nepotvrzovaného multicastu jeho potvrzovaná alternativa. Podpora této komunikace přináší zlepšení některých vlastností zmíněných v kapitole 3.

25


Jiří Slivárich

4.2 Zasílání testovacích zpráv 4.2.1 Analýza zasílání V této kapitole se nejprve zaměřuji na důležité vlastnosti, které musí splňovat funkcionalita zasílání testovacích zpráv, ať už z technického hlediska či z pohledu uživatele. Dále analyzuji způsob, jak a kam nejlépe tuto vlastnost zapojit do stávajícího řešení.

Důležité vlastnosti testovacích zpráv Dle mého názoru je pro jakoukoliv testovací funkcionalitu důležité, aby se zaměřila pouze na testovanou část systému a na zbytku byla co nejvíce nezávislá, aby zbytek systému nemohl ovlivňovat výsledky testování. Pro testování přenosu dat nezáleží na tom, jaký typ dat posílám, ale to jakou mají data velikost. Neměl by být rozdíl, zda posílám červený obrázek nebo náhodný shluk binárních dat v paměti. Proto je z mého pohledu nejjednodušší použít právě náhodná data v paměti. Pro uživatele, který bude testy provádět by mělo jejich vyvolání být co nejjednodušší, protože ho zajímají hlavně výsledky a protože testování se může mnohokrát opakovat. Z tohoto důvodu by bylo nejjednodušší aby odeslání zprávy bylo otázkou jednoho kliknutí. Samotná funkcionalita musí být principiálně dostatečně jednoduchá, abychom mohli co nejvíce eliminovat jakákoliv rizika. To znamená, že je výhodnější vytvořit si pouze data v paměti systému, než posílat soubor z disku, kde mohou nastat například problémy s právy. Pokud chci používat náhodná data, tak mám dvě možnosti. Buď je budu generovat v paměti nebo využiji nějaké soubory na disku. Ale protože chci co nejvíce eliminovat rizika, tak generování dat je dle mého názoru lepší, protože nemusím řešit například otázky přístupu k souboru, jeho práva či jeho neexistenci.

26


Jiří Slivárich

Jak a kam zapojit testovací zprávy? Jestliže se nejprve zaměříme na to, kde je potřeba tuto funkcionalitu zapojit, tak z důvodu co nejjednoduššího použití je potřeba vytvořit novou komponentu v uživatelském rozhraní modulu. Přes tuto komponentu bude možné zasílání zpráv ovládat. Protože mi jde jenom o funkcionalitu jednorázového zaslání zprávy, lze tuto komponentu realizovat pouze jedním tlačítkem. Aby bylo zasílání zprávy funkční, musí být tlačítko připojeno k aplikační logice. Toto připojení je pro většinu komponent uživatelského rozhraní modulu realizováno v souboru cluster.cpp. Proto by bylo nejlepší se držet tohoto standardu a umístit ho také do tohoto souboru. Samotná akce by vytvořila blok dat o předem určené velikosti, která budou zaslána stejným způsobem jako probíhá jakákoliv jiná komunikace v Clusteru.

4.2.2 Implementace řešení Jak jsem již zmínil v analýze, pro přidání komponenty (tlačítka) do grafického uživatelského rozhraní aplikace jsem vložil do souboru cluster.cpp následující kód, který vytvoří tlačítko, které umožní odeslání testovací zprávy. Toto tlačítko má nastavený specifický popisek a id. Toto id je použito pro navázání tlačítka na aplikační kód.

Stejně jako u ostatních komponent v GUI i u této musím odchytávat, zda nedošlo k interakci s ním. To řeší následující kód

27


Jiří Slivárich

V následujících útržcích kódu je vidět, jak je generována testovací zpráva. Proměnná dataSize vyjadřuje velikost dat. Takto velký kus je následně pomocí metody malloc alokován v paměti a odeslán po síti. Důležité je data na konci vymazat pomocí metody delete.

Poslední část kódu je ze souboru ClusterParser.cpp a jedná se o parsování přijatých dat po síti.

28


Jiří Slivárich

4.3 Přidání spolehlivého multicastu Celá komunikace v Clusteru probíhá pomocí multicastu, který, jak jsem již popsal v předchozích kapitolách, není vhodné v takovéto aplikaci využít bez doplnění jeho implementace o potvrzování. V této kapitole se zaměřuji na analýzu řešení potvrzovaného multicastu. Analyzuji zde jakým způsobem je možné multicast zapojit a využít v v modulu Cluster a způsob jak toto zapojení realizovat.

4.3.1 Analýza změn v současné implementaci Přínosy potvrzovaného multicastu Jak jsem již zmínil v předchozím textu, tak v rámci komunikace v Clusteru, je nutné aby byly doručeny všechny packety. To však standardní multicast nezaručuje a to může způsobovat nechtěné zpožďování distribuce scény. Zavedením potvrzovaného multicastu by mělo v tomto směru dojít ke zvýšení spolehlivosti doručování dat. Pokud bude potvrzeno nedoručení packetu, server bude vědět, že musí poslat packet znovu a až po doručení všech packetů může posunout takzvané klouzavé okno a tím posílat další data ve frontě. To se nyní neděje a tím se nezaručuje doručení všech packetů nutných ke správnému vykreslování či ovládání scény.

29


Jiří Slivárich

Vlastní nebo existující řešení Důležité je rozhodnutí, zda si pro spolehlivý multicast napsat vlastní řešení, či využít již stávající dostupné například na internetu.

Vlastní řešení

Hotové dostupné řešení

Časová náročnost

-

+

Možná rizika

-

+

Získáne zkušenosti

+

-

Znovu-využitelnost

-

+

Komplexnost

-

+

Podpora

-

+

Flexibilita

+

-

CELKEM

2

5

Tabulka 3: Porovnání kritérií vlastního a cizího řešení

V tabulce 3 je uveden výčet kritérií, které jsem bral v potaz při rozhodování, zda napsat vlastní implementaci, či využít cizí. V zásadě nejpodstatnějším kritériem je časová náročnost, která by byla pro napsání a otestování vlastního řešení velká. Dalším kritériem, které velmi ovlivnilo mé rozhodování, bylo možné riziko. To zahrnuje například nezvládnutí zadání tak komplexního požadavku, jakým je implementace vlastního spolehlivého multicastu. Zároveň bych nemohl pro vytvořené řešení poskytnout takovou podporu, jaká je dostupná pro cizí řešení, kterým se někdo výhradně zabývá. Pro vlastní řešení hovoří pouze získané zkušenosti při jeho implementaci a flexibilita, která by umožňovala úpravy řešení na míru. Z tabulky tedy celkem jasně vyplývá, že se vyplatí využít cizího řešení a raději se zaměřit na následnou optimalizaci přenosu. 30


Jiří Slivárich

Volba vhodného existujícího řešení V současné době jsou na internetu již dostupná hotová řešení spolehlivého multicastu. Při výběru řešení jsem se rozhodoval dle několika kritérií: •

Licence, pod kterou je řešení dostupné

•

Aktivita vývoje a tudíž budoucí potenciál tohoto řešení

•

Složitost použití tohoto řešení v rámci Clusteru.

•

Dokumentace dané knihovny pro vývojáře Po relativně dlouhém pátrání a studování zbyli dva kandidáti, kteří připadali

v úvahu pro použití v modulu Cluster. Srovnání těchto knihoven je dostupné v tabulce 4 respektive v tabulce 5.

Název

Spread toolkit

openPGM

Dostupné na webu www.spread.org

code.google.com/p/openPGM

Licence

Spread open-source license

LGPL 2.1 license

Aktivita vývoje

Aktivní vývoj

Aktivní vývoj

Složitost použití

Horší možnost zapojení ve Jednoduché na všech platformách Windows

Dokumentace

Obsáhlá,

dostupná

na Obsáhlá, v podobě WIKI stránek,

stránkách

občas matoucí

Tabulka 4: Porovnání knihoven dostupných na internetu

31


Jiří Slivárich

Na základě výše uvedené tabulky jsem nakonec zvolil openPGM řešení a to hned z několika důvodů: 1. Licence – LGPL je pro nasazení v prostředí Clusteru vhodnější než Spread open-source license, která vychází z BSD licence. 2. Aktivita vývoje – v obou případech stále probíhá aktivní vývoj a tudíž možný posun do budoucna 3. Složitost použití – ačkoliv se zdá, že má Spread jednodušší API, tak openPGM je lepší v tom, že se tato knihovna dostupná jako zdrojový kód, dá přeložit i pro platformu Windows pro architektury x86 a AMD64. 4. Dokumentace – Oba projekty mají kvalitní dokumentaci, ačkoliv openPGM dokumentace je občas matoucí

Spread toolkit

openPGM

Licence

-

+

Aktivita vývoje

+

+

Složitost použití

-

+

Dokumentace

+

-

Celkem

2

3

Tabulka 5: Vyhodnocení porovnání dostupných řešení

Jakým způsobem zapojit PGM? openPGM knihovna žádným způsobem nezasahuje do jakékoliv jiné vrstvy aplikace než do té, která se stará o přímou síťovou komunikaci. Proto by měla být zapojena jako další NetworkController a to oboustranný jak pro klienta tak pro server.

32


Jiří Slivárich

Z mého pohledu nejvýhodnějším postupem zapojení je postupná analýza dosavadního řešení (bez PGM) a porovnávání jednotlivých prováděných operací proti testovacím ukázkovým aplikacím použití PGM při komunikaci v praxi. Z kódu dosavadního řešení komunikace jsou rozpoznatelné fáze navázání spojení a následnou komunikaci, což je už samotné posílání dat. V obou kódech lze nalézt podobné prvky, jakými jsou řešeny jednotlivé fáze komunikace. Proto je dle mého názoru nejvhodnějším přístupem namapovat odpovídající si fáze na sebe a následně do modulu Cluster přidat implementací openPGM, jako další z možností komunikace pro propojení s uživatelským rozhraním. Dokud vše nebude řádně otestováno a vyladěno, měl by mít dle mého názoru uživatel možnost používat jak staré tak nové řešení komunikace. Z tohoto důvodu je nutné vytvořit prvek v GUI aplikace, který umožní uživateli zvolit si právě jednu z těchto možností.

4.3.2 Implementace potvrzovaného multicastu Knihovnu openPGM jsem do modulu Cluster staticky přilinkoval, což umožňuje její lepší přenositelnost. V první fázi bylo nutné ji přeložit ze zdrojových kódu, k čemuž výborně slouží dokumentace přiložená v archivu knihovny. Následně bylo třeba správně nastavit vývojové prostředí, aby při překladu modulu Cluster staticky přilinkovalo knihovnu a nabízelo funkce, které jsou součástí jejího API. Z důvodu větší obsáhlosti kódu zde zmíním pouze jednotlivé části použitého openPGM API a jeho účel ve fázi komunikace v modulu Cluster. Kompletní zdrojový kód je k nahlédnutí na přiloženém datovém nosiči.

33


Jiří Slivárich

Základem pro spuštění celého openPGM je inicializace, která je vidět v následujícím kódu

O celou inicializaci se stará metoda pgm_init, která spustí jak na klientovi tak na serveru všechny potřebné záležitosti. Proměnná pgm_err zde může obsahovat chybový kód podle toho, zda se inicializace povedla či nikoliv. Na serveru je nutné spustit další vlákno, které se stará o příjem NAK packetů ze sítě. Pokud toto vlákno neběží a tím pádem se server o NAK packety nestará, jedná se v podstatě obyčejný multicast, jaký je užívaný nyní. Server odesílá data pomocí metody pgm_send(), která je vidět níže v kódu.

Tento kód zajišťuje příjem dat na straně klienta, kde se do bufferu uloží data o velikosti 4096 bytů. A zároveň se získají další potřebné informace jako délka dat a chybový výstup

34


Jiří Slivárich

Tento kód je opak inicializace. Musíme za sebou zavřít socket a vypnout pgm funkci, díky čemuž za sebou openPGM nenechá neuvolněnou paměť a podobné nežádané záležitosti.

35


Jiří Slivárich

36


Jiří Slivárich

5 Testování Důležitým krokem během implementace nové funkcionality je samozřejmě její otestování. V tomto případě je testování o to komplikovanější tím, že je nutné ho provádět na více strojích. Testování nové implementace probíhalo jak během vývoje, kdy bylo nutné postupně ověřovat nově přidávané funkcionality poskytované knihovnou openPGM, tak i po implementační fázi, kdy bylo nutné získat srovnání stávající a nové metody posílání zpráv.

5.1 Testovací prostředí Pro účely testování bylo využito uzavřené síťové prostředí, tedy takové které nebylo připojeno k internetu ani do jiné sítě. Toto prostředí se skládalo ze 3 PC (1 server a 2 klienti), jednoho síťového směrovače a 3 UTP kabelů kategorie 5, o délce 5m, které mají přenosovou rychlost 1 Gbps. Konfigurace počítačů se liší hardwarově liší, ačkoliv celkový rozdíl ve výkonu není velký. Všechny počítače měly stejný operační systém a to Windows 7 Profesional 64bit. V tabulce 6 je dostupná hardwarová konfigurace těchto strojů.

37


Jiří Slivárich

PC1 - server

PC2 - klient

PC3 - klient

Typ PC

Stolní počítač

Notebook

Notebook

Procesor

Intel Core i7 – 3,4GHz

Intel Core i7 – 2,67GHz

Intel Core i5 – 2.33GHz

8MB L3 cache

4MB L3 cache

4MB L3 cache

Operační paměť

8GB DDR3

8GB DDR3

4GB DDR3

Síťová karta

Realtek 811E Gigabit Intel 82577LC Gigabit

Realtek Gigabit Ethernet

Ehternet Operační systém Windows 7, 64bit

Windows 7, 64bit

Windows 7, 64bit

Tabulka 6: Přehled konfigurací testovacích PC

Z tabulky vyplývá, že PC1 a PC2 jsou si tabulkově svým výkonem velmi podobné, ale musíme brát v úvahu to, že se jedná o stolní PC a notebook, kde například u notebooků je osazován „slabší procesor“ kvůli jeho nižším energetickým nárokům. PC3 je celkově slabší, ale pro účely mého testování tato konfigurace dostačuje. Dalším podstatným prvkem je router, který zajišťuje samotnou síťovou konektivitu. V mém případě se jedná o model TPLINK TL-WR1043ND, který zajišťuje gigabitovou konektivitu pomocí 4 ethernetových portů. Router je také vybaven bezdrátovým modulem, ten ale nebyl pro testování využit a během testování byl neaktivní. Spojení routeru s PC bylo realizováno pomocí stejně dlouhých UTP kabelů kategorie 5, které umožňují při zapojení všech 4 párů přenášet data rychlostí 1 Gbps.

5.2 Postup testování Testování proběhlo ve třech iteracích, které se od sebe lišily pouze velikostí testovací zprávy. V první iteraci byla přenášena pouze malá zpráva (0,5MB) v druhé iteraci se jednalo o zprávu větší (50MB) a v poslední iteraci se jednalo o zprávu, která asi nejlépe simuluje reálný přenos dat na klienty v ostrém provozu (500MB).

38


Jiří Slivárich

V následujícím seznamu jsou uvedeny počty odeslaných zpráv každé velikosti každou metodou. •

Velikost zprávy = 0,5MB; Počet zpráv = 50

•

Velikost zprávy = 50MB; Počet zpráv = 20

•

Velikost zprávy = 500MB; Počet zpráv = 20

Zprávy jsem následně posílal ze serveru na klienta a do konzole jsem si nechal vypisovat čas odeslání ze serveru (po kliknutí na tlačítko odeslat) a čas přijetí klientem. Tyto časy jsem od sebe odečetl a tím jsem získal celkový čas přenosu. Nakonec jsem vypočítal průměr naměřených hodnot.

5.3 Potíže zjištěné při testování Během testování nedošlo k žádným větším potížím, které by jakkoliv mohly ohrozit jeho úspěšné dokončení. Co jsem však nečekal, byla v dnešní době slabší podpora výrobců routerů v oblasti multicastové komunikace. Během testování došlo totiž k situaci, kdy komunikace vůbec nebyla navázána a až prozkoumání samotné komunikace pomocí programu WireShark prozradilo, že router vůbec neodesílá IGMP packety, které jsou základem pro navázání multicastové komunikace. Toto mě velice překvapilo a musel jsem se pro další testování poohlédnout po jiném routeru, který multicastovou komunikaci umožňuje. Další problémy nastaly při portování prvních vývojových verzí během implementace v rámci virtuálních strojů. Aplikace přeložená ve Visual Studiu 2012 v rámci Windows 7, které bylo využito jako vývojové prostředí při implementaci, není podporovaná ve Windows XP ačkoliv se jedná o stejnou 32 bitovou architekturu. Pro toto buď bylo nutné složitě pozměnit konfiguraci překladače

nebo nainstalovat vývojové

prostředí i na Windows XP a překládat aplikaci přímo v něm. Toto jsem nakonec vyřešil

39


Jiří Slivárich

vytvořením virtuálního stroje s Windows 7, ve kterém již aplikaci bylo možné spustit po pouhém přenesení složky s přeloženou aplikací.

5.4 Výsledky testování Testování probíhalo v několika iteracích v nichž jsem posílal různý počet zpráv o různé velikosti. Všechny výsledky jsem zprůměroval a vytvořil na základě nich graf, který ukazuje, že využití PGM v rámci multicastové komunikace je na mé síti pomalejší než původní multicastová komunikace obsažená v modulu Cluster nyní. Během testování jsem originální multicast ponechal nastavený tak, jak byl. OpenPGM řešení jsem se snažil pomocí různých nastavení, která se s v něm dají ovlivnit, vyladit tak, abych se dostal alespoň na srovnatelné hodnoty jako u původního multicastu.

Ilustrace 7: Čas příjmu pomocí PGM multicastu

Jak je vidět na ilustraci 7, tak celkově je průběh příjmu packetu stabilní. Příčinu výkyvu přibližně u 21 packetu se mi nepovedlo nijak blíže určit.

40


Jiří Slivárich

Ilustrace 8: Čas příjmu UDP packetů Pro porovnání na ilustraci 8 uvádím i graf průběhu při standardním multicastu. Jak je na časech zobrazených na ose Y vidět, je tato metoda řádově rychlejší než její PGM alternativa.

41


Jiří Slivárich

42


Jiří Slivárich

6 Závěr V rámci této práce jsem vysvětlil, co je VRUT (Virtual Reality Universal Toolkit), že se jedná o projekt, který vznikl spoluprací společnosti Škoda Auto a.s. a Katedry počítačové grafiky a interakce FEL ČVUT. Popsal jsem základy návrhu aplikace a požadavky na její moduly. Detailněji jsem se věnoval modulu Cluster. Analyzoval jsem požadavky na komunikaci v clusteru v rámci aplikace typu VRUT, které jsem následně využil při návrhu změn v současné implementaci modulu. Zaměřil jsem se na přizpůsobení uživateli a stabilní a rychlou komunikaci, což jsou dle mého důležité vlastnosti síťového modulu pro aplikaci, jakou představuje VRUT. Dále jsem analyzoval současnou implementaci modulu Cluster, kde jsem se zaměřil na zahájení a samotný průběh komunikace. Také jsem se zaměřil na popis základních tříd tohoto modulu a práci uživatele s tímto modulem. V dalších kapitolách jsem se věnoval analýze a realizaci dvou nových funkcionalit modulu Cluster. Těmito funkcionalitami jsou zasílání testovacích zpráv, které umožňují testování výkonu samotné komunikace modulu, a potvrzovaný multicast. Pro realizaci potvrzovaného multicastu jsem provedl porovnání náročnosti při využití existujících řešení oproti vlastní implementaci, ze kterého vyšlo vítězně využití existujícího řešení. Pro výběr z mého pohledu nejvhodnějšího řešení jsem provedl analýzu a porovnání, na základě jehož výsledků jsem zvolil knihovnu openPGM. V poslední kapitole jsem provedl testování nové implementace potvrzovaného multicastu. Testování probíhalo zasíláním testovacích zpráv různých velikostí jak pomocí původního tak nového řešení. Z výsledků vyplynulo, že pro optimální výkon je potřeba správně nastavit mnoho parametrů přenosu například velikost okna nebo velikost packetu. Celkově je v mém testovacím prostředí openPGM implementace pomalejší. Tímto testem jsem také otestoval fungování posílání testovacích zpráv.

43


Jiří Slivárich

44


Jiří Slivárich

Seznam použitých zdrojů 1. Cluster. In: Techterms.com [online]. 2012- [cit. 2012-05-5]. Dostupné z: http://www.techterms.com/definition/cluster

2. KYBA, Václav a Antonín MÍŠEK. VRUT: Dokumentace aplikace. Praha, 2012. Dostupné z: http://dcgi.felk.cvut.cz/home/bitner/vrut/doc_cz.pdf

3. Lidské oko: Setrvačnost zrakového vjemu. In: PanWiki [online]. 16.4.2007, 17.4.2007 [cit. 2012-05-5]. Dostupné z: http://panwiki.panska.cz/index.php/Lidské_oko

4. IPv6 [online]. 5.11.2008 [cit. 3.12.2012]. Dostupné z: http://www.ipv6.cz 5. IP Multicast. Fakulta elektrotechniky a informatiky: Katedra informatiky [online]. 2012 [cit. 2013-05-24]. Dostupné z: http://www.cs.vsb.cz/grygarek/SPS/lect/multicast/multicast.html

45


Jiří Slivárich

46


Jiří Slivárich

Seznam použitých zkratek Zkratka

Popis

VRUT

Virtual Reality Universal Toolkit

GUI

Graphical user interface (grafické uživatelské rozhraní)

API

Application programming interface

IGMP

Internet Group Management Protocol

PGM

Pragmatic General Multicast

ACK

Acknowledgement

NAK

Negative acknowledgement

47


Jiří Slivárich

48


Jiří Slivárich

Příloha A Instalační a uživatelská příručka Instalace a spuštění VRUT není nutné instalovat, o to těžší je však provést kompilaci pro zvolený systém. V prostředí Microsoft Windows je vhodné mít nainstalované Visual Studio verze 2012 nebo Eclipse CDT minimálně verze 3.6 Helios. Ze zdrojových kódů lze pomocí aplikace Cmake vytvořit projekt pro jedno z výše zmíněných vývojových prostředí. Nutné je také mít nainstalovány potřebné závislosti, kterými jsou minimálně pro modul Cluster knihovny Glew, Glut a wxWidgets. Všechny závislosti lze najít na internetu a některé i ve složce /KOD/trunk/support na přiloženém CD. V prostředí GNU/Linux (ideálně Ubuntu) musí být splněny stejné závislosti jako u Microsoft Windows, ale balíkovací systém Ubuntu nabízí snadnou instalaci. Aplikace Cmake je pro Linux také dostupná, takže příprava projektu pro vývojové prostředí Eclipse je záležitost pár okamžiků. V dokumentaci, která je ve složce /DOKUMENTY/DOKUMENTACE na přiloženém CD naleznete ilustracemi doplněný postup, jak VRUT i s Clusterem zkompilovat v prostředí Windows.

Popis uživatelského rozhraní Uživatelské rozhraní aplikace VRUT je v kontrastu s celkovou složitostí aplikace velmi jednoduché a přímočaré. Skládá se ze čtyř spojených oken nad sebou, která jdou v případě potřeby oddělit, skrýt či změnit jejich pořadí. V pořadí odshora dolů jsou tedy vidět následující okna •

okno s renderovanou scénou – v tomto okně se zobrazují grafická data a průběh jejich renderování

49


•

Jiří Slivárich

okno s ovládacími prvky – toto okno se skládá ze záložek, jejichž počet je závislý na počtu spuštěných modulů. Na ilustraci 4 této práce lze vidět ovládací prvky modulu Clusterovou

•

okno s konzolí – do třetího okna, které slouží jako konzole, vypisuje aplikace a zavedené moduly všechny zprávy, o kterých by měl uživatel vědět. Toto logování lze upravit podle toho, jaké zprávy (od běžných informací po chyby) chce uživatel vidět.

•

Jako poslední je úplně dole zobrazen řádek, kam lze zadávat příkazy, které bude aplikace vykonávat. Téměř všechny moduly mají svoje ovládání realizované pomocí tlačítek a jiných prvků, ale například spuštění modulu se provádí právě pomocí této řádky.

50


Jiří Slivárich

Příloha B Struktura obsahu přiloženého CD •

DOKUMENTY ◦ BP ▪ PDF ▪ ODT ◦ DOKUMENTACE ▪ PDF ▪ TEX

•

KOD ◦ TRUNK

•

readme.txt

DOKUMENTY – obsahuje dva podadresáře. BP obsahuje tuto práci. Dokumenty, které se nacházejí na přiloženém CD pochází z doby před finální jazykovou korekturou, a proto mohou obsahovat chyby, které byly během této korektury odstraněny. DOKUMENTACE – obsahuje dokumentaci k celému systému VRUT KOD – obsahuje adresář trunk se zdrojovým kódem aplikace VRUT readme.txt – obsahuje tuto přílohu

51

Cluster pro Virtual Reality Universal Toolkit

Recommend Documents