Univerzita Hradec Králové Fakulta informatiky a managementu Katedra informatiky a kvantitativních metod
Použití BitTorrent protokolu pro komunikaci v nespolehlivé síti Bakalářská práce
Autor: Jiří Kolář Studijní obor: Aplikovaná informatika (Ai3)
Vedoucí práce: Ing. Pavel Kříž, Ph.D.
Hradec Králové
Srpen 2015
Prohlášení: Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a s použitím uvedené literatury.
vlastnoruční podpis V Hradci Králové dne 26.8.2015
Jiří Kolář
Poděkování: Děkuji vedoucímu bakalářské práce Ing. Pavlu Křížovi, Ph.D. za metodické vedení práce, ochotu věnovat čas a vstřícnost při konzultacích, které mi pomohli tuto práci zkompletovat.
Anotace Bakalářská práce pojednává o možnostech využití BitTorrent protokolu pro účely sdílení a rozesílání zpráv v nespolehlivé síti. Popsán je zde základní princip BitTorrent protokolu a některých jeho nadstaveb. Na tomto rozboru je poté navrhnuta implementace do stávající aplikace HKFreeMonitor. Výsledkem je rozšíření aplikace o funkcionalitu umožňující distribuci zpráv od administrátorů sítě pomocí BitTorrent protokolu a webového rozhraní pro administrátory. Řešení je popsáno, následují ukázky implementace a nakonec jsou popsány výsledky. Význam práce spočívá v usnadnění dostupnosti informací o výpadcích a opravách sítě uživatelům sítě HKFree.
Klíčová slova BitTorrent, Peer-to-Peer, počítačová síť, aplikace, sdílení informací, nespolehlivá síť, zasílání zpráv
Annotation Title:
Using
BitTorrent
Protocol
for
Communication
in
Unreliable Network The bachelor’s thesis deals with options of using the BitTorrent protocol for purposes of sending messages over the unreliable network. Basic principles and some of its extensions are described here. On the analysis, implementation for the current HKFreeMonitor application is suggested. In results there is an extension of application for distribution of messages from administrators of the network using BitTorrent protocol and web interface for administrators. Solution is described, followed by examples of implementation and in the end results are described. Purpose of the work is in simplifying the availability of information about failures and repairs of the network for users of HKFree.
Key words BitTorrent, Peer-to-Peer, computer network, application, information sharing, unreliable network, messaging
Obsah 1
Slovník pojmů .............................................................................................................................. 1
2
Úvod................................................................................................................................................. 2
3
Cíl práce.......................................................................................................................................... 3
4
Protokol BitTorrent a jeho způsoby použití .................................................................... 4 4.1
BitTorrent – Peer to Peer protokol v praxi .............................................................. 4
4.2
Magnet-link (URI)............................................................................................................... 6
4.3
DHT .......................................................................................................................................... 6
4.4
Peer-Exchange ..................................................................................................................... 7
4.5
Problémy BitTorrent protokolu ................................................................................... 7
4.5.1
NAT.................................................................................................................................. 7
4.5.2
UPnP .............................................................................................................................10
4.5.3
Port-Forwarding ......................................................................................................10
4.5.4
DMZ host .....................................................................................................................10
4.6
5
Využití BitTorrentu..........................................................................................................10
4.6.1
BitTorrent Chat.........................................................................................................11
4.6.2
BitTorrentSync .........................................................................................................12
Existující aplikace a knihovny .............................................................................................15 5.1
Vuze .......................................................................................................................................15
5.2
BitTorrentSync API ..........................................................................................................15
5.3
Ostatní...................................................................................................................................16
6
Analýza využitelnosti pro šíření zpráv v nespolehlivé síti.......................................18
7
Návrh a implementace řešení ..............................................................................................19 7.1
Java a Vuze ..........................................................................................................................19
7.2
Java a BitTorrentSync API .............................................................................................19
7.3
C# .NET a BitTorrentSync API .....................................................................................19
7.4
Použité technologie .........................................................................................................20
7.5
Implementace ....................................................................................................................21
8
7.5.1
Klientská aplikace....................................................................................................21
7.5.2
Formát distribuovaných zpráv ...........................................................................29
7.5.3
Serverová část ...........................................................................................................30
7.5.4
Řešené problémy .....................................................................................................32
Výsledky .......................................................................................................................................35 8.1
9
Testování v domácím prostředí ..................................................................................35
8.1.1
Scénář 1 – Ideální prostředí ................................................................................36
8.1.2
Scénář 2 – Ztráta připojení k serveru lab.hkfree.org .................................37
8.1.3
Scénář 3 – Ztráta připojení k serveru lab.hkfree.org – dvojitý NAT ....38
Závěry a doporučení ...............................................................................................................39
10
Seznam použité literatury .................................................................................................41
11
Přílohy .......................................................................................................................................44
Seznam obrázků Obr. 1 – Porovnání Client-Server a P2P topologie .................................................................. 4 Obr. 2 - Ukázka Swarmu .................................................................................................................... 5 Obr. 3 - BitTorrentChat ....................................................................................................................11 Obr. 4 – Příklad odpovědi od webové služby ve formátu JSON .......................................16 Obr. 5 – Podíl OS na PC (Únor 2015) ..........................................................................................16 Obr. 6 – Class diagram zobrazující rozšíření původní HKFreeMonitor aplikace ......22 Obr. 7 - Ukázka upraveného okna Nastavení aplikace. .......................................................28 Obr. 8 – Homepage webového rozhraní....................................................................................30 Obr. 9 – Ukázka zobrazení oznámení z webového rozhraní .............................................32 Obr. 10 – GUI webového rozhraní aplikace BitTorrentSync .............................................33 Obr. 11 – Schéma zapojení č. 1 – ideální prostředí ...............................................................36 Obr. 12 – Schéma zapojení č. 2 – odpojený uzel.....................................................................37 Obr. 13 – Schéma zapojení č. 3 – simulace vícenásobného NAT .....................................38
Seznam tabulek Tabulka 1 - Příklad dynamického NAT ........................................................................................ 8 Tabulka 2 - Příklad NAT Overload ................................................................................................ 9 Tabulka 3 – Parametry konfigurace BitTorrentSync API ...................................................25 Tabulka 4- Seznam zařízení použitých při testování ...........................................................35
1 Slovník pojmů Peer-to-Peer – typ architektury sítě, decentralizovaná Client-server – alternativní typ architektury sítě, centralizovaná správa BitTorrent – Peer-to-Peer protokol určený pro distribuci souborů swarm – síť uživatelů jednoho torrentu torrent – soubor obsahující informace o peerech a trackerech peer – účastník swarmu leecher – peer, který neodesílá žádná data seeder – peer, který má stažen celý soubor a dále jen odesílá data ostatním tracker – Centralizovaná služba běžící na serveru zajišťující aktuální informace o peerech prostřednictvím torrent souboru DHT (Distributed Hash Table) – Decentralizovaná nadstavba BitTorrent protokolu pro vyhledávání peerů PEX (Peer Exchange) – Nadstavba BitTorrent protokolu pro vyhledávání peerů se stejnou implementací PEX NAT (Network Adress Translation) – Soubor metod a protokolů pro přístup více uživatelů v jedné síti do Internetu pod jednou veřejnou IP adresou Choked – Peer má obsazené všechny upload kanály. Unchoked – Peer odesílá data.
1
2 Úvod Počítačové sítě se postupem času rozrostly na takovou úroveň, že už jsou vnímány jako samozřejmost. I při dnešních možnostech a rozsahu počítačových sítí, však stále může dojít k výpadku nebo plánované či neplánované odstávce části počítačové sítě. V takovém případě je často obtížné nebo nemožné dostat se k informacím o stavu sítě z centrálního zdroje. Peer-to-Peer protokoly dávají možnost vzájemné komunikace jednotlivým uživatelům sítě při nedostupnosti centrálního prvku sítě. V teoretické části této práce bude rozebrán způsob komunikace mezi jednotlivými počítači v síti, následně bude detailněji popsán protokol BitTorrent a některé jeho nadstavby zajišťující jeho robustnost. V další části teoretického oddílu práce budou nastíněny některé z nevýhod BitTorrent protokolu a jeho problémů. V závěru teoretické části budou uvedeny stávající aplikace implementující protokol BitTorrent a bude provedena analýza možnosti využití tohoto protokolu pro šíření zpráv v nespolehlivé síti. V praktické části práce bude popsán postup implementace BitTorrent protokolu do stávající aplikace HKFreeMonitor a technologie použité v praktické části práce. Vysvětlena bude důležitá funkcionalita a popsány některé zajímavé části zdrojového kódu. Krátce popsána bude implementace serverové části, jež je nutná pro správnou funkčnost aplikace HKFreeMonitor. Dále bude ukázáno prvotní nastavení serverových služeb. V závěru práce budou rozebrány problémy, které se vyskytly v průběhu implementace. V poslední části budou uvedeny výsledky dosažené implementací praktického řešení popsaného v této práci.
2
3 Cíl práce Cílem této práce je analyzovat možnosti BitTorrent protokolu a některých jeho nadstaveb a rozšíření, existujících aplikací a knihoven pro šíření zpráv v nespolehlivé síti. Praktickou části je navržení řešení pro hromadné zasílání informací uživatelům (nespolehlivé) počítačové sítě HKFree. Implementování tohoto řešení do aplikace, která bude poskytovat zprávy šířené od administrátorů, i po možném výpadku určité části sítě. Dále vytvoření jednoduchého webového rozhraní pro službu běžící na serveru HKFree, přes které administrátoři sítě budou moci vkládat a upravovat jednotlivá oznámení a zprávy. Na závěr budou uvedeny výsledky dosažené při vypracovávání této práce a zhodnocení, zda BitTorrent protokol byl vhodný pro řešení daného problému.
3
4 Protokol BitTorrent a jeho způsoby použití Počítačové sítě je možné rozdělit do dvou hlavních typů z hlediska hierarchie koncových prvků v síti a to na client-server a Peer-to-Peer. Ty se liší v několika aspektech, které budou v následující kapitole stručně naznačeny.
4.1 BitTorrent – Peer to Peer protokol v praxi Client – Server Nejrozšířenější typ architektury počítačových sítí, kde obvykle jeden počítač funguje jako server, který pasivně naslouchá požadavkům ostatních - klientů. Na serveru zpravidla běží nějaká služba, která obstarává výpočetní logiku (např. webový server). To s sebou přináší také pár nevýhod, jednou z nich je přetěžování sítě, kdy při velkém počtu požadavků od klientů dochází ke zpomalení nebo úplnému výpadku služeb. To je druhá hlavní nevýhoda, jelikož většina nebo i celá výpočetní logika je zpracovávána na serveru.
Peer-to-peer Na rozdíl od client-server architektury u Peer-to-Peer (díle jen P2P) není žádný nadřazený centrální prvek, který by zajišťoval správu jednotlivých počítačů nebo výpočetní logiku. Rapidně se tak snižuje šance výskytu pádů celé sítě nebo nedostupnosti služeb. S růstem počítačů v síti také roste šířka pásma sítě.
Obr. 1 – Porovnání Client-Server a P2P topologie Zdroj: autor
4
BitTorrent protokol funguje na principu P2P sítě. Nejrozšířenější verzí jakékoliv implementace BitTorrent protokolu [1] je stále použití trackeru, služby běžící na serveru, která zprostředkovává informace o adresách peerů. Peer (Uživatel připojený do sítě) obdrží torrent soubor (například z klasického http serveru), obsahující IP adresy peerů momentálně sdílejícím daný soubor a informace o souborech, které se budou sdílet. Takovéto síti uživatelů se říká swarm [2]. Ve swarmu se nacházejí všichni peeři. Ti, kteří vlastní kompletní sdílený soubor se nazývají seedeři, uživatelé, kteří ještě nemají stahovaný soubor kompletní, se nazývají peeři. Peer, který dále neposkytuje již stažená data ostatním, se nazývá Leecher.
Obr. 2 - Ukázka Swarmu Zdroj: (převzato a upraveno autorem z: http://newtecharticles.com/what-is-bittorrent-createtorrent-file/)
Z obrázku č. 1 by se mohlo zdát, že jednotliví peeři stahují sdílené soubory z trackeru, není tomu tak. Peeři pouze v určitých intervalech požádají tracker o seznam ostatních peerů. Při výpadku trackeru, však další komunikace mezi peery nebude možná. Takto vypadá komunikace pomocí BitTorrent protokolu stále nejčastěji. Jedná se o centralizovanou strukturu, což znamená, že všechny informace o peerech zajišťuje tracker. Avšak s postupem času bylo na snaze, nalézt řešení, které by nebylo tolik závislé na využití trackeru. 5
Sdílení souborů vypadá jinak než u běžného stahování například z FTP serveru. V první řadě je šířka použitého pásma rozdělena mezi všechny peery. Datový tok mezi peery a trackerem je zanedbatelný v porovnání s běžným stahováním souboru ze serveru. BitTorrent rozdělí sdílený soubor na malé kousky (pieces) běžně o velikostech 32-512 KB [3]. BitTorrent má naimplementovanou metodu tzv. Rarestfirst (nejvzácnější co nejdříve) [4] peer si zajistí, který piece souboru je nejméně dostupný a tím začne, zvyšuje se tak dostupnost jednotlivých kousků. Výjimka nastává, pokud peer nemá žádný kousek souboru (typicky při začátku stahování), poté je první kousek vybrán náhodně (Random First Piece), aby bylo možné je co nejdříve dále sdílet data ostatním. BitTorrent má dva druhy spojení tzv. choked a unchoked. Choked znamená, že peer neodesílá žádná data, protože má obsazeny všechny odesílací sloty, ty jsou defaultně nastaveny 4.
4.2 Magnet-link (URI) Na rozdíl od .torrent souborů, které obsahují meta-data o sdílených souborech a adresy trackerů, Magnet-URI je odkaz identifikující sdílené soubory ne podle umístění, ale podle obsahu, lépe řečeno hash řetězci obsahu. Magnet URI má několik parametrů. Jelikož obliba Magnet-linků stále roste, mnoho BitTorrent klientů tento standart již podporuje. Díky magnet-linku odpadá potřeba .torrent souboru.
4.3 DHT Distributed-hash-table (dále jen DHT) [5] je nadstavbou BitTorrent protokolu, jednotliví peeři se nemusí spoléhat pouze na tracker, který jim poskytne informace o ostatních peerech ve swarmu, ale sdílí DHT mezi sebou. Každý uzel se nazývá „node“. Jedná se o decentralizované řešení, při výpadku jednoho node DHT pracuje dále a umožňuje vyměňovat informace o případných nových připojeních. Pro připojení do DHT je zapotřebí znát IP adresu alespoň jednoho node, ve většině případu se používá tzv. Bootstrap node. DHT je vlastně síť spolupracujících peerů, klient se ptá sousedů (peeru), jestli neznají IP adresu cíle, který potřebuje. Pokud soused adresu nezná, klient se ptá jejich dalších sousedů, tak dlouho dokud
6
nenarazí na požadovanou IP adresu, tomuto peerovi je pak předána i adresa klienta, který jí vyhledával Nejnovější implementace DHT je díky šifrované komunikaci velmi bezpečná [6]. Detailně popsané funkce a principy DHT popisuje například Gummadi [5].
4.4 Peer-Exchange Další decentralizovanou nadstavbou BitTorrent protokolu je Peer-Exchange (PEX). V současnosti jsou nejrozšířenější tři implementace PEX protokolu, které nejsou vzájemně kompatibilní. Nevýhodou PEX je, že nemůže fungovat samostatně, ke své správné funkčnosti vyžaduje funkční tracker nebo DHT. Podle [7] je však implementací PEX možno dosáhnout až 7% zkrácení doby stažení souboru. Nejrozšířenější implementací PEX je UT_PEX, který je naimplementován na zhruba 70 % BitTorrentových klientů [7]. Další verze jsou AZ_PEX a BC_PEX, ty dohromady zahrnují zbývajících 30 %.
4.5 Problémy BitTorrent protokolu Jednou z největších nevýhod komunikace pomocí BitTorrent prokolu obecně je nedostatek veřejných peerů, disponujících veřejnou IP adresou. Velká většina uživatelů (až 66 % dle [8]) používající nějakou implementaci BitTorrentu se nachází v sítí za routerem, který používá NAT (Network-address-translation). Problém se dále stupňuje díky tomu, že BitTorrent protokol má tendenci vyhledávat snadno dostupné peery, tedy ty kteří mají například veřejnou IP adresu.
4.5.1 NAT Z důvodu nedostatku veřejných IPv4 adres byla původně dočasně zavedena metoda Network-Adress-Translation (NAT) [3], neboli překlad síťových adres, umožňující velkému počtu zařízení v privátních sítích přistupovat do Internetu pod jednou veřejnou IP adresou. Prakticky tak ISP (Internet Service Provider) může zajistit stovkám uživatelů přístup k Internetu, všichni avšak vystupují pod stejnou veřejnou IP adresou. Pokud uživatel „schovaný“ za NAT odesílá požadavky na veřejné servery (například webový server) připojené do Internetu s veřejnou IP
7
adresou nepozná rozdíl, problém nastává ve chvíli, kdy se někdo z Internetu pokusí vytvořit příchozí připojení, počítače za NAT nevidí. Z hlediska principu existuje více možných typů NAT, zde budou uvedeny 3 typy NAT.
Statický NAT Neboli překlad 1:1 využívá jedné veřejné IP adresy k překladu na jednu privátní adresu. Díky tomu je možné například provozovat webový server s privátní adresou např. 192.168.1.254 tak, aby byl stále přístupný z internetu pod veřejnou adresou.
Dynamický NAT Na rozdíl od statického NATu má dynamický k dispozici několik veřejných IP adres. Pokud host v síti chce přistoupit na Internet, zařízení spravující NAT (typicky router) namapuje do NAT tabulky privátní adresu hosta a k ní volnou veřejnou IP adresu z rozsahu. Pokud ve stejnou chvíli přistupuje na Internet druhý host, router přiřadí další volnou IP adresu. Pro lepší ilustraci bude uveden příklad v následující tabulce.
Přidělený rozsah veřejných IP adres: 77.78.89.1 – 77.78.89.7
Adresní prostor privátní LAN sítě – 192.168.1.0/24
Cílový server – google.cz – 173.194.122.15
Inside local
Inside global
Outside local
Zdrojová IP uvnitř NAT Zdrojová IP vně NAT Cílová IP uvnitř NAT
Outside global Cílová IP vně NAT
192.168.1.100
77.78.89.1
173.194.122.15
173.194.122.15
192.168.1.101
77.78.89.2
173.194.122.15
173.194.122.15
192.168.1.102
77.78.89.3
173.194.122.15
173.194.122.15
Tabulka 1 - Příklad dynamického NAT Zdroj: Autor
NAT Overload Někdy také zvaný NAPT (Network-adress-port-translation) nebo PAT (Portadress-translation). NAT Overload je nejčastějším typem NAT použitým na 8
routerech v domácích sítích. Od předchozích dvou typů se liší především tím, že veškerou komunikaci z LAN sítě překládá na jednu adresu viditelnou zvenčí (ať už veřejnou nebo privátní v případě více routerů za sebou). Aby však současně mohlo komunikovat s vnějším prostředím (např. Internetem) více počítačů z LAN sítě najednou, je potřeba namapovat odchozí port ke zdrojové IP adrese. Router zjistí, zda je odchozí zdrojový port na vnější straně NAT volný a napamuje ho na zdrojový port vnitřní straně NAT. Pokud je již tento port obsazený zvolí router pro odchozí spojení jiný dostupný port. Příklad bude opět uveden v tabulce.
Přidělená veřejná IP adresa: 77.78.89.96
Adresní prostor privátní LAN sítě – 192.168.1.0/24
Cílový server – google.cz – 173.194.122.15
Inside local
Inside global
Zdrojová IP uvnitř NAT Zdrojová IP vně NAT
Outside local
Outside global
Cílová IP uvnitř NAT
Cílová IP vně NAT
192.168.1.10:51111
77.78.89.96:51111
89.248.240.42:443
89.248.240.42:443
192.168.1.11:51111
77.78.89.96:51112
89.248.240.42:443
89.248.240.42:443
192.168.1.12:12111
77.78.89.96:12111
89.248.240.42:23
89.248.240.42:23
Tabulka 2 - Příklad NAT Overload Zdroj: Autor
Největším nedostatkem NAT je počet jeho implementaci, jelikož NAT sám o sobě není standardizován. V současné době existuje mnoho řešení zajištující průchod přes NAT. Jmenovitě například UPnP, dále pak protokol NAT-PMP (NAT Port Mapping Protocol) od společnosti Apple, STUN (Session Traversal Utillities for NAT), nebo Port-Forwarding, který v dnešní době podporují snad již všechny domácí routery. Další druhy P2P komunikace týkající se NAT jsou popsány v [9]. Obecně všechny P2P aplikace mají problémy s NAT, v současné době se výrobci routerů snaží implementovat lépe prostupný NAT zejména kvůli VoIP (Voice Over IP) [9]. BitTorrentChat implicitně podporuje protokoly NATPMP a UPnP [6].
9
4.5.2 UPnP Universal Plug And Play je široce implementovaná sada síťových protokolů, kterou podporuje velká většina domácích routerů a modemů. Díky UPnP dokáže router automaticky přesměrovat porty, na kterých pracuje komunikace automaticky. Bohužel toto řešení nefunguje ve 100 % případů.
4.5.3 Port-Forwarding Port-Forwarding (Přesměrování portů) je pokročilejší metoda, díky níž je možné zbavit se problémů týkajících se NAT. Nevýhodou je nutnost manuálně nastavit (tzv. otevřít) porty v konfiguraci routeru používané BitTorrent aplikací pro zvolenou IP adresu hosta v místní síti. Správně nastavená síť však musí být po celé délce mezi Peery, a tak pokud je chyba na straně ISP, ani toto řešení není dokonalé. Statický Port-Forwarding zajišťuje otevření portu pouze pro jednu IP v hosta nacházející se za NAT, není tak možné provozovat stejné aplikace na různých PC naslouchající na stejném portu.
4.5.4 DMZ host Na většině domácích routerů lze povolit funkci DMZ hosta (z angl. Demilitarized zone), na rozdíl od opravdové DMZ však neodděluje hosta od zbytku LAN sítě. Po zvolení IP adresy hosta dojde k otevření všech portů a přesměrování na zvolenou IP. Výhodou je otevření více portů najednou, nemusíme tedy znát přesné číslo nebo rozsah TCP/UDP portů. Nevýhodou je naopak nutnost statické IP adresy, přicházíme tím tak o komfort přidělení adres k danému PC pomocí DHCP, výjimkou je rezervace IP adresy přidělené DHCP serverem pomocí MAC adresy PC. Další nevýhodou je potencionální bezpečnostní riziko v důsledku otevření všech příchozích portů.
4.6 Využití BitTorrentu Použití BitTorrent protokolu pro distribuci a sdílení souborů je stále nejrozšířenější možností jeho využití. Distribuují se tak například některé verze
10
operačního systému Linux1. Aktualizace pro MMO hry (např. League of Legends2, hry společnosti Wargaming3 a další), zvláště aby bylo ulehčeno vlastním serverům a šířce pásma připojení. Mnoho menších společností by si bez pomoci BitTorrentu nebyla
schopna
dovolit
spolehlivě
distribuovat
svůj
obsah
z výše
zmíněných důvodu. Ve velkém se BitTorrentu zneužívá pro Warez [10]. Mezi nejznámější tracker patří například ThePirateBay4. V současnosti však společnosti BitTorrent, Inc. [1] vyvíjí další použití BitTorrent protokolu v aplikacích jako je BitTorrentChat a BitTorrentSync.
4.6.1 BitTorrent Chat Prvním zmíněným použitím protokolu BitTorrent je služba BitTorrentChat. Na rozdíl od chat služeb jako je ICQ 5 nebo Skype 6 , BitTorrentChat nepracuje s uživatelskými jmény a uživatel se nemusí ani nikam přihlašovat, protože chat není spuštěný na žádném serveru. Každý uživatel vystupuje ve formě klíče, znamená to, že každý muže BitTorrentChat používat anonymně, bez sdělování svých osobních informací. Jediná cesta ke komunikaci je skrze výměnu veřejných klíčů.
Obr. 3 - BitTorrentChat Zdroj: převzato z (http://engineering.bittorrent.com/2013/12/19/update-on-bittorrent-chat/)
http://www.linux.cz/ http://eune.leagueoflegends.com/en 3 http://eu.wargaming.net/ 4 http://thepiratebay.se/ 5 http://www.icq.com/ 6 http://www.skype.com/ 1 2
11
4.6.2 BitTorrentSync BitTorrentSync je formou úložiště jakým je například OneDrive7 nebo DropBox8, které však funguje na úplně odlišném principu. Zatímco u výše zmíněných alternativ se data ukládají na externí server a v případě potřeby se opět stahují do klientského zařízení u BitTorrentSync se nachází pouze na zařízeních (klientech), které si uživatel zvolí. Informace o adresářích jsou v šifrované podobě přeneseny na tracker, aby se k nim další uživatel dokázal připojit. Přenosy jsou šifrované a data uživatel poskytuje jen tomu, komu opravdu chce. Jak výhody, tak nevýhody vychází z podstaty BitTorrent protokolu. Přenos je šifrovaný (AES-128) za použití unikátního session klíče o délce 33 bytů. Šance na zneužití klíče nebo snad jeho prolomení, je tak rovna téměř nule. Na druhou stranu pro dosáhnutí co nejvyšších možných rychlostí je dobré sdílet na co nejvíce zařízení. BitTorrentSync se stále velmi aktivně vyvíjí (aktuální verze 2.0 ke dni 8. 3. 2015), a tak je zde možné nalézt podporu DHT, vyhledávání v místní síti LAN nebo přenos skrze relay server právě pro případy, kdy nelze dosáhnout přímého spojení dvou peerů. Je velice pravděpodobné, že v budoucnu bude do profesionálních business a enterprise verzí aplikace přidána podpora vlastní instance trackeru a relay serveru, čímž bude zajištěno případné kompletní oddělení od internetu [11]. Synchronizace dat (ve verzi 1.4) je dostupná jak s úplnými právy, tak s právy pouze pro čtení. Zařízení, které chce získat přístup ke sdíleným datům, potřebuje znát „secret“ (klíč), řetězec o délce 33 znaků. Ke každému sdílenému adresáři jsou dostupné 2 klíče, pomocí jednoho (pouze pro čtení) se data sdílejí do dalšího zařízení, ale už ne nazpět. Druhý klíč zajišťuje plný přístup, změněná data jsou opět synchronizována s ostatními peery připojenými pomocí stejného klíče [12].
7 8
https://onedrive.live.com/about/cs-cz/ https://www.dropbox.com/
12
DHT implementované v BitTorrentSync aplikaci je sdílené napříč všemi peery nezávisle na adresáři, který sdílejí. Jedná se tak o jednu rozsáhlou síť, konkrétně se jedná o Kademlia DHT, kterou detailně popisuje Maymounkov a Mazières [13]. DHT může současně být použito na milionech PC, není proto možné na každém uzlu DHT ukládat seznam a informace o všech ostatních uzlech. Jednak z důvodu velikosti a zadruhé by bylo nutné tento seznam aktualizovat při každém připojení či odpojení uzlu DHT. Každý uzel DHT je označen unikátním nodeID o délce 160bitů. Routovací tabulka DHT sítě se nazývá „k-bucket“. Každý k-bucket je seznam uzlů o maximálně k vstupech. Uzly Kademlia DHT mohou mezi sebou zasílat čtyři druhy zpráv:
PING – Ověření, zda je uzel stále aktivní.
FIND_NODE – Příjemce zprávy vrátí uzly ve svém bucketu, které jsou nejblíže požadovanému klíči.
FIND_VALUE – Příjemnce zprávy vrátí odpovídající hodnotu z dvojice klíč:hodnota
STORE – Uloží dvojici klíč:hodnota pro daný uzel do souboru sync.dat
Každá zpráva, kterou uzel posílá, zahrnuje mimo vlastního ID také nodeID jako identifikátor. Důležité je poznamenat, aby byl uzel označen jako aktivní, musí se periodicky každých X minut ohlásit v DHT, popř. trackeru (typicky v rozsahu 10-60 minut, záleží však na konfiguraci). Je však možné identifikovat peery, kteří byli již dříve kontaktováni ze souboru sync.log [11]. Konfigurační soubory jsou uloženy v adresáři vybraným v průběhu instalace. Jedná se zvláště o soubory settings.dat, sync.log, sync.pid, sync.dat a další. Soubory .dat obsahují slovníky a seznamy informací o jednotlvých souborech sdílených pomoctí BitTorrent protokolu. Tyto soubory jsou uloženy pomoci tzv. „bencoded“ metody. Jedná se o rozšíření binární metody zápisu dat nezávislé na platformě, lze ho tak přirovnat k formátu JSON a XML. Informace uložené v souboru jsou zapsány
13
v následujících dvojicích Klíč:Hodnota (angl. Key:Value). Princip zápisu je popsán Toolem [14]. BitTorrentSync je dostupný volně ke stažení, free verze je omezena hlavně počtem sdílených adresářů, těch může být v jednu chvíli sdíleno pouze 10 (vygenerováno je tak 10 různých klíčů pro úplný přistup a 10 pro přístup pouze pro čtení). Obsah sdíleného adresáře pak může obsahovat libovolný počet souborů a adresářů. Dostupná je však i placená verze, která umožňuje neomezený počet sdílených adresářů, změnu přístupových práv pro jednotlivé peery za chodu a přístup k souborům na vyžádání. BitTorrentSync (ve verzi 2.1.X) je k dispozici pro velkou řadu platforem a operačních systémů. Desktopové operační systémy na PC zastupuje Windows, Linux a OS X. Z mobilních operačních systémů je to klasická trojice Android, iOS, Windows Phone a navíc i FireOS. V poslední řadě je aplikace dostupná i pro NAS zařízení renomovaných výrobců jako jsou Western Digital, Seagate, Netgear aj.
14
5 Existující aplikace a knihovny Kromě výše zmíněných dvou příkladů, existuje poměrně mnoho aplikací implementující BitTorrent protokol, z velké časti se však jedná pouze o klienty pro stahování souborů (nejčastěji warezu). Většina těchto aplikací je napsaná v jazyce C++ a jedná se o aplikace bez veřejně dostupných zdrojových kódů.
5.1 Vuze BitTorrentový
program,
dříve
známý
pod
jménem
Azureus.
Vuze
9
je
naprogramovaný v jazace Java, a díky tomu multiplatformní. Je velice rozšířený mezi uživateli zvláště díky neustálému vývoji. Díky množství plug-inů a modifikací lze přidávat další funkcionalitu, jmenovitě například různé implementace DHT nebo chat skrze BitTorrent protokol. Další nespornou výhodou jsou volně dostupné zdrojové kódy, kde jádro aplikace je možno použít v rámci GPL (General Public Licence). Kromě základní funkcionality jako je přidávání .torrent souborů, podpora magnet-linků, DHT, obsahuje Vuze také množství nástrojů pro statistiku připojení a aktivity aplikace.
5.2 BitTorrentSync API API aplikace BitTorrentSync pro vývojáře bylo zpřístupněno relativně nedávno (5. 11. 2013). API je přístupné pomocí speciálního konfiguračního souboru, který mimo jiné obsahuje umístění, kam si BitTorrentSync aplikace ukládá všechna potřebná data. Boolean hodnotu pro skrytí uživatelského rozhraní aplikace BitTorrentSync a dále pak IP adresu a port, přes kterou je dostupná webová služba API odpovídající na požadavky aplikace. Dále je nutný klíč, od společnosti BitTorrent, který zaručuje vlastní přístup k API. Volitelně je zde možnost konfigurace
přihlašovacích
údajů
pro
webovou
službu.
Díky
oddělení
konfiguračních dat od standardní aplikace BitTorrentSync je možné provozovat jak samotnou aplikaci BitTorrentSync tak aplikace implementující BitTorrentSync API zároveň a nezávisle na sobě.
9
http://www.vuze.com/
15
API není přístupné jako klasická knihovna, Jednotlivé metody jsou volány ve formě http dotazů na lokální službu (IP adresa a port nastavený v konfiguračním souboru). Všechny metody API vracejí řetězec znaků ve formátu JSON.
Obr. 4 – Příklad odpovědi od webové služby ve formátu JSON Zdroj: Autor
V současné verzi pro Windows je podporován pouze systém Windows 7 a vyšší (32 i 64bitová verze). Podle průzkumu [15] však více jak 2/3 uživatelů OS Windows 7 či novější používá, a tak by tento fakt neměl být příliš limitující.
Obr. 5 – Podíl OS na PC (Únor 2015) Zdroj: (převzato z: http://www.netmarketshare.com/operating-system-market-share.aspx?)
5.3 Ostatní Z ostatních BitTorrent aplikací a klientů pro stahování je vhodné zmínit například µTorrent10, který je populární pro svoji jednoduchost a funkcionalitu. Dostupný je však pouze pro Windows a MacOS. Dalšími podobnými klienty jsou například
10
http://www.utorrent.com/
16
BitComet11, který je dostupný pouze pro Windows, naproti tomu ale obsahuje možnost stahování z HTTP nebo FTP serverů. Posledním zmíněným je qBittorrent12, který je na rozdíl od ostatních dostupný kromě Windows a MacOS i na Linux, ale také BSD a mobilní operační systémy Android a iOS. V programu je také zaimplementován plně funkční tracker. Samozřejmě se nejedná o všechny aplikace, těch je celkem velké množství, některé však postrádají kompatibilitu s novějšími funkcemi. Mimo hotových bittorrentových aplikací a vlastních implementačních řešení existuje také libtorrent13, což je open-source knihovna napsaná v jazyce C++ implementující BitTorrent protokol. Klade malé nároky na CPU a paměť a je implementován v řadě aplikací, například i výše zmíněném qBittorrent.
http://www.bitcomet.com/ http://www.qbittorrent.org/ 13 http://libtorrent.org/ 11 12
17
6 Analýza využitelnosti pro šíření zpráv v nespolehlivé síti Šíření zpráv je možné dvojím způsobem. První možností je zřízení služby na serveru, který by v případě potřeby odpovídal na požadavky jednotlivých klientů z části sítě. Například ve formě webového obsahu ze serveru zobrazovaným v aplikaci. Druhým způsobem je systematické a pravidelné zasílání informačních zpráv, do jednotlivých klientů ve formě jakéhosi updatu. Problém nastává v případě výpadku serveru anebo selhání konektivity od klienta k serveru. V obou případech klient není schopen obdržet jakoukoliv zprávu. Nasnadě je tedy redundance zdrojů zpráv. Náhradním zdrojem zpráv se za použití správného protokolu mohou stát sami klienti. Nejprve zde bude nastíněno stručné uvedení do problému. Program, potažmo funkcionalita by měla být nasazena na komunitní síti HKFree na území Hradce Králové. Snaha je umožnit uživatelům sítě snadný přistup k aktuálním informacím o stabilitě sítě, plánovaným výpadkům v důsledku údržby nebo selhání části sítě. Například pokud bude ohlášen výpadek části sítě, uživatel obdrží zprávu v aplikaci o plánované nedostupnosti služeb. Problém však může nastat v případě, kdy klient neobdržel informaci (zprávu) v době, kdy síť ještě fungovala, a komunikace se serverem již není možná. Při použití BitTorrent protokolu (za předpokladu, že nejsme zcela závislí na trackeru) se pravděpodobnost, že by se klient ocitl v odříznuté části sítě osamocen, rapidně snižuje. Ve většině případů tak vždy bude dostupný jiný klient (ideálně více), který poskytne zdroj aktuálních zpráv, které byly naposledy obdrženy ze serveru, namísto serveru. Nevýhodou tohoto řešení je množství zařízení nacházející se za NAT. Tento počet je dále umocněn množstvím zařízení, které jsou používány uživateli sítě a jejich různou konfigurací pro tzv. „penetraci NAT“. V závislosti na okolnostech je tak možné, že dva klienti v různých částech sítě nedokážou navázat přímé spojení.
18
7 Návrh a implementace řešení Klientská aplikace využívající protokolu BitTorrent pro zobrazení zpráv od administrátorů sítě, které budou dostupné v rámci možností i při výpadku časti sítě a vytvoření slepého uzlu. Dále poté možnost jednotlivým uživatelům umožnit komunikovat mezi sebou prostřednictvím privátního či skupinového chatu.
7.1 Java a Vuze Z počátku rešerše dostupných BitTorrentových možností se nejlépe jevila možnost implementace některých knihoven aplikace Vuze, jehož zdrojové kódy je možno použít. Z dalšího průzkumu se však ukázalo toto řešení jako zbytečně složité a v průběhu
zkoumání knihoven
Vuze
byl
získán
přístup
k API
aplikace
BitTorrentSync, který pomocí 17 metod (verze 1.4) umožňuje všechnu potřebnou funkcionalitu BitTorrent protokolu pro použití v aplikaci.
7.2 Java a BitTorrentSync API Původní myšlenkou bylo implementování BitTorrentSync API do samostatné Java aplikace, posléze však bylo upuštěno od výhody v podobě multi-platformní aplikace, pro lepší kompatibilitu s OS Windows, který bude v síti převažovat. Pro uživatele aplikace tak odpadá nutnost nainstalovaného prostředí Java Runtime Environment, které na rozdíl od Frameworku .NET není součástí OS Windows.
7.3 C# .NET a BitTorrentSync API Nakonec bylo rozhodnuto o implementaci BitTorrentSync API do stávající aplikace HKFreeMonitor naprogramované v jazyce C#, které tak bude rozšiřovat funkcionalitu. Zároveň je na serveru hkfree.org spuštěna služba BitTorrentSync, ze které jsou rozesílány prvotní zprávy s oznámením. Prostřednictvím webového rozhraní je možné po přihlášení přistupovat k formuláři pro vytváření a editaci zpráv rozesílaných pomocí BitTorrentSync. Do tohoto kanálu je možné vytvářet zprávy pouze ověřenými administrátory, které mohou sloužit jako zdroj informací o stavu sítě, plánovaných odstávkách, ale i neplánovaným kolapsům části sítě. Druhý kanál slouží jako veřejný chat, do kterého je možno odesílat zprávy i
19
z desktopové aplikace HKFreeMonitor bez nutnosti přihlášení, uživatelé sítě tak mohou komunikovat i mezi sebou.
7.4 Použité technologie Následující technologie byly použity při vypracování návrhu a rozšíření aplikace HKFreeMonitor a webového rozhraní pro administrátory, běžící na serveru HKFree. C# Objektově orientovaný programovací jazyk odvozený od jazyka C a velmi podobný jazyku Java, vyvinutý společností Microsoft pro vývoj .NET aplikací. .NET Framework 4.0 Softwarový framework vyvinutý společností Microsoft, běžící primárně na platformě Microsoft Windows. Zahrnuje velké množství knihoven pro vývoj desktopových aplikací pro OS Windows. Aplikace je vyvinuta na verzi .NET 4.0. BitTorrentSync API v1.4.110 Rozhraní aplikace BitTorrentSync pro programování umožňující snadný přistup k metodám implementujícím protokol BitTorrent pro sdílení souborů. Přístup k metodám API je řešen pomocí http dotazů. HKFreeMonitor 2.0 Diplomová práce studenta UHK Martina Kašpara. Zdrojové kódy aplikace byly poskytnuty vedoucím práce. V původní podobě instalátor pro OS Windows vyžadující nainstalovaný .NET 3.5. Aplikace umožňuje monitoring sítě, zasílání zpráv pomocí TCP protokolu a testování konektivity v rámci internetu a sítě HKFree. Tato aplikace slouží jako základ pro rozšíření implementující BitTorrentSync API. PHP 5.X Skriptovací programovací jazyk použitý pro vytvoření webového rozhraní k aplikaci. 20
Nette Framework 2.4.1 Velmi rozšířený a oblíbený framework pro PHP od Davida Grudla, poskytující mnoho rozšíření pro PHP usnadňující vývoj a zabezpečení webových aplikací. JSON JavaScript Object Notation - Způsob zápisu dat určených pro přenos, který je nezávislý na platformě. Umožňuje organizaci dat do polí nebo agregaci v objektech. Inno Setup 5.5.6 Freeware vývojové prostření pro vytváření instalátorů pro operační systémy Microsoft Windows. Vytváření instalačního souboru je jednoduché, konfigurace instalátoru se provádí pomocí skriptů v jazyce Pascal.
7.5 Implementace V této práci nebudou popsány veškeré úpravy kódu aplikace HKFreeMonitor. Všechny zdrojové kódy aplikace, serverové části a instalátoru, budou přiloženy na CD. Rozdíl oproti implementaci v jazyce Java je minimální, odpadá však nutnost nainstalovaného Java Runtime Environment (JRE). Oproti původní verzi HKFreeMonitor vyžaduje framework .NET verze 4.0, ta je však součástí systému Microsoft Windows 7, jež je vyžadován pro spuštění aplikace i BitTorrentSync API. Původní návrh počítal s vlastním kanálem, pro jednotlivé administrátory, sdílen by tak byl počet složek odpovídající počtu administrátorů s přístupem k rozhraní na serveru. Od tohoto návrhu bylo po domluvě s vedoucím práce odstoupeno. V současné implementaci jsou tak sdíleny dva adresáře obsahující zprávy s oznámením a zprávy z chatu.
7.5.1 Klientská aplikace Úpravy aplikace proběhly tak, aby byl zachován původní návrh aplikace a nebyl příliš změněn grafický vzhled aplikace. Došlo k úpravám všech oken aplikace, aby
21
nedocházelo k rozsypání designu jednotlivých oken, Do klientské aplikace byly přidány formuláře, které jsou zobrazovány v samostatných oknech pro přístup ke zprávám.
Obr. 6 – Class diagram zobrazující rozšíření původní HKFreeMonitor aplikace Zdroj: Autor
Na obrázku č. 6 je zobrazen diagram tříd, které byly implementovány do původní aplikace. Tyto třídy zajišťují komunikaci s BitTorrentSync API, načítání souborů se zprávami a vytváření nových souborů do adresáře s chatem. Do hlavní třídy s programem Program.cs byla přidána metoda InitializeBt(). Tato metoda má na starost správné spuštění procesu BitTorrentSync.
22
//start BTS.exe with parameter String args = "/config " + Application.StartupPath + "\\BTSync\\config.api"; System.Diagnostics.Process.Start(Application.StartupPath +"\\BTSync\\BTS.exe", args);
Konfigurační soubor config.api je generován při prvním spuštění aplikace (a vždy pokud není nalezen) a obsahuje parametry potřebné pro spuštění BitTorrentSync pomocí aplikace HKFreeMonitor. Níže je znázorněn zdrojový kód. public void CreateConfig() { string path = Application.StartupPath + "\\BTSync\\config.api"; string json = JsonConvert.SerializeObject(this); json = json.Replace("\"false\"", "false"); try { // Delete the file if it exists. if (File.Exists(path)) { File.Delete(path); } // Create the config.api file. using (FileStream fs = File.Create(path)) { Byte[] info = new UTF8Encoding(true).GetBytes(json); fs.Write(info, 0, info.Length); //write into file fs.Close(); //close file } } catch (Exception ex) { Console.WriteLine(ex.ToString()); } }
Dále je metodou obstaráno stažení souboru keys.ini, stažena je vždy (za předpokladu, že je klient připojen k internetu) ze serveru nejnovější verze souboru. Obsah souboru je poté porovnán se starší verzí (pokud se nejedná o první spuštění aplikace). V případě neshodě klíčů (secret aplikace BitTorrentSync) dojde k zavolání metody pro odebrání starých složek z aplikace BitTorrent. /// <summary> /// Removes folder from Sync while leaving actual folder and files on disk. /// It will remove a folder from the Sync list of folders and does not touch any files or folders on disk. /// Returns '0' if no error, '1' if there’s no folder with specified secret. /// public void RemoveFolder(String secret) { Call(_reqAddress + "/api?method=remove_folder&secret="+ secret); Console.WriteLine(_reqAddress + "/api?method=remove_folder&secret=" + secret); }
23
Důvodem je implementace free verze BitTorrentSync API, to dovoluje sdílení pouze 10 ti různých adresářů současně. V případě časté změny obsahu keys.ini by tak došlo vyčerpání volných adresářů a případné nefunkčnosti sdílení zpráv. Přidání vytvořených složek do BitTorrentSync. Adresáře jsou vytvářeny v adresáři BTUpdates v instalačním adresáři aplikace a jsou pojmenovány dle klíčů v souboru keys.ini.
7.5.1.1 SyncApi Třída SyncApi (viz příloha 1) má na starosti veškerou komunikaci s API programu BitTorrentSync. Jak již bylo uvedeno, přístup k metodám BitTorrentSync API 1.4 je zajištěn pomocí http dotazů na webovou službu. Ta je v případě HKFreeMonitor spuštěna na adrese 127.0.0.1 a naslouchá na síťovém portu 8888. V následující tabulce jsou uvedeny parametry nastavení BitTorrentSync API pro aplikaci HKFreeMonitor. Parametr
config_refresh_interval device_name disk_low_priority external_port folder_defaults.delete_to_trash sync_trash_ttl
Hodnota
3600 HKFreeApp
True 0
Popis Interval ukládání interní konfigurace BitTorrentSync aplikace Jméno zařízení (Aplikace HKFreeMonitor) Operace disku čteni a zápis mají nízkou prioritu Odchozi port aplikace BitTorrentSync
True 30
folder_defaults.use_lan_broadcast
True
folder_defaults.use_dht
true
folder_defaults.use_relay
True
folder_defaults.use_tracker
True
24
Archivuje smazané soubory ze sdíleného adresáře Doba (dny) po kterou jsou sobory archivovány Vyhledávání peeru v místní LAN síti Použítí DHT – zvyšuje šanci nalezení peerů Použití relay serveru – zajišťuje nepřímou komunikaci mezi peery. Použití Trackeru – zvyšuje šanci
nalezení peerů
folder_rescan_interval
600
lan_encrypt_data
True
lang
-1
listening_port
0
log_size
Interval (s) automatického scanování adresáře Šifrování dat v LAN síti Jazyk webui – není nastaven. Příchozí port aplikace BitTorrentSync – 0 znamená náhodně zvolený port
100
Maximálni velikost log souboru (MB) Maximálni velikost dat souboru, která
max_file_size_for_patching
1000
bude aktualizována, při překročení je soubor stažen celý znovu
max_file_size_for_versioning peer_expiration_days folder_defaults.known_hosts profiler_enabled
1000 14
Maximální velikost souboru v uloženého v archivu Počet dní, po uplynutí je peer odebrán ze seznamu
89.248.24 Seznam předdefinovaných peerů. IP 0.42 False
recv_buf_size
10
send_buf_size
10
adresa lab.hkfree.org Použití testovacích souborů pro potřeby analýzy Velikost paměti (MB) alokované pro příchozí data Velikost paměti (MB) alokované pro odchozí data Maximální časový posun mezi
sync_max_time_diff
3600
jednotlivými peery – nastavena 1hodina.
download_limit
0
Omezení rychlosti downloadu
upload_limit
0
Omezení rychlosti uploadu
rate_limit_local_peers
False
use_upnp
True
Aplikování limitů rychlosti i pro místní LAN síť Použití UPnP a NAT-PMP pro mapování příchozích spojení
Tabulka 3 – Parametry konfigurace BitTorrentSync API Zdroj: Autor
25
Tyto hodnoty nastavení zajišťují co největší pravděpodobnost vyhledání a spojení peerů v případě, že není dostupná komunikace se serverem HKFree. Jednotlivé parametry lze upravit ve třídě BtPreferences. Hodnoty jsou poté předány metodou instanci třídy SyncApi. Pro lepší pochopení zvolené konfigurace budou následující parametry popsány detailněji. disk_low_priority – Diskové operace, které provádí BitTorrentSync při synchronizaci souborů (zpráv) mezi peery mají nízkou prioritu. Při větší velikosti sdílených dat a vyšší prioritě by mohlo dojít ke zpomalení PC. folder_defaults.use_lan_broadcast – Vyhledávání peerů v LAN síti. Při zjištění sdíleného adresáře se stejným klíčem, dochází přednostně k přenosu dat pouze v rámci LAN. Nedochází tak ke zbytečnému zahlcení šířky pásma mimo LAN. peer_expiration_days – Počet dní, po kterých je peer při neaktivitě vyřazen ze swarmu. folder_defaults.known_hosts – Předem definovaný seznam IP adres peerů. folder_defaults.use_relay – Pokud nelze navázat přímé spojení mezi dvěma peery, sdílení dat probíha skrze relay server aplikace BitTorrentSync. Data procházející přes server jsou šifrovaná. listening_port – Síťový port, na kterém naslouchá aplikace BitTorrentSync. Pokud je nastavena 0, je výchozí port vybrán při každém spuštění náhodně. max_file_size_for_patching – Maximální množství dat změněných v jednom souboru sdíleného pomocí BitTorrentSync, které můžou být dodatečně staženy. Při přesažení této hodnoty dojde ke stažení celého souboru od začátku. sync_max_time_diff – Maximální povolený rozdíl času jednotlivých peerů. Při překročení této hodnoty nebude realizován přenos dat mezi těmito peery. V soukromém použití tato možnost zabraňuje nechtěnému sdílení dat peerům, kteří získají secret (klíč) ke sdílenému adresáři neoprávněně. download a upload limit – Nastavení limitů pro rychlost downloadu a uploadu dat. Tento parametr šetří šířku pásma při sdílení velkých souborů. Velikosti souborů sdílených v rámci HKFreeMonitor jsou řádově desítky kilobyte, limit je tedy nastaven na 0 (bez omezení), aby došlo k co nejrychlejšímu přenosu zpráv.
26
rate_limit_local_peers – Aplikování limitu rychlosti uploadu a downloadu také na přenosy v rámci LAN sítě. use_upnp – Vynucení BitTorrentSync aplikace zasílání UPnP a NAT-PMP packetů pro mapování příchozích spojení na router. Pomáhá správné funkčnosti peerům za NAT. Načítání zpráv (pro oznámení a chat) a vytváření nových souborů se zprávami do chatu je zajištěno pomocí třídy BtHandler (příloha 1). Konstruktor třídy BtHandler je volán v novém vlákně. Komponentou BackgroundWorker je zajištěno vytváření a ukončování jednotlivých vláken. BackgroundWorker je součástí formulářových tříd frmChat a frmBTUpdates, které se starají o jejich zobrazení uživateli. //Load Form private void frmBTUpdates_Load(object sender, EventArgs e) { backgroundWorker1.RunWorkerAsync(btHandler = new BtHandler(msgLimit, new SyncApi(8888, "127.0.0.1"))); } private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e) { BackgroundWorker worker = sender as BackgroundWorker; btHandler.LoadFilesBtmsg(this.keys); }
7.5.1.2 BT Oznámení Okno pro zobrazování oznámení od administrátorů je jedna z hlavních současí rozšiřující původní aplikaci HKFreeMonitor. Uživatel může v okně zobrazovat zprávy s oznámením od administrátorů. Načítání souborů se zprávami je prováděno periodicky (pouze při otevřeném okně) a je vykonáváno v jiném vlákně za pomocí komponenty BackgroundWorker. Díky tomu nedochází při načítání zpráv z adresářů ke krátkodobému zamrznutí aplikace v důsledku provádění na procesor časově náročnějšího kódu. Načtená oznámení jsou zobrazována v komponentě DataGridView a jsou defaultně řazena podle data vytvoření. Stav nových oznámení je automaticky kontrolován aplikací HKFreeMonitor, při zjištění nové zprávy je uživatel upozorněn pomocí změny ikony aplikace v oznamovací oblasti a oznamovací bublinou obsahující informace o novém oznámení. Po kliknutí levým tlačítkem myši na modrou obálku signalizující nové oznámení je
27
ihned
zobrazeno
okno
s oznámeními.
Zprávy
zobrazené
v tabulce
jsou
aktualizovány každých 10 minut.
7.5.1.3 BT Chat Okno s přístupem k chatu se podobá oknu pro zobrazení oznámení, nachází se zde však několik změn. Při prvním otevření okna s chatem je uživatel dotázán na uživatelské jméno, které bude spojeno s jeho zprávami. Kromě tabulky se zprávami se v okně nachází textové pole pro vlastní obsah zprávy. Zprávu je poté možné odeslat pomocí tlačítka nebo stiskem klávesy Enter. K automatické aktualizaci dat v komponentě DataGridView dochází jedenkrát za 60 sekund.
7.5.1.4 Nastavení aplikace Do okna nastavení aplikace byla přidána možnost nastavení uživatelského jména, pod kterým bude uživatel identifikován v chatu. Dále si uživatel může nastavit maximální možný počet zobrazených zpráv v oknech BT Chat a BT Updates (nedochází tak při větším množství sdílených zpráv k vytvoření rozsáhlé tabulky). Tlačítko „Přidat výjimku do firewallu“ nyní přidává do výjimek kromě aplikace HKFreeMonitor.exe také aplikaci BitTorrentSync (BTS.exe), pro správnou funkčnost tohoto tlačítka je nutné mít aplikaci spuštěnou jako správce.
Obr. 7 - Ukázka upraveného okna Nastavení aplikace. Zdroj: Autor
28
7.5.1.5 Instalační soubor Klientskou aplikaci HKFreeMonitor je možno nainstalovat za pomocí instalačního .exe souboru
vytvořeného v programu InnoSetup.
Skript pro vytvoření
instalačního souboru je uveden v příloze této práce. Instalační .exe soubor je lokalizován do dvou jazyků (češtiny a angličtiny), průběh instalace je standardní, po přijmutí podmínek aplikace může uživatel zvolit adresář na disku, kam bude aplikace nainstalována. Výchozí umístění je však doporučené z důvodů popsaných v Diplomové práci Kašpara [16]. Uživatelem může být dále zvoleno, zda aplikace má vytvořit zástupce na ploše a adresář se zástupci v nabídce Start. Instalační soubor je dostupný na:
CD v příloze této práce
webové adrese: http://lab.hkfree.org/~kolar/files/installer/
Aplikaci je možno odinstalovat spuštěním odinstalátoru nacházejícím se v instalačním adresáři aplikace.
7.5.2 Formát distribuovaných zpráv Jednotlivé zprávy jsou distribuovány jako samostatné soubory s příponou .btmsg. Zprávy jsou uloženy ve formátu JSON, díky kterému lze snadno soubory číst v aplikaci i z webového rozhraní. Struktura obsahu souboru je následující:
id – číslo zprávy
adminName – jméno (nick) administrátora, který zprávu vytvořil (u zpráv v chatu je pole použito pro nick uživatele)
title – titulek zpávy (u zpráv v chatu je titulek nahrazen slovem chat)
content – vlastní obsah zprávy
date – přesný čas vytvoření zprávy
Název souboru se zprávou je ve tvaru: datum_cas_nick_revize.btmsg
29
V případě potřeby je tak přímo z průzkumníka souborů jasné, kdy a kým byla zpráva vytvořena. V případě zpráv z chatu je název souboru uveden bez revize a je zde uvedeno, zda byla zpráva vytvořena v aplikaci HKFreeMonitor.
7.5.3 Serverová část Z klientské aplikace není možné vytvářet oznámení administrátory. Pro tuto funkcionalitu bylo vytvořené webové rozhraní běžící na serveru lab.hkfree.org. Webové rozhraní bylo vytvořeno v jazyce PHP s použitím frameworku Nette. Zdrojové kódy a projekt aplikace NetBeans je přiložen na CD. Přístup je možný pouze po přihlášení, v současné verzi jsou autorizovaní administrátoři uvedení v souboru users.web umístěném na serveru.
Obr. 8 – Homepage webového rozhraní Zdroj: Autor
Webové rozhraní je přístupné na adrese http://lab.hkfree.org/~kolar/
a bez problémů může být zobrazeno i na menších obrazovkách například v mobilním telefonu díky responzivnímu designu.
7.5.3.1 Prvotní spuštění Před využitím funkcí BitTorrent protokolu, je nutné spustit službu pomocí skriptu uvedeného níže.
30
#DIR=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd ) #echo dirname #cd $DIR #cd bin mkdir -p /home/kolar/other/messages/; chmod 777 -R /home/kolar/other/messages/; echo Slozka messages vytvorena mkdir -p /home/kolar/other/chat/; chmod 777 -R /home/kolar/other/chat/; echo Slozka chat vytvorena /home/kolar/other/btsync --config /home/kolar/other/config.api wait
echo "All processes done!" Tento skript spustí BitTorrentSync na serveru s potřebnými parametry tak, aby byl přístupný administrátorům přes webové rozhraní z internetu. Dále jsou skriptem vytvořeny adresáře pro oznámení a chat, které budou později přiřazeny ke službě BitTorrentSync. Tento skript je potřeba spustit pouze jednou, po vytvoření dvou adresářů již není třeba nic upravovat. Nutné je pouze propojení adresářů se službou BitTorrentSync, které je popsáno v kapitole 7.5.4
7.5.3.2 Soubor s klíči keys.ini Klíčový soubor s řetězci potřebnými pro sdílení zpráv pomocí BitTorrentSync se nachází v adresáři na serveru a je přístupný na adrese: http://lab.hkfree.org/~kolar/files/keys.ini.
Editace řetězců souboru je možná skrze jednoduchý formulář, obsahující dvě textová pole, pro jednotlivé klíče. Tento soubor je stahován aplikací HKFreeMonitor při každém spuštění. 31
7.5.3.3 Zobrazení oznámení Zobrazení všech zpráv vytvořených administrátory je přístupné z domovské stránky webového rozhraní. Zobrazeno je vždy 10 oznámení na stránce, tím je zajištěna snazší orientace při větším celkovém množství. Graficky jsou pak oddělené zprávy vytvořené právě přihlášeným administrátorem a zprávy vytvořené ostatními administrátory. Přihlášenému administrátorovi je umožněna po kliknutí na hlavičku zprávy editace obsahu a následné vytvoření novější revize zprávy.
Obr. 9 – Ukázka zobrazení oznámení z webového rozhraní Zdroj: Autor
7.5.4 Řešené problémy Při nestandardním ukončení aplikace například v důsledku pádu aplikace, nebo ukončení procesu HKFreeMonitor.exe nedojde k ukončení procesu BTSync.exe, tento proces je nutné ukončit uživatelem pomocí správce úloh, nebo je proces ukončen při opětovném spuštění a řádném ukončení aplikace HKFreeMonitor. Webové
rozhraní
umístěné
na
serveru
nemá
implementovány
metody
BitTorrentSync API (toto řešení bylo schváleno vedoucím práce). Přidání adresářů pro chat a oznámení vytvořených pomocí skriptu tedy musí být provedeno administrátorem manuálně skrze vlastní webové GUI rozhrání aplikace BitTorrentSync. Přístup k tomuto GUI (obr. 10) je možný přes odkaz na domovské 32
stránce
webového
rozhraní
po
zadání
přístupového
jména
a
hesla
nakonfigurovaných v souboru config.api v adresáři s aplikací BitTorrentSync. Po kliknutí na tlačítko přidat adresář je nutné vybrat adresář vytvořený inicializačním skriptem. Dalším krokem je zkopírování klíče (read only pro messages a read and write pro chat) a vložení skrze formulář pro editaci souboru keys.ini. Obsah adresáře chat je vhodné po určitém časovém intervalu vymazat a vygenerovat nový klíč, který bude sdílen.
Obr. 10 – GUI webového rozhraní aplikace BitTorrentSync Zdroj: Autor
GUI umožňuje přidání složek určených ke sdílení, nastavení preferencí pro BitTorrentSync služby a nastavení jednotlivých složek. Dále pak umožňuje zobrazení a zkopírování klíčů. Zhruba v 10-20 % případů může nastat při prvním spuštění klientské aplikace po dokončení instalačního průvodce neočekávaný pád aplikace HKFreeMonitor. Aplikace při dalším spuštění již pracuje normálně. Příčina tohoto problému nebyla zjištěna. Ačkoliv
jsou
konfigurační
soubory
BitTorrentSync
implementované
v HKFreeMonitor oddělené od samostatné aplikace BitTorrentSync. Při pokusu o spuštění
aplikace
BitTorrentSync
při
právě
běžící
instanci
procesu
HKFreemonitor.exe, dochází k problémům se spuštěním aplikace BitTorrentSync. V opačném pořadí problém nenastává. Tento problém se týká pouze identické verze BitTorrentSync, implementované v aplikaci HKFreeMonitor (tj. 1.4.110).
33
Posledním zjištěným problémem je zvýšená síťová aktivita. Ta je způsobena BitTorrent protokolem jako takovým. Kromě připojení k jednotlivým peerům sítě hkfree je při funkční konektivitě navázáno několik desítek připojení k nodum DHT a trackeru BitTorrentSync aplikace.
34
8 Výsledky Po spuštění aplikace HKFreeMonitor dojde k vytvoření potřebných adresářů v instalačním adresáři aplikace. Vytvořeny konfigurační soubory HFMonitor.ini a config.api. Ze serveru je obdržen seznam klíčů pro BitTorrentSync. Po určité době (řádově několik desítek sekund) BitTorrentSync zajistí ze serveru, popřípadě ostatních dostupných klientů zprávy pro oznámení a chat. Uživatel je o novém oznámení graficky upozorněn. Upozornění je zobrazeno i při dalším spuštění aplikace za předpokladu, že uživatel nezobrazil seznam oznámení. Tím je zabráněno nechtěnému přehlédnutí nového oznámení při ukončení aplikace. Uživatelské rozhraní, zvláště pak všechna okna aplikace byla upravena tak, aby nedocházelo ke grafickým deformacím při změně velikosti. Změnu velikosti nyní dovolují pouze okna BT Updates, BT Chat a zprávy. Obsah oken je nyní přizpůsobován jejich velikosti. Ostatní okna, která lze zobrazit mají nyní pevnou velikost.
8.1 Testování v domácím prostředí Aplikace byla testována v domácích podmínkách při různých konfiguracích sítě a propojení routerů pro simulaci NAT a reálného provozu aplikace. V tabulce číslo 4 je uveden seznam zařízení, která byla použita pro testování funkčnosti. Síťové prvky
Počítače
D-Link DIR-615 (revize H1) – firmware PC 1 – Windows 8.1 x64 dd-wrt (v24-sp2) Linksys
WRT54G
PC 2 – Windows 7 x64 (verze
7.0)
– PC 3 – Windows 7 x32
originální firmware (v7.00.8)
PC 4 – Windows 7 x32
Tabulka 4- Seznam zařízení použitých při testování Zdroj: Autor
35
Na použitých PC byly nainstalovány nejnovější ovladače a aktualizace OS. Na routeru D-link je kromě výchozích rout nastavena statická routa zajišťující správné směrování do sítě 192.168.100.0.
8.1.1 Scénář 1 – Ideální prostředí
Obr. 11 – Schéma zapojení č. 1 – ideální prostředí Zdroj: Autor
První testovaný scénář simuloval ideální prostředí, kde klienti obdrží zprávy s oznámením a chatem ze serveru lab.hkfree. Jako první byla aplikace puštěna na PC1. Poté co byly úspěšně staženy zprávy s oznámením a chatem na PC1, následoval start aplikace na PC2. Díky zapnuté funkci vyhledávání v LAN síti proběhla výměna zpráv přímo mezi PC1 a PC2. Stejné případ nastal u PC3 a PC4. Po vytvoření nového oznámení na serveru došlo prakticky okamžitě k distribuci zprávy na všechna PC. Prodleva mezi kompletním přijetím zprávy na disk a zobrazenou notifikací v aplikaci může být maximálně 30 sekund, jedná se o
36
interval napevno nastavený v aplikaci HKFreeMonitor. Na obou routerech byl povolen UPnP a vypnutý SPI firewall.
8.1.2 Scénář 2 – Ztráta připojení k serveru lab.hkfree.org
Obr. 12 – Schéma zapojení č. 2 – odpojený uzel Zdroj: Autor
Druhým testovaným scénářem bylo odpojení přístupu k internetu a serveru lab.hkfree.org. Na obou routerech byla opět povolena funkce UPnP. Chatová komunikace mezi všemi 4mi PC probíhala i nadále bez problémů (za předpokladu že aplikace na všech PC již měla přístup k lab.hkfree.org ze kterého obdržela soubor keys.ini). Po opětovném připojení routeru D-link k internetu se zprávy sesynchronizovaly i na server lab.hkree.org. V případě, že některý z PC měl oznámení ze serveru, které ostatní PC neměly, došlo k rozeslání zpráv na zbylá PC obou sítí. Toto je klíčová funkcionalita, která je od protokolu BitTorrent očekávána. Díky ní je možné šíření novějších zpráv mezi uživateli. Přenos zpráv mezi sítěmi 192.168.1.0 a 192.168.100.0 nastává pouze za předpokladu, že je povolena funkce UPnP. V aktuální verzi HKFreeMonitor je nastavován příchozí port vždy náhodný, Port-Forwarding tak není možné použít. 37
8.1.3 Scénář 3 – Ztráta připojení k serveru lab.hkfree.org – dvojitý NAT Poslední testovaný scénář (obr. 13) zahrnoval propojení routerů proti sobě, nastavení UPnP a firewallu zůstalo stejné. Proběhlo pouze upravení statických rout, pro zajištění komunikace obou sítí. Zde BitTorrentSync narazil na problém, kvůli tomu že nebyl dostupný tracker ani DHT, bylo přímé spojení mezi PC v sítích 192.168.1.0 a 192,168.100.0 možné.
Obr. 13 – Schéma zapojení č. 3 – simulace vícenásobného NAT Zdroj: Autor
Pouze v případě, že BitTorrentSync API mělo nastavenou IP adresu známého hosta (peera), V tomto případě například vnější rozhraní routeru. Taková možnost prozatím v aplikaci HKFreeMonitor není implementována. V budoucnu by aplikace, konkrétně konfigurace implementovaného BitTorrentSync mohla zahrnovat kromě adresy hlavního peera (tedy lab.hkfree.org) i co možná největší počet adres síťových prvků, které se nenacházejí za NAT.
38
9 Závěry a doporučení Zadání se vcelku úspěšně podařilo splnit. V teoretické části byl analyzován protokol BitTorrent a některé jeho nadstavby a zmíněny problémy týkající se jeho použití. Popsány byly aplikace implementující protokol BitTorrent. Provedena byla krátká analýza o možnostech použití BitTorrent protokolu pro zasílání zpráv v nespolehlivé síti pro potřeby hkfree. V praktické části bylo k funkcionalitě aplikace HKFreeMonitor implementováno API programu BitTorrentSync. Díky tomu byla přidána funkce zobrazení sdílených oznámení od administrátorů a komunikace s uživateli v síti HKFree pomocí chatu. Implementované BitTorrentSync API je nastaveno co možná nejlépe tak, aby uživatelé sítě měli co největší šanci pro spolehlivou funkčnost aplikace. Aplikace byla naprogramována v jazyce C# ve vývojovém prostředí Microsoft Visual Studio 2012. Ke službě běžící na serveru bylo vytvořeno jednoduché funkční webové rozhraní v jazyce PHP za pomocí frameworku Nette. Tato část byla programována ve vývojovém prostředí NetBeans. Webové rozhraní slouží administrátorům sítě k vytváření a editaci oznamovacích zpráv a zároveň také pro přístup do chatu, kde mohou s uživateli sítě hromadně komunikovat. Z rozhraní je dále možno editovat soubor s klíči, pro jednotlivé sdílené adresáře v rámci BitTorrentSync. Aplikace byla testována na několika PC včetně konektivity k serveru. A podle očekávání je komunikace pomocí BitTorrent protokolu velmi závislá na nastavení jednotlivých uzlů sítě a dostupnosti PC připojených za NAT potažmo. V ideálních podmínkách, kdy je dostupný dostatek jednotlivých peeru popř. peeru s veřejnou IP funguje aplikace velice spolehlivě. V aplikaci je určitě místo pro další rozšíření a vylepšení funkcionality. Za zmínku například stojí podpora více operačních systému, jmenovitě Linux a Mac OS. V dnešní době rostoucího počtu mobilních zařízení a rychle rostoucího výkonu
39
zvláště mobilních telefonů, se možnost přístupu k oznámením popř. chatu z mobilní aplikace jeví velice prakticky. V neposlední řadě také možnost do aktualizačního nástroje HKFreeMonitor zahrnout i novější verze aplikace BitTorrentSync, nutné pro přístup k API. V červenci 2015 byla uvolněna verze 2.0 BitTorrentSync API, toto rozhraní obsahuje lepší funkcionalitu pro práci s BitTorrent protokolem, další úprava aplikace by tak mohla zahrnovat úpravu této implementace a souvisejících metod ve třídě SyncApi.
40
10 Seznam použité literatury [1] BitTorrent inc. BitTorrent. [Online] http://www.bittorrent.com/. [2] NEWMAN, Jared. www.pcworld.com. PC World. [Online] 19. Prosinec 2013. http://www.pcworld.com/article/2082081/bittorrent-chat-promises-messagingfree-from-prying-eyes-including-the-nsas.html. ISSN 0737-8939. [3] LIU, Yangyang a PAN, Jianping. The Impact of NAT on BitTorrent-like P2P Systems. [Seattle, Washington : IEEE, Září 2009. Peer-to-Peer Computing. IEEE Ninth International Conference. ISBN 978-1-4244-5066-4. [4] COHEN, Bram. Incentives Build Robustness in BitTorrent. 22. Květen 2003. Přístup
z
Internetu:
http://pdos.csail.mit.edu/6.824-2010/papers/cohen-
btecon.pdf. [5] GUMMADI, Krishna Phani; GUMMADI, R; GRIBBLE, S; RATNASAMY, Sylvia Paul; SHENKER, Scott J; STOICA, Ion. The Impact of DHT Routing Geometry on Resilience and Proximity. 2003. Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications. ISBN 158113-735-4.
Přístup
z Internetu:
http://www.cs.cmu.edu/~./dga/15-
849/papers/gummadi-sigcomm2003.pdf [6] GOLDOOR, Abraham. Engeneering BitTorrent. [Online] Prosinec 2013. Přístup z Internetu: http://engineering.bittorrent.com/2013/12/19/update-on-bittorrentchat/. [7] DI, Wu; DHUNGEL, Prithula; HEI, Xiaojun; CHAO, Zhang; ROSS, Keith W. Understanding Peer Exchange in BitTorrent Systems. Delft : IEEE, Srpen 2010. Peerto-Peer Computing (P2P). IEEE Tenth International Conference. ISBN 978-1-42447139-0.
41
[8] MOL, J.J.D.; POUWELSE, J.A.; EPERMA, D.H.J.; SIPS, H.J. Free-Riding, Fairness, and Firewalls in P2P File-Sharing. Aachen : IEEE, Září 2008. Peer-to-Peer Computing. IEEE Eighth International Conference. ISBN 978-0-7695-3318-6. [9] FORD, Bryan, SRISURESH, Pyda a KEGEL, Dan. Peer-to-Peer Communication Across Network Address Translators. Anaheim, California : USENIX Association Berkeley, 2005. Proceedings of the annual conference. USENIX Annual Technical Conference . ISBN 1-931971-10-2. [10] GOLDMAN, Eric. Warez Trading and Criminal Copyright Infringement. Santa Clara :
School
of
Law,
7.
Leden
2004.
Přístup
z
Internetu:
http://ssrn.com/abstract=487163 [11] SCANLON, Mark; FARINA, Jason; LE KHAC, Nhien An; KECHADI, Tahar. Leveraging Decentralization to Extend the Digital Evidence Acquisition Window: Case Study on BitTorrent Sync. Dublin, Ireland : ARXIV, School of Computer Science & Informatics, University College Dublin, Září 2014. Přístup z Internetu:: http://arxiv.org/pdf/1409.8486v1.pdf. 2014arXiv1409.8486S. [12] BOŘÁNEK, Roman. www.root.cz. Root.cz. [Online] 28. Září 2013. Přístup z Internetu: http://www.root.cz/clanky/bittorrent-sync-uloziste-bez-pana/. ISSN 1212-8309. [13] MAYMOUNKOV, Petar a MAZIÈRES, David. Kademlia: A Peer-to-Peer Information System. New York University, New York : Springer Berlin Heidelberg, 2002. ISBN 978-3-540-45748-0. [14] TOOLE, Ryan a VOKKARANE, Vinod. BitTorrent Architecture and Protocol. Dartmouth, Massachusetts : University of Massachusetts Dartmouth, 17. Duben 2006.
Přístup
z Internetu:
http://160592857366.free.fr/joe/ebooks/ShareData/BitTorrent%20Architecture %20and%20Protocol.pdf 42
[15] NET MARKETSHARE. NET MARKETSHARE. [Online] Net Applications. http://www.netmarketshare.com/. [16] KAŠPAR, Martin. Distribuovaný informační a diagnostický systém. Hradec Králové : Fakulta informatiky a managementu UHK, 2014. Diplomová práce.
43
11 Přílohy 1) Zdrojové kódy 2) Disk CD-Rom obsahující aplikaci a přiložené projekty a) Text Bakalářské práce b) Spustitelný instalační soubor c) Projekty MS Visual Studio 2012 d) Projekt NetBeans e) InnoSetup skript pro vytvoření instalačního souboru f) Bash skript pro spuštění služby na linuxovém serveru.
44
Příloha č. 1
Zdrojové kódy SyncApi namespace HKFmonitor { public class SyncApi { private String _ipAddress; private Int16 _port; private CredentialCache myCache = new CredentialCache();//Cache credential data private String reqAddress; public String json { get; set; } public String obsah { get; set; } //Constructor public SyncApi(Int16 port, String ipAddress) { this._ipAddress = ipAddress; this._port = port; reqAddress = "http://" + ipAddress + ":" + port; myCache.Add(new Uri("http://127.0.0.1:8888/"), "Basic", new NetworkCredential("admin", "admin")); //default login + psw } public String Call(String url) { WebRequest request = WebRequest.Create(url); request.Credentials = myCache; // Response from a server WebResponse response = request.GetResponse(); Console.WriteLine(((HttpWebResponse)response).StatusDescription); // Get the stream containing content returned by the server. Stream dataStream = response.GetResponseStream(); // Open the stream using a StreamReader for easy access. StreamReader reader = new StreamReader(dataStream); // Reads the content string responseFromServer = reader.ReadToEnd(); // Writes into the console obsah = responseFromServer; String json = responseFromServer; Console.WriteLine(responseFromServer); // Erase reader and response reader.Close(); response.Close(); return json; } /// <summary> /// Returns an array with folders info. If a secret is specified, will return info about the folder with this secret. /// public void GetFolder(String secret) { Call(reqAddress + "/api?method=get_folders&secret=" + secret); Console.WriteLine(); }
Příloha č. 1
/// <summary> /// Adds a folder to Sync. If a secret is not specified, it will be generated automatically. /// The folder will have to pre-exist on the disk and Sync will add it into a list of syncing folders. /// Returns '0' if no errors, error code and error message otherwise. /// public void AddFolder(String dirPath, String secret) { Call(reqAddress + "/api?method=add_folder&dir=" + dirPath + "&secret=" + secret); Console.WriteLine(reqAddress + "/api?method=add_folder&dir=" + dirPath + "&secret="+ secret); } /// <summary> /// Removes folder from Sync while leaving actual folder and files on disk. /// It will remove a folder from the Sync list of folders and does not touch any files or folders on disk. /// Returns '0' if no error, '1' if there’s no folder with specified secret. /// public void RemoveFolder(String secret) { Call(reqAddress + "/api?method=remove_folder&secret="+ secret); Console.WriteLine(reqAddress + "/api?method=remove_folder&secret=" + secret); } /// <summary> /// Returns list of files within the specified directory. /// If a directory is not specified, will return list of files and folders within the root folder. /// Note that the Selective Sync function is only available in the API at this time. /// public String GetFiles(String secret) { String result = Call(reqAddress + "/api?method=get_files&secret=" + secret); Console.WriteLine(reqAddress + "/api?method=get_files&secret=" + secret); return result; } /// <summary> /// Selects file for download for selective sync folders. Returns file information with applied preferences. /// public void SetFilesPreferences(String secret) { //Console.WriteLine(reqAddress + "/api?method=get_files&secret=" + secret); }
Příloha č. 1
/// <summary> /// Returns list of peers connected to the specified folder. /// public void GetFolderPeers(String secret) { Call(reqAddress + "/api?method=get_folder_peers&secret=" + secret); Console.WriteLine(reqAddress + "/api?method=get_folder_peers&secret=" + secret); } /// <summary> /// Generates read-write, read-only and encryption read-only secrets. If ‘secret’ parameter is specified, will return secrets available for sharing under this secret. /// This is a secret for a read-only peer with encrypted content (the peer can sync files but can not see their content). /// One example use is if a user wanted to backup files to an untrusted, unsecure, or public location. /// This is set to disabled by default for all users but included in the API. /// public void GetSecrets(String secret) { if (secret == "") { Call(reqAddress + "/api?method=get_secrets"); } else { Call(reqAddress + "/api?method=get_secrets&secret=" + secret); } } /// <summary> /// Returns preferences for the specified sync folder. /// public String GetFolderPreferences(String secret) { String result = Call(reqAddress + "/api?method=get_folder_prefs&secret=" + secret); Console.WriteLine(reqAddress + "/api?method=get_folder_prefs&secret=" + secret); return result; } /// <summary> /// Sets preferences for the specified sync folder. Parameters are the same as in ‘Get folder preferences’. /// Returns current settings. /// public void SetFolderPreferences(String secret, bool folder_trash, bool overwrite_changes, bool search_lan, bool dht, bool tracker, bool relay) {
Příloha č. 1
Console.WriteLine(_reqAddress + "/api?method=set_folder_prefs&secret=" + secret + "&use_sync_trash=" + Convert.ToInt32(folder_trash) + "&use_dht=" + Convert.ToInt32(dht) + "&overwrite_changes=" + Convert.ToInt32(overwrite_changes) + "&search_lan=" + Convert.ToInt32(search_lan) + "&use_tracker=" + Convert.ToInt32(tracker) + "&use_relay_server=" + Convert.ToInt32(relay)); //{use_dht, use_hosts, search_lan, use_relay_server, use_tracker, use_sync_trash} Call(_reqAddress + "/api?method=set_folder_prefs&secret=" + secret + "&use_sync_trash=" + Convert.ToInt32(folder_trash) + "&use_dht=" + Convert.ToInt32(dht) + "&overwrite_changes=" + Convert.ToInt32(overwrite_changes) + "&search_lan=" + Convert.ToInt32(search_lan) + "&use_tracker=" + Convert.ToInt32(tracker) + "&use_relay_server=" + Convert.ToInt32(relay)); } /// <summary> /// Returns list of predefined hosts for the folder, or error code if a secret is not specified. /// public void GetFolderHosts(String secret) { Call(reqAddress + "/api?method=get_folder_hosts&secret=" + secret); } /// <summary> /// Sets one or several predefined hosts for the specified sync folder. Existing list of hosts will be replaced. /// Hosts should be added as values of the ‘host’ parameter and separated by commas. /// Returns current hosts if set successfully, error code otherwise. /// public void SetFolderHosts(String secret, List<String> hosts, List
ports) { String parameter = ""; int i = 0; foreach (String h in hosts){ parameter = parameter + h + ":" + ports[i]; } Call(reqAddress + "api?method=set_folder_hosts&secret=" + secret + "&hosts=" + parameter); } //overload SetFolderHosts public void SetFolderHosts(String secret, String host, int port) { Call(_reqAddress + "api?method=set_folder_hosts&secret=" + secret + "&hosts=" + host + ":" + port); } /// <summary>
Příloha č. 1
/// Returns BitTorrent Sync preferences. Contains dictionary with advanced preferences. /// public void GetPreferences() { Call(reqAddress + "/api?method=get_prefs"); Console.WriteLine(reqAddress + "/api?method=get_prefs"); } /// <summary> /// Sets BitTorrent Sync preferences. Parameters are the same as in ‘Get preferences’. /// Advanced preferences are set as general settings. Returns current settings. /// public void SetPreferences() { BtPreferences btPref = new BtPreferences(); String parameters = btPref.getParameters(); Call(reqAddress + "/api?method=set_prefs" + parameters); } /// <summary> /// Returns OS name where BitTorrent Sync is running. /// public void GetOsName() { Call(reqAddress + "/api?method=get_os"); Console.WriteLine(reqAddress + "/api?method=get_os"); } /// <summary> /// Returns BitTorrent Sync version. /// public void GetVersion() { Call(reqAddress + "/api?method=get_version"); Console.WriteLine(reqAddress + "/api?method=get_version"); } public void GetSpeed() { Call(reqAddress + "/api?method=get_speed"); Console.WriteLine(reqAddress + "/api?method=get_speed"); } /// <summary> /// Gracefully stops Sync. /// public void Shutdown() { Call(reqAddress + "/api?method=shutdown"); Console.WriteLine(reqAddress + "/api?method=shutdown"); } } }
Příloha č. 1
BTHandler namespace HKFmonitor.Model { class BtHandler { SyncApi syncApi; BTMessage msgBt; public BTMessage lastBtMsg; List<String> files = new List<String>(); List messagesBt = new List(); private String key; private int limit; private IList filesBt = new List(); private string nick; /// <summary> /// Constructor of class BTHandler /// /// <param name="limit">Limit of loaded messages(Integer) public BtHandler(int limit) { this.limit = limit; syncApi = new SyncApi(8888, "127.0.0.1"); syncApi.SetPreferences(); } public Int64 loadLastBtmsg(List<String> xkeys, Int64 highest) { Int64 lastOrderValue; foreach (String xKey in xkeys) { this.key = xKey; string path = Application.StartupPath + "\\BTUpdates\\" + key + "\\";
dynamic filesbtx = JArray.Parse(syncApi.GetFiles(key)); foreach (dynamic fl in filesbtx) { if (fl.state == "created") { String name = fl.name; String date = name.Substring(0, 10); String time = name.Substring(11, 8); String day = date.Substring(0, 2); String month = date.Substring(3, 2); String year = date.Substring(6, 4); String hours = time.Substring(0, 2); String mins = time.Substring(3, 2); String secs = time.Substring(6, 2); String highestValue = year + month + day + hours + mins + secs;
Příloha č. 1
Int64 hodnota = Convert.ToInt64(highestValue); if (hodnota > highest) { highest = hodnota; try { this.lastBtMsg = readFile(path, name); } catch (Exception e) { Console.WriteLine(e); } } } } } lastOrderValue = highest; return lastOrderValue; } /// <summary>Load the content of files in shared folders via BT. /// /// <param name="xkeys">Keys for BT (List<String>) //Load all files from directory specifik with key public void LoadFilesBtmsg(List<String> xkeys) { files.Clear(); filesBt.Clear(); messagesBt.Clear(); foreach (String xKey in xkeys) { this.key = xKey; string path = Application.StartupPath + "\\BTUpdates\\" + key + "\\"; dynamic filesbtx = JArray.Parse(syncApi.GetFiles(key)); int count = 0; foreach (dynamic fl in filesbtx){ if (fl.state == "created") { count = count + 1; string name = fl.name; string state = fl.state; string type = fl.type; FileBt x = new FileBt(name, state, type); filesBt.Add(x); } } int xlimit; if (count < limit) { xlimit = count; } else {
Příloha č. 1
xlimit = limit; } var filesBtOrdered = filesBt.OrderByDescending(name => name.name).ToList(); // ToList optional for (int i = 0; i < xlimit; i++) { FileBt x = filesBtOrdered[i]; messagesBt.Add(readFile(path, x.name)); } } } //Returns list of BTMessage public List GetBTMessagesList() { return messagesBt; } //Creates new chat message public void newMessage(String text, String nick) { this.nick = nick; if (nick == "Default") { nick = "Default_HKFreeApp"; } Random r = new Random(); int id = r.Next(0, 10000); //for ints string date = DateTime.Now.ToString("dd.MM.yyyy_HH-mm-ss"); string json = JsonConvert.SerializeObject(new BTMessage(id, nick, "chat", text, date)); createFile(json, date); } //Create new file with the message private void createFile(string content, string date) { string filePath = Application.StartupPath + "\\BTUpdates\\" + this.key + "\\"; string fileName = date + "_" + nick + "HKFree.btmsg"; String path = filePath + fileName; try { // Delete the file if it exists. if (File.Exists(path)) { File.Delete(path); } // Create the file. using (FileStream fs = File.Create(path)) { Byte[] info = new UTF8Encoding(true).GetBytes(content); fs.Write(info, 0, info.Length); //Writes into the file fs.Close(); //Close the file
Příloha č. 1
} } catch (Exception ex) { Console.WriteLine(ex.ToString()); } } //Convert date to value used for the sort private String convertDateToValue(BTMessage msg) { String date = msg.date.Substring(0, 10); String time = msg.date.Substring(11, 8); String day = date.Substring(0, 2); String month = date.Substring(3, 2); String year = date.Substring(6, 4); String hours = time.Substring(0, 2); String mins = time.Substring(3, 2); String secs = time.Substring(6, 2); String order_value = year + month + day + hours + mins + secs; return order_value; } //Reads the file with the message private BTMessage readFile(String filePath, String fileName) { String path = filePath + fileName; try { using (StreamReader sr = new StreamReader(path)) { String jsonMsg = sr.ReadToEnd(); //read file msgBt = JsonConvert.DeserializeObject(jsonMsg); //JSON to object msgBt.order_value = convertDateToValue(msgBt); return msgBt; } } catch (Exception e) { Console.WriteLine(path); Console.WriteLine("The file could not be read:"); Console.WriteLine(e.Message); return null; } } } }
Skript pro vytvoření instalačního souboru #define MyAppName "HKFreeMonitor" #define MyAppVersion "2.5.3" #define MyAppPublisher "HKFree.org"
Příloha č. 1
#define MyAppURL "http://hkfree.org" #define MyAppExeName "HKFmonitor.exe"
[Setup] ; NOTE: The value of AppId uniquely identifies this application. ; Do not use the same AppId value in installers for other applications. ; (To generate a new GUID, click Tools | Generate GUID inside the IDE.) AppId={{E6B31DBD-8AC1-441E-A48B-6C4E6919ED16} AppName={#MyAppName} AppVersion={#MyAppVersion} ;AppVerName={#MyAppName} {#MyAppVersion} AppPublisher={#MyAppPublisher} AppPublisherURL={#MyAppURL} AppSupportURL={#MyAppURL} AppUpdatesURL={#MyAppURL} DefaultDirName=C:\Users\{username}\AppData\Roaming\{#MyAppName} DefaultGroupName={#MyAppName} AllowNoIcons=yes LicenseFile=D:\BP\kolar-final\HKFmonitor\HKFmonitor\Docs\TermsOfUse.txt InfoBeforeFile=D:\BP\kolar-final\HKFmonitor\HKFmonitor\Docs\BeforeInstall.txt OutputDir=D:\BP\kolar-final\Installer OutputBaseFilename=HKFreeMonitor_setup_2_5_3 Compression=lzma SolidCompression=yes
[UninstallDelete] Type: filesandordirs; Name: "{app}\BTUpdates" Type: filesandordirs; Name: "{app}\BTSync" Type: filesandordirs; Name: "{app}\update" Type: files; Name: "{app}\keys.ini" Type: files; Name: "{app}\oldKeys.ini" Type: files; Name: "{app}\HKFmonitor.ini" Type: files; Name: "{app}\HKFmonitor.msg"
[Languages] Name: "english"; MessagesFile: "compiler:Default.isl" Name: "czech"; MessagesFile: "compiler:Languages\Czech.isl"
Příloha č. 1
[Tasks] Name: "desktopicon"; Description: "{cm:CreateDesktopIcon}"; GroupDescription: "{cm:AdditionalIcons}"; Flags: unchecked Name: "quicklaunchicon"; Description: "{cm:CreateQuickLaunchIcon}"; GroupDescription: "{cm:AdditionalIcons}"; Flags: unchecked; OnlyBelowVersion: 0,6.1 [Files] Source:"D:\BP\kolar-final\HKFmonitor\HKFmonitor\bin\Debug\HKFmonitor.exe"; DestDir: "{app}"; Flags: ignoreversion Source: "D:\BP\kolar-final\HKFmonitor\HKFmonitor\bin\Debug\BTSync\*"; DestDir: "{app}\BTSync"; Flags: ignoreversion recursesubdirs createallsubdirs Source: "D:\BP\kolarfinal\HKFmonitor\HKFmonitor\bin\Debug\Newtonsoft.Json.dll"; DestDir: "{app}"; Flags: ignoreversion Source: "D:\BP\kolarfinal\HKFmonitor\HKFmonitor\bin\Debug\Newtonsoft.Json.xml"; DestDir: "{app}"; Flags: ignoreversion ; NOTE: Don't use "Flags: ignoreversion" on any shared system files [Icons] Name: "{group}\{#MyAppName}"; Filename: "{app}\{#MyAppExeName}" Name: "{group}\{cm:UninstallProgram,{#MyAppName}}"; Filename: "{uninstallexe}" Name: "{commondesktop}\{#MyAppName}"; Filename: "{app}\{#MyAppExeName}"; Tasks: desktopicon Name: "{userappdata}\Microsoft\Internet Explorer\Quick Launch\{#MyAppName}"; Filename: "{app}\{#MyAppExeName}"; Tasks: quicklaunchicon
[Run] Filename: "{app}\{#MyAppExeName}"; Description: "{cm:LaunchProgram,{#StringChange(MyAppName, '&', '&&')}}"; Flags: nowait postinstall skipifsilent
