Podpora automatizovaného multiplatformního sdílení a synchronizace souborů

Mendelova univerzita v Brně Provozně ekonomická fakulta

Podpora automatizovaného multiplatformního sdílení a synchronizace souborů Diplomová práce

Vedoucí práce: Ing. Oldřich Trenz, Ph.D.

Bc. Michal Košíček

Brno 2013

Rád bych poděkoval panu Ing. Oldřichu Trenzovi, Ph.D. za jeho vedení, ochotu a trpělivost. Dále musím poděkovat panu Ing. Janu Kolomazníkovi za konzultace a odporné rady. V neposlední řadě patří poděkování mojí přítelkyni a rodině za jejich pomoc, podporu a trpělivost.

Prohlašuji, že jsem práci „Podpora automatizovaného multiplatformního sdílení a synchronizace souborů“ vypracoval samostatně a veškeré použité prameny a informace uvádím v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s § 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle § 60 odst. 1 autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše. V Brně dne 24. listopadu 2013

__________________

Abstract KOŠÍČEK, M. Support for automated cross-platform sharing and files synchronization. Brno, 2013. This thesis examines the issue of sharing and synchronizing files between different types of devices. It deals with the possible tools and technologies for the realization of automated sharing. It performs analysis of applications to share data and on the basis of this knowledge determines the appropriate procedures and techniques for the implementation application for data sharing. Keywords Sharing, synchronization, peer-to-peer, bitTorrent, decentralization.

Abstrakt KOŠÍČEK, M. Podpora automatizovaného multiplatformního sdílení a synchronizace souborů. Diplomová práce. Brno, 2013. Diplomová práce zkoumá problematiku sdílení a synchronizace souborů mezi různými typy zařízení. Zabývá se možnými nástroji a technologiemi pro realizaci automatizovaného sdílení. Provádí analýzu trhu s aplikacemi pro sdílení dat a na základě těchto poznatků stanovuje vhodné postupy a techniky pro realizaci systému sdílení dat. Klíčová slova Sdílení, synchronizace, peer-to-peer, bitTorrent, decentralizace.

Obsah

5

Obsah 1

2

3

4

5

6

Úvod a cíl práce

8

1.1

Úvod .......................................................................................................... 8

1.2

Cíl práce ...................................................................................................10

Průzkum trhu

11

2.1

Dropbox ................................................................................................... 11

2.2

Google Drive ............................................................................................ 12

2.3

SkyDrive ................................................................................................... 12

2.4

Cubby ....................................................................................................... 13

2.5

Syncplicity ................................................................................................ 13

2.6

SpiderOak ................................................................................................ 13

2.7

GoodSync ................................................................................................. 14

Sdílení a synchronizace dat

15

3.1

Definice základních pojmů ...................................................................... 15

3.2

Sdílení ...................................................................................................... 15

3.3

Synchronizace .......................................................................................... 17

3.4

Synchronizační postupy ...........................................................................18

Cloud Computing

23

4.1

Výhody Cloud Computingu .................................................................... 25

4.2

Nevýhody Cloud Computingu ................................................................ 26

Modely Cloud Computingu

27

5.1

Model NIST ............................................................................................. 27

5.2

Cloud Cube Model .................................................................................. 28

5.3

Modely nasazení ..................................................................................... 28

5.4

Servisní modely ....................................................................................... 30

Peer-to-peer model 6.1

36

Výhody a nevýhody peer to peer sítí ........................................................37

Obsah

6

6.2

Decentralizace ......................................................................................... 38

7

8

9

Typy Peer-to-peer sítí

39

7.1

Čisté P2P sítě .......................................................................................... 39

7.2

Hybridní P2P sítě .................................................................................... 40

BitTorrent

41

8.1

Součásti sítě BitTorrent ........................................................................... 41

8.2

Typy uživatelů sítě BitTorrent ................................................................ 43

8.3

Princip činnosti sítě bitTorrent .............................................................. 44

Vývoj systému sdílení souborů

46

9.1

Specifikace aplikace ................................................................................ 46

9.2

Funkční požadavky ................................................................................. 46

9.3

Nefunkční požadavky ............................................................................. 47

9.4

Metodika řešení ...................................................................................... 48

10 Návrh a architektura

49

10.1 Metody fungování ................................................................................... 50 10.2 Součásti systému ...................................................................................... 51 10.3 Struktura databáze.................................................................................. 54 10.4 Použité technologie ................................................................................. 55 11

Implementace 11.1

57

Serverová aplikace ...................................................................................57

11.2 Uživatelská aplikace ................................................................................. 61 12 Závěr

65

13 Literatura

67

A

71

Vzhled aplikace

Seznam zkratek

Seznam zkratek  API – Application Programming Interface  CaaS - Communication as a Service                       

ERD – entity–relationship diagram ERP – Enterprise Resource Planning FTP – File Transfer Protocol GSTP – Good Secure Transfer Protocol HTML – HyperText Markup Language HTTP – Hypertext Transfer Protocol HTTPS – Hypertext Transfer Protocol Secure IaaS - Infrastrucutre as a Service JSON – JavaScript Object Notation MaaS - Monitoring as a Service MVC – Model-View-Control Model NIST – National Institute of Standards and Technology PaaS - Platform as a Service P2P – peer-to-peer SaaS – Software as a Service SQL - Structured Query Language SSH - Secure Shell SSL - Secure Sockets Layer TCP - Transmission Control Protocol UI – User Interface URL - Uniform Resource Locator VPN - virtual private network XaaS - Everything as a Software

7

Úvod a cíl práce

8

1 Úvod a cíl práce 1.1

Úvod

Potřeba sdílet informace je jednou ze základních potřeb lidstva již od nepaměti. Nejdříve se informace předávaly ústně, pak přišla doba papíru. Za dobu existence lidstva vznikaly nové a nové způsoby, jak informace předávat. Revoluce v komunikaci nastala s příchodem Internetu. Začaly se vyskytovat nejrůznější webové aplikace, které uživatelům umožnily vyměňovat si informace rozličnými způsoby. Se zvětšujícím se počtem dat a informací se ale objevila i celá řada problémů k řešení. V dnešní době má velké množství uživatelů celou řadu různých zařízení. Je naprosto běžné, že uživatel nemá pouze jeden počítač nebo notebook, ale vlastní stolní počítač, notebook, mobilní telefon, tablet atd. S tím jak se objevila celá škála zařízení, objevil se další problém dnešní doby. Tím je vzájemná synchronizace těchto zařízení. Většina uživatelů ráda využívá k různým akcím různé typy zařízení. Typické je, když uživatel k práci používá notebook, k prohlížení internetu tablet a pro komunikaci mobilní telefon. Proto by bylo vhodné, kdyby i přesto, že se jedná o různé nástroje, bylo možné synchronizovat tyto zařízení mezi sebou. Přitom synchronizaci je možné chápat nejrůznějšími způsoby. Je možné synchronizovat nastavení zařízení, provozní informace, data atd. Tato problematika je velice rozsáhlá a věnovat se jí komplexně by bylo nad možnosti této práce. Tato práce se věnuje zejména možnosti synchronizace dat mezi zařízeními. Většina dnešních nástrojů, které se synchronizaci dat věnují, pracuje na bázi klient-server. Klientská část systému, kterou tvoří aplikace nainstalovaná ve všech navzájem se synchronizujících zařízeních, odesílá synchronizovaná data prostřednictvím sítě Internet na server, kde jsou tyto data uložena a předána do dalších připojených zařízení. Výhodou tohoto řešení je, že data mohou být nejen synchronizována, ale zároveň i uchována na serveru. Tento fakt znamená, že je k datům následně možné přistupovat i pomocí jiných zařízení například prostřednictvím webového rozhraní. Zmiňované řešení má značné množství výhod, ale ne vždy je vhodné jej použít. Existuje totiž celá řada dat, která je sice vhodné synchronizovat, avšak jejich uchovávání na serveru není žádoucí. Může se jednat o citlivé údaje, jako jsou výpisy z bankovních účtů, telefonní kontakty atd. Také u velkých souborů není toto řešení úplně ideální, ať už z důvodu, že zabírají velké množství úložného prostoru na straně serveru, tak také proto, že čas jejich přenosu je značný. Pro takové situace je třeba hledat jiné možnosti, jak přenášet data mezi klientskými zařízeními prostřednictvím Internetu. K uváděnému úče-

Úvod a cíl práce

9

lu se nabízí tzv. peer-to-peer komunikace, která staví všechny komunikující zařízení na stejnou úroveň. V takovém případě se data dostanou jen k těm subjektům, ke kterým je to nezbytné. Přenosová rychlost je zde limitována pouze rychlostí připojení jednotlivých zařízení. Bohužel toto řešení vyžaduje složitější vnitřní logiku, a proto dnes není natolik používáno. Dalším nezbytným požadavkem na úspěšný synchronizační nástroj je jeho podpora napříč platformami. Zařízení uživatele dnes nepoužívají jeden operační systém, ale ve většině případů jsou řízeny celou řadou systémů od nejrůznějších výrobců. Mezi nejznámější patří Microsoft Windows, Mac OS X a Linux v nejrůznějších distribucích. Pro mobilní platformy jsou to pak zejména OS Android, Windows Phone atd. V zásadě existují dva způsoby, jak zajistit chod aplikace na různých systémech. První možností je realizovat pro každý systém vlastní aplikaci. Takové řešení ovšem přináší velké množství práce nejen při realizaci, ale zejména při údržbě a změnách systému. Další možností je použití programovacích jazyků nebo frameworků, které je možné provozovat na různých systémech. Mezi ně můžeme jmenovat např. programovací jazyk Java. Z mobilních frameworků např. Phonegap. Samozřejmě i tyto nástroje mají určité nevýhody. Jmenovat můžeme například pomalejší běh, nebo absence některých nástrojů.

Úvod a cíl práce

10

1.2 Cíl práce Cílem této práce je provést analýzu současné nabídky synchronizačních nástrojů, vytvořit jejich přehled, zhodnotit jejich možnosti a nedostatky a na základě této analýzy následně navrhnout vlastní systém pro sdílení dat prostřednictvím sítě Internet. Aplikace by měla uživatelům nabídnout bezpečnou možnost sdílení jejich soukromých údajů a dat, která nechtějí zveřejňovat, nebo uchovávat na straně serveru. Dále by měla uživatelům poskytnout možnost synchronizace jakéhokoliv adresáře bez ohledu na jeho umístění v systému souborů. Dílčím cílem je takový systém implementovat s využitím multiplatformních vývojových nástrojů a provést test funkčnosti této aplikace.

Průzkum trhu

11

2 Průzkum trhu Před samotným zahájením vývoje jakéhokoliv systému je zapotřebí zaměřit se na průzkum ostatních nástrojů a možností, které jsou již na trhu k dispozici. Jinak tomu není ani v případě této práce. Tato kapitola vytváří ucelený přehled nejvíce používaných řešení pro sdílení a synchronizaci dat prostřednictvím Internetu. Snahou bylo zahrnout všechny běžně používané aplikace, které jsou dnes dostupné. Tyto aplikace zmapovat a u kterých je to možné, provést jejich otestování a ověření principů činnosti. Z průzkumu vyplynulo několik zajímavých zjištění. Tím hlavním je, že většina dnes existujících řešení používá komunikační model klient-server-klient. To znamená, že data jsou po změně přesunuta nejdříve na server a odtud jsou dále distribuována na další zařízení. Hlavní vlastností tohoto řešení je, že přenášená data zůstávají k dispozici na serveru, který je využit i k samotnému přenosu. To uživateli přináší výhodu, protože k datům může přistoupit, kdekoliv je připojen k Internetu. To i ze zařízení, které se neúčastní synchronizace. Většinou se tak děje prostřednictvím webového rozhraní, ale je samozřejmě možné použít i jiné nástroje a protokoly jako například FTP, SSH atp. Existuje ovšem skupina dat, které uživatel může chtít synchronizovat prostřednictvím sítě Internet, ale není žádoucí, aby tyto informace procházely nebo byly ukládány na serveru. U těchto dat je zapotřebí využít aparátu, který umožní uživateli posílat data přímo mezi zařízeními bez použití prostředníka. To znamená, že využívají komunikace typu peer-to-peer. Takových aplikací je na trhu podstatně méně.

2.1 Dropbox „Dropbox je primárně určen k synchronizaci dat mezi více zařízeními, kterými nemusí být jen počítače. Klientská aplikace pro Dropbox je totiž dostupná také pro mobilní telefony s operačním systémem Android a rovněž i pro iPhone, iPad a telefony BlackBerry. Podporovány jsou i různé operační systémy (nejen Windows, ale rovněž i Linux a Mac OS X).“ (Moravec J., 2011) Jedná se o velice rozšířenou aplikaci mezi uživateli. Je to typický zástupce klient–server–klient systému. Princip této aplikace spočívá ve vytvoření jedné složky v rámci souborového systému každého zařízení, které se podílí na synchronizaci. Toto řešení má výhodu ve své jednoduchosti pro uživatele. Orientace v užívání není nikterak složitá. Bohužel tento systém neumožňuje zachovat přirozenou strukturu dat v souborovém systému. To znamená, že pokud chce uži-

Průzkum trhu

12

vatel zachovat adresářovou strukturu, kterou užívá na svém zařízení, je nucen data duplikovat do pracovního adresáře.

Obr. 1

Domovská stránka služby dropbox1.

2.2 Google Drive Po technické stránce velice podobné řešení jako konkurenční aplikace Dropbox. K dispozici je opět jedna složka v rámci souborového systému, která se automaticky synchronizuje s webovým úložištěm. Velkou výhodou tohoto řešení je propracovaná webová aplikace nazvaná stejně jako klient tj. „Google Drive“. Prostřednictvím této aplikace může uživatel nejen procházet obsahem jednotlivých souborů, ale má k dispozici i aplikace pro jejich editování, správu, sdílení atd.

2.3 SkyDrive Naprosto obdobný způsob použití nabízí i služba SkyDrive od společnosti Microsoft. Jedinou změnou oproti dříve zmíněným konkurenčním produktům je možnost povolit aplikaci přístup k celému souborovému systému v počítači, díky

1

https://www.dropbox.com/

Průzkum trhu

13

kterému je možné do složky SkyDrive vkládat soubory a složky i prostřednictvím jiných zařízení. Služba SkyDrive podporuje také různé souborové formáty. Podpora Microsoft Office je samozřejmá a schopností editovat jednotlivé soubory přímo v prohlížeči se tato služba řadí po bok své konkurenci ve formě Google Docs. Zároveň je možné prohlížet soubory PDF a také fotografie ve formátech RAW. (Moravec J., 2011)

2.4 Cubby Cubby umožňuje synchronizovat soubory a složky, aby byly dostupné ve všech počítačích, nebo pomocí cloudu. (LogMeIn, 2013) Jedná se o velice zajímavé řešení pro sdílení dat mezi počítači. Na rozdíl od dříve zmiňovaných nabízí možnost synchronizovat libovolnou složku v rámci souborového systému a tuto následně přiřadit k jiné složce v dalších zařízeních. To umožňuje zachovat adresářovou strukturu v rámci synchronizace a zamezuje zbytečné redundanci dat uložených na disku zařízení. Mnohem zajímavější možností je ovšem služba pojmenovaná jako „Direct Sync“. Pomocí tohoto nastavení je možné pro jednotlivé složky určit, že pro jejich sdílení nebude použito vzdáleného uložiště, ale přenos bude probíhat přímo prostřednictvím peer-topeer komunikace. Nevýhodou je fakt, že tato služba je zpoplatněna a bez prémiového účtu není k dispozici.

2.5 Syncplicity Další zástupce cloudových uložišť je nástroj s názvem Syncplicity. Pro výběr synchronizovaných složek používá trochu odlišný přístup než ostatní zmiňované. Umožňuje vytvářet obraz souborového systému v rámci webového uložiště. Tento způsob je jednoduchý z uživatelského hlediska, ale bohužel neumožňuje variabilitu v rámci napojení sdílených složek pro více zařízení.

2.6 SpiderOak Jedná se o zajímavě pojatou aplikaci pro synchronizaci dat prostřednictvím vzdáleného serveru. Pomocí klientské aplikace si uživatel nejprve zvolí složky na disku, které chce zpřístupnit. Dále si vytvoří tzv. „sync“ což jsou záznamy o propojení jednotlivých složek. Do tohoto záznamu je možné přidat libovolné množství složek z libovolných zařízení uživatele. Takto nastavené složky si dále automaticky synchronizuje.

Průzkum trhu

14

2.7 GoodSync GoodSync synchronizuje a zálohuje soubory, jako jsou fotografie, finanční dokumenty, MP3, e-maily, atd. Synchronizace probíhá mezi stolními počítači, notebooky, servery atd. Používá inovativní synchronizační algoritmus, který nabízí skutečnou obousměrnou synchronizaci. (SiberSystems, 2013) Jedná se o aplikaci určenou k synchronizaci souborů, která pracuje čistě na principu peer-to-peer komunikace. To znamená, že k samotnému přenosu souborů nevyužívá prostředníka v podobě serveru, ale soubory přenáší přímo do jiných zařízení. Tento přenos je realizován pomocí protokolu GSTP (Good Secure Transfer Protocol). Jedná se o zabezpečený protokol pro přenos binárních souborů prostřednictvím TCP protokolu. Přenos dat je relativně rychlý a komunikace probíhá s malou latencí. Nevýhodou je, že přenos dat probíhá vždy pouze mezi dvěma klienty. Z toho vyplývá, že není možné dosáhnout vyšší rychlosti v případě, že požadovaný soubor je k dispozici na více jak jednom zařízení. Kromě synchronizace mezi klienty umožňuje tento nástroj synchronizovat složku s celou řadou dalších služeb a protokolů. Například Google Drive, FTP server, Amazon S3 atd.


15

3 Sdílení a synchronizace dat 3.1 Definice základních pojmů Ač byly některé pojmy vysvětleny již v předchozí kapitole, bude vhodné pro lepší orientaci v následujícím textu definovat přehled pojmů.  Data – pojem data bude v rámci této práce chápán jako celek reprezentovaný jedním nebo více soubory.  Sdílení dat – činnost, při které je pomocí hardwarových a softwarových prostředků zajištěno jejich kopírování nebo přesouvání do dalších zařízení.  Peer-to-peer – „jedná se o decentralizované systémy aplikací a přenosových prostředků využívané pro sdílení dat. V tomto modelu neexistuje centrální server, veškerá kapacita a přenosové prostředky jsou poskytovány jednotlivými členy (uživateli) P2P sítě. S rostoucím počtem uživatelů tak roste i kapacita celého systému.“ (Hřebabecký J., 2011) Základní princip tohoto modelu spočívá tedy v tom, že jednotlivé uzly jsou schopny komunikovat přímo mezi sebou a nepotřebují prostředníka v podobě serveru.  Klient-server – systém, ve kterém probíhá komunikace pomocí prostředníka v podobě serveru. Tento systém bývá využíván například u webových aplikací s komunikací prostřednictvím HTTP protokolu.  Webové uložiště – datové uložiště realizované prostřednictvím webového serveru. Ve většině případů má uživatel k dispozici určité množství úložného prostoru, které může využívat. Někdy jsou k takovému uložišti k dispozici i klientské aplikace, které umožňují komfortnější práci s uložištěm. „Pokud však nemáte přístup internetu, nedostanete se k datům.“ (Kubeš R., 2011)  Cloud Computing (Cloudová služba) – „jedná se o způsob poskytování určité služby v prostředí internetu, kdy uživatel této služby pouze tuto službu využívá a to odkudkoli bez ohledu na to, aby musel řešit hardwarovou či softwarovou stránku.“(Hřebabecký J., 2011)

3.2 Sdílení Samotný pojem sdílení dat je sám o sobě velice obecný a obsáhlý. Může se jednat o sdílení jakýchkoliv binárních dat v podobě jedniček a nul, přes data reprezentovaná malými zprávami zasílanými mezi komunikujícími klienty (ICQ, Jabber, Skype, atd.) až po gigabajtové multimediální soubory. Jako sdílení dat je


16

možné chápat i předávání informací v podobě webových aplikací, kde tvůrce takové aplikace je chápán jako producent a uživatel jako konzument. V moderním pojetí webových aplikací je producentem dat také uživatel. Tvůrce webové aplikace poskytuje pouze prostředí umožňující data tvořit i konzumovat. Zabývat se proto sdílením všech typů dat by překročilo možnosti této práce. V rámci práce budeme chápat data jako celek reprezentovaný jedním, nebo více soubory. Může se jednat o multimediální soubory v podobě obrázků, videí, hudby, atd. Ovšem sdílet můžeme jakékoliv jiné soubory, jako jsou textové dokumenty, binární soubory, atd. Pro potřebu této práce nebude vůbec podstatné, kde a za jakým účelem data vznikla, ani kdo je jejich autorem. Práce se zabývá problematikou, jak zajistit, aby se tato existující data úspěšně distribuovala dalším uživatelům, tj. sdílela. Pojem sdílení dat je v tomto případě chápán jako činnost, při které je pomocí hardwarových a softwarových prostředků zajištěno jejich kopírování nebo přesouvání do dalších zařízení. Tato akce vychází z faktu, že data, jako každá jiná komodita, uspokojující některou z potřeb lidských jedinců, jsou subjektem lidského zájmu. Tento lidský zájem a potřeba se projevuje snahou člověka tuto komoditu shromažďovat. (Hřebabecký J., 2011) Sdílení dat je nástrojem pro uspokojování těchto potřeb. „Posledním prvkem je médium, schopné zprostředkovat směnu, šíření dat a interakci uživatelů a to jak komunikační tak peněžní.“ (Hřebabecký J., 2011) V našem případě je tímto médiem počítačová síť respektive prostředí Internetu. 3.2.1

Faktory sdílení dat

Sdílení je asi nejdůležitějším nástrojem v prostředí sítě Internet. Především v posledních letech zaznamenává využívání internetu raketový nárůst a služby pro sdílení informací se mění do podoby velkých a komplikovaných aplikací. K tomuto rozvoji by nemohlo dojít bez zlepšení a nárůstu klíčových faktorů ovlivňujících samotnou komunikaci. Těmito faktory jsou především:  Technologie a nástroje – technologie udávají rámec, jakým je možné na internetu přistupovat k požadovaným datům, ale také to, jak je možné s těmito daty zacházet. Typickým příkladem rozvoje technologií jsou webové aplikace. Zatímco před několika lety jsme mluvili o internetových stránkách, nebo internetových prezentacích, které byly ve většině případů jen statické kusy textů zabalených do značkovacího jazyka, tak dnes je situace naprosto odlišná. Z termínu webová prezentace se postupně stal pojem


17

webová aplikace. Tento přechod nebyl pouze slovní hříčkou, ale byl založen na zcela logickém podkladu. Internetové služby totiž začaly poskytovat uživatelům podobné možnosti jako klasické desktopové aplikace. Tento rozvoj by ovšem nebyl možný bez podpory a rozvoje technologií, které se využívají k tvorbě webu. Například díky rozvoji webových prohlížečů, které začaly implementovat nové technologie, jako je například HTML5, lepší podpora JavaScriptu atd. Je možné dnes tvořit aplikace, které využívají souborové API, lokalizaci pozice, pokročilé uživatelské funkce jako je například Drag and Drop a to vše přímo v okně prohlížeče. Situace dokonce došla tak daleko, že vznikají řešení, která se přímo v prohlížeči pokoušejí implementovat webové operační systémy.  Rychlost připojení – rozvoj technologií je jen jeden z aspektů rozvoje sdílení dat. S nárůstem aplikačních možností vzrůstají také požadavky na rychlejší přenos dat. K čemu by byly internetové aplikace umožňující provádět složité operace nad zadanými daty, kdyby rychlost přenosu těchto dat byla tak nízká, že než by se do aplikace dostaly, trvala by tato operace např. několik dní. „Prakticky nemožné, velmi časově i finančně nákladné, by bylo sdílení dat na internetu pro uživatele s pomalým připojením k internetu. Kolem roku 2000 ještě bylo například naprosto běžné připojení přes 56 kb modem, s jehož využitím by nebylo vůbec myslitelné kvalitní multimediální obsahy stahovat. Například za rok 2009 byl v České republice zaznamenán největší nárůst rychlosti připojení. Následně pak rychlost připojení a rozvoj sdílení dat na internetu představují vzájemně se propojující jevy. Čím vyšší je rychlost připojení uživatelů internetu, tím větší je uživatelská základna serverů pro sdílení dat na internetu, tím větší je jejich popularita a opět tím větší je poptávka po vyšší rychlosti internetového připojení.“ (Hřebabecký J., 2011)

3.3 Synchronizace Obdobně jako sdílení dat je i synchronizace značně obecný pojem, pod kterým je možné chápat celou množinu procesů, nástrojů a metodik. V nejobecnější rovině je možné popsat synchronizaci, jako proces ztotožnění. Může se jednat o synchronizaci myšlenek dvou nebo více komunikujících jedinců, synchronizaci biorytmů, pracovních postupů napříč odděleními nebo firmami atd. V rozsahu této práce je synchronizace chápána jako proces ztotožnění části souborového systému dvou nebo více komunikujících zařízení. Hansmann definuje synchronizaci jako proces, který zajistí, že dvě sady dat budou vypadat


18

identicky. K dosažení tohoto cíle musí docházet ke změně dat na jedné straně na základě změny dat na straně druhé. (Hansmann, 2002) Stejně jako sdílení tak i synchronizace může probíhat na celé řadě přenosových médií a kanálů. Můžeme udržovat soubory v rámci jednoho počítače, počítače a přenosného hardwarového uložiště, počítače a webového úložiště, dvěma webovými úložišti atd. V kontextu této práce se pod pojmem synchronizace rozumí udržení stejného obsahu dat mezi dvěma a více zařízeními, jako jsou počítače, mobilní telefony, tablety atd. Obdobně jako má proces sdílení možnost používat nejrůznější komunikační rozhraní, používá různá rozhraní i proces synchronizace. Můžeme používat nejrůznější flash disky pro dočasný přenos souborů, bezdrátové technologie bluetooth, wifi atd. V tomto kontextu budeme chápat synchronizaci jako udržování obsahu mezi zařízeními prostřednictvím počítačové sítě. Dalším způsobem a do jisté míry opačnou filozofií pro zajištění konzistentních dat je tzv. „Cloud Computing“. „Tento směr zažívá v posledních letech silný rozvoj. To je vidět třeba na srovnání výrazů Cloud Computing a synchronization v Google Trends, který porovnává četnost jejich hledání a další statistiky.“ (Homolka V., 2010) Podle Homolky (Homolka V., 2010) mezi hlavní důvody, proč se nevydat cestou Cloud Computingu, patří tyto:      

nemožnost být pořád připojený k síti, pomalé připojení nebo připojení s výpadky, cesty do zahraničí, neochota spoléhat se na neustálé připojení, nativní aplikace mobilního zařízení rychlejší než webové aplikace, lokální aplikace se synchronizovanými daty mohou byt efektivnější na práci než síťové.

3.4 Synchronizační postupy Nástrojů pro synchronizaci uživatelských souborů existuje celá řada. Dnes velice moderním pojetím je provádět synchronizaci prostřednictvím prostředníka v podobě webového nebo jiného datového uložiště. I přesto, že tento přístup je dnes hodně rozšířen, není to jediné možné řešení. Další možností je využití protokolů pro peer-to-peer přenos souborů a synchronizovat soubory přímo mezi připojenými klienty. Nevýhodou přímého sdílení je značně komplikovaná logika pro vyhodnocování změn a porovnávání mezi dalšími soubory.


19

Pro odstranění nevýhod těchto řešení je možné použít kombinaci obou. Kombinování umožňuje uchovávat informace o jednotlivých souborech určených k synchronizaci na webovém serveru a samotný přenos provádět pomocí peer-to-peer protokolů. Přitom na webovém serveru mohou být uloženy všechny informace potřebné k synchronizaci, jako je název souboru, datum změny, hash a spousta dalších. Samotný soubor ovšem stále zůstává na klientském zařízení. Toto řešení disponuje celou řadou výhod. Díky sdíleným informacím je možné jednodušším způsobem provádět srovnávání souborů. Není zapotřebí velké kapacity na samotném serveru, protože se uchovávají pouze metainformace, takže velikost samotného souboru nehraje žádnou, nebo minimální roli v množství uchovávaných informací na straně serveru. Dále je možné na server přenést i část logiky pro vyhodnocení souborů k synchronizaci. Logikou je v tomto případě myšlen postup, za pomoci kterého systém určuje, které soubory byly změněny nebo přidány, a je tedy nutné zajistit jejich přenos. Jak již bylo zmíněno, tyto operace mohou být prováděny přímo na serveru nebo v klientských aplikacích za pomoci dat na serveru uložených. I v tomto případě je samozřejmě možné přístupy kombinovat. 3.4.1

Klient-server-klient synchronizace

Jak již bylo zmíněno v předchozí kapitole, jedná se v dnešní době o velice oblíbený způsob synchronizačního řešení, který využívá naprostá většina dnes rozšířených nástrojů, jež jsou uživatelům k dispozici. Jak název napovídá, celý proces je založen na klient-server architektuře. „Klient-server popisuje vztah mezi dvěma počítačovými programy, v nichž první program, klient, žádá o služby jiný program zvaný server. Na tomto modelu je založen například přístup na E-mail, Web, přístup k databázi, atd. Například Webový prohlížeč, to je klientský program na uživatelském počítači, který může přistupovat k informacím na libovolném webovém serveru na světě. Chcete-li například ze svého počítače zkontrolovat zůstatek na Vašem bankovním účtu, Váš webový prohlížeč předá tento dotaz webovému serveru banky, tento server předá dotaz databázovému programu, který pošle dotaz databázovému serveru. Odtud je zůstatek vrácen zpět do banky databázovému programu, ten ji zase pošle zpět do Vašeho webového prohlížeče a ten výsledný zůstatek zobrazí.“ (Vlastnisystem.cz, 2013) Z přechozí definice vyplývá, že použití tohoto typu synchronizace vlastně znamená, že namísto toho, aby celý proces probíhal mezi klienty, kteří potřebují udržovat stejný obsah, je realizován mezi klientem a serverem. Poslední část


20

spojení klient-server-klient značí, že data obsažená na serveru jsou na žádost jiného klienta (klientů) dále přeposílána. Takové řešení samozřejmě disponuje celou řadou výhod jak pro uživatele, tak pro poskytovatele služby. Zde je seznam těch základních:    

relativně jednoduchá implementace, přístup vždy k aktuálním datům, možnost procházení dat i bez použití klientské aplikace, možnost sdílení dat jiným uživatelům.

Ovšem existuje také celá řada problémů s tímto systémem spjatých:    

závislost na poskytovateli služby, závislost na dostupnosti serveru, existence uživatelských dat i mimo jeho zařízení, nadměrná míra komunikace (data jsou vždy přesouvány minimálně dvakrát).

Obr. 2

Klient-Server model (Sanati J.,2011)


3.4.2

21

Peer-to-peer synchronizace

„Peer-to-peer (P2P) se říká sítím, které jsou založené na vzájemné komunikaci jednotlivých uživatelů (neboli klientů). Takže zatímco se běžně na internetu uživatelé většinou připojují k nějakému serveru (na kterém jsou uložené třeba obrázky nebo celé webové stránky), u P2P si jednotliví uživatelé vyměňují všechny informace přímo mezi sebou.“ (Národní centrum bezpečnějšího internetu, 2013)

Obr. 3

peer-to-peer model (Sanati J., 2011)

Peer-to-peer synchronizace vychází z peer-to-peer modelu komunikace. Základním principem je, že všichni klienti podílející se na komunikaci jsou si rovni. V případě peer-to-peer synchronizace to znamená, že všechny zařízení, které se mají synchronizovat, jsou si rovny. Sami si řídí proces synchronizace a komunikují přímo mezi sebou. Toto řešení je decentralizované a nepotřebuje ke své činnosti žádný řídící server. Obdobně jako klient-server-klient synchronizace má i toto řešení své klíčové výhody a nevýhody. Mezi výhody patří:  nezávislost na centrálním serveru,  výpadek jednoho zařízení nezpůsobí nefunkčnost celého systému,  menší množství nadbytečných přenosů dat,  v některých případech rychlejší přenos,


22

 data nejsou uložena na cizím stroji. Obdobně ovšem můžeme jmenovat seznam nevýhod:  velice složitá realizace logiky aplikace,  nutnost připojení vlastníka souboru pro synchronizaci,  nemožnost přistupovat k souborům online. Především z důvodu zajištění logiky aplikace je čistě peer-to-peer řešení velice komplikované na realizaci. Vzniká totiž celá řada problémů týkajících se vyhodnocení změn v souborech v případě odpojení některých klientů a jejich připojení až po další změně souboru atd.

Cloud Computing

23

4 Cloud Computing „První vědecké použití slovního spojení Cloud Computing je z roku 1997, kdy ho ve své přednášce použil profesor Ramnath Chellappa, který vyučuje Informační systémy na Goizueta Business School, Emory University.“ (Karpeta J., 2011) Ten Cloud Computing definoval jako počítačové paradigma, ve kterém jsou hranice výpočetní techniky stanoveny ekonomickou rozvahou místo technologickými limity. (Chellappa R., 2011) Dá se říci, že Cloud Computing představuje aplikace a služby běžící na distribuované síti a používající virtualizované zdroje, které jsou přístupné pomocí sdílených internetových protokolů a síťových standardů. (Sosinsky B., 2011) Cloud Computing vytváří služby a aplikace podobné těm na internetu a převádí je do samoobslužné podoby. Při tom vychází ze dvou základních konceptů, kterými jsou: (Sosinsky B., 2011)  Abstrakce – Cloud Computing abstrahuje podrobnosti o implementaci systému od uživatelů a vývojářů. Aplikace běží na fyzickém systému, který není specifikován, data jsou uložena na místech, která nejsou známá, a správa systému je dodávána z jiných zdrojů. Přístup uživatelů je všudypřítomný.  Virtualizace – Cloud Computing virtualizuje systémy pomocí sdružování a sdílení zdrojů. Systémy a uložiště mohou být placeny dle potřeby z centrální infrastruktury. Obecně lze říci, že tento pojem nemá ustálenou definici. To je způsobeno tím, že spadá do obrovské škály oborů a zájmů, a proto si jeho definici upravuje každý do trochu jiné podoby. „Na Internetu je velké množství odborných portálů, které se věnují aktuálním trendům v informačních technologiích a většina z nich uvádí vlastní definici Cloud Computingu. Protože se jedná o oblast, která protíná velkou část informačních technologií, jsou definice rozdílné a oborově zaměřené. V tomto kontextu jsou většinou definice subjektivní, a snaží se jednoduše a výstižně odpovědět na složité otázky. Neustálý vývoj spojený s aktuálností tématu přináší stále nové a výstižnější definice a charakteristiky.“ (Němec P., 2012) Například definice podle Melvina Greera popisuje Cloud Computing jako „druh nasazení počítačů, kde masivně škálovatelné IT kapacity jsou dodávány ‚jako služba‘ koncovým uživatelům pomocí internetových technologií.“ (Greer M., 2009)

Cloud Computing

24

Právě z toho důvodu, že existuje celá řada definic a ve výsledku je velice obtížné popsat Cloud Computing, navrhla firma Gartner pět klíčových vlastností, které jej vymezují. (Gartner, 2009)  Založený na službách – uživatel je zcela odstíněn od konkrétní implementace. Pouze využívá dostupné funkce jako jednotlivé služby. „Zákazník odebírá službu bez toho, aniž by se jakkoli zajímal o využívaný software a hardware. Zákazník přistupuje ke službě přes rozhraní a to pro něj zajišťuje veškerou funkcionalitu. Pro službu je důležitější její funkcionalita (funkce, dostupnost, odezva, cena atd.) než technologie, pomocí kterých je funkcionality dosaženo.“ (Klimt R., 2012)  Škálovatelnost a elasticita – službu je možné škálovat dle potřeby nahoru a dolů. To znamená, že uživateli jsou přiřazovány zdroje (výkon a kapacita) právě podle jeho potřeb. Tato přizpůsobitelnost se může projevovat v řádech vteřin až hodin v závislosti na typu služby. Elasticita znamená, že stejně jako zdroje, je možné uživateli přidávat a odebírat poskytované služby podle jeho potřeb.  Sdílení – „Hlavní rozdíl cloudových služeb a stejně tak i SaaS ve vztahu k ASP spočívá ve sdílené formě poskytování. Cloud služby společně sdílejí hardware, výpočetní výkon, infrastrukturu, případně podpůrný software, což umožňuje maximální efektivitu jejich využití. Díky již zmíněné elasticitě využívají sdílených prostředků všichni zákazníci dané služby. To umožňuje poskytovateli realizovat úspory z rozsahu. Oproti tomu ve standardních datových centrech platí, že jeden virtuální stroj je přiřazen právě jednomu zákazníkovi a je tedy potřeba rozšiřovat výpočetní výkon i v případě, že výkon serverů není ani zdaleka využit. Cloud architektura umožňuje sdílet nevyužité prostředky bez ohledu na jednotlivé virtuální stroje apod.“ (Klimt R., 2012)  Měřitelnost dle využití – pro poskytovatele služeb je velice důležité mít možnost sledovat využití výpočetních prostředků.  Využití internetových technologií – služba je realizována pomocí internetové komunikace a je založena na protokolech využívaných v rámci sítě Internet. Pro účely této práce můžeme Cloud Computing definovat jako způsob přístupu k aplikacím, datům, výpočetnímu výkonu a prostoru pro ukládání dat, které jsou k dispozici na sdílené geograficky neohraničené bázi výpočetních prostředků především prostřednictvím internetu. (Němec P., 2012) Přičemž v rámci sdílení a synchronizace dat je nejdůležitější část „prostor pro ukládání dat“.

Cloud Computing

25

Obecně lze tedy říci, že Cloud Computing je více než nový revoluční nástroj nebo služba spíše nový trend v přístupu a zpracování dat. Jinak řečeno se jedná o nový trend ve vztazích mezi zákazníky a poskytovateli služeb. Cloud Computing je možné rozdělit do několika skupin. Podle základních charakteristik (MELL a kol., 2011):     

samoobsluha podle volby, široký přístup k síti, sdílení zdrojů, pružnost, měřené služby.

Obr. 4

Model Cloud Computingu (Cloud Computing, 2012)

4.1 Výhody Cloud Computingu Hlavní efekt Cloud Computingu spočívá v tom, že uživatelské aplikace jsou hostovány jinou společností. Z toho faktu také vyplývají základní výhody tohoto řešení. Jiná firma než vaše nese náklady na servery, stará se o udržování aktuálnosti aplikace, nese náklady na pořizování a údržbu hardwaru atd. Z těchto faktů je zřejmé, že za určitých okolností může zákazník platit méně, než při použití klasických způsobů nasazení.

Cloud Computing

26

Je nutné brát v úvahu hardware, který nemusíme nakupovat. Díky tomu klesnou investiční náklady. Vzhledem k tomu, že aplikace hostuje někdo jiný, není nutné nakupovat servery, platit za napájení a chlazení atd. (Velte A., 2011) Koncepce Cloud Computingu může být také vhodná pro zaměstnance, kteří nemusí být vázáni na konkrétní pracovní prostory, ale můžou se kdekoliv přihlásit do své aplikace a provádět úkony spojené s jejich náplní práce.

4.2 Nevýhody Cloud Computingu Stejně jako jakékoliv jiné technologie má i Cloud Computing své výhody a nevýhody. Zde jsou ve stručnosti shrnuty potenciální možná slabá místa Cloud Computingu. Jedna z hlavních nevýhod spočívá v závislosti na poskytovateli připojení a obecně řečeno na konektivitě. Výpadky připojení se sice nevyskytují moc často, ale v případě, že se vyskytnou, mohou znemožnit přístup k aplikacím. To může mít za následek velké ztráty. Problémy mohou nastat nejen s poskytovatelem připojení. Výpadek může postihnout také servery, ke kterým se uživatel připojuje. Z toho plyne, že další velkou nevýhodou tohoto řešení je závislost na poskytovateli služeb. (Velte A., 2011) Dalším potencionálním problémem, který může nastat při používání Cloud Computingu, je problém s integrací aplikací. Například pokud je zapotřebí zajistit výměnu informací mezi aplikacemi, je mnohem snazší, když jsou obě umístěny na jednom místě. V případě, že je zapotřebí kontaktovat aplikaci v Cloudu, věci jsou komplikovanější a náchylnější k poruchám.


27

5 Modely Cloud Computingu Vzhledem k tomu, že se jedná o relativně volný pojem jak z hlediska definice, tak nasazení, existují různé modely, jak lze Cloud Computing chápat. V této kapitole zmíníme základní rozdělení z hlediska poskytovaných služeb, způsobu přístupu ke službám atd. Pro popis Cloud Computingu vznikla celá řada nejrůznějších modelů. Většinou se modely rozdělují do dvou oddělených skupin, kterými jsou: (Sosinsky B., 2011)  Modely nasazení – jedná se o nasazení a řízení „cloudové infrastruktury“  Servisní modely – skládá se z jednotlivých typů služeb, pomocí kterých je možné přistoupit k „cloudové platformě“.

5.1

Model NIST

Jedná se o množinu pracovních definic organizace „U.S. National Institute of Standards and Technology“, která rozděluje Cloud Computing mezi modely nasazení a servisní modely. Tyto modely a jejich vztah k základním charakteristikám Cloud Computingu jsou uvedena na obrázku 5.

Obr. 5

Rozdělení modelů Cloud Computingu podle NIST modelu. (Sosinsky B., 2011)

V původní verzi NIST model nevyžadoval nutně použití cloudu k virtualizaci sdílení zdrojů. Nebylo nezbytně nutné, aby jedna instance softwaru obsluhovala více klientských organizací. Poslední verze NIST definice striktně vyžadují


28

použití cloudových sítí, použití vizualizace a podporu sdílení zdrojů mezi dvěma nebo více organizacemi. (Sosinsky B., 2011)

5.2 Cloud Cube Model Organizace s názvem „Jericho Forum“, jejímž hlavním cílem je ochrana „cloudové sítě“ vytvořila zajímavý model, který se pokouší roztřídit „cloudovou síť“ na dimenze. Těmito dimenzemi jsou (Sosinsky B., 2011):  Fyzické umístění dat – Interní/externí, určuje hranice organizace.  Vlastnictví – Proprietární/otevřené, neurčuje pouze míru vlastnictví technologií, ale také spolupráci, jednoduchost přenosu dat a stupně prodejnosti aplikace.  Hranice zabezpečení - určuje, zda je prováděná operace v nebo mimo bezpečnostní hranici nebo síťový firewall.  Zdroje – Insourcované/outsourcované určuje, zda je služba poskytována zákazníkem nebo poskytovatelem služby.

Obr. 6

CUBE model Cloud Computingu (Sosinsky B., 2011)

5.3 Modely nasazení S postupným vývojem technologií a rostoucími kapacitami internetového připojení se Cloud Computing za posledních několik let velice rozšířil. S jeho rozšíře-


29

ním vznikly také mnohé postupy, jak jej realizovat. Modely nasazení určují účel a povahu Cloud Computingu a způsob jeho uložení. Zde si definujeme základní rozdělení tak, jak ho popisuje model NIST a i většina jiných dostupných publikací.

Obr. 7

Schéma modelů nasazení. (Němec P., 2012)

5.3.1

Veřejný cloud

Infrastruktura veřejného cloudu je k dispozici pro veřejné použití nebo pro velké průmyslové skupiny a je vlastněna organizací, která se zabývá prodejem cloudových služeb. (Sosinsky B., 2011) Takovéto cloudy jsou většinou vlastněny velkými organizacemi, které se starají o chod celého řešení, a zákazník pouze konzumuje poskytované služby. 5.3.2

Soukromý cloud

Privátní infrastruktura je provozována výhradně pro potřeby příslušné organizace. Cloud jako takový může být spravován buď přímo danou organizací, nebo třetí stranou. Samotná infrastruktura může ležet jak v organizaci, tak mimo ni. Takové řešení je vhodné zejména pro větší firmy. „Soukromý cloud tedy představuje virtualizované datové centrum chráněné firemním firewallem. Oproti veřejnému cloudu musí brát firma v úvahu jisté limity výkonu. Pokud není hardwarový výkon dostatečný, je nutné dokoupit další hardwarové zdroje.“ (Klimt R., 2012) 5.3.3

Hybridní cloud

Hybridní cloud je kombinací rozdílných typů cloudových řešení (soukromé, veřejné a komunitní). Jednotlivé cloudy si sice udržují svoje jedinečné vlastnosti,


30

ale pracují společně, jako jeden jediný celek. Hybridní cloudy mohou nabízet jak standardizované, tak proprietární přístupy k datům a aplikacím. Typickým využitím hybridního přístupu je situace, kdy jsou některé služby poskytovány v době zátěže z veřejného cloudu a v době útlumu z cloudu privátního. 5.3.4

Komunitní cloud

Komunitní cloud je takový, který je organizován za společným účelem a pro společné cíle. „Cloud infrastrukturu sdílí několik organizací, které mají společné zájmy, cíle a jsou schopny se dohodnout na požadavcích na bezpečnost a podmínkách provozu. Infrastrukturu mohou provozovat organizace vlastními silami nebo nakoupit jako službu u třetí strany.“ (Němec P., 2012)

Obr. 8

Ukázka využití různých typů Cloud Computingu pro organizace. (Sosinsky B., 2011)

5.4 Servisní modely Na rozdíl od modelů nasazení popisují servisní modely typy služeb, pomocí kterých je možné přistoupit ke cloudové platformě. Mezi takové modely patří: „Infrastrucutre as a Service (IaaS), Platform as a Service (PaaS), Software as a Ser-


31

vice (SaaS), Communication as a Service (CaaS), Monitoring as a Service (MaaS), Everything as a Software (XaaS) a další. Nejčastěji se však v praxi vyskytuje dělení podle prvních tří jmenovaných“ (Bohuslav M., 2012). Tyto modely ovšem nejsou nikterak striktně odděleny a je možné je různými způsoby kombinovat.

Obr. 9

Přehled servisních modelů. (Ektron, 2013)

5.4.1

Software as a Services (SaaS)

„SaaS je v současné době alternativa ke klasickému přístupu dodávky a implementace podnikových informačních systémů. Jedná se o software licencovaný třetí stranou, který je zákazníkovi dostupný v případě potřeby. Většinou jsou tyto služby poskytovány prostřednictvím internetu, neboť jsou snadno vzdáleně přístupné a konfigurovatelné. Mezi příklady takto poskytovaných služeb patří software pro zpracování textu, tabulkový editor, CRM32 a služby řízení webového obsahu. V současné době se již na trhu začínají objevovat i informační systémy ERP.“ (Klimt R., 2012) SaaS neboli software jako služba je jeden ze způsobů využití Cloud Computigu v praxi. Tento model spočívá v tom, že zákazníkům poskytuje hotová řešení v podobě aplikací, které mohou ihned začít využívat. Zákazník nemá možnost ovlivňovat infrastrukturu ani měnit nastavení operačního systému. „Aplikace


32

jsou přístupné přes různá klientská rozhraní, nejčastěji webový prohlížeč (tenký klient).“ (Němec P., 2012) SaaS je modelem, který aplikaci hostuje a nabízí jako službu pro zákazníky, kteří k ní přistupují pomocí internetového připojení. Výhoda hostování softwaru externě spočívá v tom, že zákazník nemusí řešit problémy se správou a podporou. Na druhou stranu nemůže zákazník žádným způsobem ovlivnit situace, kdy se poskytovatel rozhodne aplikaci změnit, nebo upravit. Hlavní myšlenka tohoto řešení vychází z toho, že celý systém je možné používat bez složité integrace s jinými systémy. O veškeré aktualizace, opravy a úpravy se stará sám poskytovatel služby. (Velte A., 2011) Výhoda SaaS spočívá především v jednoduchosti pro uživatele a v možnosti rychlého nasazení. „SaaS je vedle IaaS a PaaS jedním z nejdůležitějších modelů v dnes často skloňovaném přístupu k ICT službám, nazvaném Cloud Computing. Začíná se pomalu ale jistě prosazovat i do podnikové praxe.“ (Bohuslav M., 2012)

PC

Laptop

INTERNET SaaS řešení

Tablet

Smartphone

Obr. 10

Pobočka 1

Pobočka 2

Uspořádání informačního systému pomocí SaaS (Němec P., 2012)

Mez hlavní výhody SaaS modelu patří úspora nákladů oproti nákupu aplikace, přičemž poskytovatel často nabízí lepší a spolehlivější aplikace, než by dokázala zpřístupnit samotná organizace. Mezi další výhody je možné jmenovat: (Velte A., 2011)  Znalost webu – většina lidí a tím i pracovníků má znalost práce s webovým prostředím.


33

 Méně zaměstnanců – díky možnosti přistupovat dálkově k aplikacím není nutné zaměstnávat tolik IT pracovníků.  Přizpůsobení – SaaS aplikace se mnohem snáze přizpůsobují a aktualizují.  Lepší marketing – SaaS řešení umožňuje hledat potenciální zákazníky po celém světě.  Spolehlivost webu – i když je možné považovat web za potenciální místo selhání, obecně je možné konstatovat, že v praxi je web relativně spolehlivé médium.  Zabezpečení – díky používání protokolu SSL (Secure Sockets Layer) mohou zákazníci přistupovat do aplikací zabezpečeně, bez nutnosti používat složité bezpečnostní postupy.  Větší šířka pásma – vzhledem k tomu, že za poslední dobu znatelně vzrostla kapacita přenosových linek, mohou se zákazníci spolehnout na přístup k aplikacím bez velké latence. Ovšem jako jakékoliv jiné řešení i SaaS model má i své nedostatky. Jako první překážku je možné označit fakt, že pro některé firmy, které potřebují velice sofistikované a netradiční řešení, může vzniknout problém s nalezením poskytovatele, jenž by splňoval jejich požadavky. Další problém spočívá v závislosti na poskytovateli služby. V případě, že by se zákazník rozhodl změnit dosavadního poskytovatele, nemusí existovat způsob, jak příslušnou aplikaci přenést. 5.4.2

Infrastructure as a Service (IaaS)

„Infrastructure as a Service“ poskytuje virtuální stroje, virtuální úložiště, virtuální infrastrukturu a jiné hardwarové prostředky jako zdroje, které si klienti zvolí. Poskytovatel služeb IaaS spravuje všechny požadavky na infrastrukturu, přičemž klient je zodpovědný za všechny ostatní aspekty nasazení. To může zahrnovat operační systém, aplikace a uživatelskou interakci se systémem. (Sosinsky B., 2011) V dnešní době je tento model uplatňován především u velkých korporací, jako je například IBM, Amazon atd. Jedná se o poskytování výpočetního výkonu koncovým uživatelům, kteří tento výpočetní výkon používají k běhu vlastních aplikací. Uživatel má možnost na poskytnuté infrastruktuře provozovat takřka libovolné operační systémy a aplikace. Jde tedy o kombinaci základních hardwarových a softwarových prostředků. „Zákazník nemá kontrolu nad infrastrukturou samotného cloudového řešení, ale může ovládat operační systém, ukládání dat, nasazení a běh aplikací.


34

V některých případech může tato služba umožňovat kontrolu síťových zdrojů, např. firewall.“ (Němec P., 2012) Existuje několik typů zdrojů, které jsou prostřednictvím IaaS poskytovány. Těmito typy jsou: (Velte A., 2011)  místo na serveru,  síťová zařízení,  paměť,  cykly procesoru,  úložné místo. Infrastrukturu je navíc možné dynamicky škálovat oběma směry v závislosti na požadavcích aplikace na prostředky. Kromě toho může zařízení sdílet více nájemců. Obecně lze říci, ze IaaS zahrnuje několik složek (Velte A., 2011):  Smlouvy o úrovni služeb – jedná se o dohodu mezi uživatelem a poskytovatelem služby, která specifikuje požadovanou míru služeb a výkonu.  Počítačový hardware – jedná se o prostředky, které jsou pronajímány. Tyto prostředky je možné zapojovat do gridu.  Síť – jedná se o hardware firewallů, směrovačů, vyrovnávání zatížení atd.  Internetová konektivita – díky ní je možné přistupovat k hardware z klientských zařízení.  Prostředí vizualizace platformy – umožňuje klientům spouštět požadované virtuální počítače.  Fakturace spotřebovaných výpočetních zdrojů – většinou se faktury vystavují v závislosti na objemu využitých systémových služeb „Příklady IaaS služeb jsou například: Amazon EC2 vCloudExpress nebo Rackspace Cloud a další. Služba je ve většině případů účtována na základě množství využití zdrojů a odráží úroveň aktivity zákazníka.“ (Klimt R., 2012) 5.4.3

Platform as a Service

U tohoto modelu má zákazník k dispozici kompletní platformu, pomocí které může vyvíjet vlastní aplikaci popř. nasadit aplikaci třetí strany. „Pro zákazníka je připravena sada vývojových nástrojů a programovacích jazyků, včetně podpory poskytovatele. Zákazník nemůže ovlivňovat samotnou infrastrukturu Cloud řešení, nemá přístup k síťovému nastavení, operačním systémům a ne-


35

může ovlivnit způsob ukládání dat. Má však plnou kontrolu nad nasazením a provozem aplikace. Příklady: Google AppEngine, Microsoft’s Azure, Heroku.com.“ (Němec P., 2012) Vzhledem k tomu, že obvykle se u tohoto typu řešení očekává současný přístup mnoha uživatelů, je běžné, že implementace zohledňuje automatickou správu souběžného přístupu, škálovatelnost, odolnost proti selhání a zabezpečení. Nevýhodou této koncepce je absence interoperability a přenositelnosti mezi poskytovateli. Pokud uživatel vytvoří aplikaci u jednoho poskytovatele cloudového řešení a rozhodne se pro přechod k jinému, není to vždy možné. Další riziko SaaS spočívá v tom, že pokud poskytovatel ukončí svou činnost, ztratí zákazník funkčnost svojí aplikace i uložená data. Mezi služby, které mohou být poskytovány prostřednictvím PaaS, můžeme zařadit návrh aplikací, vývoj, testování, implementace a hostování. Dále pak například týmové spolupráce, integrace webových služeb, integrace databází, bezpečnost, škálovatelnost, úložiště, správa stavu a správa verzí. (Velte A., 2011) Možnost pro nasazení PaaS je především ve třech typech systémů: (Velte A., 2011)  Nástroje pro vývoj doplňků – dovolují přizpůsobit stávající aplikace SaaS.  Samostatná prostředí – tato prostředí se používají při obecném vývoji.  Prostředí pouze pro poskytování aplikací – poskytují služby na úrovni hostingu, jako například zabezpečení a škálovatelnost na vyžádání. „PaaS se při své implementaci potýká se stejnými faktory jako SaaS, protože se nachází v rané fázi. Přijetí této koncepce dále ovlivňují např. následující faktory“: (Velte A., 2011)  Schopnost spolupráce geograficky izolovaných oddělených týmů.  Možnost slučovat webové služby z více zdrojů.  Příležitost finančních úspor díky používání integrovaných služeb infrastruktury pro zabezpečení, škálovatelnost a odolnost proti selhání, místo aby bylo nutné je pořizovat a testovat samostatně.  Možnost finančních úspor díky používání vysokoúrovňových programovacích abstrakcí.

Peer-to-peer model

36

6 Peer-to-peer model Vzhledem k tomu, že praktická část této práce je do značné míry založena právě na peer-to-peer modelu komunikace, bylo by vhodné detailněji objasnit, jak peer-to-peer model funguje, v čem jsou jeho přednosti a k čemu se využívá. Jak již bylo nastíněno v předchozích kapitolách, základní myšlenkou peerto-peer systémů je fakt, že všechny komunikující subjekty v síti jsou si rovny. To samo o sobě úzce souvisí s pojmem decentralizace, který bude objasněn v následující kapitole. Ovšem rovnost není úplně přesným popisem vztahu mezi jednotlivými uzly P2P řešení. Existují různé typy P2P systémů s různými přístupy. Lépe je tedy popsat P2P model jako systém, v němž jsou jednotlivé autonomní uzly schopny výměny dat a informací přímo mezi sebou bez použití serveru jako prostředníka. Mezi charakteristické vlastnosti peer-to-peer modelu tedy patří: (Frkáň T., 2012)  Škálovatelnost – s rostoucím počtem uživatelů může růst i šířka přenosového pásma, velikost prostoru pro data, výpočetní výkon atd. To samo o sobě znamená, že P2P systémy mohou růst až do obrovských rozměrů.  Symetrie – klienti v P2P systémech mohou požadavky tvořit a zároveň obsluhovat. To vyplývá z faktu, že uzel se chová jako klient a server současně.  Dynamika – prostředí pro P2P systémy má často velice proměnlivé rysy. To je dáno jednak množstvím uzlů, které se dynamicky a ve velkých počtech připojují a odpojují, a zároveň také velkou proměnlivostí typu a množství dat, která jsou v rámci sítě přenášeny.  Sdílení prostředků – každý z uzlů disponuje určitými prostředky. Ty mohou být výpočetní, přenosové atd. Tyto prostředky jsou sdíleny v rámci sítě prostřednictvím každého připojeného uzlu. V ideálním případě je míra sdílení prostředků přímo úměrná množství využití systému daným uzlem. V problematice P2P systémů se ustálilo několik základních pojmů. Velice často se může uživatel těchto systémů setkat s pojmy „peer“ a „node“. Pojem „peer“ reprezentuje síťový uzel, který může fungovat jako klient i jako server. Může a nemusí být centrálně řízen a stejně tak může a nemusí být neustále připojen k dané síti. Výraz „peer“ lze použít pro širokou škálu zařízení přes malé kapesní počítače až po výkonné servery.

Peer-to-peer model

37

„Node“ je výpočetní zařízení uvnitř sítě. Může se jednat o univerzální počítače nebo specializovaná zařízení určená pro realizaci konkrétních služeb uvnitř sítě. (Maly R., 2003)

Obr. 11

Zobrazení začlenění P2P v rámci systémů. (Maly R., 2003)

6.1 Výhody a nevýhody peer to peer sítí Je možné definovat celou škálu výhod a nevýhod P2P sítí. Vždy záleží na zkoumaných faktorech a na úhlu pohledu. V této kapitole je zobrazen základní přehled charakteristických vlastností a z nich vyplývajících výhod a nevýhod tak, jak jsou uváděny v jiných materiálech a zdrojích. Mezi základní výhody peer to peer modelů tedy patří zejména (Maly R., 2003):  V čistých peer-to-peer sítích neexistuje jediný bod selhání. To znamená, že v případě výpadku jednoho nebo více uzlů jsou zbylé uzly stále schopny komunikovat.  Peer-to-peer řešení umožňuje použití nevyužitých zdrojů jako je výpočetní výkon a skladovací kapacity. V klient-server architektuře nese většinu nákladů na systém centralizovaná část. P2P umožňuje rozložit náklady mezi jednotlivé vrstevníky.  P2P zabraňuje vzniku úzkých míst v přenosových cestách díky tomu, že zátěž je distribuována na jednotlivé uzly.  Existuje zde větší škálovatelnost z důvodu absence serveru. Mezi obecně známé nevýhody těchto systému patří:

Peer-to-peer model

38

 Dnes vyžaduje velké množství aplikací vysoký bezpečnostní standard, který současná řešení neumí poskytnout.  V některých případech nejsou spojení mezi jednotlivými uzly připravena na velké přenosové zátěže.  V případě, že se značná část uzlů odpojí od sítě, mohou se některé služby zpomalit nebo se stát nedostupnými.  Vyhledávání v rámci sítě je jednodušší implementovat na centrální databázi, než spouštět meta vyhledávání nad jednotlivými uzly sítě.

6.2 Decentralizace S pojmem peer-to-peer sítí je úzce spojen také pojem decentralizace. I když ne všechny P2P řešení jsou plně decentralizované, tak určitá část vždy decentralizovaně funguje. V opačném případě by totiž nebylo možné mluvit o peer-to-peer sítích. Hlavní myšlenkou decentralizace je oprostit se od určitého hlavního řídícího bodu v rámci řešení ať už počítačové sítě, tak čehokoliv jiného. Jde o to poskytnout jednotlivým zástupcům v systému možnost určité autonomie a vybavit je potřebnými nástroji a funkcemi, pomocí kterých dokážou vyhledat ostatní uživatele, navázat komunikaci a provést potřebné úkony bez toho, aby byly nuceny získávat informace od prostředníka. Mohou existovat jak plně decentralizované, tak částečně decentralizované systémy. V praxi je možné se setkat s oběma typy, ale obecně se dá říci, že plně decentralizované řešení se vyskytuje méně často. Mezi typické zástupce takovýchto řešení patří například systém DNS, který v návrhu využívá peer-to-peer protokol, avšak s vybudovanou hierarchií. Najdeme ovšem celou řadu dalších řešení s podobnou logikou, jako jsou například Usenet, Napster, instant messaging a další. (Oram A., 2001) Usenet je typickým příkladem vývoje decentralizovaného systému. Propagace v rámci sítě Usenet je symetrická: uživatelé sdílejí provoz. Ale vzhledem k vysoké ceně údržby plné informovanosti se v praxi udržují pouze páteřní hostitelské stroje, které se starají o veškerý provoz a předkládají jej velkému množství koncových uzlů. Základním trendem sítě Usenet bylo vytvářet hierarchickou propagaci, a to i přes to, že protokol to striktně nevyžadoval. Tato forma tzv. „jemné centralizace“ může být ekonomicky výhodná pro mnoho peer-topeer systémů s velkou cenou přenosu dat. (Oram A., 2001)


39

7 Typy Peer-to-peer sítí Jako i v jiných oblastech i v této problematice můžeme rozdělit peer-to-peer sítě do několika typů. Takové dělení může vycházet z nejrůznějších parametrů a kritérií. Tato část práce prezentuje nejběžnější způsoby dělení P2P sítí.

7.1

Čisté P2P sítě

Aby bylo možné síť označit jako čistou peer-to-peer, musí splňovat několik základních předpokladů. Je nutné, aby se jednalo a distribuovanou peer-to-peer síť. Zároveň musí být možné z takovéto sítě odebrat jakýkoliv komunikující uzel bez toho, aby došlo k omezení nebo ztrátě některé ze síťových služeb, popřípadě k omezení funkčnosti sítě. (Schollmeier R., 2002) V této architektuře je opravdu každý uzel rovnocenným účastníkem. Neexistují zde žádné řídící servery, ani uzly se speciálním zaměřením nebo administračním úkolem. Řízení takové sítě obstarávají sami jednotlivé uzly, které udržují lokální informace a jsou v kontaktu s ostatními uzly, které jsou dostupné. Většinou spolu komunikují sousedící uzly. Řízení takových systému je poměrně značně složité. Nejčastěji se dnes čisté systémy využívají pro sdílení souborů. (Maly R., 2003) Tyto sítě se často označují také jako decentralizované sítě. Někdy se chybně považují za čisté peer-to-peer řešení také tzv. sítě druhé generace. Jedná se o sítě, které se dnes nejčastěji používají pro sdílení souborů na internetu. Tyto sítě sice nemají centrální server, což naznačuje, že se jedná o čisté P2P, ale většina takovýchto řešení nemá jeden typ uzlů. To znamená, že každé zařízení v síti nemůže být nahrazeno jakýmkoliv jiným. „V praxi se z dokonalé symetrie v rámci principu peer-to-peer často slevuje, a to kvůli zefektivnění a větší spolehlivosti hledání či identifikace souborů a zrychlení jejich stahování.“ (PCWorld, 2009) Největší výhodou čistých sítí a obecně takových řešení, kde nefigurují centrální servery (sítě druhé generace) je fakt, že na rozdíl od centralizovaných řešení nebo klient-server architektuře vzrůstá s počtem uživatelů také přenosová kapacita celé sítě. Tohoto jevu se využívá právě pro sdílení multimediálních obsahů, kdy ve velké míře dochází k situaci, kdy v jeden okamžik má zájem daný soubor stahovat velké množství uživatelů. Hlavní nevýhoda decentralizovaných systémů spočívá především ve složitosti celého řešení.


40

7.2 Hybridní P2P sítě Podle jedné z definic můžeme nazvat síť hybridní peer-to-peer sítí v případě, že se jedná o distribuovanou síť, která splňuje definici peer-to-peer sítě zmíněnou v předchozí kapitole a zároveň je k provozu této sítě potřebný centrální subjekt, který zajišťuje provoz části síťových služeb. (Schollmeier R., 2002) Na rozdíl od čisté P2P sítě začleňuje hybridní P2P řešení některé prvky z klient-server modelu. Hybridní v tomto významu znamená, že v rámci sítě existuje centrální server. Ten má v systému ale pouze roli zprostředkovatele. Obecně lze říci, že takový server má v systému dvě základní úlohy (Maly R., 2003):  Centrální adresář – server představuje centrální adresář, ve kterém jsou uloženy informace o uživatelích a indexech obsahu a jejich mapování na příslušné IP adresy.  Řízení provozu mezi zařízeními – za některých okolností probíhá navázání komunikace skrz serverovou část systému a až následně přejde komunikace do přímé podoby mezi uzly. V některých publikacích můžeme nalézt označení takového přístupu jako tzv. centralizované P2P. Někdy je možné také nalézt označení „sítě první generace“. Jde o evolučně nejstarší typ sítí, který používal pro část svých činností centralizovanou strukturu typu klient-server. Zejména jde o připojení k síti a o vyhledávání zdrojů na ní. Pro rutinní komunikaci a sdílení mezi koncovými klienty není zapotřebí využívat servery. Tato činnost probíhá ryze formou peer-to-peer. (PCWorld, 2009) Hlavním rozdílem tohoto přístupu oproti klient-server řešení je, že v případě klient-server modelu jednotliví klienti nesdílejí žádný ze svých zdrojů. Existuje jeden centrální server, který obsluhuje požadavky klientů, a ti jsou od sebe vzájemně odděleni. Další rozdíl spočívá v tom, že na rozdíl od klient-server modelu, kde jsou na serveru uchovávány všechny potřebná data, jsou v tomto případě v rámci serveru obsaženy pouze tzv. metainformace potřebné pro zajištění přímé komunikace. Nevýhoda tohoto řešení spočívá především v tom, že při velkém počtu uživatelů může docházet ke stejným problémům jako v případě klient-server architektury a to především k zatížení serveru. Nicméně zatížení zde může vznikat především po stránce zahlcení přenosových kapacit, spíše než v nedostatku úložných kapacit serveru (jak již bylo zmíněno, na serveru jsou ukládána většinou jen pomocná data).

BitTorrent

41

8 BitTorrent Protokol bitTorrent se řadí mezi skupinu protokolů sloužící především pro sdílení a přesun dat mezi jednotlivými klienty. Jedná se o protokol, který využívá v této práci popsaný model peer-to-peer sítě. Ovšem nejedená se o čisté peer-topeer řešení. Tento protokol je možné zařadit do skupiny tzv. hybridních systémů, které ke své práci využívají částečně serverovou část. V případě, že jsou soubory k dispozici pomocí HTTP protokolu, jsou veškeré uploadované soubory umístěny na serverovém stroji. U bitTorrent protokolu jsou jednotlivé části souboru stahovány a odesílány současně přímo od jejich vlastníků, což umožňuje teoreticky neomezený počet uživatelů stahujících daný soubor. (Cohen B., 2003) Hlavní specifikum bitTorrentu spočívá ve způsobu vyhledávání uživatelů, kteří vlastní požadovaný soubor. Odpověď na otázku „kdo nabízí to, co potřebuji“, poskytuje trochu jinou cestou, než většina ostatních protokolů jako jsou Gnutella, Limeware, Kazaa atd. (KaZaA,2004) U těchto řešení probíhá nalezení vlastníků požadovaného souboru tím způsobem, že uživatel zašle požadavek o soubor a následně si vybere ze seznamu možných uživatelů. V případě bitTorrentu se seznamy souborů, které mají jednotliví uživatelé k dispozici, nalézají na webu. Uživatel po nalezení příslušného odkazu na požadovaný soubor tento soubor stáhne od osoby nebo osob, které jej sdílí. „V případě bitTorrentu se tedy uživatel nestává členem velké „sdílecí“ rodiny, kde může současně vyhledávat z nabídky tisíců lidí, ale místo toho nalezne na webu přímo odkaz na uživatele nabízejícího daný soubor a přímo si jej od něj stáhne. Obtížné je hlavně nalezení správného odkazu.“ (KaZaA,2004)

8.1 Součásti sítě BitTorrent Jako jakékoliv jiné technické řešení i bitTorrent systém se skládá z několika stěžejních součástí, které umožňují realizaci funkčnosti systému. Mezi stěžejní součásti patří:

8.1.1

Klientská aplikace

Jedná se o program instalovaný na klientském zařízení, který se řídí pravidly bitTorrent protokolu pro realizaci příslušných funkcí. Stejně jako existuje celá řada webových prohlížečů, které jsou v principu schopny realizovat stejnou činnost díky tomu, že dodržují základní pravidla http protokolu, tak může existovat

BitTorrent

42

celá sada klientských programů pro realizaci sdílení dat pomocí bitTorrent protokolu. (BitTorrent, 2013) 8.1.2

Odkazové soubory

Takzvané „torrent“ soubory jsou soubory s příponou „.torrent“, které představují způsob, jak sdílet informace o souborech mezi uživateli. Takový soubor umí využít klientská aplikace, která z něj získá potřebné informace pro získání seznamu uživatelů disponujícími souborem, který chce uživatel stáhnout. Soubory „.torrent“ obsahují následující informace (Cohen B., 2003):  název souboru,  velikost souboru,  URL adresa tracker serveru,  velikost jedné části stahovaného souboru (soubory jsou rozděleny na části pevné velikosti, které se sdílí paralelně),  SHA-1 hashe jednotlivých částí,  datum vytvoření,  komenáře,  tvůrce. 8.1.3

Tracker server

Jediná součást systému, která je centralizovaná. Tento server umožňuje realizovat navázání komunikace mezi uživateli tím, že udržuje informace o uživatelích a stavu stahování souborů. Poskytuje informace o tom, kteří uživatelé vlastní který soubor. S těmito uživateli je tak možné navázat komunikaci a zahájit stahování souboru. Uživateli stahující soubor poskytuje tracker server IP adresy a čísla portů, na kterých je možné soubory získat. 8.1.4

Webové servery sdílející odkazy

Jedná se o jedinou část sytému, která není přímo vyžadována pro funkčnost řešení. Jde vlastně a běžný webový server, pomocí kterého si uživatelé předávají „.torrent“ soubory pro získání potřebných informací ke stahování. Ač to není vyžadovaná část pro realizaci sdílení, pro použití bitTorrent systému běžným způsobem je velice důležitá.

BitTorrent

Obr. 12

43

Schéma systému BitTorrent (NewTechArticles, 2013)

8.2 Typy uživatelů sítě BitTorrent V principu lze v rámci sítě BitTorrent identifikovat tři hlavní typy uživatelů. Těmi jsou:  Seeds – jedná se o takové uživatele, kteří vlastní všechny části požadovaného souboru. Čím více je seedů, tím se zvětšuje dostupnost daného souboru a tím vzrůstá rychlost stahování daného souboru. Ve chvíli, kdy uživatel stáhne kompletní obsah souboru, stává se z něj automaticky seed.  Peers – jsou to uživatelé, kteří jsou připojeni k ostatním uživatelům (seedům i peerům) a stahují příslušný soubor. Přitom vlastní jen některé nebo žádné části požadovaného souboru. Ve chvíli, kdy stáhnou jednu kompletní část souboru, poskytují ji rovnou ke sdílení pro ostatní peery, jenž ji zatím nevlastní.  Leechers – na tohoto uživatele je možné nahlížet ze dvou pohledů. Může se jednat o uživatele, kteří pouze stahují příslušný soubor. Dále to mohou být uživatelé, kteří sice sdílí, ale přenosová kapacita je natolik malá, že ji lze považovat za zanedbatelnou. (NewTechArticles, 2013)

BitTorrent

Obr. 13

44

Přehled typů uživatelů sítě bitTorrent (NewTechArticles, 2013)

8.3 Princip činnosti sítě bitTorrent Jak již bylo řešeno, protokol bitTorrent využívá ke své činnosti odkazy na požadovaný soubor, na základě kterých je uživatel schopen k souboru přistoupit a stáhnout jej od jiných uživatelů. Tyto odkazy jsou reprezentovány tzv. „.torrent“ soubory. Jedná se o malé soubory s příponou „.torrent“, které obsahují informace o daném požadovaném souboru. V případě, že chce uživatel poskytnout svůj obsah ostatním klientům prostřednictvím sítě bitTorrent, rozdělí poskytované soubory na stejně velké části, pro které vypočítá hash. Vytvoří pro daný obsah „.torrent“ soubory s potřebnými informacemi včetně velikosti jedné části souboru a seznam hashů pro všechny části. Tyto soubory umístí na přístupné místo pro ostatní uživatele. Může se jednat o specializované servery zaměřené přímo na sdílení seznamu „.torrent“ souborů, webové stránky organizací, soukromou poštu atd. Zde záleží na povaze a vyžadovaném způsobu využití. Dále je zapotřebí, aby příslušný klient, který vlastní celý soubor a zároveň „.torrent“ soubor, kontaktoval tzv. „tracker“. Adresa trackeru je uvedena v „.torrent“ souboru. Klient serveru poskytne potřebné informace pro přístup k danému klientovi. Mezi tyto informace patří především:  peer id – identifikátor příslušného uživatele,  info hash – informační hash pro daný soubor,  IP adresa – adresa, pod kterou je daný uživatel přístupný,

BitTorrent

45

 port – pod kterým uživatel provozuje komunikaci pro daný soubor,  downloaded – množství stažených součástí webu,  left – zbývající množství částí souboru,  event – příslušná událost (sdílení, stahování, začátek stahování atd.). Následně v pravidelných intervalech odesílá požadavky na „tracker“ server, aby jej informoval o tom, že je stále online a případně updatoval potřebné informace. Tím je zajištěna inicializace sdílení pro nově vzniklé soubory v síti. Dalším krokem je stažení sdíleného souboru ostatními uživateli. Uživatel, který potřebuje stáhnout příslušný soubor, musí nejprve vyhledat příslušný „.torrent“ soubor. Z tohoto souboru jeho klient načte potřebné informace a kontaktuje příslušný „tracker“ prostřednictvím „url“ adresy uvedené v „.torrent“ souboru. Požadavek má stejnou strukturu, jako již popsaný požadavek v případě začátku sdílení. Samozřejmě se liší v odesílaných informacích. Server vrátí uživateli seznam IP adres uživatelů a portů, na kterých je možné daný soubor stahovat. Uživatel naváže komunikaci s příslušnými klienty. Ti mu poskytnou informaci o tom, které části souboru již mají stáhnuté a mohou je poskytnout. Na základě této informace začne klient stahovat dostupné části souboru. Nadále v pravidelných intervalech kontaktuje příslušný „tracker“ a zasílá informace o tom, kolik částí již stáhl a kolik mu ještě zbývá. V případě, že klient určitou část souboru stáhne, je tato část ihned poskytována ke stáhnutí dalším klientům. Ve chvíli, kdy klient dokončí stahování všech potřebných částí, stává se z něj tzv. „seed“. To znamená, že již daný soubor nestahuje, pouze ho poskytuje ostatním uživatelům.

Obr. 14 Znázornění procesu zahájení sdílení dat pomocí bitTorrent protokolu. (NewTechArticles, 2013)


46

9 Vývoj systému sdílení souborů V předešlých kapitolách se práce zaměřovala na představení nejdůležitějších teoretických poznatků z oblasti synchronizace a sdílení souborů. Definovala základní možné technologie k zajištění automatizovaného udržování identického obsahu v různých zařízeních. Dále byly popsány nejznámější existující synchronizační nástroje, které jsou na trhu dostupné. V této části práce bude kladen důraz na popis postupu při vývoji konkrétního systému, který umožní sdílení souborů prostřednictvím Internetu. Budou specifikovány funkční a nefunkční požadavky na systém, principy fungování, návrh systému a architektura. Představena bude také samotná implementace a ukázky.

9.1 Specifikace aplikace Tato práce se zabývá problematikou synchronizace dat mezi definovanou množinou uživatelských zařízení. Cílem práce je navrhnout a implementovat aplikaci, která svým uživatelům umožní udržovat konzistentní obsah mezi jím definovanými adresáři z různých zařízení (stolní počítač, notebook). Uživatel bude mít možnost specifikovat neomezenou množinu „virtuálních adresářů“, do kterých bude možné mapovat jednotlivé složky z registrovaných zařízení. Důraz bude kladen na multiplatformní řešení aplikace. Důležitou vlastností aplikace je také udržení soukromí přenášených dat a využití možnosti rychlejšího sdílení dat v případě, že se na synchronizaci podílí více zařízení.

9.2 Funkční požadavky Funkce, které musí aplikace obsahovat z pohledu uživatele, můžeme definovat následovně:  registrace uživatele,  přihlášení uživatele do webového rozhraní,  definice virtuálních složek,  volba nastavení pro jednotlivé složky,  instalace klienta na jednotlivá zařízeni,  definice názvu pro zařízení,  spárování reálných adresářů s virtuálními,


47

 ruční synchronizace jednotlivých adresářů.

9.3 Nefunkční požadavky 9.3.1

Webová aplikace

Jednou z částí realizovaného systému je webové uživatelské rozhraní, které umožní uživateli spravovat jeho účet. Hlavní funkčnost spočívá v administraci virtuálních adresářů, na které bude možné následně „zavěšovat“ reálné adresáře pomocí klientské aplikace. Pro realizaci tohoto rozhraní je k dispozici webový server Apache. Na něm bude implementována samotná aplikace prostřednictvím programovacího jazyka PHP a jeho frameworku Nette. 9.3.2

Klientská aplikace

Druhou součástí systému je klientská aplikace, která uživateli umožňuje ověření identity a následnou práci se souborovým systémem počítače. Uživatel zde bude moci definovat složky, které hodlá sdílet. Bude je mapovat na virtuální složky, které si definoval pomocí webového rozhraní. Tato aplikace bude dále sledovat změny v definovaných složkách a následně provádět jejich synchronizaci s ostatními počítači. K této synchronizaci aplikace používá protokol na bázi peer-to-peer komunikace. 9.3.3

Bezpečnost

Na straně webové aplikace je nutné zajistit zejména bezpečnost uložení přihlašovacích údajů. Tyto údaje jsou uloženy v relační databázi a hesla jsou šifrovány prostřednictvím zvolených šifrovacích algoritmů. V rámci klientské aplikace a sdílení dat je potřebné zajistit bezpečnost přenášených dat a komunikace se serverem. Co se týká přenosu dat, je bezpečnost zajištěna prostřednictvím SSL. Pro komunikaci se serverovou částí bude použit zabezpečený protokol HTTPS. 9.3.4

Provozní požadavky

Pro provoz webové části systému nejsou zapotřebí žádné nestandartní aplikace nebo pluginy. Pro jeho běh postačí uživateli pouze moderní webový prohlížeč. Pro běh aplikace na PC bude zapotřebí, aby měl uživatel nainstalováno prostředí Java 7.0 a vyšší.


48

9.4 Metodika řešení Tato podkapitola se zaměřuje na popis metodiky vývoje systému. V bodech shrnuje kroky, které vedly k realizaci řešení, a nastiňuje, jakým způsobem byly jednotlivé kroky prováděny. Mezi hlavní body v postupu řešení patří: 1.

Definice požadavků – v první fázi byly specifikovány základní požadavky na systém, primární podoba aplikace a její účel. Dá se říci, že tato fáze integrovala jak definici problému, tak analýzu a specifikaci požadavků.

2.

Volba technologií – další důležitou součástí komplexního postupu vývoje je volba vhodných dostupných technologií. Nevhodně zvolené technologie mohou mít za následek značné prodlužování času vývoje, neoptimální výsledek a někdy i nezdárný konec řešení. Při volbě technologií byl kladen důraz především na jejich dostupnost a podporu potřebných nástrojů a protokolů. Dále pak na odborné znalosti dané technologie.

3.

Návrh architektury – v tomto kroku byl proveden návrh komplexní architektury systému, návrh databázového modelu, rozdělení aplikací do adresářových struktur atd.

4.

Implementace – v této fázi byla provedena implementace konkrétních částí systému. Jednotlivé součásti aplikace byly implementovány postupnou metodou a je tedy možné hovořit o tzv. „iterativní metodě vývoje“.

5.

Zavedení a testování – testování do značné míry prolínalo část implementační. Jednotlivé funkce systému byly testovány postupně během vývoje. Na konci implementace bylo provedeno testování systému jako celku.

Jak je z předchozího textu patrné, metodika vývoje do značné míry dodržovala obecně známý postup vývoje aplikací, který se nazývá „vodopádový model“. Tento model byl v některých krocích kombinován s dalším způsobem vývoje tzv. „iterativním modelem“. Tato kombinace je patrná především pro části implementace a testování.

Návrh a architektura

49

10 Návrh a architektura V kontextu praktické části práce nelze mluvit pouze o jedné aplikaci. Jedná se o ucelený komplexní systém, jehož části jsou sice odděleny, ale jsou v neustále interakci a vzájemně spolu komunikují. Tato komunikace je realizována prostřednictvím specifických komunikačních rozhraní a bez její existence by takový systém nemohl vzniknout a fungovat. Soustavu je možné chápat z několika různých hledisek. Na základě těchto hledisek je možné specifikovat různé části a účastníky v komplexním řešení. Pokud bychom se na systém podívaly z globálního pohledu, tak můžeme říci, že se skládá z jednotlivých uživatelů a z nástrojů, které těmto uživatelům poskytují patřičnou funkcionalitu. Z pohledu čistě implementačního je systém možné definovat jako dvě samostatné aplikace, které mezi sebou komunikují a navzájem poskytují ucelený nástroj pro synchronizaci dat. Těmito částmi jsou webový server a uživatelská aplikace. Na obrázku 15 jsou demonstrovány informační kanály, kterými je realizována komunikace mezi účastníky systému.

Obr. 15

Schéma komunikace účastníků systému.

Z obrázku vyplývá, že systém obsahuje jeden centrální server, který poskytuje základní funkcionalitu. K tomuto serveru se připojuje celá řada klientských aplikací. Tyto aplikace jsou instalovány na různých zařízeních a realizují samotný proces vyhodnocování jednotlivých souborů a jejich následnou synchronizaci. Je


50

možné si povšimnout, že v modelu jsou znázorněny dva typy spojení. Spojení zakreslená celou čárou demonstrují výměnu tzv. „metainformací“ o souborech. Naopak spojení znázorněná nevyplněnou čarou demonstrují přesun samotných souborů mezi zařízeními. Z toho jasně vyplývá, že mezi serverem a klienty putují pouze provozní „metaiformace“ a samotné uživatelské data jsou přenášeny pouze mezi klientskými aplikacemi.

10.1 Metody fungování V této podkapitole bude stručně objasněn způsob, jakým je zajištěno samotné sdílení. Bude nastíněna spolupráce jednotlivých součástí systému a demonstrovány kroky, jakými je možné systém využívat z uživatelského hlediska. Pro používání implementovaného systému je bezpodmínečně nutné, aby si uživatel zřídil vlastní účet, pomocí kterého se bude přihlašovat do webového rozhraní a do klientských aplikací. Pro tento účel může využít webový server, který mu danou funkcionalitu poskytuje. V rámci tohoto účtu si uživatel vytvoří množinu tzv. „virtuálních složek“, pomocí kterých bude realizováno propojení skutečných složek v rámci jednotlivých zařízení. Dalším krokem je instalace klientské aplikace do všech zařízení, které mají být synchronizovány. Po nainstalování se uživatel přihlásí do této aplikace prostřednictvím svého účtu a provede potřebná nastavení. Hlavním nastavením je přiřazení reálných složek v rámci souborového sytému na virtuální složky. Tyto složky si uživatel vytvořil prostřednictvím webu. Namapovány musí být všechny složky, u kterých je vyžadována synchronizace. Například, když uživatel namapuje složku s umístěním „D:\dokumenty\fotografie“, bude obsah této složky synchronizován s obsahem složek všech dalších zařízení, ve kterých je namapován nějaký adresář na stejnou virtuální složku. Tím je docíleno toho, že je uživatel odstíněn od nutnosti zachovávat stejnou datovou strukturu napříč zařízeními. Při tomto řešení má možnost synchronizovat obsah složek s úplně odlišným umístěním v jednotlivých zařízeních. Ve chvíli, kdy uživatel provede toto mapování, je obsah reálných složek prozkoumán. Pro každý nalezený soubor je sestaven balík tzv. „metainformací“ a tyto data jsou odeslány na server. Do těchto dat patří především:  název souboru,  doba změny souboru,  hash souboru,  „.torrent“ soubor.


51

Tato data jsou na serveru uložena a poskytnuta aplikacím v ostatních zařízeních. Aplikace data vyhodnotí a porovnají proti obsahu jednotlivých složek v souborovém systému. Může se stát, že aplikace nalezne chybějící soubor, nebo soubor se starším časem vytvoření, než je čas v přijímaných datech. V takovém případě je stáhnut příslušný „.torrent“ soubor a na základě dat v něm obsažených je zahájeno stahování příslušného souboru z ostatních zařízení. Po dokončení stahování uloží novou verzi souboru do příslušného adresáře. Všechny aplikace zároveň provádí v pravidelných intervalech srovnání aktuální verze oproti datům ze serveru. Dále je zajištěno, že příslušné aplikace provádí naslouchání na mapovaných adresářích. V případě změny v datech (nahrání souboru, změna souboru a odstranění souboru) je tato informace odeslána na server a poskytnuta ostatním klientům. Tito klienti při další periodické kontrole srovnají přijaté změny a v případě potřeby zahájí potřebné kroky, které byly popsány výše.

10.2 Součásti systému 10.2.1

Webový server

Webový server má hned několik základních účelů, které je možné rozdělit na tři primární části. V první řadě slouží jako nástroj pro uživatele, kterým umožní zřídit si vlastní účet a provádět nejrůznější nastavení. V současné fázi implementace jsou realizovány primární funkce webového serveru, které jsou nutné pro zdárný provoz systému z pohledu uživatele. V případě, že se uživatel rozhodne využít tento systém, je právě webový server prvním nástrojem, který musí využít. Webový server poskytuje uživateli následující funkcionalitu:  Registrace – uživatel má možnost vytvořit si vlastní profil, na základě kterého se následně přihlašuje do systému.  Vytvoření „virtuálních složek“ – prostřednictvím webového serveru poskytuje server možnost zřízení množiny složek, na které budou mapovány reálné cesty ze souborového systému jednotlivých zařízení.  Sledování zařízení – server uživateli předkládá informace o jednotlivých zařízeních a jejich aktuálním stavu (připojeno/nepřipojeno). Druhou ze tří částí, pro které je určen webový server, je tzv. „API rozhraní“. Jedná se o způsob, jakým probíhá komunikace mezi serverem a klientskými aplikacemi. Hlavním účelem bylo vytvořit nástroj, který na pevně stanovených


52

URL adresách poskytne aplikaci data v takové podobě, ve které je bude schopna číst a zpracovávat. Z toho důvodu bylo zapotřebí nalézt vhodný formát dat, který je standardizovaný a jednoduchý pro softwarové zpracování. Pro tyto účely byl zvolen formát JSON, který je na webu velice rozšířený a pro účely tohoto úkolu je více než dostačující. Hlavními důvody pro zvolení tohoto formátu byly především tyto:  Podpora napříč platformami – nástroje pro zpracování a generování dat v tomto formátu jsou dostupné v celé škále nástrojů, mezi které patří i PHP, použité pro serverovou část řešení a Java, která byla využita pro klientskou část řešení.  Přehlednost – formát sám o sobě je velice čitelný i pro člověka, proto je jeho využití vhodné i z hlediska vývoje a ladění.  Nízká datová náročnost – JSON je vhodný také pro jeho velice úspornou formu. To snižuje zátěž na přenosové kapacity. Mezi data, která API rozhraní poskytuje aplikacím, patří především nejrůznější seznamy. Jako příklad je možné jmenovat seznam složek uživatele, uživatelská zařízení, ale třeba i informace o tom, zda jsou uživatelské informace pro přihlášení správné. Poslední částí, která je realizována prostřednictvím webového serveru, je tzv. „tracker server“. Co je „tracker server“ a k čemu slouží, se věnovaly předchozí kapitoly. Jako konkrétní implementace byl zvolen tzv. „Bitstorm“, což je server implementovaný prostřednictvím jazyka PHP. Jedná se o jednoduchou implementaci pod „GNU“ licencí, která je realizována prostřednictvím jednoho jediného PHP souboru. Volba na tento nástroj padla především proto, že jeho nasazení je jednoduché a pro vývoj je toto řešení naprosto dostačující. Výhodou je, že „tracker server“ je možné kdykoliv změnit na jinou implementaci, takže volba konkrétního nástroje není nikterak klíčová. 10.2.2 Klientská aplikace Další nedílnou součást celého řešení tvoří klientská aplikace. Jedná se o program, který je nainstalován na všech dílčích klientských zařízeních. V rámci tohoto nástroje probíhá samotné vyhodnocování jednotlivých souborů. Tato aplikace realizuje také samotný přenos souborů z jiných zařízení. Mezi základní funke, které poskytuje aplikace uživateli, patří:  Přihlášení do aplikace – uživatel má možnost přihlásit se do dané aplikace pomocí účtu, který si vytvořil na webu.


53

 Namapování složek – pomocí aplikace je možné nastavit jednotlivé adresáře souborového systému na předem vytvořené „virtuální složky“.  Vyhodnocování souborů – aplikace vyhodnocuje soubory v namapovaných adresářích a srovnává je s daty, které získala ze serveru.  Synchronizace souborů – v případě, kdy jsou nalezeny zastaralé, nebo chybějící soubory, provede aplikace jejich stažení od ostatních klientů.  Naslouchání na namapovaných složkách – aplikace naslouchá na složkách a v případě změny o tom informuje webový server prostřednictvím jeho API rozhraní. Jak již bylo zmíněno, aplikace provádí také samotné stažení souborů. Na základě požadavků, které byly specifikovány pro realizaci tohoto systému je zřejmé, že bylo zapotřebí pro přenos využít nástrojů peer-to-peer. Pro tento účel bylo zapotřebí zvolit některý z protokolů, které jsou pro takový model komunikace určeny. Vybrán byl protokol bitTorrent a to především z těchto důvodů:  vhodná koncepce fungování z pohledu systému,  možnost využití současného stahování z více aplikací současně,  dobrá podpora práce s protokolem pomocí nástroje zvoleného pro implementaci aplikace (Java).

Obr. 16

Naslouchání aplikace a informování serveru.

Vzhledem k tomu, že aplikace využívá protokol bitTorrent, je zapotřebí získat pro stahované soubory jejich příslušné „.torrent“ soubory. Tyto soubory aplikace získá z webového serveru. Na ten byly zaslány společně s „metainformacemi“ z klientské aplikace, která příslušné soubory zaznamenala.


54

Jakmile aplikace získá potřebné „.torrent“ soubory, využije připraveného rozhraní pro práci s bitTorrent protokolem a soubor jednoduše stáhne pomocí připravených metod.

10.3 Struktura databáze V rámci systému bylo nezbytně nutné navrhnout způsob, jakým budou ukládána data potřebná pro správnou funkci řešení. Pro ukládání dat byla zvolena relační databáze. Konkrétně se jedná o databázi MySQL. Správný návrh struktury databáze je jedna z klíčových úloh při vývoji systému. Vhodné je věnovat tomuto kroku dostatek prostředků již ve fázi návrhu. Důležitost tohoto kroku spočívá především v tom, že obslužné aplikace pracují s příslušnými daty a pozdější změny v datovém schématu často znamenají nutnost provést změny i v příslušných aplikacích. Fáze návrhu by měla obsáhnout co nejkomplexněji danou problematiku a všechny důležité aspekty zahrnout v rámci datového modelu. Výsledný model databáze systému čítá třicet tabulek. Nicméně ne všechny jsou spojeny přímo se systémem sdílení. Značná část realizuje funkčnost samotného webového rozhraní. Obrázek 17 znázorňuje ERD části databáze, která se věnuje přímo problematice sdílení dat. Nejdůležitější entitou je tabulka „virtualfolders“, která reprezentuje virtuální složky jednotlivých uživatelů. Z této tabulky existuje vazba na tabulku „files“. Zde jsou uloženy informace o jednotlivých souborech. Je možné si povšimnout, že tabulka opravdu obsahuje všechny již dříve zmíněné informace, které jsou zasílány na server klientskými aplikacemi. Velice důležitou položkou je sloupec „torrent“. Ten představuje odkaz na příslušný „.torrent“ soubor. Další důležitou entitu představuje tabulka „requestedfile“. Tato tabulka obsahuje informace o souborech, které je nutné synchronizovat. Existují zde vazby na tabulky „virtualfolders“ a „devices“. To znamená, že jsou zde obsaženy informace o vyžadovaných souborech a také o tom, které zařízení je vyžaduje a do které virtuální složky soubor patří. Dále zde jsou tabulky „bindfolders“ a „deletedfile“. Jak již názvy napovídají, tyto tabulky obsahují informace o tom, jaké cesty jsou namapovány na virtuální složky v jednotlivých zařízeních a také o tom, které soubory mají být ze zařízení odstraněny.


Obr. 17

55

ERD model databáze systému.

10.4 Použité technologie Před samotnou implementací jakéhokoliv systému je velice důležité zvolit technologie, které jsou pro danou problematiku vhodné. Špatná volba technologií může mít za následek vznik problémů během realizace a někdy může vést až k nezdárnému zakončení projektu. V první fázi bylo zapotřebí nalézt vhodné technologie pro implementaci webové části systému. Po zvážení všech faktorů byl zvolen programovací jazyk PHP a to především kvůli těmto faktorům:  velká rozšířenost napříč servery,  znalost tohoto jazyka,  dobrá podpora práce s formátem JSON,  jednoduchá práce s MySQL databází,  existence velkého množství implementací „tracker serverů“. Nicméně vzhledem k tomu, že se webová část systému skládá z několika oddělených modulů a zároveň je poměrně rozsáhlá, bylo zapotřebí najít nástroj, který


56

umí s takovým modulárním rozdělením pracovat. Zároveň bylo vhodné, aby podporoval obecně známé praktiky při vývoji webových aplikací jako je například model MVC atd. Z toho důvodu byl použit PHP framework „Nette“. Jeho výhody spočívají právě v podpoře modulů a dodržování základních vývojových praktik. Dále lze za výhody považovat jeho neustálý vývoj a velkou základnu uživatelů. Pro vývoj webové aplikace byly dále použity běžné nástroje, jako jsou značkovací jazyk HTML doplněný o JavaScriptové prvky. Jak již bylo zmíněno v předchozí kapitole, pro ukládání dat byl zvolen nástroj MySQL. Po volbě technologií pro serverovou část bylo zapotřebí nalézt vhodné nástroje pro vývoj klientské aplikace. Zde padla volba na programovací jazyk Java. Důvodů pro volbu tohoto řešení je celá řada. Nejpodstatnější z nich jsou:  Podpora napříč operačními systémy – vzhledem k tomu, že u tohoto systému je zapotřebí zohlednit co nejvíce platforem a operačních systémů, je Java vhodným kandidátem.  Jednoduchá práce s formátem JSON – stejně jako u PHP je i pro tento nástroj k dispozici řešení, které umožňuje jednoduše pracovat s formátem JSON.  Podpora pro práci s protokolem bitTorrent – pro jazyk Java existuje celá řada rozšíření, která umožňují jednoduše pracovat s bitTorrent protokolem.  Podpora pro naslouchání nad složkami v souborovém systému – Java od verze 7 má k dispozici nástroje, které umí sledovat změny ve složkách souborového systému. Jak již bylo řečeno, jazyk Java má rozšíření jak pro práci s formátem JSON, tak s protokolem bitTorrent. Volba rozšíření pro práci s JSON formátem byla poměrně jednoduchá. Existuje nástroj s názvem „Json Simple“, který je jednoduchý na zpracování a poskytuje naprosto dostatečnou množinu nástrojů. Poněkud složitější situace existuje při výběru rozšíření pro práci s bitTorrent protokolem. Těchto nástrojů existuje celá řada, ale dá se říci, že ani jeden není úplně optimální. Z toho důvodu byly využity dvě knihovny. První z nich nese název „Ttorrent“. Tato knihovna poskytuje funkcionalitu umožňující velice jednoduše provádět stahování souborů prostřednictvím bitTorrent protokolu. Bohužel pro sdílení souborů se tento nástroj ukázal jako ne úplně optimální. Největší problém byl v rychlosti generování „.torrent“ souborů, v malé podpoře nástrojů pro sdílení a v nemožnosti editovat soubor, pokud je momentálně sdílen tímto nástrojem. Z tohoto důvodu byl pro sdílení souboru zvolen nástroj „jBitTorrentAPI“.

Implementace

57

11 Implementace Předchozí kapitoly se věnovaly nejdříve teoretickému základu, průzkumu trhu, specifikaci požadavků a následně návrhu a architektuře systému. Tato kapitola se zaměřuje na již konkrétní implementaci jednotlivých součástí systému. Popisuje jednotlivé postupy a prezentuje dílčí části implementace. Samozřejmě není možné postihnout komplexní přehled celé implementační části. Kompletní řešení je k dispozici na přiloženém CD. Zde budou prezentovány nejdůležitější postupy a ukázky klíčových částí implementace. Obdobně jako v předchozích kapitolách bude vhodné rozdělit i tuto část na popis implementace serverové aplikace a následně implementace uživatelské aplikace.

11.1 Serverová aplikace Jak již bylo nastíněno, pro implementaci serverové části byl použit framework „Nette“2 potažmo programovací jazyk PHP. Při vývoji bylo nutné dodržet určitou adresářovou strukturu. Ta je do značné míry specifikována samotným frameworkem. V rámci aplikace existuje několik hlavních adresářů. Těmi jsou:  app – pro vývojáře asi nejdůležitější součást aplikace. Obsahuje třídy pro konkrétní modely, presentery a šablony.  libs – adresář pro samotné knihovny frameworku. Ve většině případů není nutné tento adresář jakkoliv měnit.  log – zde jsou obsaženy logy aplikace.  temp – adresář obsahující cache a dočasné soubory.  www – další velice důležitý adresář. Obsahuje soubory, které jsou dostupné prostřednictvím webového rozhraní. Například se může jednat o obrázky, CSS soubory, doplňkové PHP skripty atd. Z pohledu implementace patří mezi nejdůležitější části adresáře „app“ a „www“. Jak již bylo řečeno, serverová část se skládá ze tří modulů. Rozdělení aplikace na oddělené moduly podporuje i framework „Nette“. To je realizováno rozdělením do příslušných podadresářů v adresáři „app“. Jeho struktura je tedy následující:  AdminModule – obsahuje součásti pro administrační část webového rozhraní.

2

http://nette.org/cs/

Implementace

58

 FrontModule – zde jsou uloženy potřebné soubory pro veřejně dostupnou část webového rozhraní.  ApiModule – reprezentuje modul pro poskytování dat uživatelské aplikaci.  _common – adresář obsahující společné části pro všechny moduly. V tomto případě se jedná například o třídu reprezentující společného předka pro všechny presentery.  config – adresář obsahující nastavení aplikace.  model – zde jsou uloženy všechny třídy, které reprezentují příslušné modely systému. V rámci každého modulu je zapotřebí opět dodržet určitou adresářovou strukturu. Vždy je zapotřebí, aby existovaly adresáře „presenters“ a „templates“. Tyto adresáře slouží pro uchování jednotlivých presenterů. Presenter reprezentuje obslužnou třídu uživatelských požadavků. Jedná se o část „control“ v rámci MVC modelu. Konkrétní šablony, které se starají o část „view“ jsou uloženy právě ve složkách templates. Framework samotný již zajišťuje spouštění příslušných akcí v příslušných presenterech na základě URL adresy. Například při volání adresy „http://www.example.cz/admin/user/login“ se spouští akce login z presenteru user v modulu admin. Mezi další složky, které mohou být obsaženy v adresářích jednotlivých modulů, patří složka „models“, která může obsahovat třídy modelů pro jeden jediný modul. Dále se zde může nacházet složka „compoents“, která obsahuje jednotlivé komponenty. Věnovat se detailně všem modulům a popisu implementace jeho částí by bylo nad možnosti této práce. Navíc popis modulů pro administrátorské rozhraní webu a veřejně dostupnou část není nikterak podstatný. Zaměříme se tedy spíše na problematiku implementace části reprezentující modul „API“. Jak již bylo řečeno, jedná se a část aplikace, která generuje výstupy ve formátu JSON pro uživatelské aplikace. Tento modul se skládá ze tří presenterů, z nichž jeden reprezentuje pouze obecného předka pro další dva. Těmi jsou „PublicPresenter“ a „SecurePresenter“. Tím je zajištěno rozdělení metod, které jsou poskytovány do zabezpečené a nezabezpečené části aplikace. Ve veřejné části aplikace je v současné době pouze akce login, která zajišťuje přihlášení uživatele do systému a předání informací o přihlášeném uživateli. Tato akce je prezentována následující ukázkou:

Implementace

59

public function actionLogin() { $request = $this->getHttpRequest(); $login = $request->getPost('login'); $password = $request->getPost('password'); $user = new User($this->getUser()); if ($user->login($login, $password)) { $dataUser = new \AdminModule\User($this->database,$this->user->getId()); $this->data['user'] = $dataUser->getData()->toArray(); $this->data['logged'] = true; } else { $this->success = false; $this->message = "Data is not valid"; $this->errorCode = 1; } } Kód. 1

Metoda pro přihlášení uživatele do serverového API.

Jak je možné vidět, každá metoda reprezentující akci musí být typu public a její název musí začínat klíčovým slovem „action“. Kromě akcí může presenter obsahovat jakékoliv další ať už privátní nebo veřejné metody. Kromě akcí existuje ještě celá řada speciálních metod v rámci presenterů. Jejich kompletní seznam je k dispozici v dokumentaci3 frameworku. Mezi takové metody patří například metoda „startup“. Ta je volána vždy jako první v případě spuštění jakékoliv akce presenteru. Toho je využito v SecurePresenteru pro ověření přihlášení uživatele. To demonstruje následující ukázka: protected function startup() { parent::startup(); $request = $this->getHttpRequest(); $login = $request->getPost('xConnLogin'); $passwd = $request->getPost('xConnPasswd'); try{ 3

http://doc.nette.org/cs/presenters

Implementace

60

$this->user->login($login, $passwd); } catch(\Exception $e){ $result['success'] = false; $result['error'] = Array('message' => 'User is not logged','code' => 1); $this->sendResponse(new \Nette\Application\Responses\JsonResponse($result)); } } Kód. 2

Zaváděcí metoda zabezpečeného presenteru.

Obr. 18

Dialog pro nastavení virtuálních složek.

Tato metoda se zavolá pokaždé při inicializaci příslušného presenteru. Získá data odeslaná metodou POST. Z nich načte přihlašovací údaje a pokusí se uživatele přihlásit. V případě neúspěchu vrátí chybovou zprávu a číslo chyby. Mezi další akce v rámci SecurePresenteru patří nejrůznější metody pro získání existujících dat, vložení nových dat a mazání stávajících. K tomu je využita práce s jednotlivými modely. Práce s modelem je demonstrována na následujícím pří-

Implementace

61

kladu. Jedná se o jednoduchou metodu, která slouží k odstranění příslušného souboru určeného pro smazání. public function actionRemoveFileFromDeleteList(){ $fileId = $this->getHttpRequest()->getPost('fileId'); foreach($fileId as $id){ $f = new \AdminModule\DeletedFile($this->database, $id); $f->delete(); } $this->success = true; } Kód. 3

Ukázka práce se serverovými modely.

11.2 Uživatelská aplikace Implementace uživatelské aplikace je realizována prostřednictvím programovacího jazyka Java. Stejně jako při popisu implementace webové aplikace bude vhodné nejdříve definovat základní části, ze kterých je finální aplikace složena. Řešení je rozděleno do několika základních balíků, kterými jsou:  myShare – obsahuje definice tříd pro základní modely, se kterými aplikace pracuje.  myShare.ext – zde jsou definovány nejrůznější rozšíření.  myShare.torrent – představuje předpis tříd pro práci s protokolem bitTorrent.  myShare.ui – obsahuje třídy uživatelského rozhraní.  myShare.utils – na tomto místě je možné naleznout různé utility a nástroje, jako jsou nejrůznější konvertory atd.  exceptions – v tomto místě jsou definovány třídy pro jednotlivé výjimky. Kromě balíků obsahuje aplikace ještě několik dalších knihoven. Z nich nejdůležitější jsou knihovny pro práci s bitTorrent protokolem a JSON formátem. Ty byly popsány v kapitole 10.4. Stejně jako v předchozí části, tak i zde by nebylo možné postihnout celou fázi procesu implementace. Proto se tato část práce zaměří pouze na vybrané oblasti, které se jeví jako nejpodstatnější a nejzajímavější.

Implementace

62

V rámci implementace vznikla velká množina tříd pro nejrůznější účely. Některé z nich zde budou popsány a částečně prezentovány. Jako první se zaměříme na třídu „Folder“, která je jednou z nejkomplexnějších a reprezentuje jednotlivé virtuální složky. V rámci této třídy se provádí samotná kontrola a srovnávání souborů ve složkách. Dále obsahuje celou řadu metod. Mezi ně patří například metoda „bindFolder“, která obstarává namapování reálné složky pro příslušné zařízení. Samozřejmě není možné zde obsáhnout všechny metody implementované v rámci této třídy. Jako ukázka bude demonstrována metoda „deleteFile“. Jedná se o příklad využití serverového API. public void deleteFile(String fileName) throws Exception{ this.files.remove(fileName); HashMap<String, String> params = new HashMap(); …. Date time = new java.util.Date(); params.put("time", new Long(time.getTime()).toString() ); URL url = new URL(Sys.getUrl("secure/deleteFileFromFolder")); this.loader.loadJson(url,params); } Kód. 4

Metoda pro odstranění obrázku demonstrující práci se serverovým API.

Na předchozí ukázce je patrné, jak aplikace spolupracuje s webovým serverem. Nejdříve je vytvořena množina potřebných atributů a následně je přes příslušný objekt zaslán dotaz na server. Pro stahování a sdílení využívá třída dvou dalších tříd. Jedná se o třídy „DownloadTorrentThread“ a „SharedTorrentThread“. Třídy reprezentují vlákna pro realizaci příslušných úkonů. Tyto vlákna jsou implementačně velice jednoduchá, což demonstruje následující ukázka: public void run(){ try{ Downloader downloader = new Downloader(this.folder, this.file.get("name").toString(), this.file.get("torrent").toString(), "d",this.deviceName,this.fileChange,this.downloadCounter ); downloader.download(file); }

Implementace

63

catch(Exception e){ System.out.println(e.getMessage()); } } Kód. 5

Ukázka práce se stahovacími vlákny.

Jak můžeme vidět, v rámci vlákna se vytvoří objekt „downloader“ a vyvolá se jeho příslušná metoda. Další důležitou třídou je právě zmiňovaný „Downloader“. Ta je součástí balíku „MyShare.torrent“. Jedná se implementaci nástroje, který pomocí příslušných rozšíření, umožňuje sdílet a stahovat soubory prostřednictvím protokolu bitTorrent. Vzhledem k použití zmiňovaných rozšíření není jeho implementace nikterak složitá. Obsahuje tři základní metody. První je samotný konstruktor, který zajišťuje všechna potřebná nastavení. Dále jsou to metody „download“ a „share“. Jak už názvy napovídají, tyto metody se starají o stažení a sdílení souborů. Právě v rámci těchto metod se pracuje s rozšířeními pro práci s bitTorrent protokolem. V následujícím kódu je možné vidět použití nástroje pro stahování. SharedTorrent torent = SharedTorrent.fromFile(this.torrent, folder); Client client = new Client(InetAddress.getLocalHost(),torent); client.download(); if(torent.isComplete()){ client.stop(); } Kód. 6

Ukázka práce s torrent klientem.

Samozřejmě existuje ještě celá řada dalších tříd jako například „DonloadCounter“, „RealyFile“, „Device“, atd. Bohužel není v silách této práce se jim detailněji věnovat. V další části se zaměříme na implementaci uživatelského rozhraní. Všechny třídy reprezentující UI jsou součástí balíku myShare.ui. Každá z implementovaných tříd realizuje nějaký prvek. Ve většině případů se jedná o jednotlivá okna aplikace. Prakticky je možné říci, že aplikaci realizují tři základní okna. Jsou to:  Login,  MachineName,  MainWindow.

Implementace

64

Všechna okna byla vytvořena prostřednictvím nástroje obsaženého v rámci vývojového prostředí NetBeans a následně byly doimplementovány obslužné metody pro jednotlivé prvky. Okno s názvem „Login“ zajišťuje přihlášení uživatele do aplikace. Ukázka je k vidění na obrázku 19.

Obr. 19

Přihlašovací okno uživatelské aplikace.

Součástí příslušné třídy je i implementace obslužných metod pro jednotlivé funkční prvky. Například se jedná o tlačítka atd. Jako příklad obslužné metody můžeme uvést obsluhu tlačítka pro přihlášení. private void loginButtonMouseClicked(java.awt.event.MouseEvent evt) { …. } Kód. 7

Obslužná metoda ovládacího prvku.

Samozřejmě uvnitř této metody je obslužný kód, který zajistí komunikaci se serverem a přihlášení uživatele. Další součástí uživatelského rozhraní je okno s názvem „MachineName“. To slouží uživateli pro zadání jména příslušného zařízení. Nejrozsáhlejší implementací v rámci UI je třída „MainWindow“. Jedná se o defaultní obrazovku aplikace. Tato třída řídí běh aplikace, spouští jednotlivé úlohy a předkládá uživateli základní nástroje pro práci s aplikací. V rámci této třídy se spouští periodické naslouchání nad složkami, kontrola vůči datům ze serveru atd. Grafická podoba okna je demonstrována v části přílohy.

Závěr

65

12 Závěr Primárním cílem této práce bylo zanalyzovat současný stav v oblasti synchronizačních nástrojů a technologií a na základě této analýzy pak navrhnout a realizovat řešení, které by umožňovalo provádět synchronizaci souborů na základě stanovených požadavků. Za jeden z hlavních požadavků lze přitom označit provádění synchronizace takovým způsobem, aby byla data přenášena opravdu pouze mezi zařízeními bez zbytečných prostředníků. Dalším požadavkem bylo vybudovat aplikaci, která by byla nezávislá na konkrétní platformě. Je možné konstatovat, že na základě analýzy problematiky a následnému návrhu se podařilo implementovat relativně nevšední řešení, jakým synchronizaci provádět. Byl navrhnut komplexní systém, který pro svoji činnost kombinuje celou řadu technologií, jak z oblasti vývoje aplikací, tak komunikačních protokolů. Tento systém tvoří dvě základní aplikace, které jsou ve vzájemné interakci a společně zajišťují komplexní funkcionalitu. Bezesporu lze za jednu z hlavních technologií, která umožnila vznik tohoto systému, označit komunikační protokol bitTorrent. Díky tomuto protokolu bylo možno splnit jeden z hlavních cílů, kterým je přenos souborů přímo mezi konkrétními zařízeními. To je zajištěno tím, že protokol bitTorrent umožňuje komunikaci prostřednictvím peer-to-peer modelu, a díky tomu je možné komunikovat bez jakéhokoliv prostředníka v podobě serveru. Díky využití nativních technologií na straně serveru v podobě protokolu HTTP a výstupů v podobě HTML a JSON formátů byla zajištěna nezávislost serverové části na platformě. Nezávislost aplikační části zajišťuje její implementace programovacím jazykem Java. Tento jazyk je v dnešní době podporován většinou operačních systémů. Co se konkrétní implementace týče, podařila se naimplementovat funkční verze systému, která demonstruje funkčnost a základní práci se systémem. Z důvodu bezpečnosti a zabezpečení některých sítí funguje aplikace pouze na úrovni lokálních sítí. Pro další nasazení by bylo vhodné použít aplikaci v kombinaci s VPN sítěmi. Systém v současné fázi slouží jako demonstrace funkčnosti daného návrhu. Aplikace představuje velký potenciál pro další rozšíření a vývoj a případně také následné masovější využití. Otázkou ovšem zůstává, do jaké míry by byla schopna konkurovat jiným aplikacím. Kromě vývoje a zlepšování samotné aplikace vzniká také prostor pro vývoj doplňkových služeb a podpůrných nástrojů. Například by bylo možné rozšířit aplikaci takovým způsobem, aby poskytovala svoje API prostřednictvím webových služeb. Tím by se ještě více otevřel prostor pro využití návrhu jako komplexního systému, bez závislosti na konkrétní klientské aplikaci. Ostatním vývo-

Závěr

66

jářům by toto řešení poskytlo možnost vytvářet vlastní aplikace, které by příslušné rozhraní využívaly. Další možností pro vývoj je implementace klientských aplikací do nejrůznějších přenosných zařízení, jako jsou mobilní telefony, tablety atd. I přes zmíněné možnosti rozšíření a úprav je možné konstatovat, že se podařilo implementovat systém demonstrující možnosti synchronizace relativně netradičním způsobem a kombinací technologií. Bylo využito hybridního přístupu, který umožnil zjednodušit logiku celé aplikace a přitom zachovat výhody plynoucí z použití peer-to-peer technologií. Avšak samotná implementace není jediným přínosem této práce. Práce přináší jasnou demonstraci toho, jak lze využít jednotlivé zdánlivě nesouvisející technologie a jejich spojením dosáhnout komplexního fungujícího systému. Z práce je patrné, že projekty založené na podobném principu mohou být potenciálně zajímavé pro celou škálu korporací. Mezi hlavní osobní přínosy je možné zařadit především rozšíření obzorů a znalostí v problematice synchronizace a práce s P2P systémy. Dále možnost vyzkoušet hledání netradičních a zajímavých řešení návrhu aplikací. V neposlední řadě také poznání způsobu, jak zajistit komunikaci mezi různými druhy systémů a aplikací.

Literatura

67

13 Literatura BITTORRENT. About BitTorrent. [online]. 2013 [cit. 2013-11-23]. Dostupné z: http://www.bitTorrent.com/help/manual/chapter0101. BOHUSLAV, Martin. Implementace CRM systému prostřednictvím SaaS. Praha, 2012. Diplomová práce. Vysoká škola ekonomie a managementu. CLOUD COMPUTING. Cloud Computing and Types of Cloud. Http://cloudblog.8kmiles.com [online]. 2012 [cit. 2013-05-05]. Dostupné z: http://cloudblog.8kmiles.com/2012/02/27/cloud-computing-type/. COHEN, Bram. Incentives Build Robustness in BitTorrent. [online]. [cit. 201312-01]. Dostupné z: http://www.ittc.ku.edu/~niehaus/classes/750s06/documents/BT-description.pdf. EKTRON. CMS in the Cloud Part 1: What is Cloud Computing?., Inc. Ektron [online]. United Kingdom, 2013 [cit. 2013-11-02]. Dostupné z: http://www.ektron.com/Blogs/Arun-Chaloori/CMS-in-the-Cloud-Part-1-What-is-Cloud-Computing-/. FRKÁŇ, Tomáš. Animácia smerovania požiadaviek v peer-to-peer sieťach. Brno, 2012. Bakalářská práce. Masarykova univerzita. GARTNER. Gartner Highlights Five Attributes of Cloud Computing. Gartner [online]. 2009 [cit. 2013-05-06]. Dostupné z: http://www.gartner.com/newsroom/id/1035013. GREER, Melvin B. 2009. Software as a Service Inflection Bloomington : iUniverse, 2009. ISBN 978-1-4401-4196-6.

Point.

HANSMANN, Uwe; METTÄLÄ, Riku; PURAKAYASTHA, Apratim; THOMSON, Peter. SyncML: Synchronizing and Managing Your Mobile Data. 1st edition. Pearson Education, 2002. 320 s. ISBN978-0-13-009369-1. HŘEBABECKÝ, Jan. Projekty pro sdílení dat na internetu typu Rapidshare se zaměřením na konkrétní vybraný projekt a jeho rozbor. Praha, 2011. Diplomová práce. Vysoká škola ekonomická v Praze. HOMOLKA, Vítězslav. Synchronizace dat webových aplikací s mobilními zařízeními. Brno, 2010. Diplomová Práce. Masarykova univerzita. CHELLAPPA, Ramnath. Prof. Ramnath Chellappa, PhD. [Online] 2010. [Citace: 2011.10 15.] Dostupné z WWW: .

Literatura

68

KARPETA, Jiří. Počítače v oblacích: Cloud je všude kolem. Computerworld [online]. 2011 [cit. 2013-05-05]. Dostupné z: http://computerworld.cz/aktuality/pocitace-v-oblacich-1-cloud-je-vsudekolem-8397. KAZAA, DirectConnect, eDonkey, bitTorrent a další: průvodce výměnou souborů přes Internet. Vyd. 1. Redaktor Stanislav Závodný. Brno: Computer Press, 2004, 190 s. ISBN 80-251-0465-6. KLIMT, Roman. Informační systémy v éře Cloud Computingu. Praha, 2012. Diplomová práce. Vysoká škola ekonomická v Praze. KUBEŠ, Radek. Na internetu si můžete zadarmo odložit gigabajty informací. Technet.cz [online]. 2011 [cit. 2013-05-04]. Dostupné z: http://technet.idnes.cz/na-internetu-si-muzete-zadarmo-odlozit-gigabajtyinformaci-p4x-/software.aspx?c=A110520_133222_software_mbo. LOGMEIN, INC. Cubby.com [online]. 2013 [cit. 2013-05-04]. Dostupné z: https://www.cubby.com/. MALY, Robin Jan. Comparison of Centralized (Client-Server) and Decentralized (Peer-to-Peer) Networking. Zurich, 2003. Semestrální Prace. ETH Zurich, Switzerland. MELL, Peter; GRANCE, Timothy. 2011. The NIST Definition of Cloud Computing. National Institute of Standards and Technology. [Online] September 2011. [Citace: 6. května 2013.] http://csrc.nist.gov/publications/nistpubs/800145/SP800-145.pdf. Special Publication 800-145. MORAVEC, Josef. Datová úložiště výukových objektů. Brno, 2011. Diplomová práce. Masarykova univerzita. NÁRODNÍ CENTRUM BEZPEČNĚJŠÍHO INTERNETU. Bezpečně online [online]. 2013 [cit. 2013-05-05]. Dostupné z: http://www.bezpecne-online.cz. NĚMEC, Petr. Cloud Computing a jeho aplikace. Praha, 2012. Diplomová práce. Vysoká škola ekonomická v Praze. NEWTECHARTICLES [online]. What is BitTorrent, How to create torrent file, How downloading speed is affected?. 2013 [cit. 2013-11-23]. Dostupné z: http://newtecharticles.com/what-is-bitTorrent-create-torrent-file/. ORAM, Andrew. Peer-to-peer: harnessing the benefits of a disruptive technology. 1st ed. Sebastopol, CA: O'Reilly, 2001, xv, 432 p. ISBN 05-960-0110-X.

Literatura

69

SANATI, Jennifer. Top 10 Reasons to Setup a Client-Server Network. INTEL CORPORATION. Communities.intel.com [online]. 2011 [cit. 2013-05-05]. Dostupné z: http://communities.intel.com/community/datastack/blog/2011/05/02/to p-10-reasons-to-setup-a-client-server-network. SCHOLLMEIER, Rüdiger. A Definition of Peer-to-Peer Networking for the Classification of Peer-to- Peer Architectures and Applications. Proceedings of the First International Conference on Peer-to-Peer Computing. 2002. SIBERSYSTEMS. GoodSync [online]. 2013 [cit. 2013-05-04]. Dostupné z: http://www.goodsync.com. SOSINSKY, Barrie A. Cloud Computing bible. Chichester: John Wiley [distributor], c2011, xxviii, 497 p. ISBN 04-709-0356-2. VACHTL, Pavel. Sdílení souborů na Internetu a sítě P2P. IDG CZECH REPUBLIC. PCWorld [online]. 2009 [cit. 2013-11-16]. Dostupné z: http://pcworld.cz/internet/sdileni-souboru-na-internetu-a-site-p2pzakladni-technologicky-prehled-8350. VELTE, Anthony T. Cloud Computing: praktický průvodce. Vyd. 1. Brno: Computer Press, 2011, 344 s. ISBN 978-80-251-3333-0. VLASTNISYSTEM.CZ [online]. Klient - Server. 2013 [cit. 2013-05-05]. Dostupné z: http://www.vlastnisystem.cz/supp-idea-cz/basics/general/client-serverpg.html.

70

Přílohy

Vzhled aplikace

A Vzhled aplikace

Obr. 20

Registrace do systému pomocí webového serveru.

Obr. 21

Hlavní obrazovka klientské aplikace.

71

Podpora automatizovaného multiplatformního sdílení a synchronizace souborů

Recommend Documents