MASARYKOVA UNIVERZITA F}w¡¢£¤¥¦§¨ AKULTA INFORMATIKY !"#$%&'()+,-./012345 Protokoly pro komunikaci klient ˚una platformˇeFlash BAKALÁRSKAPRÁCA Tomáš Mizerák Brno, jar 2010 Prehlásenie Prehlasujem, že táto bakalárska práca je mojím pôvodným autorským dielom, ktoré som vypracoval samostatne. Všetky zdroje, pramene a literatúru, ktoré som pri vypracovaní používal alebo z nich ˇcerpal,v práci riadne citujem s uvedením úplného odkazu na prís- lušný zdroj. Vedúci práce: RNDr. David Šafránek, Ph.D. ii Pod’akovanie Dakujemˇ svojmu vedúcemu bakalárskej práce RNDr. Davidovi Šafránkovi, Ph.D. za pomoc, ochotu a strpenie, ktoré mi venoval pri tvorbe tejto práce. Taktiež d’akujem svojej rodine za podporu poˇcascelého štúdia a všetkým, ktorí mi akýmkol’vek spôsobom pomohli pri spracovaní tejto bakalárskej práce. iii Zhrnutie Vd’aka vysokej rozšírenosti technológie Flash a výkonu dnešných poˇcítaˇcovmôžeme im- plementovat’ aplikácie a hry bez nutnosti inštalácie. Táto práca zh´rˇnaspôsoby komunikácie klientov Flash a prehl’ad dostupných protokolov. V rámci práce boli jednoduchým nástro- jom otestované dva najrozšírenejšie protokoly pre Flash – HTTP a RTMP. Súˇcast’ou práce je ukážková aplikácia využívajúca RTMP pre spojenie klient-server a RTMFP pre peer-to-peer komunikáciu. iv Abstract Because of the great expansion of Flash technology and thanks to the performance of mod- ern computers we’re able to implement applications and games without the necessity of installing them. This thesis includes various possibilities of communication between Flash clients and an overview of available protocols. As a part of this thesis two most common protocols for Flash – HTTP and RTMP – were tested by a simple custom tool. The practical part is a demo application which uses RTMP for a client-server and RTMFP for peer-to-peer communication. v Kl’úˇcovéslová Flash, ActionScript, Flex, HTTP, RTMP, RTMFP vi Obsah 1 Úvod ...... 3 2 Platforma Adobe Flash ...... 4 2.1 ActionScript 3 ...... 4 2.1.1 Flash IDE a Flex SDK ...... 4 2.2 Flex framework ...... 5 2.3 Adobe Flash Player ...... 5 2.3.1 Javascript knižnica SWFObject ...... 6 2.3.2 Bezpeˇcnostnépolitiky cross-domain ...... 7 2.4 Adobe Air ...... 7 2.5 Nástroje na vývoj ...... 8 3 Komunikaˇcnéprotokoly ...... 9 3.1 Hypertext transfer protocol ...... 9 Program telnet ...... 10 3.1.1 Požiadavka ...... 10 Metódy požiadaviek HTTP 1.1 ...... 10 Ukážka HTTP požiadavky POST ...... 11 3.1.2 Odpoved’ ...... 12 Ukážková odpoved’ na POST ...... 12 3.1.3 HTTP a Flash ...... 13 3.2 Socket a XMLSocket ...... 13 3.2.1 Socket ...... 14 3.2.2 XMLSocket ...... 14 3.3 Real-Time Messaging Protocol ...... 14 3.3.1 RTMPT ...... 15 3.3.2 Stream audia a videa ...... 15 3.3.3 NetConnection ...... 15 3.3.4 RemoteObject ...... 16 3.3.5 SharedObject ...... 16 3.4 Real-time media flow protocol ...... 17 4 Serverové aplikácie ...... 20 4.1 AMF brána ...... 20 4.2 Komplexné riešenia ...... 21 4.2.1 Flash Media Interactive Server ...... 21 4.2.2 BlazeDS ...... 21 1 4.2.3 WebORB for .NET ...... 21 4.2.4 Red5 ...... 21 4.2.5 Wowza Media Server ...... 22 4.2.6 LiveCycle Data Services ...... 22 4.3 RTMFP služby ...... 22 4.3.1 Adobe Labs Stratus ...... 22 4.3.2 LiveCycle Collaboration Services ...... 22 5 Porovnanie výkonu protokolov HTTP a RTMP ...... 24 5.0.3 Prostriedky na testovanie ...... 24 5.1 Algoritmus ...... 24 5.2 Serverová ˇcast’ ...... 25 5.3 Klientská ˇcast’ ...... 25 5.4 Výsledky ...... 26 6 Program BPChat ...... 28 6.1 Klientská ˇcast’ ...... 28 6.2 Serverová ˇcast’ ...... 29 6.2.1 Nasadenie serverovej ˇcastiaplikácie ...... 30 7 Záver ...... 32 2 Kapitola 1 Úvod Flash je svetovo vel’mi rozšírená technológia. Každý, kto používa internet, Flash pozná. Ciˇ už v podobe známeho video prehrávaˇcana YouTube alebo nepreberného množstva zobra- zovaných reklám. Možnosti jeho použitia sa však v poslednej dobe stále rozširujú. Flash prechádza aj do sféry aplikácií a hier. Táto práca pojednáva o možnostiach komunikácie aplikácií postavených na platforme Flash a okolia, spôsoby ako najlacnejšie komunikovat’ medzi Flash aplikáciou vloženou na internetovej stránke a serverom pripojeným na databázu a ako najlacnejšie vymieˇnat’ dáta priamo medzi dvoma Flash klientami pomocou peer-to-peer spojenia. Prvá kapitola predstavuje základné stavebné prvky platformy Flash. Na struˇcnýchukáž- kach zdrojového kódu v jazyku ActionScript ukazuje základnú štruktúru a syntax. Dalejˇ uvedie Flex framework pre tvorbu aplikácií deklaratívnym spôsobom. Nasleduje popis sa- motného prehrávaˇcaaplikácií Flash na internetových stránkach a zdrojové kódy ako správne Flash vložit’. V druhej kapitole sú zhrnuté možnosti ako komunikovat’ z Flash a predstavená je tech- nológia pre spojenie Flash aplikácií peer-to-peer. Kapitola zah´rˇnaprincípy najpoužívanejšie- ho internetového protokolu HTTP, ako aj možnosti využitia pre samotný Flash. Pre prenos digitálneho obsahu a výmenu iných údajov poukazuje na protokol RTMP a nový RTMFP, ako na ideálny spôsob komunikácie Flash klientov. Serverové riešenia, ktoré sú nutné pre klient-server komunikáciu, sú struˇcneopísané v tretia kapitole. Sú to jednoduché riešenia využívajúce HTTP a skriptovacie jazyky ale i komplexné serverové aplikácie, ktoré implementujú rýchly binárny prenos protokolom RTMP. Nové služby poskytujúce RTMFP spojenie ani samotný protokol nemajú otvorenú špecifikáciu a preto sa im venuje len malá ˇcast’ kapitoly. Porovnanie výkonu v dnešnej dobe dvoch najpoužívanejších protokolov HTTP a RTMP sú zaznamenané v štvrtej kapitole. Meranie je zamerané špecificky na rýchlost’ odozvy pri vel’kom poˇctezasielaných objektov, ˇcovyužívajú aplikácie nároˇcnéna prácu s databázou. V poslednej kapitole tejto práce je popísaná implementácia jednoduchej aplikácie, pomo- cou ktorej používatelia môžu medzi sebou komunikovat’. Základom je klientská a serverová ˇcast’ a použitie binárnych RTMP a RTMFP. 3 Kapitola 2 Platforma Adobe Flash Adobe Flash (skrátene Flash) je multimediálna platforma vyvinutá pôvodne spoloˇcnost’ou Macromedia. V dnešnej dobe sa Flash používa na zobrazovanie animácií a dynamického ob- sahu na webe. Sú to najmä reklamné banery, Flash hry, interaktívne webové prezentácie, no v poslednej dobe i Flex aplikácie. Silnou stránkou Flash je však i možnost’ prehrávat’ audio a video návštevníkom webových stránok simultánne s jeho st’ahovaním zo serveru (A/V streaming), kde príkladom je známa služba YouTube. Technológia Flash patrí medzi jednu z troch najvýznamnejších pre tvorbu RIA (Rich Internet Applications) [15]. Svoje uplatnenie nachádza aj v malých zariadeniach typu mobilné telefóny a PDA. 2.1 ActionScript 3 Hlavným programovacím jazykom technológie Flash je ActionScript 3. ActionScript je ob- jektovo orientovaný. Základná syntax je odvodená z ECMAScript. ActionScript 3 si však ponechal prvky svojich predchodcov ActionScript 1 a 2, ktoré boli skriptovacie, procedu- rálne jazyky s prvkami objektového programovania. ActionScript je vel’mi podobný jazyku Java a používa i podobné dátové typy. Primitívne dátové typy sú: Boolean, int, Null, Num- ber, String, uint, void. Základnou triedou je trieda typu Object. ActionScript 3 nie je silne ty- povaný jazyk a nevýhodou je slabá kontrola pri kompilácii. Slabé typovanie však umožˇnuje použit’ objekty typu Object ako slovník, ktorý má kl’úˇcetypu String a hodnoty akéhokol’vek typu. Zaujímavost’ou sú netypované premenné1 [1][4]. 2.1.1 Flash IDE a Flex SDK Ako kompilátor pre ActionScript 3 a Flash slúži software Adobe Flash Professional alebo kompilátor z Flex SDK (software development kit). Pôvodne bol Flash a SWF vytváraný iba v nástrojoch Adobe. Vo Flash IDE sa animuje na ˇcasovejosi a kompilácia prebieha pria- mo v tomto programe vstavaným kompilátorom. Vznikom Flex frameworku bol vydaný Flex SDK a vývoj aplikácií bol umožnený aj v Eclipse IDE s názvom Adobe Flex Builder, v súˇcastnotiAdobe Flash Builder. Flex SDK je aktuálne opensource a je spoloˇcnost’ou Adobe ponúkaný na stiahnutie z ich webových stránok pod licenciou Mozilla Public License. 1. netypovaný objekt môžme oznaˇcit’ ‘typom’ hviezdiˇcka: var untyped:*; 4 2.2. FLEX FRAMEWORK package com.mizerak { public class HelloWorld { public function sayHello():String { var greeting:String = "Hello World"; var untyped:*; var dict:Object = new Object(); dict.key1 = greeting; dict["key2"] = greeting; for (var key in dict) { dict[key] = greeting + "!"; } return greeting; } } } Obrázok 2.1: Helloworld a prvky jazyka ActionScript 3 2.2 Flex framework Flex framework vnáša do technológie Adobe Flash nové knižnice a funkcionalitu pre tvorbu rozsiahlych aplikácií. Rozširuje možnosti o deklaratívne programovanie pomocou jazyka MXML (dokument XML). Zdrojové kódy HelloWorld aplikácie naprogramovanej pre Flex sú na obr. 2.2 a 2.3. Obrázok 2.2: HelloWorld v MXML, verzia Flex 3 2.3 Adobe Flash Player Adobe Flash používa pre svoju distribúciu súbory SWF (odvodené z pôvodného Macro- media ShockWave Flash). SWF je proprietárny (uzavretý) binárny formát súboru urˇcený pre Adobe Flash Player. Tento prehrávaˇcv podobe plugin do internetového prehliadaˇca typu Mozilla alebo ActiveX modulu do Internet Explorer umožˇnujezobrazit’ Flash na in- ternetových stránkach. V HTML sa používa tag 5 2.3. ADOBE FLASH PLAYER Obrázok 2.3: HelloWorld v MXML, verzia Flex 4 Opera je funkˇcnezobrazený Flash pri použití zdrojového kódu na obrázku 2.4. Pre správne zobrazenie alternatívneho obsahu v Internet Explorer je nutné použit’ atribúty uvedené na obr. 2.5. Flash Player vo verzii Debugger umožˇnujevývojárom debug režim – teda sledovat’ a krokovat’ práve vykonávaný kód. Flash Player slúži ako sandbox pre prehrávanie a jeho súˇcast’ou je Virtual Machine pre spracovanie kódu. Tento sandbox nedovol’uje kódu operá- cie, ktoré by mohli zneužívat’ zdroje operaˇcnéhosystému a chráni užívatel’ove dáta. Obrázok 2.4: Vloženie SWF pomocou OBJECT Obrázok 2.5: Vloženie SWF pre Internet Explorer 2.3.1 Javascript knižnica SWFObject Najlepším riešením pre vkladanie SWF/Flash do internetových stránok je JavaScript knižni- ca SWFObject [5]. Automaticky deteguje prehliadaˇc,v ktorom je spustená a správne vloží SWF do každého z nich. Parametre metódy embedSWF (na obr. 2.6) sú: názov SWF súboru, identifikátor ciel’ového DOM objektu na stránke, rozmery a verzia požadovaného Flash Player. Ak prehliadaˇcneobsahuje plugin na zobrazovanie Flash obsahu, je mu ponúknutá možnost’ tento nainštalovat’ s priamym odkazom na stiahnutie potrebnej verzie (plugin, resp. ActiveX). 6 2.4. ADOBE AIR Alternative content
Obrázok 2.6: Vloženie SWF pomocou SWFObject
2.3.2 Bezpeˇcnostnépolitiky cross-domain Crossdomain.xml je XML dokument, ktorý vymedzuje použitie zdrojov pre SWF z inej domény2. Súborom crossdomain.xml je možné povolit’ len urˇcitéakcie SWF spustených z urˇcitýchdomén. Možno regulovat’ akceptované typy HTTP požiadaviek a prípustné do- mény [13].
Obrázok 2.7: Príklad odpovede na požiadavku crossdomain.xml, ktorý povol’uje všetky domény a typy požiadaviek
2.4 Adobe Air
Adobe Air je desktopová varianta Adobe Flash, kedy je po inštalácii na poˇcítaˇcoperaˇcným systémom umožnené pristupovat’ Air aplikácii k lokálnym prostriedkom. Vytvárat’ Air ap- likácie je možné v nástrojoch Adobe Flash Builder 4, Flash Catalyst a kompilovat’ pomocou
2. Ak flash.swf je spustený z domény www.site1.com a chce pristupovat’ k zdrojom domény www.site2.com, musí byt’ v súbore www.site2.com/crossdomain.xml uvedené povolenie pre využívanie zdrojov z domény www.site1.com
7 2.5. NÁSTROJE NA VÝVOJ
Flex SDK.
2.5 Nástroje na vývoj
Vyvíjat’ pre technológiu Flash je možné v mnohých komerˇcnýcha opensource prostrediach.
Adobe Flash urˇcenýhlavne grafikom; animovanie prebieha na ˇcasovejosi; scénu je možné rozvrh- nút’ do vrstiev
Adobe Flash Catalyst novinka pre Adobe Flash; umožˇnujevytvorit’ základnú štruktúru a interakcie i bez písania kódu; prepojitel’ný s d’alšími nástrojmi Adobe
Adobe Flash Builder 4 vývojové IDE postavené na Eclipse; urˇcenéhlavne vývojárom; umožˇnujedebug kódu; pôvodný Flex Builder
Powerflasher FDT 3 vývojové IDE postavené na Eclipse; urˇcenéhlavne vývojárom; umožˇnujedebug kódu
FlashDevelop 3.6.0 opensource IDE; podporuje ActionScript aj haXe3; neumožˇnujevšak debug kódu
3. haXe je opensource programovací jazyk zameraný na rôzne platformy a prostredia
8 Kapitola 3 Komunikaˇcnéprotokoly
Na prenos dát poˇcítaˇcovousiet’ou môžeme nahliadat’ rôznymi úrovˇnamipriblíženia. Na najnižšej úrovni to môže byt’ pohyb elektrónov na fyzickej vrstve siete, pohyb paketov na dátovej vrstve alebo prenos samotného súboru HTML na aplikaˇcnejvrstve. Tieto vrstvy abstraktne popisuje ISO-OSI siet’ový model. Spôsob, akým sa zariadenia na poˇcítaˇcovejsieti spolu dorozumievajú, je definovaný v špecifikácii daných protokolov [2].
Obrázok 3.1: Ilustraˇcnéporovnanie TCP/IP vzhl’adom na ISO/OSI
3.1 Hypertext transfer protocol
Hypertext transfer protocol (HTTP) je protokol aplikaˇcnejvrstvy. Vlastný prenos dát zabez- peˇcujeTCP, protokol transportnej vrstvy (Transmission Control Protocol). Pôvodne bol ten- to ˇcistotextový protokol vo verzii HTTP z roku 19921 vyvinutý pre prenos HTML súborov z webového serveru [6]. V roku 1996 prevzalo W3C a IETF koordináciu na vývoji HTTP/1.1,
1. oznaˇcovanýaj ako HTTP/1.0
9 3.1. HYPERTEXT TRANSFER PROTOCOL ktorý je aktuálne zhrnutý najmä v norme RFC 2616 [7]. Protokol je založený na modeli požiadavka-odpoved’ (request-response) a neudržiava si stav komunikácie. Klient inicial- izuje spojenie na transportnom protokole TCP s ciel’ovým serverom na aplikaˇcnomporte 802. Server naˇcúvajúcina tomto porte otvorí spojenie s klientom a oˇcakávapožiadavku ukonˇcenúprázdnym riadkom. Po obdržaní tejto požiadavky odošle ako odpoved’ status a telo správy. Telo správy obsahuje samotnú informáciu, iné zdroje alebo rozšírené chybové hlásenie.
Program telnet
Program telnet je možné použit’ pre HTTP komunikáciu. Pracuje na protokole TCP a môže- me pomocou neho posielat’ textové dáta. Pripojením na webový server na port 80 môžeme vyžiadat’ napríklad domovskú stránku pre web www.mojshop.sk následovne:
GET / HTTP/1.1 Host: www.mojshop.sk
3.1.1 Požiadavka
Po inicializovaní spojenia medzi klientom a serverom tento server ˇcakána správu od klienta. Správa je text obsahujúci hlaviˇckya telo; je ukonˇcenáprázdnym riadkom (CR LF, carriage re- turn a line feed 3). Prvý riadok požiadavky je zostavený z názvu metódy požiadavky, adresy a verzie HTTP protokolu. Nasledovat’ môžu d’alšie hlaviˇcky, podl’a typu metódy.
Metódy požiadaviek HTTP 1.1
RFC2616 definuje pre HTTP/1.1 tieto metódy:
OPTIONS reprezentuje požiadavku na možnosti komunikácie, ktoré sú dostupné na serveri pre požadovaný zdroj4
GET požiadavka na získanie informácií pre požadovaný zdroj (štandardné naˇcítaniezdro- jov, HTML stránky, obrázku a podobne)
HEAD zhodná s GET, ale server neodosiela žiadne telo správy (na získanie informácií o poža- dovanom zdroji)
2. pre HTTP je doporuˇcenýa zaužívaný port 80 3. slušný HTTP klient a server rešpektuje aj LF 4. zdrojom (Request-URI) sa rozumie napríklad adresa stránky
10 3.1. HYPERTEXT TRANSFER PROTOCOL
POST od serveru sa požaduje prevziat’ a spracovat’ priloženú entitu požadovaným zdrojom (odosielanie hodnôt formulárov)
PUT od serveru sa požaduje uloženie priloženej entity na daný zdroj
DELETE požiadavka na odstránenie zdroja
TRACE vyžiada odoslanú správu spät’ (pre overenie spojenia)
CONNECT vyhradená metóda pre použitie s proxy a tunelovaním
V bežnej praxi internetu sú však využívané najmä GET a POST. GET na získavanie we- bového obsahu ( HTML, CSS, JavaScript súborov, obrázkov, videa, . . . ). POST je vyžívaný najmä na zasielanie obsahu formulárových polí, obrázkov a v technológii AJAX. Telo správy (ak je danou metódou podporované) nasleduje po hlaviˇckácha prázdnom riadku. Obsahuje priloženú entitu, napríklad hodnoty formulárových polí alebo posielaný obrázok.5
Ukážka HTTP požiadavky POST
Ukážková požiadavka 3.2 slúži na vloženie dvoch produktov do košíka. Priloženou en- titou je zakódovaný ret’azec itemid=428&count=2&action=add. Pripojením na server požadujeme odoslat’ túto entitu na zdroj /cart.php ˇcoje PHP skript pre manipuláciu s košíkom. Pre identifikáciu virtuálneho serveru použijeme hlaviˇcku Host. Hlaviˇckyzaˇcí- najúce na slovo Content informujú server o priloženej entite – obsahu správy.
POST /cart.php HTTP/1.1 Host: www.mojshop.sk Content-Type: application/x-www-form-urlencoded Content-Length: 29 itemid=428&count=2&action=add
Obrázok 3.2: Ukážka HTTP požiadavky metódou POST
5. Architektúra založená na štýle REST využíva GET na SELECT (získanie), PUT na INSERT (vytvorenie), POST na UPDATE (aktualizovanie) a DELETE na DELETE (odstránenie) záznamu na danom zdroji.
11 3.1. HYPERTEXT TRANSFER PROTOCOL
3.1.2 Odpoved’
Po prijatí a interpretovaní požiadavky server odpovedá HTTP odpoved’ou. Prvý riadok je status danej odpovede kategorizovaný podl’a kódu (Status-Code). Po statuse nasledujú d’alšie hlaviˇckyoddelené od tela správy prázdnym riadkom. Status-Code nadobúda tieto možné hodnoty:
1xx: informaˇcnýstatus (Informational) požiadavka bola prijatá, pokraˇcujesa so spracovaním
2xx: úspešný status (Success) požiadavka bola úspešne prijatá, pochopená a akceptovaná
3xx: presmerovanie (Redirection) pre dokonˇceniepožiadavky je nutné d’alšej akcie (presmerovania)
4xx: chyba klienta (Client Error) požiadavka obsahuje chyby alebo jej nemôže byt’ vyhovené
5xx: chyba serveru (Server Error) serveru sa nepodarilo splnit’ požiadavku
Ukážková odpoved’ na POST
HTTP/1.1 200 OK Date: Sat, 08 May 2010 13:25:53 GMT Transfer-Encoding: chunked Content-Type: text/html
Obrázok 3.3: Odpoved’ na požiadavku z 3.2
Status 200 OK informuje o úspechu vykonaní požiadavky (obr. 3.3). Nasleduje hlav- iˇckaDate s ˇcasomwebserveru a informácie o obsahu (Transfer-Encoding a Content-Type). V samotnom tele správy je PHP skriptom vygenerovaný dokument informujúci používatel’a o úspechu vkladania produktu do košíka.
12 3.2. SOCKET A XMLSOCKET
3.1.3 HTTP a Flash
Pre komunikáciu na úrovni HTTP sú pre Flash dostupné triedy v package flash.net. URL- Loader slúži na posielanie požiadaviek typu URLRequest prostredníctvom URLStream. Po- mocou objektu URLStream je možné sledovat’ priebeh st’ahovania výsledku požiadavky, napríklad pri st’ahovaní väˇcšiehosúboru. URLLoader je v bežnej praxi zvykom používat’ na naˇcítanied’alších externých zdrojov pre SWF a to napríklad zvuky, obrázky, konfiguraˇcné súbory v XML ale i externé SWF. public function URLRequestMethod() { var request:URLRequest = new URLRequest("http://www.mojshop.sk/cart.php"); request.method = URLRequestMethod.POST;
var data:URLVariables = new URLVariables(); data.itemid = "428"; data.count = "2"; data.action = "add"; request.data = data;
var loader:URLLoader = new URLLoader(); loader.addEventListener(Event.COMPLETE, loaderComplete); loader.addEventListener(IOErrorEvent.IO_ERROR, loaderIOError);
loader.load(request); }
Obrázok 3.4: Príklad požiadavky POST pomocou URLRequest
V metóde URLRequestMethod v zdrojovom kóde 3.4 je použitý objekt URLRequest na odoslanie jednoduchej požiadavky POST na server. Požiadavka generovaná týmto spôso- bom je zhodná s ukážkou 3.2.
3.2 Socket a XMLSocket
Socket a XMLSocket sa nachádzajú v package flash.net. Pomocou triedy Socket vytvárame obojsmerné binárne spojenie na protokole TCP. Umožˇnujeposielat’ binárne dáta smerom server-klient i klient-server. Na rozdiel od HTTP spojenia cez URLRequest je Socket a XML- Socket spojenie trvalo otvorené a umožˇnujetak serveru posielat’ dáta klientovi aj bez za- sielania požiadavky klientom pre získanie aktualizácie (polling).
13 3.3. REAL-TIME MESSAGING PROTOCOL
3.2.1 Socket
Socket operuje nad binárnym spojením TCP. Umožˇnujeteda odosielat’ a ˇcítat’ iba binárne dáta. Socket spojenie je z bezpeˇcnostnéhohl’adiska obmedezené na doménu, z ktorej je SWF spustený. SWF súbory naˇcítanéa spustené z lokálnej domény (zo súborového systému file://, local-with-filesystem sandbox) nemajú dovolené používat’ Socket spojenie.
3.2.2 XMLSocket
Trieda XMLSocket operuje nad binárnym spojením TCP, ale umožˇnujevymieˇnat’ iba XML dokumenty medzi klientom a serverom. Socket spojenie zaruˇcujeobojsmerný prenos. Pre- nášané XML správy sú kompletné a well-formed XML dokumenty ukonˇcenénulovým baj- tom (zero byte). Na jednom uskutoˇcnenomXMLSocket spojení je možné posielat’ a prijímat’ neobmedzené množstvo XML správ. Ako aj pre Socket, tak aj pre XMLSocket platí, že nie je možné vytvárat’ XMLSocket spojenie zo SWF spusteného z lokálnej domény. Avšak na rozdiel od Socket má XMLSocket možnost’ spojit’ sa so serverom z inej domény a to za pod- mienky, že tento server poskytne crossdomain.xml (obrázok 2.7), ktorý túto akciu povol’u- je [13].
3.3 Real-Time Messaging Protocol
Real-Time Messaging Protocol (RTMP) bol navrhnutý ako binárny proprietárny aplikaˇcný protokol spoloˇcnost’ou Adobe pre vysoko výkonné prenosy zvuku, videa a interaktívneho obsahu medzi Adobe Flash technológiami vrátane Adobe Flash Player a Adobe Air [14][12]. Špecifikácia RTMP bola zverejnená 20. januára 2009 spoloˇcnost’ou Adobe v rámci projektu Open Screen Project so zámerom sprístupnit’ RTMP pre prehliadanie internetu a samostatné aplikácie na osobných poˇcítaˇcoch,mobilných zariadeniach a spotrebnej elektronike. Podl’a špecifikácie RTMP je tento protokol vhodný na široké použitie v audio-video aplikáciách pre vysielania typu one-to-one (unicast), one-to-many (multicast) a video-on- demand (video na vyžiadanie), ako aj interaktívne aplikácie a online konferencie. RTMP spolu s použitím zaruˇcenéhoprenosu protokolom TCP garantuje ˇcasovooznámkované a us- poriadané doruˇcenievšetkých správ (všetkými otvorenými spojeniami). Samotný protokol však nemá kontrolu nad prioritou doruˇcovaniaspráv. Pre tento úˇcelje možné využit’ nas- tavenie vyššieho protokolu napríklad na strane serveru, nastavením zanechania dát obsahu- júcich video na úkor zvuku, ktorý je pre videokonferenciu dôležitejší. Toto rozhodovanie môže prebiehat’ na základe doby, ktorú klient potrebuje na zaslanie potvrdenia (ACK) da- ného TCP paketu s videom. Spojenie RTMP je inicializované s handshake. Handshake je špeciálna ˇcast’ posielaných dát. Pozostáva z troch ˇcastís fixnou d´lžkou. Klient (koncový bod - endpoint, ktorý inicial- izuje spojenie) i server si vymieˇnajúrovnaké 3 dátové bloky (chunks, C0-2 zo strany klienta, S0-2 zo strany serveru). Handshake prebieha následovne: klient odošle 2 dátové bloky a ˇcaká,kým sa vráti na každý z nich odpoved’ od serveru predtým, ako bude posielat’ d’alšie
14 3.3. REAL-TIME MESSAGING PROTOCOL dáta. Druhý paket o d´lžke 1536 bajtov odoslaný od klienta obsahuje náhodné dáta, ktoré ˇcakázo serveru ako odpoved’, nezmenené. Nasledujúca komunikácia prebieha po viacerých kanáloch. Posielané dáta sa rozkladajú na dátové bloky dynamickej d´lžky6 a posielajú sa týmito kanálmi. Dátové bloky sú identifikované a dáta sú zostavené na druhom koncovom bode na základe znaˇckyidentifikátora kanálu (stream ID). Dátové bloky sú zostavené z hlaviˇckya tela správy. V hlaviˇckesú informácie o prilože- ných dátach (ˇcasováznámka, d´lžka správy, typ správy a streamID). Samotné telo správy ob- sahuje dáta rôzneho typu. Môže to byt’ komprimované video, kus zvukového záznamu ale- bo binárne dáta vo formáte AMF (Action Message Format) [8][9]. AMF je pre Flash natívny formát (serializovaný ActionScript objekt), preto Flash Player môže takto uložené objekty priamo používat’. Pri požiadavke na stream videa zo serveru klient odošle požiadavku na spojenie, objekt typu NetConnection a objekt typu NetStream vo formáte AMF cez RTMP.
3.3.1 RTMPT Flash Player komunikuje štandardne protokolom RTMP na porte 1935. Pri striktnom nas- tavení podnikového firewall, ktorý bráni spojeniu TCP/IP na štandardnom porte, sa Flash Player pokúša spojit’ sa cez port 443 alebo 80. Tento prístup umožˇnujetakmer 96 % použí- vatel’ov pristupovat’ k službám RTMP serveru. Pre doruˇcenieobsahu takmer 100 % používatel’ov je možné použit’ proxy server ale- bo HTTP ako protokol na posielanie RTMP dátových blokov (HTTP tunneling). Správy posielané variantou RTMPT (RTMP Tunneled) sú väˇcšieako ekvivalent posielaný RTMP a taktiež viac zat’ažujú CPU oboch úˇcastníkovkomunikácie. Varianta RTMPS (RTMP Secure) používa na prenos dát tunelovanie cez HTTPS.
3.3.2 Stream audia a videa Pre zobrazovanie videa vo Flash môžme použit’ objekt typu flash.media.Video. Objekt Video umožˇnujezobrazit’ video živé alebo zo záznamu bez toho, aby bol zdroj obsiahnutý v samotnom SWF súbore. Prehrávat’ môže FLV (FLash Video) uložené lokálne, na serveri alebo živé video priamo z používatel’ovho poˇcítaˇca.Pri použití spojenia (NetStream) so serverovou aplikáciou Flash Media Server môže klient posielat’ toto živé video na server a ten ho rozpošle (broadcast) d’alším používatel’om. Pre prehrávanie zo siet’ového zdroja ako je napríklad RTMP server sa používa metóda attachNetStream() (príklad na 3.5), pre zobrazenie živého videa z kamery lokálneho poˇcítaˇcametóda attachCamera().
3.3.3 NetConnection Trieda NetConnection (flash.net.NetConnection) vytvára obojsmerné spojenie medzi dvoma stranami komunikácie na aplikaˇcnejúrovni. Využívat’ môžeme RTMP alebo AMF bránu cez HTTP. NetConnection umožˇnujevzdialené volanie procedúr (Flash remoting) a posielanie
6. d´lžka dátového bloku je v intervale [128, 65 536] bajtov
15 3.3. REAL-TIME MESSAGING PROTOCOL var nc:NetConnection = new NetConnection(); nc.connect("rtmp://server-name.com/vod/"); var ns:NetStream = new NetStream(nc); ns.play("video1"); // video1.flv var v:Video = new Video(); v.attachNetStream(ns);
Obrázok 3.5: Pripojenie a zobrazenie videa z RTMP serveru objektov. Na obrázku 3.5 sa pripája NetConnection na objekt ‘vod’. Pomocou objektu Net- Stream volá play metódu na zdroji ‘video1’. NetStream slúži na posielanie objektov pros- tredníctvom NetConnection.
3.3.4 RemoteObject RemoteObject (mx.rpc.remoting.RemoteObject) ako súˇcast’ Flex framework ul’ahˇcujeprácu s Flash remoting vzdialeným volaním procedúr. Vytvára prístupové rozhranie na objekt umiestnený na strane serveru. RemoteObject komunikuje s AMF bránou, ktorá poskytu- je rozhranie k metódam zdiel’aného objektu. Každé volanie inicializuje nové HTTP, odošle príslušné hlaviˇcky, serializovaný AMF objekt s požiadavkou a ˇcakána odpoved’ zo serveru. Je teda ihned’ jasné, ˇcivolanie prebehlo alebo nastala chyba. Ak však potrebujeme komu- nikovat’ aj s inými klientami, prípadne chceme dovolit’ serveru vyvolat’ akciu u klienta, RemoteObject nebude postaˇcovat’, pretože spojenie na HTTP je možné vyvolat’ iba z klien- ta. Ak je vyžadovaná autentizácia pre použitie objektov na strane serveru, klient nastavuje prístupové údaje metódou setRemoteCredentials(). Volanie vzdialených procedúr (metód na objektoch na strane serveru) sprístupˇnujemetóda getOperation() alebo deklaratívny zá- pis elementom method. Zdrojový kód 3.6 ukazuje použitie RemoteObject deklarovaného v MXML na volanie metódy getMyData na strane serveru. RemoteObject vykonáva akcie asynchrónne, treba preto nastavit’ akcie pre úspech a zlyhanie vzdialenej operácie.
3.3.5 SharedObject SharedObject (flash.net.SharedObject) je urˇcenýna ukladanie a ˇcítaniemalého množstva dát na strane klienta (LSO, Local Shared Object) alebo serveru. LSO je známy aj ako Flash cookies. Ukladá sa do izolovaného úložiska avšak mimo úložisko cookies internetového prehliadaˇca.SharedObject ponúka real-time zdiel’anie dát medzi niekol’kými SWF súˇcasne a to pomocou LSO alebo SharedObject distribuovaných cez server. Komunikuje spojením klient-server na protokole RTMP. Cez server je takto možný multicast všetkým klientom pristupujúcim k danému SharedObject.
16 3.4. REAL-TIME MEDIA FLOW PROTOCOL
Obrázok 3.6: Použitie RemoteObject var lso:SharedObject = SharedObject.getLocal("mySampleLSO"); lso.data = new Person("Tomas Mizerak", ...); lso.flush();
Obrázok 3.7: Použitie SharedObject lokálne
Metóda setProperty nastavuje položku zdiel’aného objektu (remoteObject.data) a oz- naˇcujeju ako dirty, ˇcospôsobí vyvolanie synchronizácie medzi všetkými klientmi, ktorí sú pripojení na daný objekt. Zdiel’aný objekt môžu takto menit’ súˇcasneviacerí klienti. Pre vytvorenie transakcie (neprerušitel’nej operácie nastavenia dátovej položky) sa volá metóda lock() a po ukonˇcenízmien unlock(). Každá zmena na SharedObject vyvolá reakciu onSync. Na onSync môže byt’ preto naviazaná akcia u ostatných klientov, resp. na strane serveru.
3.4 Real-time media flow protocol
Real-time media flow protocol (RTMFP) je nový komunikaˇcnýprotokol od Adobe s uzavre- tou (nezverejnenou) špecifikáciou [10]. Dovol’uje priamu komunikáciu medzi samotnými inštanciami Flash Player a aplikáciami Adobe Air, tzv. peer-to-peer. RTMFP je vhodné pre aplikácie, v ktorých záleží na rýchlom doruˇceníaudia, videa a iných dát, napríklad apliká- cie pre sociálne siete a multiplayer hry. Umožˇnujeto priame spojenie koncových bodov, bez nutnosti posielat’ dáta prostredníctvom serveru. Preto je prenos peer-to-peer pomocou RTMFP pre poskytovatel’ov služieb výhodný [12][3]. Protokol prenáša dáta na siet’ovom protokole UDP (User Datagram Protocol) [11]. Paket UDP je menší ako paket prenášaný TCP, preto je aj tento prenos rýchlejší. UDP v štandard- nom nastavení nemá žiadnu kontrolu nad doruˇcenímsprávy a server neˇcakána potvrdenie
17 3.4. REAL-TIME MEDIA FLOW PROTOCOL var nc:NetConnection = new NetConnection(); nc.connect("rtmp://server-name.com/mysharedobjectsapp"); var rso:SharedObject = SharedObject.getRemote("mySampleRSO", nc.uri, false); rso.connect(nc); rso.setProperty("myProp", someObject); // server-side rso.data["myProp2"] = someObject2; // client-side rso.data.myProp3 = someObject3;
Obrázok 3.8: Použitie SharedObject a NetConnection na server prenosu7. UDP je teda efektívnejší spôsob prenášat’ audio a video dáta. UDP ul’ahˇcujeaj komunikáciu za NAT (network address translation8), pretože umožˇnujetzv. NAT traversal. K tomuto však potrebuje server ako prostredníka k otvoreniu portov na oboch stranách s NAT. Rozdiel medzi RTMP a RTMFP je teda siet’ový protokol, kde RTMP používa zaruˇcený TCP a RTMFP rýchly ale nespol’ahlivý UDP. Prenos dát protokolom RTMFP je neustále šifrovaný šifrou o d´lžke 128-bit. Na to aby klient mohol prehrávat’ video stream zasielaný pomocou RTMFP musí vediet’ názov streamu a tzv. Peer ID koncového bodu, ˇcotento stream vysiela. Peer ID je 256-bitová hodnota asociovaná s identitou zdroja. Taktiež odbera- tel’ tohto streamu musí potvrdit’ požiadavku na spojenie. var nc:NetConnection = new NetConnection(); nc.connect("rtmfp://stratus.adobe.com/YOUR-DEVELOPER-KEY"); var myPeerID:String = nc.nearID; var sendStream:NetStream = new NetStream(nc, NetStream.DIRECT_CONNECTIONS); sendStream.publish("media"); var recvStream:NetStream = new NetStream(nc, farPeerID); recvStream.play("media"); nc.call("someMethodOnOtherPeer", ...someArgs);
Obrázok 3.9: peer-to-peer s použitím Adobe Labs Stratus
Momentálna implementácia RTMFP sa nachádza vo Flash Player od verzie 10. Adobe Flash Player 10, ktorý umožˇnujetoto asistované peer-to-peer spojenie je rozšírený na viac ako 90 % klientských poˇcítaˇcov. Server, ktorý však poskytuje službu nie je komerˇcneprís-
7. Pre zaruˇcenýprenos sa používa TCP alebo RUDP (Reliable User Datagram Protocol, varianta UDP) 8. skrývanie adries za siet’ové zariadenia typu router
18 3.4. REAL-TIME MEDIA FLOW PROTOCOL tupný. Je možné však použit’ Adobe Labs Stratus, ˇcoje pre vývojárov zadarmo poskytovaný server pre asociáciu klientov a ich Peer ID. Na posielanie Peer ID medzi nimi však potre- bujeme využit’ iný server ako tretiu stranu. V ukážke výˇnatkovzo zdrojového kódu na 3.9 otvoríme oboma klientami spojenie NetConnection na Stratus server. Získame tak Peer ID potrebné na spojenie. Peer ID navzájom vymeníme prostredníctvom iného kanálu (napríklad cez NetCon- nection prostredníctvom serveru) a inicializujeme kanál objektom NetStream. Klient, ktorý vysiela, zadáva ako druhý argument NetStream.DIRECT_CONNECTIONS. Príjemca auto- rizuje zadaním Peer ID vzdialeného klienta (farPeerID). NetStream.publish("media") zareg- istruje kanál "media"na RTMFP pre posielanie správ. Volanie vzdialenej procedúry potom prevedieme volaním metódy call na objekte NetConnection.
19 Kapitola 4 Serverové aplikácie
Na trhu je vel’ké množstvo implementácií serverových riešení. Každé riešenie ponúka rôzne sady implementovaných protokolov a spôsobov komunikácie s Flash Player. Sú to jednodu- ché riešenia napísané v skriptovacích jazykoch ako je PHP alebo Ruby, ako aj komplexné riešenia naprogramované v C++, Java a C#. Pôvodnými produkatmi Adobe pre serverové riešenie je Adobe ColdFusion a Flash Me- dia Server. ColdFusion slúžil pre Flash remoting tým, že poskytoval AMF bránu pre volanie vzdialených procedúr. Flash Media Server poskytoval zväˇcšalen multimediálny obsah vo forme audio a video stream a komunikáciu klientov cez SharedObject. V súˇcasnostije však na trhu množstvo iných riešení, ktoré posúvajú možnosti komunikácie klient-server o kus d’alej.
4.1 AMF brána
AMF brána pre Flash remoting je súˇcast’ ColdFusion serveru a množstva opensource pro- jektov ako sú: AMFPHP, ZendAMF, RubyAMF, PyAMF a iné. Binárne AMF objekty musia byt’ zakódované do textu pre prenos cez HTTP a na strane serveru spät’ odkódované, dese- rializované a spracované samotnou aplikáciou. Vel’ké zdržanie nastáva aj pri otváraní TCP spojenia a výmene sprievodných hlaviˇciekprotokolu. Toto riešenie nie je teda vhodné pre aplikácie s vysokým poˇctompoužívatel’ov vyžadujúcich neustály prísun dát, ako v prípade streamingu audia a videa.
Obrázok 4.1: HelloWorld v AMFPHP
Na príklade 4.1 deklarujeme v PHP triedu HelloWorld a jej metódu say. Pre spuste-
20 4.2. KOMPLEXNÉ RIEŠENIA nie tejto metódy na strane serveru staˇcínaviazat’ RemoteObject na AMF bránu (napríklad http://server-name.com/amfphp/gateway.php) a invokovat’ vzdialeným volaním procedúry na RemoteObject (ako v kóde 3.6). Výhodou AMF brány je v prípade použitia AMFPHP alebo ZendAMF jednoduché nasa- denie, pretože webhostingové riešenia s podporou PHP sú vel’mi dostupné.
4.2 Komplexné riešenia
4.2.1 Flash Media Interactive Server Základným riešením pre poskytovanie multimediálneho obsahu pomocou RTMP je Adobe Flash Media Server. Rozšírenie Interactive dop´lˇnamožnost’ využívat’ server-side Action- Script na vytvorenie aplikácií pre RemoteObject a SharedObject. Ako úˇcastníkspojenia môže nahrávat’ obsah (stream webkamery klienta) v reálnom ˇcases kodekmi H.264 a AAC. Pri poskytovaní multimediálneho obsahu automaticky nastavuje kvalitu prenášaného obrazu a zvuku v závislosti na šírke pásma spojenia. Flash Media Interactive Server ani server-side ActionScript však nemôže priamo pristupovat’ k databázam.
4.2.2 BlazeDS BlazeDS je serverové riešenie naprogramované v jazyku Java. Pôvodne ho vyvíjalo Adobe, no v roku 2007 ho uvol’nilo ako opensource. Spustit’ je ho možné ako Tomcat1 webovú aplikáciu. Implementuje Flash remoting a AMF bránu pre “real-time” komunikáciu klient- server. Flash remoting invokuje Java triedy umiestnené v aplikaˇcnomadresári BlazeDS ser- veru.
4.2.3 WebORB for .NET WebORB for .NET od MidnightCoders naprogramovaný v C# poskytuje AMF bránu, Share- dObject, RemoteObject, Flash remoting a implementáciu RTMP. Vzdialené volanie procedúr využíva objekty nasadené vo forme .NET knižníc. V základnej inštalácii je aj generátor kó- du pre Flash, Flex, PureMVC2, Cairngorm3. Obsahuje taktiež komplexný Data Management pre generovanie ORM4 z vybranej databázy a to pre klientskú (MXML a ActionScript 3) aj serverovú (C# 2.0) ˇcast’ aplikácie.
4.2.4 Red5 Opensource projekt Red5 je napísaný v jazyku Java pre Tomcat server. Implementuje AMF bránu aj RTMP pre RemoteObject a SharedObject. Ako aj BlazeDS implementuje Flash re-
1. Apache Tomcat, webový server napísaný v jazyku Java, implementuje Java Servlet a JavaServer Pages 2. model-view-controller framework pre Flex a iné jazyky 3. Adobe sada knižníc, nástrojov a návrhových vzorov pre vývoj Flex aplikácií 4. objektovo relaˇcnémapovanie; mapuje relácie z databázy do objektov
21 4.3. RTMFP SLUŽBY moting nad Java objektami. Red5 pôvodne vznikol ako reverse engineering protokolu RTMP a AMF, ked’ špecifikácie týchto ešte neboli zverejnené.
4.2.5 Wowza Media Server
Dalšíˇ komerˇcnýmultimediálny Java server. Implementuje AMF bránu aj RTMP pre Remo- teObject, SharedObject a volanie metód Java tried. Narozdiel od opensource produktov však výrobca poskytuje platenú podporu.
4.2.6 LiveCycle Data Services
LiveCycle Data Services je služba ponúkaná spoloˇcnost’ou Adobe. Slúži ako vysoko výkon- né a škálovatel’né riešenie. Vysokú dostupnost’ zaruˇcujenasadenie do cluster riešenia5. Im- plementuje RemoteObject, SharedObject, Flash remoting ako aj RTMP. Dovol’uje nasadit’ vlastné Java objekty a databázu pre uloženie perzistentných dát.
4.3 RTMFP služby
Ked’že špecifikácia protokolu RTMFP nie je verejná, na trhu nie sú iné riešenia ako priamo od spoloˇcnostiAdobe. Sú to Stratus a LiveCycle Collaboration Services (LCCS).
4.3.1 Adobe Labs Stratus Stratus je služba poskytovaná Adobe Labs pre vývojárov. Umožˇnujespojit’ aplikácie plat- formy Adobe Flash priamym spojením na protokole RTMFP. Pôvodne bol Stratus v roku 2008 publikovaný ako služba pre asistenciu peer-to-peer spojenia. Posledné rozšírenie služ- by Stratus (na verziu 2) a Adobe Flash Player 10.1 umožˇnujemulticast pre skupiny použí- vatel’ov pripojených pomocou RTMFP taktiež peer-to-peer. Služba Stratus nie je urˇcenápre komerˇcnépoužitie. Využívat’ ju môžu iba vývojári, ktorý obdržali beta developer key. Aktuálne je Stratus obmedzený na 10 simultánnych spojení pomocou RTMFP. Komerˇcnénasadenie Adobe plánuje v pripravovanej verzii Adobe Flash Media Server 4 (FMS 4). Niektorú funkcionalitu je už však možné nájst’ v službe LiveCycle Collaboration Services.
4.3.2 LiveCycle Collaboration Services LiveCycle Collaboration Services (LCCS) je platená služba. Cena sa vypoˇcítavapodl’a množ- stva prenesených dát a poˇctuhodín pripojenia jediného klienta. LCCS aktuálne poskytuje RTMFP pre peer-to-peer prenos videa a audia. Pre dáta (AMF objekty) je však nutné využit’ služby push messages, ktorá je spoplatnená za každú tisícku správ. Výhodou LCCS oproti
5. množina prepojených poˇcítaˇcov, ktoré spolu úzko spolupracujú; zlyhanie jedného stroja tak neovplyvní dos- tupnost’ služieb
22 4.3. RTMFP SLUŽBY službe Stratus je spätná kompatibilita. Ak sa klient nachádza za NAT, ktoré je pre RTMFP neprechodné, použije sa riešenie cez protokoly triedy RTMP.
23 Kapitola 5 Porovnanie výkonu protokolov HTTP a RTMP
Ciel’om merania je zistit’, ktorý protokol je výhodnejší pre vzdialené volanie procedúr klient- server pre nároˇcnúaplikáciu pracujúcu s vel’kým množstvom dát a operácií vykonávaných na strane serveru. Pre porovnanie výkonnosti HTTP a RTMP v praxi som naprogramoval jednoduchý ná- stroj (na priloženom CD). Test ukazuje, ktorý protokol je výhodnejší pre vel’ké množstvo volaní vzdialených procedúr na serveri z jedného klienta.
5.0.3 Prostriedky na testovanie Hardware PC s procesorom Intel Core 2 Duo E8200 (2.66GHz), operaˇcnápamät’ 4 GB
Software
• Microsoft Windows 7 Professional • Internet Information Services 7.5 • .NET Framework v2.0 • WebORB for .NET 3.6.0.3 • klientská aplikácia (Benchmark.swf) • serverová aplikácia (Benchmark.dll)
5.1 Algoritmus
1. Klient si vyžiada zo serveru testovací objekt (TestObject)
2. Server vytvorí nový testovací objekt a pošle ako odpoved’ klientovi
3. Klient zvýši hodnotu clientcount++1 a pošle na spracovanie serveru
4. Server zvýši hodnotu servercount++ a pošle klientovi
1. dátová položka testovacieho objektu typu int
24 5.2. SERVEROVÁ CASˇ Tˇ
Kroky 3 a 4 sa opakujú. Pre každú n-tú iteráciu2 sa odmeria ˇcas,ktorý sa vykresluje do grafu.
5.2 Serverová ˇcast’
BenchmarkAppHandler aplikaˇcný handler pre RTMP spojenie Tests verejná trieda a metódy operujúce s TestObject TestObject objekt na prenášanie informácií medzi klientom a serverom
Pre potreby serverovej ˇcastiaplikácie som zvolil WebORB for .NET 3. Do adresáru pre aplikácie (weborb30/Applications) som nahral app.config. Tento definuje handler pre poži- adavky na aplikáciu a smeruje ich na implementovaný BenchmarkAppHandler. Aplikácia je nutná pre RTMP pripojenie. Pre Flash remoting AMF/HTTP postaˇcujenasadit’ knižnicu s verejnými metódami. Použité sú metódy: GetTestObject() a ReceiveTestObject(TestObject to).
5.3 Klientská ˇcast’
Klientská ˇcast’ je napísaná vo Flash Builder 4 a Flex framework (Flex SDK 4). Benchmark.mxml hlavný objekt zobrazuje graf a ovládacie prvky pre meranie TestHTTP.mxml komponenta pre meranie Flash remoting pomocou RemoteObject cez HTTP TestRTMP.mxml komponenta pre meranie vzdialených volaní procedúr pomocou NetConnection.call cez RTMP CSVExport.mxml komponenta pre export dát do CSV4
Hlavnou ˇcast’ou programu je trieda Benchmark, ktorá sústred’uje a vykresl’uje dáta o- doslané z komponent TestHTTP a TestRTMP. Pre možnost’ exportu zobrazuje komponentu CSVExport (pre import do tabul’kového editoru a na výpoˇcetštatistiky).
2. hodnota n je menitel’ná posuvníkom v dolnej ˇcastigrafického rozhrania aplikácie; východzie nastavenie 30, tj. ked’ clientcount mod 30 = 0 3. v stabilnej verzii 3.6.0.3 4. comma separated values;
25 5.4. VÝSLEDKY
Obrázok 5.1: Porovnanie výkonnosti HTTP a RTMP
5.4 Výsledky
Meral som na testovacom poˇcítaˇcis uvedenou konfiguráciou a výsledky som exportoval do CSV. Tieto som potom importoval do tabul’kového editoru Excel a zostavil graf a deskrip- tívnu štatistiku. Výsledky sú zaznamenané v tabul’ke na obr. 5.2 (dáta ku grafu na obr. 5.1 a k tabul’ke na obr. 5.2 sú v súbore HTTPvsRTMP.xls na priloženom CD). Záverom je, že RTMP je pre danú aplikáciu rýchlejší 6, 29-násobne. Výkonnost’ RTMP zaruˇcujevyužívanie už otvoreného spojenia. HTTP spojenie sa totiž otvára vždy pri vzdi- alenom volaní (RemoteObject) a ukonˇcísa ihned’ po prevzatí odpovede klientom. Taktiež spracovanie HTTP požiadavky trvá dlhšie, pretože sa odovzdáva viacej dát, a to binárne AMF objekty zakódované v texte a sprievodné textové hlaviˇcky(HTTP požiadavky a odpo- vede). RTMP spojenie je otvorené poˇcascelého testu u klienta i serveru.
26 5.4. VÝSLEDKY
HTTP RTMP poˇcetiterácií 100 100 poˇcetmeraní 201 201 priemer 4167, 26ms 662, 38ms priemer na 1 iteráciu 41, 67ms 6, 62ms medián 4167ms 656ms modus 4167ms 660ms
Obrázok 5.2: Zhrnutie výsledkov merania HTTP a RTMP
27 Kapitola 6 Program BPChat
Ako vzorovú aplikáciu komunikácie klientov na platforme Adobe Flash som vytvoril jed- noduchý chat, BPChat. Aplikácia pozostáva z klientskej a serverovej ˇcasti.Ako klient slúži Flash vložený do HTML stránky. Server je aplikácia WebORB for .NET nasadený na IIS 7.5 (Internet Information Services, verzia dodaná s operaˇcnýmsystémom Windows 7) s mod- ulom BPChatAppHandler. Spojenie klienta a serveru prebieha na RTMP, spojenie klientov peer-to-peer pomocou RTMFP.
6.1 Klientská ˇcast’
Používatel’ským rozhraním k aplikácii je klientská ˇcast’. Na vývoj tejto klientskej ˇcastiap- likácie som použil nástroj Adobe Flash Builder 4. Výsledné SWF som kompiloval kompilá- torom mxmlc1 z Flex SDK 4. Pre návrh grafického rozhrania som použil vstavaný design- er, ktorý pracuje s komponentami z package spark.components. Umiestnenie komponent v dynamickom rozložení (dodržanie st´lpcového rozloženia) zabezpeˇcujúobjekty HGroup a VGroup s rozmermi zadanými v percentách (100 % pre vyplnenie celého vol’ného priestoru). Vstupné texty používatel’ zadáva do TextInput, zoznam pripojených používatel’ov zobrazu- je objekt List (Online users) s volitel’ným vykresl’ovaním dátových položiek pomocou Item- Renderer. Tento je použitý pretože zoznam používatel’ov udržuje informáciu nielen o mene, ale aj jeho unikátnom ID v dátovej položke objektu DataItemVO. Pre zobrazovanie vlast- ných správ, ˇciuž prijatých, odoslaných alebo systémových, je použitý objekt TextArea (Main lobby room). Po spustení Flash klienta používatel’ zadá svoje meno, pod ktorým bude vystupovat’ v miestnosti. Klient otvorí RTMP spojenie (NetConnection) na serverovú aplikáciu a dosta- ne serverom pridelené unikátne ID. Otvorené spojenie RTMP je signálom, že používatel’ je aktívny (online). Príchod do miestnosti hlási klient volaním metódy EnterRoom. Odoslanie správy zadanej do pol’a a stlaˇcenímtlaˇcítkasa vyvolá akcia, ktorá zavolá na serveri metó- du SendMessage. Správa je serverom následne rozoslaná všetkým prihláseným klientom a zobrazená v hlavnom okne správ (Main lobby room). Ak chce používatel’ súkromne komunikovat’ s iným úˇcastníkom,dvojitým kliknutím v zozname sa otvorí nové okno súkromného chatu (Private session). Spojenie súkromného chatu prebieha prostredníctvom RTMFP. Ak chce jeden klient (nazvem ho Alica) kontak-
1. mxmlc verzia 4.0.0 build 14159
28 6.2. SERVEROVÁ CASˇ Tˇ
Obrázok 6.1: Sekvenˇcnýdiagram znázorˇnujúciinicializáciu peer-to-peer spojenia tovat’ druhého klienta (Bob), tak sa najskôr spojí so službou Stratus. Stratus pridelí Alici identifikátor PeerID. Alica ho odošle prostredníctvom metódy SendPeerIDToOtherClient serverovej aplikácie (BPChatApp) Bobovi. Ten sa pripojí na Stratus a akceptuje spojenie od Alice. Tým sa ustanoví peer-to-peer spojenie medzi Alicou a Bobom. Alica a Bob si tak môžu zasielat’ správy pomocou objektu NetStream, ktorý je naviazaný na RTMFP NetConnection.
6.2 Serverová ˇcast’
Implementáciu serverovej aplikácie som nasadil na WebORB for .NET2 v IIS 7.5. Objekty a metódy, ktoré WebORB poskytuje ako aplikáciu sú v .NET knižnici BPChat.dll. Na písanie a vývoj knižnice som použil Microsoft Visual C# 2010 Express. Do projektu bolo nutné refer- encovat’ knižnicu weborb.dll dodávanú spolu s WebORB for .NET. Obsahuje implementácie potrebných objektov na manipuláciu so spojením a abstraktnú triedu ApplicationAdapter. Táto slúži ako základ pre triedu BPChatAppHandler. Pret’ažená metóda appStart vytvára novú inštanciu generickej kolekcie Dictionary3 pre udržiavanie aktívnych klientov. Objekt BPChatAppHandler existuje v pamäti pre daný pro- ces poˇcascelej doby behu serverovej aplikácie a vd’aka tomu môžeme ku kolekcii klientov pristupovat’ zo všetkých d’alších metód objektu. Dalšouˇ pret’aženou metódou je appCon- nect, kde sa inicializuje nové spojenie s klientom (pri volaní netConnection.connect zo strany klienta). Server priradí ID, ktoré pošle klientovi spätným volaním (server-klient)
2. v stabilnej verzii 3.6.0.3 3. System.Collection.Generic.Dictionary
29 6.2. SERVEROVÁ CASˇ Tˇ metódy SetClientIdHandler na strane klienta (vlastnost’ netConnection.client). Metó- da appDisconnect oboznámi v prípade prerušenia spojenia, resp. odpojenia, všetkých ostat- ných klientov o tejto skutoˇcnostiaktualizáciou zoznamu aktívnych používatel’ov volaním klientských metód LeftRoomHandler a RoomClientsHandler. Volanie metódy EnterRoom oboznámi všetkých ostatných klientov o vstupe nového používatel’a do miestnosti. V pret’ažených metódach je využita kolekcia serverom udržiavaných RTMP spojení, ktorú získame volaním scope.getConnections(). Kolekciu môžeme prechádzat’ a pre každé spojenie získat’ ID pripojeného klienta metódou connection.getClient().getId() a overit’ tak, ˇcichceme komunikovat’ práve s týmto spojením. Na rozoznanie klientov preto používam práve kolekciu typu Dictionary.
6.2.1 Nasadenie serverovej ˇcastiaplikácie
Postup inštalácie serverovej ˇcasti:
1. nainštalovat’ WebORB for .NET do IIS (napr. C:/inetpub/weborb30)
2. skopírovat’ app.config do weborb30/Applications/BPChatApp
3. skopírovat’ BPChatApp.dll do weborb30/bin
Pri inštalácii WebORB for .NET do IIS 7.5 je nutné nainštalovat’ aj .NET framework v2.0 programom aspnet_regiis. Aplikáciu WebORB potom zaradíme do Classic .NET AppPool (ApplicationPool v režime Classic).
Obrázok 6.2: app.config pre BPChatApp
Súbor app.config z obrázku 6.2 skopírujeme do weborb30/Applications. Adresár slúži pre aplikácie registrované do WebORB. Súbor app.config registruje aplikaˇcný handler, a to cestu k triede v knižnici BPChatApp.dll. Do tohto súboru sa môžu d’alej vkladat’ definí- cie ako napríklad handler pre spracovanie požiadaviek na video, SharedObject, kontrolu rýchlosti spojenia a iné. Knižnicu BPChatApp.dll, ktorá je výsledkom kompilácie projektu BPChat vo Visual Stu- dio, staˇcínakopírovat’ spolu s potrebnými referenciami do adresáru pre binárne súbory we- borb30/bin. Po reštartovaní IIS serveru je ešte nutné spustit’ RTMP handler. Spustenie je im- plementované v súbore Global.asax ASP.NET aplikácie WebORB po naˇcítaníprvej stránky.
30 6.2. SERVEROVÁ CASˇ Tˇ
Obrázok 6.3: Obrazovka klienta aplikácie BPChat
Staˇcíteda pristúpit’ napríklad na stránku weborb.aspx na adrese http://localhost/ weborb30/weborb.aspx. Klientskú aplikáciu nasadenú na IIS napríklad do adresáru weborb30/BPChat spustíme naˇcítanímadresy http://localhost/weborb30/BPChat/BPChat.html. Flash Player naˇcítaa zobrazí BPChat.swf, ˇcoje hlavný súbor aplikácie.
31 Kapitola 7 Záver
Ciel’om bakalárskej práce bolo previest’ ˇcitatel’a súhrnom možností komunikaˇcnýchpro- tokolov, zostavit’ meranie a implementovat’ ukážkovú aplikáciu. V práci som predstavil všetky možnosti komunikácie Flash s okolím pre model klient- server aj peer-to-peer. V rámci technických možností som nameral a vyhodnotil rýchlost’ vz- dialených volaní procedúr oboma protokolmi. V praktickej ˇcastisom implementoval ukážkovú aplikáciu BPChat, ktorá je funkˇcnýzáklad pre d’alšie rozšírenie. So svojou prácou som spokojný. Presvedˇcilsom sa o výkonnosti binárneho protokolu RTMP a jeho vhodnosti na implementáciu do pripravovanej online Flash hry pre vel’ké množstvo hráˇcov. Nadobudnuté vedomosti a skúsenosti využijem pri d’alšej práci na vývoji hry a vd’aka novému protokolu RTMFP podporujúceho peer-to-peer bude implementácia hry dvoch hráˇcovreálna aj s nárokmi na nízke náklady, rýchlost’ odozvy a prenesené dáta.
32 Literatúra
[1] Rosalind W. Picard. Adobe Flash CS4 Professional: oficiální výukový kurz. Computer Press, Brno, 2009.
[2] Andrew S. Tanenbaum. Computer networks. Prentice-Hall International, London, 1996.
[3] Flashrealtime.com, URL: http://www.flashrealtime.com/.
[4] Actionscript 3.0 Reference for the Adobe Flash Platform, URL: http://help.adobe. com/en_US/FlashPlatform/reference/actionscript/3/.
[5] swfobject documentation, URL: http://code.google.com/p/swfobject/.
[6] The original HTTP as defined in 1991, URL: http://www.w3.org/Protocols/ HTTP/AsImplemented.html.
[7] RFC 2616, URL: http://www.rfc-editor.org/rfc/rfc2616.txt.
[8] Adobe Systems Inc. Action Message Format – AMF 0. 2007. URL: http://opensource.adobe.com/wiki/download/attachments/1114283/ amf0_spec_121207.pdf
[9] Adobe Systems Inc. Action Message Format – AMF 3. 2008. URL: http://opensource.adobe.com/wiki/download/attachments/1114283/ amf3_spec_05_05_08.pdf.
[10] Adobe Labs – Stratus, URL: http://labs.adobe.com/technologies/ stratus/.
[11] RFC 768 (rfc768), URL: http://www.faqs.org/rfcs/rfc768.html.
[12] Wikipedia the Free Encyclopedia, URL: http://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol, URL: http://en.wikipedia.org/wiki/Real_Time_Media_Flow_Protocol.
[13] Cross-domain policy file specification, URL: http://www.adobe.com/devnet/ articles/crossdomain_policy_file_spec.html.
33 7. ZÁVER
[14] Real-time Messaging Protocol (RTMP) Specification, URL: http://www.adobe.com/ devnet/rtmp/.
[15] Rich Internet Application Market Share, URL: http://www.statowl.com/custom_ ria_market_penetration.php.
34 Obsah priloženého CD
/Benchmark/ zdrojové súbory k nástroju Benchmark
/BPChat/ zdrojové súbory k programu BPChat
/install/ inštalácia k programu WebORB for .NET 3.6.0.3 pre IIS 7.5, inštalácia Flash Player 10 vo verzii plugin a ActiveX
/obrazky/ obrázky k bakalárskej práci
/HTTPvsRTMP.xls Excel dokument s výsledkami merania
/praca.tex zdrojový dokument vo formáte LATEX /praca.pdf dokument vo formáte PDF
35