Univerzita Karlova v Praze Matematicko-fyzikální fakulta
BAKALÁŘSKÁ PRÁCE
Milan Plachý
Peer-to-peer komunikace Katedra softwarového inženýrství Vedoucí bakalářské práce: Mgr. Martin Nečaský, Ph.D. Studijní program: Informatika, Obecná informatika
2010
Rád bych poděkoval všem, kteří mě podporovali při psaní této práce. Zejména děkuji mému vedoucím Mgr. Martinu Nečaskému za pomoc se strukturalizací práce.
Prohlašuji, že jsem svou bakalářskou práci napsal samostatně a výhradně s použitím citovaných pramenů. Souhlasím se zapůjčováním práce. V Praze dne 20.5.2010
Milan Plachý
2
Obsah 1 Úvod...................................................................................................................5 1.1 Zadání.......................................................................................................5 1.2 Motivace...................................................................................................5 1.3 OS a nástroje.............................................................................................5 1.4 Struktura práce..........................................................................................5 2 Analýza možných metod....................................................................................7 2.1 Základní principy......................................................................................7 2.2 Základní funkce a možná rozšíření...........................................................8 2.3 Předpoklady a umístění.............................................................................9 2.4 Klient, identifikace a bezpečnost............................................................10 2.5 Analýza zapojení klientů a serverů.........................................................10 2.6 Analýza databáze....................................................................................16 2.7 Analýza komunikační vrstvy...................................................................20 3 Analýza existujících aplikací...........................................................................23 3.1 ICQ..........................................................................................................23 3.2 Windows Live Messenger.......................................................................24 3.3 Skype.......................................................................................................25 4 Návrh a implementace vlastního řešení (Ecom)..............................................27 4.1 Požadavky na funkčnost, vybraná schémata...........................................27 4.2 Použité technologie, návrh vlastního protokolu......................................27 4.3 Práce se soubory......................................................................................33 5 Testování aplikace............................................................................................34 5.1 Provedená testování................................................................................34 5.2 Problémy.................................................................................................35 6 Závěr................................................................................................................36 6.1 Shrnutí …................................................................................................36 6.2 Možné úpravy..........................................................................................36 6.3 Srovnání s popisovanými programy........................................................36 7 Zdroje...............................................................................................................38 8 Přílohy..............................................................................................................39 8.1 Uživatelská dokumentace – Server.........................................................39 8.2 Uživatelská dokumentace – Klient.........................................................40 8.3 Programátorská dokumentace – Server...................................................45 8.4 Programátorská dokumentace – Klient...................................................51 8.5 Přiložené CD...........................................................................................56
3
Název práce: Peer-to-peer komunikace Autor: Milan Plachý Katedra (ústav): Katedra softwarového inženýrství Vedoucí bakalářské práce: Mgr. Martin Nečaský, Ph.D. E-mail vedoucího:
[email protected] Abstrakt: Tento text je určen především zájemcům o informace o vzájemné komunikaci uživatelů na lokální síti a internetu. Je zaměřen na textovou komunikaci v reálném čase (Instant messaging). Dále pak na analýzu možných a existujících řešení. Část textu je věnována popisu existujících komunikačních protokolů a návrhu nového protokolu. Součástí práce je návrh, implementace a dokumentace jednoduchého messengeru. Práce by měla posloužit i jako návod při návrhu a implementaci jednotlivých částí aplikace pro vzájemnou textovou komunikaci určené skupiny uživatelů podle okolností a zadaných kritérií, kterými jsou například typ sítě nebo rozsah řešení. Klíčová slova: Klient-server, Peer-to-peer, Komunikace, Protokol
Title: Peer-to-peer communication Author: Milan Plachý Department: Department of Software Engineering Supervisor: Mgr. Martin Nečaský, Ph.D. Supervisor's e-mail address:
[email protected] Abstract: This text is especialy intended to those who are interested into users communication on local network and the internet. It is mainly foccused on Instant messaging. Also on analysing possible and existing solutions. Part of text is dedicated to describing existing communication protocols and desining one. Part of the work is design, implementation and creation of easy messenger. It should also serve as a guide for implementing all parts of aplication for mutual text communication in group of users with certain factors and criteria which are for example network type or range of solution. Keywords: Client-server, Peer-to-peer, Communication, Protocol
4
1 Úvod 1.1 Zadání Cílem této bakalářské práce je popsat návrh a postup při implementaci peer-to-peer komunikátoru s dalšími funkcemi, jako například offline posílání souborů nebo řešení aplikace s více servery a rezistencí proti výpadku některého (některých) z nich. Dále zjistit fungování některých z existujících řešení a popsat vhodné technologie, které se dají použít k implementaci konkrétního řešení. Součástí bakalářské práce bude i konkrétní implementace jednoduchého komunikátoru spolu s nutnými dokumenty (uživatelská a programátorská dokumentace).
1.2 Motivace Díky rozvoji internetu se stala vzájemná komunikace lidí velmi jednoduchou. Na základě této skutečnosti vzniklo i velké množství aplikací umožňující vzájemnou komunikaci dvojic či skupin uživatelů připojených k internetu (nebo k lokální síti) vlastnících uživatelskou část aplikace. Pro tyto aplikace se ujal název Instant messenger a vznikla tak celá oblast zabývající se komunikací pomocí takových aplikací: Instant messaging. Název vznikl na základě toho, že zpráva je na rozdíl od klasické pošty předána ihned. Přechod internetu z akademické do komerční sféry se bohužel výrazně na tomto typu aplikací podepsal. Velké množství z nich je přeplněno reklamami a nutí uživatele k akcím, které by za normálních podmínek nebyly nutné. Dále jsou některé zbytečně složité a kvůli tomu i pomalejší. Proto by tato práce měla být z velké části návodem jak postupovat při vytváření jednoduchého a rychlého komunikátoru (messengeru). Příkladem využití může být například firma, kde je potřeba komunikace pouze mezi zaměstnanci. Dále je možné do aplikace implementovat velmi jednoduše bezpečnostní opatření (např. kontrolu odesílaných dat a zpráv), která mohou být vyžadována.
1.3 OS a nástroje Návrh je nezávislý na platformě nebo programovacím jazyku. Pro postup při implementaci je předpokládán operační systém Microsoft Windows (2000+) podporující .net 3.5. Programovacím jazykem je C# (doporučené a použité prostředí pro programování je Microsoft Visual studio 2008 TS). Dále je potřeba vytvoření databáze. Z důvodu použití jazyka C# je zvolen Microsoft SQL server.
1.4 Struktura práce Tato práce je rozdělena do pěti základních částí. Část 2 popisuje základní koncept fungování aplikací typu instant messenger, jejich funkce, možnosti umístění částí
5
aplikace a roli databáze v aplikaci jako celku. Dále obsahuje popis komunikační vrstvy a možnosti jejího řešení. V části 3 je analyzován princip fungování a funkce některých existujících aplikací pro instant messaging. Část 4 se zabývá návrhem nové aplikace, vybráním vhodných schémat a technologií a její implementací. V části 5 jsou popsána provedená testování a problémy naimplementované aplikace. Poslední částí je závěr se srovnáním naimplementovaného programu a analyzovaných programů a s možnostmi rozšíření. Součástí textu je příloha obsahující uživatelskou a programátorskou dokumentaci k naprogramované aplikaci ECom.
6
2 Analýza možných metod 2.1 Základní princip Princip fungování aplikace je shodný pro většinu již existujících aplikací. Uživatel se připojí přes svou část aplikace pomocí svých přihlašovacích údajů a poté je schopen vyhledávat další uživatele a komunikovat s nimi. Jedinou informaci o topologii sítě, která je uživateli k dispozici, je adresa serveru, případně port, ke kterému se připojuje (adresu nebo port nemá k dispozici přímo uživatel, ale jeho aplikace). Ten zprostředkovává komunikační službu. Poté, co uživatel vyhledá některého z ostatních klientů, může mu odeslat autorizační požadavek. Pokud je požadavek přijat, mohou spolu tito dva klienti komunikovat pomocí nadefinovaného rozhraní. Z pohledu klienta funguje aplikace tedy takto:
Z pohledu sítě takto:
V tomto případě nejsou zakreslená spojení přímá, ale jedná se o libovolné cesty mezi počítači, na kterých je spuštěna konkrétní část aplikace. Na těchto spojeních mohu být další fyzická zařízení (switch, hub, router,...). Serverů může být po cestě od uživatele A k uživateli B více, nebo pouze jeden. Vytvoření komunikačního kanálu mezi uživateli je pouze směrování zpráv správnou trasou v síti.
7
2.2 Základní funkce a možná rozšíření Hlavní funkcí programu je posílání textových zpráv ostatním uživatelům. K tomu, aby tato funkce měla reálný význam, musí aplikace dále obsahovat funkce: • Přihlašování se k aplikaci (respektive k serveru) Je nutné uživatele identifikovat, aby ho ostatní uživatelé rozlišili. Dále je nutné, aby byl uživatelský účet chráněn heslem jako ochrana před zneužitím účtu (krádeží identity). • Možnost registrace Vytvoření nového účtu na serveru. • Vyhledávání uživatelů (není zcela nutné, ale usnadňuje velmi práci uživatele) • Zasílání žádostí o autorizaci • Příjímání žádostí o autorizaci Slouží k ochraně před útoky uživatelů a umožňuje si tak vybrat, s kým klient chce komunikovat a komu naopak komunikaci zamítne. Dalšími možnými úpravami aplikace, resp. jejími rozšířeními, jsou: • Offline předávání textových zpráv Běžné rozšíření základního odesílání zpráv. Pokud přijímající klient není připojen k aplikaci, zprávy jemu odeslané ostatními uživateli zůstanou uložené na serveru a jsou uživateli doručeny po jeho připojení. • Překlad emotikonů a další možnosti formátování textu Běžná funkce komunikačních aplikací. Nepřináší žádný přínos v oblasti čisté komunikace, ale dělají aplikaci více uživatelsky přívětivou (user-friendly). • Hlasová komunikace / Video komunikace Možnost hovořit s uživatelem přímo. Tato funkce naráží na problém u pomalejších sítí. • Posílání souborů Možnost posílání menších souborů, jako např. fotografií a rozsáhlejších textových dokumentů, je velmi populární. V dnešních aplikacích a při stoupajících rychlostech sítí není problém posílat i soubory s velikostí v rámci stovek MB. • Offline posílání souborů Podobně jako u offline odesílání zpráv je tato funkce zaměřena na ukládání souborů odeslaných odhlášeným uživatelům a jejich následné přeposlání cílovému uživateli po jeho opětovném přihlášení. • Datové úložiště Pro každou dvojici uživatelů funguje na serveru datové úložiště, nad kterým mají oba uživatelé absolutní kontrolu a mohou na toto místo nahrávat soubory, mazat je a stahovat. Tato funkce je pouze obdobou předchozí, jedná se vlastně o její absolutizaci, neboť všechny soubory se uchovávají 8
•
•
na serveru. Její nevýhodou je, že při prostém odesílání souboru od jednoho uživatele druhému je nutné, aby nejprve první uživatel soubor nahrál na server a teprve poté ho může druhý uživatel stáhnout. Uchovávání historie Běžné rozšíření, historie se ukládá přímo na počítači klienta. Jedinou nevýhodu je, že historie není distribuována mezi všechny počítače, kde se uživatel přihlašuje. Nastavení omezení, bezpečnosti nebo filtrování zpráv Funkce serveru, slouží k ochraně dat, ochraně serveru a filtrování škodlivého materiálu, který uživatelé mohou posílat.
V dnešní době mají aplikace tohoto typu velké množství dalších funkcí především z důvodu uživatelské přívětivosti. Jedná se například o rozšíření informací o uživateli, zobrazování posílaných obrázků, nastavení vzhledu, tvorbu skupin, hry a mnoho dalších. Ty ale přispívají k čisté komunikaci pouze minimálně nebo vůbec.
2.3 Předpoklady a umístění Přestože se jedná o peer-to-peer komunikaci, je potřeba další část aplikace, která bude komunikaci zprostředkovávat. Proto se jedná o aplikaci typu klient-server. Z toho vyplývá, že se bude skládat ze dvou částí (serverové a klientské). Každá funguje samostatně. Podle umístění serveru se odvíjí i funkce a dosah celého řešení: 2.3.1 Umístění v privátní síti Pokud je serverová aplikace spuštěna na počítači umístěném v privátní síti (server nemá veřejnou IP adresu), znamená to, že dosažitelnost tohoto serveru bude pouze z této sítě. Jedná se především o sítě typu LAN. To je vhodné pro různé firemní nebo školní sítě. Výhodou je větší rychlost přenosu zpráv a souborů a především bezpečnost, neboť spojení a jeho koncoví účastníci nejsou z jiné než vnitřní sítě dosažitelní. Nevýhodou je samozřejmě dostupnost pouze v rozsahu sítě. Ta je omezena zařízeními překládajícími IP adresy (NAT, PAT). Pokud jsou tato zařízení dostatečně inteligentní (mapování portů), lze rozsah rozšířit. Po přechodu na IP adresy verze 6 tento problém částečně odpadá, neboť každá adresa může být veřejná. 2.3.2 Veřejné umístění Pokud žádáme dosažitelnost z libovolného počítače připojeného k internetu, musí být serverová aplikace umístěna na počítači s veřejnou IP adresou. Výhodou tohoto umístění je globální dosažitelnost. Nevýhodou naopak rychlost při posílání zpráv a souborů, neboť mohou procházet přes velké množství aktivních prvků a síťových 9
spojení, kde rychlost přenosu zpravidla není tak vysoká jako v lokální síti. Dalším problémem je bezpečnost. Pokud bude serverová aplikace umístěna globálně, je nutné se ujistit, že je dobře zabezpečena proti všem možným útokům. Serverová aplikace je spojena s databází uživatelů. Ta může být na stejném počítači nebo se k ní server připojuje. Obě možnosti mají své výhody a nevýhody. Při připojování k databázi je „úzkým hrdlem“ rychlost a stabilita připojení k databázi, ale o funkčnost a celkovou správu databáze se stará poskytovatel. Při implementaci databáze na shodném počítači tento problém není, ale správce serveru se stává automaticky i správcem databáze se serverem spojené.
2.4 Klient (uživatel), jeho bezpečnost a identifikace Za klienta budeme považovat uživatele, který využívá klientskou část aplikace a používá program bez znalosti vnitřního fungování aplikace. Při návrhu je nutné předpokládat, že běžný uživatel se nechová podle žádných pravidel, proto musí být proti jeho všem možným akcím aplikace zabezpečena. Uživatel musí být jednoznačně identifikován, nejlépe pomocí unikátního čísla (id). Dále pro zvýšení uživatelské přívětivosti je možná identifikace např. unikátní přezdívkou nebo emailem. Zabezpečení uživatelského účtu je pomocí hesla. Toto heslo by se nemělo posílat po síti jako prostý text, neboť je možné jej ze sítě „odposlouchat“. Proto je nutné heslo šifrovat a posílat již zašifrované. V dnešní době existuje velké množství šifrovacích algoritmů. Příkladem jsou: MD5, SHA, HAVAL. Další možností je šifrovat celou komunikaci, například pomocí RSA šifry nebo podobných. Samotné šifrování hesla samozřejmě není zárukou bezpečnosti. Další nutnou podmínkou je, aby si uživatel vybral dostatečně dlouhé heslo (9 a více znaků obsahujících speciální znaky, číslice atd.).
2.5 Analýza zapojení serverů a serverů Při návrhu je nejdůležitější vybrat celkové schéma propojení klientů se serverem/servery a propojení mezi servery. Dále je také nutné rozmyslet funkci databáze. Zda bude databáze centrální nebo distribuovaná. Výběr závisí na prostoru, kde má být konkrétní řešení implementováno. Neexistuje vyloženě správné nebo špatné řešení pro všechny situace. V následujícím textu jsou popsány a schematicky zakresleny základní možnosti propojení na logické vrstvě. Další řešení se od těchto odvíjejí.
10
2.5.1 Jednoduché schéma s jedním serverem (obr. 1/a) Toto řešení je vhodné pouze pro lokální sítě, kde je jistota, že se síť nebude dále rozšiřovat, respektive, že se nebude zvyšovat počet uživatelů. „Úzkým hrdlem“ aplikace je server. Vzniká zde absolutní centralizace a všechny požadavky jsou vedeny skrze server. Z toho také vyplývají vyšší nároky na výpočetní kapacitu počítače, na kterém je server spuštěn. Výhodou je vysoká rychlost přenosu, neboť veškerá komunikace probíhá na lokální síti, která je z pravidla několikrát rychlejší než internet. Dalším kladem je nedostupnost z okolních sítí, což zaručuje bezpečnost před útoky „zvenčí“. Dále navíc absolutní centralizace umožňuje jednoduchou kontrolu posílaných zpráv a souborů. Záporem je omezení maximálního počtu připojených uživatelů a krátký dosah (pouze v lokální síti). Server je klíčovým prvkem celého systému a jeho nedostupnost způsobí nefunkčnost celého řešení. Pro komunikaci na lokální (privátní) síti se dá použít i varianta bez zprostředkovatele, kde se uživatelé připojují přímo k sobě. V tomto případě musí alespoň jeden z uživatelů znát adresu druhého, aby spolu mohli komunikovat. V tomto speciálním případě nejsou klienti nijak omezeni a mohou využít kapacitu sítě na její maximum. Je však také nutné vzít v potaz množství vzniklých spojení. Pokud budeme předpokládat, že se propojí každý uživatel s každým, vzniká úplný graf, kde počet vrcholů je roven počtu uživatelů a počet spojení bude (n*(n+1)) / 2 , kde n je počet uživatelů. Vytížení sítě tedy může být vysoké. Navíc kvůli neexistenci serveru je komunikace nekontrolovatelná. Aby nebylo nutné znát adresy všech uživatelů, může být v síti databáze s jejich adresami (centrální autorita) (obr. 1/b). Ta nebude zatížena, protože uživatel si po startu aplikace stáhne informace o ostatních uživatelích z databáze a nadále s ní nepotřebuje komunikovat.
Obr. 1/a – jednoduché schéma
Obr. 1/b - schéma bez serveru s centrální autoritou 11
2.5.2 Kruhové schéma více serverů s centrální databází (obr. 2) Na rozdíl od předešlého schématu, zde se předpokládá vyšší počet serverů. Ty jsou zapojeny v kruhu, takže každý server může komunikovat nejvýše se dvěma okolními servery. Databáze je stále jediná a všechny servery se k ní připojují. Toto schéma již je možné použít ve větších sítích, protože má více přístupových bodů. Hlavní problémy jsou: Kruhové zapojení serverů (délka trasy zprávy) Ačkoli je díky tomuto zapojení značně snížen počet spojení, které mají servery mezi sebou, velká část zpráv bude muset cestovat po více spojeních, neboť neexistuje přímá cesta mezi odesílajícím a přijímajícím serverem. Kruhové zapojení serverů (výpadek serveru/serverů) Protože konkrétní server ví jen o stavu dvou serverů kolem sebe, musí se informace o výpadku libovolného serveru odesílat po kruhu, aby všechny servery byly informovány. Z toho vyplývá, že každý server musí mít uložené informace o všech ostatních a směr, ve kterém se servery nacházejí. Navíc se po výpadku serveru musí znovu připojit jeho sousedi mezi sebou. Přestože následující případ vypadá na první pohled nereálně, není nemožné, aby nastal. Předpokládejme výpadek více serverů najednou. Příkladem může být výpadek proudu v lokalitě, kde jsou tři servery z kružnice za sebou. Poté ostatní servery zjistí výpadek pouze dvou z nich. Tento případ se dá ošetřit tak, že každý ze serverů bude připojen k centrální autoritě, která bude znát přesnou logickou topologii sítě a bude všechny informovat o změnách a případně určovat nebo dokonce vytvářet nová spojení. Vzniká opět problém při jejím výpadku. Databáze Protože je databáze sdílená všemi servery, dochází k velkým časovým prodlevám při velkém množství dotazů. Toto řešení je určeno pro větší sítě a z toho důvodu bude v databázi velký počet záznamů. Při dotazu serveru do databáze musí být zamčena tabulka se všemi uživateli, vyhledán odpovídající záznam, tabulka odemčena a teprve poté může pokračovat další dotaz. Částečným řešením je rozdělení tabulek na více částí, takže bude možné v některých případech zpracovávat více příkazů najednou. Chybou v databázi nebo jejím odpojením samozřejmě ztrácejí servery veškerou informaci o uživatelích a aplikace jako celek je nadále nepoužitelná. Naopak bezproblémové je připojení nového serveru do již fungujícího kruhu. Stačí, aby znal adresu libovolného serveru a ten informoval o tom, že se chce zapojit. 12
V tom případě dotázaný server informuje svého souseda, každý se spojí s novým serverem a teprve poté se vzájemně odpojí.
Obr. 2 – Kruhové schéma s centrální databází
2.5.3 Úplné schéma serverů s centrální databází (obr. 3) Úplné schéma řeší problém rozesílání informace mezi servery (každá zpráva projde maximálně jedním logickým spojením mezi servery). Řešení výpadku serveru není problém, protože všechny ostatní servery zjistí tento výpadek samostatně a není potřeba rozesílat další informace a vytvářet nová spojení. Připojení nového serveru je bezproblémové, ale musí se připojit ke všem funkčním serverům (kompletní informaci o topologii může získat od libovolného z připojených serverů). Problémem je případná nefunkčnost databáze a velké množství zpracovávaných požadavků. Řešení problémů s databází je částečně popsáno v následujícím bodu a poté její distribuce v odstavci o distribuci databáze.
13
Obr. 3 – Úplné schéma s centrální databází 2.5.4 Kruhové schéma serverů s distribuovanou databází (obr. 4) Toto schéma se zabývá řešením problémů s databází v kruhovém schématu (ad. 2). Databáze je distribuovaná mezi servery tak, že každý ze serverů má svou databázi se kterou pracuje. K databázi se může vzdáleně připojovat nebo je na shodném počítači a na síti odpadá komunikace mezi serverem a databází. Lepší variantou je samozřejmě databáze na stejném počítači, protože nevzniká zpoždění při posílání příkazů do databáze a snižuje se vytížení sítě. Pád libovolné z databází se projeví odpojením serveru, který byl k databázi připojen a zbytek serverů funguje dále uzavřením mezery v kruhu po odpojeném serveru. Možnosti distribuce databáze jsou popsány v odstavci o distribuci databáze. Toto řešení je vhodné pro rozsáhlejší sítě s nižším počtem serverů (většinou velmi výkonných) s předpokladem, že k výpadkům serverů nebude docházet často.
Obr. 4 - Kruhové schéma s distribuovanou databází
14
2.5.5 Úplné schéma serverů s distribuovanou databází (obr. 5) Stejně jako předchozí schéma se toto zabývá řešením problémů vyplývajících z existence pouze jedné databáze. Jedinou nevýhodou zůstává velký počet spojení. Spojení budou ale vytížena rovnoměrně a k využití většího počtu z nich najednou dochází pouze v případě, kdy server informuje ostatní uživatele/servery o změně stavu nebo o nastalé situaci. Pokud je tedy správně vytvořen návrh distribuce databáze a identifikace klientů, pak se náročnost na vytížení sítě příliš nezmění oproti řešením s menším počtem spojení. Toto řešení je vhodné pro velké sítě s velkým počtem klientů a serverů.
Obr. 5 - úplné schéma s distribuovanou databází Každé z řešení má své výhody a nevýhody. Například je zbytečné na lokální síti s nízkým omezeným počtem uživatelů vytvářet schéma s více servery, neboť není potřeba tak velká datová ani výpočetní kapacita a síť by byla naprosto zbytečně zahlcována komunikací mezi servery. Zátěž sítě je dalším důležitým aspektem. Pokud je posílána informace ze serveru jedinému konkrétnímu serveru, je výhodnější úplné schéma, neboť se zpráva odešle přímo a síť tak bude zatížena zprávou na kratší dobu než v kruhové variantě, neboť zde musí zpráva cestovat přes všechny servery na cestě mezi odesilatelem a příjemcem. Ta bude určitě delší nanejvýš rovna (ve smyslu počtu zařízení po cestě) než přímá cesta. V případě, že je potřeba rozeslat zprávu všem serverům, je naopak výhodnější kruhové schéma, neboť server rozešle do sítě stejný počet zpráv, jako je zbylých serverů. V kruhovém schématu se zpráva pošle pouze 15
jedna a tu si mezi sebou servery postupně předávají. Síť tedy bude vytížena na delší dobu, ale daleko méně. Z toho vyplývá, že volba schématu záleží i na na fyzické topologii sítě.
2.6 Analýza databáze Z předchozího textu vyplývá, že databáze je klíčovou částí aplikace. Jsou v ní uloženy především informace o uživatelích a autorizacích. Pro potřeby základní komunikace stačí, aby databáze obsahovala tabulku s uživateli a tabulku se seznamem autorizací. Další možnosti rozšíření jsou závislé na tom, jak má být výsledná implementace bohatá, na popisu uživatele (email, telefonní číslo, další údaje) a na dalších možnostech klientské části (různé typy stavů, online uložené nastavení). 2.6.1 Příklady databáze Pro jednoduchou aplikaci budou tabulky vypadat takto: Uživatel (Id uživatele, Jméno, Příjmení, Heslo, Stav) Autorizace (Id uživatele, Id autorizovaného, přezdívka) ER diagram databáze bude v tomto případě vypadat takto:
Obr. 6 - ER diagram tabulek jednoduché databáze
Další možností by bylo uložení seznamu autorizovaných uživatelů jako pole do první tabulky. To ale nelze, protože by tato tabulka porušovala 1. normální formu. Dále by bylo možné z id autorizovaných uživatelů vytvořit řetězec znaků, ve kterém by byly jednotlivé položky odděleny unikátní „zarážkou“. To je ale nepraktické pro prohledávání a navíc položka tabulky přeteče při velkém počtu autorizovaných uživatelů. Přidání nových parametrů uživatele se bude řešit přidáním položek do již existujících tabulek, případně jejich změnou a přidáním nových tabulek. Toto základní schéma databáze by mělo ve všech rozšířeních zůstat shodné, jak je vidět i v následujícím 16
příkladu. Příklad rozsáhlejší databáze s více informacemi, uloženými zprávami a online standardizovaným nastavením by mohl vypadat takto: Uživatel (Id uživatele, email, Jméno, Příjmení, Heslo, Stav, Další_informace, Id_nastavení) Autorizace (Id uživatele, Id autorizovaného, přezdívka) Nastavení (Id_nastavení, Podklad, Font, Text, Překlad_emotikonů) Zpráva (Id_uživatele, Id_odesílajícího, Jméno_typu, Text, Datum) Typ_zprávy (Jméno_typu, Popis) ER diagram bude vypadat takto:
Obr. 7 - ER diagram složitější databáze
U rozsáhlejších databází je nutné brát ohled na to, že bude obsahovat velké množství dat a server/servery budou s databází provádět časté úpravy/dotazy. Proto by databáze měla být na dostatečně výkonném počítači. Práce s databází je řešena pomocí jednoduchých příkazů/dotazů typu SQL. Je pouze na tvůrci konkrétní implementace, zda se o vytváření dotazů bude starat přímo serverová aplikací nebo zda vytvoří další logickou vrstvu v databázovém schématu z funkcí a procedur a server ji bude využívat. Obě řešení jsou stejně náročná, protože se nejedná o složité dotazy/příkazy. Dotazy/příkazy budou především: 17
• • • • • •
Vyhledání klienta a zjištění jeho vlastností (stav, jméno, příjmení) Upravení vlastnosti/vlastností klienta (především změna stavu) Zjištění všech autorizovaných klientů konkrétním klientem Zjištění vlastností všech klientů autorizovaných konkrétním uživatelem (pouze kombinace předchozích) Přidání nového uživatele/nové autorizace do tabulky Případné odebrání uživatele nebo autorizace
2.6.2 Možnosti distribuce databáze Za předpokladu, že je zvoleno schéma implementace s více servery a více databázemi, existují dva základní způsoby, jak databázi distribuovat. Absolutní replikace Databáze bude kompletně replikována na každém serveru. Všechny servery budou tedy mít absolutní informaci o stavu všech uživatelů. Po připojení uživatele k serveru se do databáze pouze přidá informace o tom, k jakému serveru je aktuálně připojen. Tato informace se rozešle ostatním serverům, což zajistí replikaci informace ve všech databázích. Výhody: Uživatel se může připojit k libovolnému serveru, takže po výpadku serveru se všichni uživatelé, kteří k němu byli připojeni, mohou připojit k jinému serveru a pokračovat bez problémů v komunikaci. Nevýhody: Redundance dat v databázích. Všechny informace o uživatelích jsou replikovány na všech databázích. Dále při připojení nového serveru se musí synchronizovat jeho databáze s ostatními servery, což může mít na delší dobu dopad na vytížení sítě, protože se budou posílat informace o absolutně všech uživatelích. To se dá částečně vyřešit offline replikací databáze a poté se budou posílat pouze informace o stavu uživatelů. Rozdělení na samostatné části Každý server bude mít přidělené určité množství klientů, kteří se budou přihlašovat výhradně k němu. V databázi pro konkrétní server budou pouze informace o jemu přidělených klientech. Aby ostatní servery „věděly“, kterému z ostatních serverů mají poslat zprávu nebo informaci, musí být schopny zjistit informaci o tom, ke kterému serveru je uživatel připojen. Tento problém lze řešit pomocí různých úprav. a) Ukládání informace o serveru do Id uživatele Nejjednodušší a nejspolehlivější řešení. Id bude přiděleno tak, aby z něj mohl libovolný server rozpoznat, ke kterému z ostatních serverů je klient přiřazen. 18
Například podle dvou prvních znaků (číslic). Je nutné dobře rozmyslet, kolik serverů bude maximálně použito, aby informace o serveru byla postačující na jejich rozlišení. Na druhou stranu je zbytečné používat prvních pět rozlišujících znaků, když víme, že maximální počet serverů bude deset. Problémem je pouze silná fixace klienta na jeho přidělený server. b) Centrální autorita Použití další databáze jako seznamu serverů a jejich uživatelů je sice flexibilní, ale stává se kritickou částí zapojení. Po jejím „pádu“ ztrácí servery informaci o připojených uživatelích. Navíc při velkém počtu serverů bude vysoce vytížena. c) Lokální proměnná na každém ze serveru Server si udržuje informaci o „cizích“ uživatelích v lokální proměnné (seznam, pole...). Toto řešení je nepoužitelné pro větší počet klientů, protože i pouhé informace o tom, ke kterému serveru náleží, zabírají příliš velkou datovou kapacitu. Toto řešení se dá vylepšit ukládáním těchto informací do zvláštní tabulky v databázi. To ale nesníží redundanci distribuovaných dat. 2.6.4 Problémy databáze a jejich řešení Hlavním problémem je „pád“ jednoho nebo více serverů. Základním požadavkem samozřejmě je, aby se odpojení serveru neprojevilo na ostatních serverech. Všechny servery jsou o výpadku informovány a informují své uživatele. Ti v případě a) rozpoznají uživatele, kteří byli odpojeni podle jejich id, neboť je v něm zakódována informace o odpojeném serveru. V případě b), c) jsou informováni svým serverem, o které uživatele se přesně jedná. Toto je další důvod, proč používat řešení a). Při výpadku serveru není nutné posílat velké množství informací klientům. Stačí odeslat informaci o odpojeném serveru, podle které uživatel odpojené klienty rozpozná. Protože je databáze distribuovaná, je problémem po výpadku domovského serveru připojit se k jinému serveru, protože je odpojena i databáze s informacemi o autorizacích uživatele a jeho vlastnostech. Možnostmi řešení jsou: Nepovolit uživateli připojit se k jinému než k domovskému serveru Takto je řešena většina jednodušších komunikačních aplikací. Vychází z předpokladu, že každý ze serverů je velice stabilní a spolehlivý. Navíc, pokud dojde k výpadku, je to jen na krátkou dobu (v rámci minut). Poté je server restartován (případně nahrazen jiným) a uživatelé se k němu mohou znovu připojit. Spolehlivost služby se tedy odvíjí od spolehlivosti samotných serverů. Replikace databáze 19
Pro každou databázi bude existovat její záložní kopie, kterou si po pádu serveru přivlastní některý z ostatních serverů. Ten poté odpojený server zastupuje. Toto řešení je velice těžkopádné, neboť v jeden okamžik bude mít server k dispozici více databází s informacemi o uživatelích. Navíc může být až dvojnásobně vytížen. Po znovu spuštění nefunkčního serveru se musí databáze zreplikovat a předat zpět. To se navíc projeví opětovným odpojením všech přepojených uživatelů. Dále samotná implementace je velice problematická, neboť se musí správně rozhodnout, kdo bude který server zastupovat, jak se bude replikovat databáze a kde se bude uchovávat. Toto řešení je i složité implementovat. Dopočítání parametrů Odpojený uživatel bude mít možnost připojit se k libovolnému z ostatních serverů. Po přihlášení se z autorizací ostatních uživatelů dopočítá částečný seznam jeho autorizovaných uživatelů. Další informace jsou zjištěny přímo od něj. V případě a) musí dostat novou součást id podle aktuálního serveru, což je jednou z nevýhod tohoto řešení. Dále je problémem replikace jednoho uživatele po všech databázích, protože pokud se postupně připojí ke všem serverům, tak se databáze zaplní neexistujícími klienty resp. jedním klientem s různými id podle toho, ke kterým serverům se již připojil. Pro uživatele by bylo nejlepší řešení, při kterém se po pádu může připojit k jinému ze serverů. Tato řešení jsou ale velmi složitá na implementaci a serverové aplikace by byly zbytečně složité, proto doporučuji řešení, kdy se uživatel může přihlašovat pouze k jednomu serveru (případně několika se shodnou databází). Uživatel je navíc připojen k serveru ve své oblasti, takže k němu má nejrychlejší připojení.
2.6 Analýza komunikační vrstvy Předchozí text se celý věnoval analýze a návrhu logické části aplikace. Další část se věnuje samotné komunikaci mezi klienty a servery. Aplikace (komunikace mezi aplikacemi) musí fungovat na některém z existujících transportních protokolů (TCP, UDP). Protože základním požadavkem na aplikaci tohoto typu je, aby odeslaná zpráva jedním klientem byla cílovému klientovi doručena a v případě, že zprávu nelze doručit, reagovala adekvátně na tuto situaci (uložení zprávy, vypsání chybového hlášení), je až na výjimky nutné použít protokol TCP. Na internetu, kde se uživatelé připojují z privátních sítí, je navíc nutné spojení navazovat od uživatele, neboť server není schopen spojení do privátní sítě vytvořit.
20
2.6.1 Možnosti řešení na různých úrovních Komunikaci lze tedy po fyzické stránce řešit na různých úrovních • Vytvoření nového protokolu jako nadstavbu transportního protokolu TCP/IP • Použití některého z existujících komunikačních protokolů (OSCAR, MSNP) • Použití technologie vytvořené pro účely vzdálené komunikace Návrh vlastního protokolu Při návrhu vlastního protokolu je nutné rozmyslet, jaké všechny situace mohou nastat, koho je nutné o nich informovat. Více tedy než o vlastní protokol se jedná o definici zpráv na již fungujícím protokolu. Komunikace se serverem a s ostatními klienty probíhá pomocí speciálních zpráv. Velikost zprávy musí být shora omezena, protože se na koncové straně bude ukládat do datové struktury (např. pole) fixní velikosti. Použití existujícího protokolu V této době existuje velké množství komunikačních protokolů určených výhradně pro aplikace typu klient-server nebo dokonce výhradně pro peer-to-peer komunikaci. Výhodou použití takového protokolu je, že aplikace poté bude schopná komunikovat s aplikacemi, které využívají shodný protokol a tím pádem i se všemi uživateli, pokud se aplikace vhodně modifikuje a připojí k internetu. Příkladem takové aplikace je program Miranda, kde je řešeno přidávání protokolů pomocí pluginů. Uživatel poté může aplikaci používat jako libovolný z messengerů (resp. jako kombinaci messengerů), který funguje na přidaném protokolu (pluginu). Nevýhodou je, že existující protokol může být specifikován poměrně složitě a aplikace musí reagovat i na zprávy, které nepodporuje. Příklady protokolů pro peer-to-peer komunikaci, které jsou využívány dnešními aplikacemi jsou: • •
OSCAR Protokol, který ke komunikaci využívá ICQ, AIM. MSNP Protokol, který ke komunikaci využívá Windows Live Messenger.
Tyto protokoly jsou popsány dále v textu u příkladů existujících aplikací (ICQ, Windows Live Messenger) Další příklady protokolů, které je možné použít pro klient-server aplikace: •
HTTP (HyperText Transfer Protocol) Protokol, který je primárně určen pro komunikaci s webovým rozhraním. Jeho struktura ale splňuje i požadavky messengeru, protože hlavička se dá 21
použít pro metadata a tělo zprávy pro samotnou informaci. •
SOAP (Simple Object Acces Protocol) Protokol pro vzdálenou komunikaci definovaný schématem XML. Před verzí 1.2 sloužil pro jednoduchý přístup k objektům.
Tyto protokoly jsou nadstavbou nad protokolem TCP/IP. Jejich použití je vlastně příkladem vytvoření protokolu nad TCP/IP a je nutné dále stejně nadefinovat typy zpráv a jejich funkci. Využití existující technologie Další možností je využití některé z existujících technologií pro vzdálenou komunikaci nebo nebo pro poskytování služby. Tato technologie používá ve většině případů větší množství protokolů v závislosti na funkci. Při implementaci poté programátor nemá přístup k používaným protokolům přímo, ale pouze k rozhraní, které technologie nabízí. Příkladem takové technologie je WCF (Windows Communication Foundation), která mimo jiných protokolů používá pro komunikaci protokoly HTTP a SOAP zmíněné výše. WCF vytváří ideální podklad pro fungování aplikace typu klient-server, kde server vystupuje jako poskytovatel služby a klient jako její konzument. Fungování WCF je popsáno v části textu o implementaci vlastní aplikace, neboť tato technologie je klíčovou součástí aplikace.
22
3 Existující aplikace a jejich fungování Předcházející dvě kapitoly se věnovaly návrhu aplikace po logické stránce a po stránce fyzické komunikace částí aplikace. Úkolem této kapitoly je analyzovat některé z existujících aplikací (messengerů) a protokoly, na kterých aplikace fungují, pokud to bude možné. Popisované aplikace jsou: • ICQ • Windows Live Messenger • Skype
3.1 ICQ (aktuální verze 7.1) Je jedním z více používaných messengerů (50 mil. aktivních uživatelů). Funguje na OS Windows a pro jiné operační systémy existují další jeho varianty. Podporuje základní posílání zpráv a s ním související funkce. Dále podporuje velké množství rozšíření, jako například odesílání souborů a offline zpráv a ukládání historie na klientském počítači. Součástí je i velké množství funkcí pro změny vzhledu a podporu vedlejší interakce s ostatními uživateli (hry, speciální formátování textu). Největším záporem této aplikace je její komerčnost. Obsahuje velké množství reklam, které často brání v samotné komunikaci klientů. Dále při vydání některých verzí programu byly staré verze zablokovány a dala se používat pouze nová verze aplikace. Alternativami využívající stejný protokol jsou např. Miranda IM nebo Qip. Protokol používaný pro komunikaci aplikací ICQ je OSCAR. OSCAR (Open System for CommunicAtion in Realtime) Tento protokol nebyl vždy veřejný. Části jeho oficiální dokumentace byly zveřejněny roku 2008. Kromě ICQ existuje velké množství aplikací využívajících tento protokol v závislosti na programovacím jazyku, ve kterém byly vytvořeny (joscar, OscarLib, ...). OSCAR je nadstavbou nad protokolem TCP. Mezi klientem a serverem je vytvořeno více komunikačních kanálu na jednom spojení. Protokol definuje přesně formáty všech typů zpráv. Pro přenos zpráv na nejnižší úrovni je použit protokol FLAP (základem zprávy poslané tímto protokolem je její délka). Samotná data se posílají pouze jedním kanálem (SNAC data) a jsou logickou nadstavbou protokolu FLAP.
23
Příkladem je „vyjednávání“ klienta se serverem o přihlášení: 2. MD5 based authorization
<> >> << >> << <>
připojení SNAC(17,06) SNAC(17,07) SNAC(17,02) SNAC(17,03) odpojení
Klient se připojí k autorizačnímu serveru Klient odešle informaci o žádosti Server odešle autorizační zprávu Klient odešle konkrétní žádost Server odešle odpověď na žádost Klient se odpojí od autorizačního serveru
Celá komunikace je v tomto případě šifrována pomocí md5 hash metody. Čísla v závorce u SNAC zprávy udávají rodinu a typy zprávy, které jednoznačně určují následující formát zprávy. Pro popis samotných dat slouží 16b informace TLV (type, length, value), která udává informace o typu a délce dat v následující části zprávy. Z předchozího textu je vidět, že protokol OSCAR je velmi striktně definovaný a aby pokryl všechny možné typy zpráv a řešení situací je i velice složitý. Pokud by chtěl programátor používat tento protokol ve své aplikaci, je nutné, aby se řádně seznámil se specifikací protokolu a s existujícími částmi dokumentace.
3.2 Windows Live Messenger (dříve MSN messenger) Messenger firmy Microsoft fungující na OS Windows a Windows mobile. Microsoft vytvořil speciální verzi tohoto programu i pro konzoly Xbox pro komunikaci hráčů. Patří mezi nejvíce používané instant messengery. Funkce tohoto programu jsou podobné jako u ICQ. Oproti ICQ ale obsahuje navíc přímé propojení s datovým úložištěm (SkyDrive) a Windows life webovou službou. Dále umožňuje volání do některých telefonních sítí. Díky SkyDrive si připojený uživatel může vyzvednout soubory, které byly na úložiště přidány, když byl odpojen. Tato funkce je zpřístupněna až od roku 2009. Do změny bylo offline odesílání souboru řešeno pomocí sdílené složky synchronizované na obou počítačích. Protokolem používaným pro komunikaci je MSNP. MSNP (Microsoft Notification Protocol) Programů používajících tento protokol je velké množství a díky tomu není použitelnost omezena pouze na OS Windows a operační systémy podporované programem Windows Live Messenger. Serverovou část zastupují dva typy serverů: • Notification server Slouží pro udržování informací o uživatelích. Pokud je k němu uživatel připojen, je pro ostatní uživatele viditelný. 24
Switchboard server Slouží pro samotnou komunikaci mezi klienty. Pro každou komunikaci, kterou klient vede, je vytvořeno spojení se switchboard serverem. Protokol funguje jako nadstavba TCP/IP a hlavním portem je port 1863. Během komunikace se serverem je možné specifikovat další porty. MSNP je primárně textový protokol a jako kódování textu ve zprávě je použito UTF-8, které je dostatečně rozsáhlé na pokrytí národních a speciálních znaků a je kompatibilní s často používaným kódováním ASCII. Dále podporuje kódování URL odkazů a kódování XML pomocí speciálních znaků a nahrazování. Dále je možné pracovat pomocí http dotazů a odpovědí. Klient zasílá příkazy a server vrací odpovědi na příkazy, případně provádí požadované akce. Veškerá komunikace mezi serverem a klientem probíhá odesíláním příkazů. Kód příkazu tvoří trojice znaků. Dále následuje mezera a id příkazu, aby ho bylo možné zpětně identifikovat. id jsou v rozsahu (0,231-1). Zpráva s příkazem je ukončena dvojicí speciálních znaků \r\n. Příkladem je informování serveru o změně stavu: •
>> CHG 7 AWY 32\r\n << CHG 7 AWY 32\r\n Kde CHG identifikuje příkaz pro změnu stavu uživatele, AWY je nový stav (Away) a 32 je id určující schopnosti a program uživatele (získává se ze součtu různých parametrů), který stav změnil. V tomto případě by server informoval všechny relevantní uživatele o změně stavu uživatele, který příkaz použil. Díky textovému chování protokolu není manipulace s ním tak složitá jako v případu protokolu OSCAR, kde je reprezentace přímo závislá na složení Bytů zprávy. Ale i v tomto případě je protokol složitý a obsahuje velké množství příkazů a zpráv, popisujících komunikaci a nastalé situace. Opět je nutné být dobře seznámen s protokolem, pokud chce programátor implementovat program, který MSNP bude využívat.
3.3 Skype Aplikace Skype slouží již v základu pro hlasovou a video komunikaci. Z tohoto důvodu se v systému fungování zcela liší od předchozích dvou. Nefunguje na principu standardního modelu klient-server, ale čistě peer-to-peer. Pro komunikaci je použita VoIP (voice over IP) technologie. Program dále podporuje textovou komunikaci (pouze online) a vytváření konferenčních hovorů. Je rozšiřitelný použitím pluginů pro zvýšení funkčnosti. Protokol pro komunikaci není veřejný. 25
Zdroje a zdrojové kódy aplikací, které ho používají, jsou uzavřené. To dělá celý protokol, a tím i aplikaci, více rezistentní proti útokům. Skype nepodporuje offline odesílání souborů, což je dáno principem jeho fungování. Skype dále navíc nabízí službu volání do pevných sítí, což ho spojuje se světem telekomunikací. Tato služba je ale placená.
26
4 Návrh a implementace vlastního řešení (ECom – Easy Communicator) [Celý kód programu je jako příloha na přiloženém CD] [Dokumentace programu jsou v příloze] Předcházející popis existujících aplikací nastínil možnosti v oblasti instant messaging. Všechny tři aplikace fungují velice spolehlivě a mají velké množství funkcí rozšiřujících možnosti čisté komunikace. Program, který budu programovat, bude zaměřen čistě na komunikaci pomocí textových zpráv, posílání souborů a funkce potřebné a spojené s těmito dvěma funkcemi. Jeho přednostmi tedy budou jednoduchost (jak ovládání tak celková), rychlost a velikost.
4.1 Požadavky na funkčnost, vybraná schémata Základním požadavkem je odesílání textových zpráv. Umístění serveru budeme předpokládat v lokální síti s možností umístění na internet s omezeným počtem připojených uživatelů. Dále bude aplikace podporovat offline odesílání a přijímání zpráv a souborů. Budeme požadovat variantu s více servery, aby byla implementována nejen komunikace klient-server, ale i komunikace server-server. Konkrétním schématem bude úplné schéma více serverů s centrální databází.
4.2 Použité technologie a návrh komunikačního protokolu Tato kapitola popisuje konkrétní technologie vybrané pro implementaci komunikační vrstvy a pro práci s databází. 4.2.1 WCF (Windows Communication Foundation) (vyžaduje .net 3.0) Model aplikace je klient-server. Proto jsem se rozhodl zvolit technologii WCF pro vzájemnou komunikaci částí aplikace. Další důvody jsou: • Pomocí WCF je na serveru vytvořena služba, kterou bude klient využívat, což přesně odpovídá požadavkům naší aplikace a obecně modelu klient-server. • Nevznikají problémy s interpretací zpráv, protože klient ani server přímo na komunikační protokol nevidí, neboť ten je zapouzdřen technologií. • Ačkoliv je server i klient vytvořen striktně pro Windows, je možné vytvořit klientskou aplikaci v jiném programovacím jazyku se znalostí služby a díky tomu i přesun na jiný operační systém. Z předcházejícího textu je zřejmé, že WCF je technologie, pomocí které se dá zprostředkovat služba na serveru. Tuto službu pak využívá klient. WCF toho dosahuje vytvořením speciálního kontraktu služby. V tom jsou nadefinovány metody (kontrakty operací) a typy objektů (datové kontrakty), které je možné v případě metod volat a v případě objektů používat jako parametry a návratové hodnoty metod.
27
Obr. 8 - Komponenty komunikace WCF Fungování schématu je následující (obr. 8): Proxy server nabízí klientovi metody, které může volat. Ty jsou poté převedeny na zprávu formátu podle používaného protokolu a odeslány komunikačním kanálem dispečeru. Ten zprávu zpětně převede na volání metody a to služba provede. Pokud klient vlastní aktuální definici kontraktu, může poté využívat všechny metody, které jsou poskytovány a implementovány samostatně na serveru. Nevýhodou technologie WCF je nemožnost duplexní komunikace. Ačkoliv WCF speciální formu duplexní komunikace poskytuje, doporučuje se jí nepoužívat a pokud ano, tak pouze v případě procesů na lokálním počítači. Z toho vyplývá, že veškerou aktivitu zařizuje klient a server na ní pouze reaguje. 4.2.2 Návrh vlastního protokolu Protokol navržený v této části byl použit v předchozí verzi programu ECom. V aktuální verzi je jeho funkce nahrazena sofistikovanou technologií WCF popsanou výše.
Základní pravidla: Transportním protokolem je protokol TCP Omezení velikosti zprávy je 1024 B Typ zprávy je určen prvními dvěma byty, tím je umožněno vytvořit postačující počet typů zpráv Každý typ zprávy má jednoznačně určený počet částí a jejich význam Kódování znaků a řetězců zprávy je pomocí kódování UTF8, aby byly zachovány národní a speciální znaky Pro oddělení částí zprávy se používá speciální znak (oddělovač ~). Aby bylo možné tento znak použít v jiných částech zprávy, je možné ho nahradit speciálním znakem \0, který UTF8 povoluje kódovat a nikde se ve zprávě nevyskytne. Zprávy je možné skládat do jedné za sebe pod podmínkou, že výsledná 28
velikost nepřesáhne max. limit 1024 B
Typy zpráv a jejich formát: A) HELLO zpráva Tuto zprávu posílá automaticky klientská aplikace po připojení k serveru. Posílá id uživatele a server poté odešle všem, kteří mají uživatele s tímto id v autorizovaných uživatelích, informaci o tom, že se připojil. Dále také pošle jemu stejnou zprávu s informací o tom, kteří z jeho autorizovaných uživatelů jsou připojeni a kteří ne a informace o nich. HE Id ~ Heslo ~ Id – id odesilatele, který se přihlásil. Posílá se i jeho heslo pro jeho ověření. Pokud je první část (id) 0, znamená to, že uživatel nemá ještě id a žádá o něj. V tom případě bude zpráva vypadat takto HE 0 ~ Jméno ~ Příjmení ~ Heslo ~ Heslo je šifrováno pomocí MD5 hashe. Výsledná velikost hesla je 14B. B) ID zpráva Zpráva obsahující přidělené id pro nově zaregistrovaného uživatele. ID Id ~ Jméno ~ Příjmení ~ C) INFO zpráva Toto je zpráva s odpovědí o online uživatelích autorizovaných jistým uživatelem. Obsahuje id uživatelů rozdělených podle jejich aktuálního stavu: 1 pro připojené a 0 pro odpojené. Pokud je informace moc dlouhá, pošle se více zpráv. IN Id1 ~ 1/0 ~ Jméno1 ~ Příjmení1 ~ Přezdívka1 ~ Id2 ... Idn – id n-tého uživatele který je autorizovaný. Podobně Jménon, Příjmenín, Přezdívkan udávají informace o jménu, příjmení a přezdívce. D) AUTORIZAČNÍ zpráva Žádost o autorizaci u některého z uživatelů. Obsahuje id uživatele, id žádaného uživatele. Server ještě přidá do zprávy další informace (jméno a příjmení žádajícího). AU Id žádaného ~ Id žádajícího ~ E) AUTHORIZACE PŘIJATA zpráva Odpověď na žádost o autorizaci uživateli, který o ní žádal. Posílá se pouze kladná odpověď.
29
AP I žádaného
~ Id žadatele ~ Jméno ~ Příjmení ~
F) SEARCH zpráva Zpráva, kterou posílá uživatel, který vyhledává na serveru uživatele podle id, jména nebo příjmení. SE Id vyhledávajícího ~ Jméno hledaného ~ Příjmení hledaného ~ Id hledaného ~ Pokud budou některé z položek prázdné, znamená to, že uživatel danou položku nevyplnil. Potom se podle této položky nebude vyhledávat. G) SEARCH RESULT zpráva Zpráva(zprávy), které odešle server zpět na dotaz uživatele. SR Id uživatele ~ Jméno ~ Příjmení ~ H) MESSAGE Klasická zpráva, kterou posílá jeden uživatel jinému uživateli. ME Id příjemce ~ Id odesilatele ~ Datum a Čas odeslání ~ Zpráva ~ I) FILE REQUEST zpráva Zpráva, kterou posílá uživatel serveru, pokud chce některému z uživatelů poslat soubor. FR Id odesilatele ~ Id příjemce ~ Jméno souboru ~ velikost ~ Velikost souboru je v bytech. J) FILE ANSWER zpráva Odpověď na žádost o poslání souboru. FA Id odesilatele ~ Id příjemce ~ Jméno souboru ~ Odpověď 1/0 ~ Typ 1/0 ~ Odpověď – 1 pro přijetí souboru, 0 pro odmítnutí Typ – 1 pro odpověď na požadavek serveru, 0 pro odpověď na požadavek klienta K) FILE OFFLINE zpráva Odpověď na žádost o poslání souboru v případě, že cílový klient je odpojen. Tuto zprávu odesílá server a automaticky se předpokládá, že znamená kladnou odpověď. FO Id odesilatele ~ Id příjemce ~ Jméno souboru ~ L) FILE zpráva Zpráva, která reprezentuje přenos souboru. Hodnota nula znamená, že tato část 30
souboru není poslední, ale bude se do něj ještě nadále zapisovat. Zpráva je vždy zcela zaplněna (1024B). Pokud je místo nuly posloupnost jedniček, znamená to, že tato část souboru je poslední. FI Id odesilatele ~ Id příjemce ~ Jméno souboru ~ 0/1...1 ~ Data
M) CHANGE zpráva Zpráva, která se pošle, pokud si uživatel změní své jméno, nebo příjmení. Id se nedá měnit. Server jí následně rozešle všem uživatelům, které má tento uživatel autorizované. CH Id odesilatele ~ Jméno ~ Příjmení ~ Stav ~ Tato zpráva se použije i v případě odhlášení uživatele. Části zprávy mohou být nevyplněné N) CHANGE NICK zpráva Tuto zprávu posílá uživatel, který chce změnit přezdívku některého z uživatelů ve svém seznamu autorizovaných. CN Id uživatele ~ Id autorizovaného ~ Nová přezdívka ~
O) SPECIAL zpráva Speciální typ zprávy pro oznamování chyb a nestandardních situací. Počáteční 2B jsou SP.
Příklad zprávy: ME 3 ~ 56 ~ Ahoj Karle ~ ME - Typ zprávy(message) – klasická zpráva 3 - id příjemce ~ - zarážka 56 - id odesilatele ~ - zarážka Ahoj Karle – odesílaná data ~ - zarážka V této zprávě je poměr dat a dalších informací 1:1. Ve větších zprávách speciální data nezabírají tak velikou část prostoru zprávy, neboť hlavička bude stejně velká.
31
Jak je z příkladu jasně vidět, program používající tento protokol bude muset rozeznávat velké množství zpráv a poté na ně reagovat. Některé typy je možné zjednodušit, nebo sloučit. Největší výhodou tohoto řešení je absolutní kontrola a nastavení posílaných dat. Proto je nutné dbát na vlastnosti zpráv především proto, že může nastat situace, kde doplňující data zabírají velkou část zprávy a na vlastní data není dostatek místa. Tím může dojít v krajních případech k pádu aplikace nebo k zahlcení sítě. 4.2.3 Práce s databází, technologie LINQ (Language Integrated Query) (.net 3.5) [SQL script pro vytvoření databáze je na CD s přílohami] Databázi reprezentuje základní jednoduché schéma s rozšířením pro ukládání zpráv. Tím je vyřešeno offline ukládání zpráv. Další možností je ukládat zprávy do souborů, což by ale mohlo vést k vytvoření obrovského množství malých souborů se zprávami, které by velmi vytěžovaly souborový systém. ER diagram databáze (obr. 9) je tedy mezistupeň mezi uvedenými příklady v obecném popisu databáze.
Obr. 9 – Databáze programu ECom
Tabulky v databázi jsou následující: Uživatel (Id uživatele, Jméno, Příjmení, Heslo, Stav) Autorizace (Id uživatele, Id autorizovaného, přezdívka) Zpráva (Id_uživatele, Id_odesílajícího, Typ, Text, Datum) Pro práci s databází jsem zvolil technologii LINQ, která vytváří objektovou vrstvu nad databází. Práce s databází je poté daleko snazší a dobře zapadá do použitého objektového modelu. V kombinaci s technologií WCF navíc při většině dotazů stačí
32
získaný objekt z databáze dobře přetypovat na serializovatelný objekt nadefinovaný pro komunikaci s klientem a ten mu odeslat.
4.3 Práce se soubory Jedním ze základních požadavků funkcí aplikace je online a offline odesílání souborů. Protože díky WCF funguje celek schematicky jako služba-konzument, rozhodl jsem se vytvořit na serveru datové úložiště (další část služby) pro každou dvojici uživatelů. Funguje podobně jako například FTP. Nejprve se na hlavním komunikačním kanálu (kde je poskytována služba) klient domluví se serverem na novém spojení. To se poté otevře samostatně na novém portu a slouží pro odesílání nebo příjem dat. Oba uživatelé mají tedy nad úložištěm absolutní kontrolu.
33
5 Testování aplikace, možné úpravy a problémy 5.1 Provedená testování Aplikace klientské části byla testována na operačních systémech Windows 7, Windows Vista a Windows XP. Na těchto třech operačních systémech jsem neshledal žádné rozdíly v rychlosti nebo spolehlivosti aplikace. Serverová část byla obdobně testována na OS Windows 7 a Windows XP bez znatelných rozdílů. Všechna další pozorování, měření a grafy výkonu a zatížení jsou získávány z aplikace fungující na operačním Systému Windows 7. 5.1.1 Testování klientské části Klientská část byla testována nejprve vyvoláváním nestandardních situací, které by normální běh programu nemusel nutně předpokládat. • Pokus o autorizaci již existujícího uživatele nebo sebe sama • Pokus o stahování/smazání souboru, který stahuje druhý uživatel • Ukončení aplikace během stahování • Chybně zadané údaje • Připojení více uživatelů na jednom počítači • Přihlášení se na již přihlášený účet Ve všech případech bylo vytvořeno ošetření, aby nedošlo k pádu aplikace. Připojení více uživatelů na jednom počítači je povoleno a to především z důvodu dalšího testování. Přehlašování účtů nebylo povoleno. Dále byla testována průchodnost klientské aplikace z privátní sítě na server, který byl na veřejné adrese. Spojení bylo vytvořeno bez problémů a komunikace byla stabilní. Další provedená testování jsou na zatížení operační paměti a procesoru při používání aplikace, protože jedním ze základních požadavků na program jsou nízké nároky na výpočetní a paměťovou kapacitu. 1) Zatížení procesoru Procesor je aplikací vytížen pouze minimálně. Výsledek testu je možné sledovat na grafu. Oranžová křivka představuje procentuální zatížení procesoru po dobu jedné minuty programem ECom. Bodem nejvyšší zátěže bylo v tomto případě přihlášení uživatele k aplikaci. Dále bylo v následujících 45s odesláno 30 zpráv s délkou mezi čtyřmi a dvaceti znaky. To mělo simulovat velkou zátěž ze strany uživatele na rychlost zasílání zpráv. Jak je i z grafu vidět, Vytížení procesoru bylo minimální. Při pokusu odeslání souboru na server byl výsledek shodný s předchozím testem (zatížení procesoru bylo po celou dobu nižší než 5%). Bod nejvyšší zátěže (55%) nastal při vyhledávání souboru pro odeslání. Prohledávání je ale implementováno pomocí služby průzkumníka Windows a vytížení je pouze krátkodobé. 34
Obr. 10 - Vytížení procesoru klientské aplikace 2) Využití operační paměti Operační paměť využitá aplikací se po spuštění aplikace pohybovala v rozmezí 20 – 30 MB. Očekávaný výsledek byl nižší a takto vysoké číslo je s největší pravděpodobností dáno použitím velkého počtu proměnných a rozhraní Windows Forms. 5.1.2 Testování serveru Po umístění serveru na veřejné místo se rychlost příjmu většího objemu dat (získání informací o autorizovaných uživatelích) znatelně zpomalila. To jsme očekávali a je to dáno menší přenosovou rychlostí na internetu. Zatížení procesoru serveru bylo podobně jako v případu klientské části nízké (do 15%). Paměťová náročnost se pohybovala do 40MB. Tyto hodnoty se shodovaly s hodnotami zjištěnými na serveru, který běžel na internetu v rámci několika dní a ke kterému se během této doby připojovali, odpojovali uživatelé a probíhala mezi nimi interakce.
5.2 Problémy Hlavním problémem především klientské části je vysoká paměťová náročnost. Ta nebyla předpokládána a jedním ze základních úprav programu by mělo být její snížení. Aplikace má pouze omezené množství funkcí a vzhledově nepůsobí příliš uživatelsky přívětivě. Protože jsem se zaměřil pouze na textovou komunikaci, nejsou ostatní funkce implementovány. Nemůže se v oblasti možností srovnávat s běžnými komunikátory popsanými výše. Velikost datového úložiště je shora omezena. Nelze tedy ani online odesílat příliš veliké soubory.
35
6 Závěr V závěru bych rád shrnul výsledky práce, porovnal program ECom s popisovanými aplikacemi a nastínil možná vylepšení a úpravy, které by naprogramovanou aplikaci mohly dále rozšiřovat.
6.1 Shrnutí V bakalářské práci jsem analyzoval možná řešení a postupy při implementaci programu pro textovou komunikaci s dalšími funkcemi ve dvou hlavních vrstvách (logická a fyzická). Dále byly analyzovány existující programy v této oblasti z hlediska funkcí a principu fungování. Část textu byla věnována obecnému pohledu na aplikace typu klient-server. Dále jsem naprogramoval jednoduchý messenger pro ukázku konkrétní implementace aplikace.
6.2 Možné úpravy Program implementuje pouze základní funkce nutné pro textovou komunikaci a přenos souborů. Díky tomu, že server funguje jako poskytovatel služby, není problémem přidávat nové služby tak, aby jejich přidání příliš nezasahovalo do existujícího kódu programu. Základními úpravami, které by byli možné přidat dále jsou např: • Snížení paměťové náročnosti klientské části aplikace • Lepší grafické rozhraní (použití technologie WPF místo Windows Forms) • Podpora přenosu hlasu a videa • Rozšíření informací o uživatelích • Zavedení skupin a konferenčních komunikací • Zavedení online odesílání souborů samostatně bez omezení velikosti souboru • Změnit schéma databáze na distribuovanou, aby byla zajištěna vyšší dostupnost
6.3 Srovnání s popisovanými programy Vybraná kritéria pro porovnání s ostatními programy jsem odvodil od požadavků na implementaci programu. V tabulce jsou proto zapsány pouze funkce pro čistou komunikaci uživatelů.
36
Tabulka porovnání funkcí popisovaných aplikací a programu ECom Aplikace Funkce
ICQ Skype
Windows Live Messenger
ECom
Odesílání zpráv Offline zprávy Odesílání souborů
Offline soubory
Datové úložiště Datové úložiště na serveru – SkyDrive *
Datové úložiště
Přenos videa Přenos hlasu Možnost konference
Vytváření konferenčních skupin
Hlavní předností programu ECom jsou nízké výpočetní nároky, jednoduchost. Dále není na rozdíl od programů vybraných na analýzu komerčně založen.
*SkyDrive není přímou součástí Windows Live Messenger, ale služby, která messenger zapouzdřuje: Windows Live
37
7 Zdroje [1] Nagel C., Evjen B., Glynn J., Skinner M., Watson K. (2009): C# 2008 Programujeme profesionálně. Computer Press, a.s, Brno [2] Dostupná dokumentace protokolu OSCAR, http://iserverd.khstu.ru/oscar (2005) [3] Dostupná dokumentace protokolu MSNP, http://www.hypothetic.org/docs/msn/resources/projects.php (2003)
38
8 Přílohy 8.1 Uživatelská dokumentace – Server Pro běh serverové části je vyžadován operační systém (2000+) s podporou .net 3.0 s přístupem k přesně nadefinované databázi MS SQL. Celá aplikace je reprezentována pouze konzolou, na kterou se vypisují proběhnuté akce klientů. Funkce uživatele této aplikace je především monitorovací, případně bezpečnostní. Aplikace funguje zcela samostatně od chvíle jejího spuštění. 1) Správa datových úložišť Pokud chce správce spravovat datová úložiště klientů, nalezne veškeré sdílené soubory v adresáři files. Ten se nachází v adresáři s aplikací serveru. Každé datové úložiště je reprezentováno speciálním adresářem pojmenovaným id1xid2, kde id1 je id klienta s vyšším id. Správce může soubory klasickým způsobem přidávat nebo mazat. Pokud cílový soubor smazat nelze, znamená to, že je v tuto chvíli stahován a správce ho může smazat až po jeho stažení. 2) Správa čekajících zpráv Zprávy čekající na vyzvednutí se nacházejí v databázi, ke které je server připojen (defaultně user_database). Zprávy se dají rozlišovat podle položky MessageType. Jedná se o: ◦ ◦ ◦ ◦
„ME“ - Klasická zpráva, v položce TheMessage se nachází tělo zprávy „AR“ - Žádost o autorizaci „AA“ - Potvrzení žádosti o autorizaci „IN“ - Informační typ zprávy, v položce TheMessage se nachází informace
Správce serveru by neměl do databáze nijak zasahovat, případně pouze přidat informační zprávu například o datu, kdy nebude server funkční z důvodu údržby. 3) Možné problémy a jejich řešení ◦ Klienti se nemohou připojit, posílat nebo přijímat soubory. Zkontrolujte, zde je server připojen k síti a má pro klíčovou síť veřejnou IP adresu. Zkontrolujte nastavení brány firewall a případně povolte TCP porty: ▪ 8080 Pro komunikaci uživatelů 39
▪ 8082 Pro nahrávání souborů na server ▪ 8083 Pro stahování souborů ze serveru ◦ Server se nemůže připojit k databázi uživatelů. Zkontrolujte nastavení připojení k databázi a její dosažitelnost. Pokud je vše v pořádku restartujte počítač s databází a poté aplikaci serveru.
8.2 Uživatelská dokumentace – Klient Klientská aplikace vyžaduje ke svému fungování operačního systému Windows(2000+) s podporou .net 3.0. Samotná aplikace je portable, čili po její instalaci (rozbalení) je možné nakopírovat na libovolný počítač připojený k síti/internetu (záleží na umístění serveru) a aplikaci je možné bez další instalace používat. 1) Start aplikace Po startu aplikace se zobrazí hlavní formulář reprezentující online a offline uživatele. Uživatel má nyní dvě možnosti. Obě jsou reprezentovány tlačítkem v menu/hlavní: 1. Registrovat Pomocí tohoto tlačítka vytváří uživatel nový účet na serveru. Informace zadává uživatel do nového formuláře a potvrdí tlačítkem. Účet je chráněn heslem a při posílání hesla na server je toto heslo šifrováno. Jako odpověď na žádost o registraci server pošle uživateli informace o jeho účtu a to především jeho číslo id, které je kritické a uživatel se pomocí něho bude přihlašovat. Heslo ani id by neměl uživatel nikomu ukazovat. Po úspěšném vytvoření registrace je uživatel automaticky aplikací přihlášen svými údaji zadanými při registraci. 2. Přihlásit Tlačítko pro přihlášení na server pro registrované uživatele. Uživatel se přihlašuje pomocí svého unikátního id a hesla. Při špatném zadání přihlašovacích údajů se uživatel může stejným způsobem pokusit přihlásit znovu. Při úspěšném zadání údajů se ze serveru pošlou informace o jeho autorizovaných uživatelích a zobrazí se pro ně tlačítka v panelech online nebo offline podle toho, zda jsou uživatelé připojeni. Poslední možností je, že server informuje uživatele o tom, že je již na svůj účet přihlášen na jiném počítači. V tom případě se 40
uživatel v přihlášené aplikaci musí odhlásit a poté se může přihlásit zde. Aplikace nezávisle před odesláním přihlašovacích údajů kontroluje jejich správný formát. Id musí být číslo a heslo nesmí být pouze prázdný řetězec. V případě, že se nelze připojit k serveru, je uživatel po krátkém časovém intervalu informován, že je nemožné se k serveru připojit. Problémy způsobující tuto chybu mohou být následující: ▪ Není funkční připojení k lokální síti nebo internetu, čili neexistuje síťová cesta k serveru ▪ Aplikace je blokována pomocí brány firewall ▪ Špatně zadaná adresa serveru, ke kterému se uživatel připojuje ▪ Chyba na straně serveru Řešení těchto nestandardních situací je uvedeno v posledním odstavci spolu s dalšími problémy, které mohou nastat. V případě některého z těchto problému se stav aplikace vrátí do stavu před pokusem o přihlášení (resp. Registraci). 2) Běh aplikace Po úspěšném přihlášení na server se změní položky v menu/Hlavní. Jsou to: 1. Najít Pro vyhledávání uživatelů a posílání žádostí o autorizace. Po stisku tohoto tlačítka se objeví samostatný formulář pro vyhledávání uživatelů. Vyhledávat je možné pomocí tří parametrů – jména, příjmení a id. Pokud je vyhledáváno podle id, další dva parametry jsou ignorovány (i pokud jsou vyplněny). Dále může být vyplněn pouze jeden z parametrů jméno/příjmení a bude se vyhledávat podle tohoto parametru. Pokud jsou oba vyplněny, bude se hledat uživatel se zadaným jménem a příjmením. Vyhledávání v případě jména nebo příjmení je vyhledáváním na částečnou shodu. Není tedy nutné znát celé jméno nebo příjmení. Dále se ignorují rozdíly mezi velkými a malými písmeny (vyhledávání tedy není „case sensitive“). Alespoň jeden ze všech tří parametrů musí být vyplněn. Výsledky vyhledávání se zobrazí v dolní tabulce. Uživatel poté může libovolnou řádku označit a příslušnému dalšímu uživateli bude poslána žádost o autorizaci. Po potvrzení autorizace se tlačítko pro komunikaci s cílovým klientem přidá do příslušného panelu. 41
2. Odhlásit Pro odhlášení ze serveru. Aplikace uživatele odhlásí a přepne se do stavu po zapnutí. Server a autorizovaní online uživatelé jsou informováni o změnu stavu odhlášeného uživatele. 3. Ukončit Toto tlačítko je v menu/Hlavní po celou dobu od spuštění aplikace. Pomocí něho se uživatel odhlásí a aplikace se vypne. Stejnou funkci má i tlačítko (klasický zavírací křížek) v pravém horním rohu aplikace. 3) Komunikace s klienty Každý autorizovaný uživatel je reprezentován vlastním tlačítkem v hlavním okně. Po stisku pravého tlačítka myši na libovolném tlačítku reprezentujícím autorizovaného uživatele nabízí možnost změnit přezdívku tohoto uživatele. Po autorizaci uživatele je tato přezdívka automaticky nastavena na spojení uživatelova jména a příjmení. Možnost změny slouží především k zpřehlednění práce pro uživatele, který je tak schopen zabránit vícenásobnému výskytu uživatelů se stejným jménem. Po stisku tlačítka uživatele se otevře okno pro komunikaci s uživatelem. To se skládá ze dvou textových polí. V horním poli se zobrazuje probíhající komunikace a do dolního pole uživatel píše. Zpráva se odesílá pomocí kombinace kláves ctrl+enter nebo stiskem tlačítka Odeslat. V obou případech (cílový uživatel je připojen nebo odpojen) je zpráva odeslána a cílový uživatel si ji buď ihned vyzvedne, nebo si ji vyzvedne po připojení k aplikaci. Kromě textových polí obsahuje komunikační okno další tlačítka reprezentující další možnosti konkrétní komunikace. 1. Tlačítko s emotikony Po jeho stisknutí se uživateli otevře malý panel s všemi podporovanými emotikony. Při stisknutí libovolného tlačítka reprezentujícího emotikon se jeho kód vloží do textového pole pro odesílání zpráv. Poslední tlačítko v panelu slouží pro zapnutí/vypnutí překladu emotikonů. Po jeho stisknutí se budou/nebudou překládat kódy reprezentující emotikony na jejich obrázky. Uživatel nemusí emotikony vybírat pouze z panelu. Pokud zná jejich kód, tak jej může přímo psát do odesílacího textového pole a kód bude stejně jako v předchozím případě při odesílání přeložen na obrázek 42
(pokud je překlad zapnut). 2. Tlačítko Historie Zobrazí historii komunikace s uživatelem. Historie se zobrazí v samostatném formuláři jako prostý text bez překladu emotikonů. Po jejím zobrazení slouží tlačítko Historie pro její připoutání k pravému kraji komunikačního okna. Pokud chce uživatel historii obnovit, musí nejprve okno s historií zavřít, a poté znovu stisknout tlačítko Historie. 3. Tlačítko datového úložiště Slouží pro správu datového úložiště s cílovým klientem. Po jeho stisku se otevře formulář, ve kterém má k dispozici uživatel seznam souborů, které mají s cílovým uživatelem společně uložené na serveru a jsou jim oběma k dispozici. Dále také základní čtyři funkce, kde každá je reprezentována vlastním tlačítkem. 1. Obnovit seznam Získá ze serveru aktuální seznam sdílených souborů na serveru. Zobrazují se pouze kompletní soubory. V případě, že je další soubor do úložiště nahráván, zobrazí se informace o něm pouze v případě, že je tlačítko stisknuto až po jeho nahrání. Soubory se zobrazují v seznamu na levé straně panelu ve formátu: jméno souboru (velikost v optimálních jednotkách). Obnovování seznamu se provádí automaticky při otevření formuláře, po smazání a nahrání souboru. 2. Smazat Smaže soubor vybraný v seznamu. Není možné mazat soubor, pokud je právě cílovým nebo tímto uživatelem stahován. 3. Stáhnout soubor Stáhne soubor vybraný v seznamu na počítač, kde je spuštěna aplikace. Soubor je uložen do adresáře Přijaté_soubory v adresáři aplikace. Není možné stahovat soubor, který stahuje druhý uživatel a je nutné počkat, než soubor stáhne druhý uživatel. Je možné stahovat pouze jeden soubor, aby nebyla počítačová síť zbytečně zatěžována. Ihned po startu stahování souboru se objeví ve spodní části obrazovky ukazatel, na kterém uživatel vidí stav příjmu souboru. Výsledek stahování se zobrazuje nad ukazatelem postupu. Pokud je soubor stažen v pořádku, zobrazí se nápis „Hotovo“ a uživatel může 43
soubor používat. V případě, že se vyskytne problém při stahování souboru, není soubor smazán, neboť i jeho část může být pro uživatele užitečná (v případě videa/mp3). V případě, že už v adresáři soubor se stejným jménem existuje, je jméno nově přidaného souboru změněno podle klasických konvencí (před příponu souboru je přidáno číslo v závorkách), aby se zajistila unikátnost jmen souborů v adresáři. 4. Nahrát soubor Řídí se stejnými pravidly jako stahování souboru. Není možné nahrávat více souborů najednou. Výběr posílaného souboru je reprezentován klasickým průzkumníkem souborů Windows. Pokud je přenos předčasně ukončen, je na serveru část přijatého souboru smazána. Při zavření formuláře se přenos souboru (nahrávání či stahování) neukončí, ale pokračuje dál. Klasická komunikace s libovolným uživatelem během stahování nebo odesílání souboru je možná. Velikost datového úložiště pro každou dvojici uživatelů je shora omezena. Pokud by uživatel nahráním dalšího souboru přesáhl povolený limit, je serverem upozorněn a soubor se nenahraje. Při žádné z výše popsaných akcí nezáleží na stavu cílového klienta. 4) Zpracování příchozích požadavků Během práce s aplikací musí uživatel reagovat na akce ostatních klientů. Možné akce jsou: 1. Žádost o autorizaci Pokud některý z ostatních klientů žádá o autorizaci, znamená to, že chce nadále s uživatelem komunikovat. Při příjmu autorizačního požadavku se zobrazí zpráva s informacemi o žádajícím uživateli. Možnosti jsou: Zamítnout/Povolit. V případě zamítnutí se žádost zruší a oba uživatelé spolu nemohou komunikovat. Pokud uživatel žádost potvrdí, oběma uživatelům se přidá druhý uživatel do seznamu a budou spolu moci vzájemně komunikovat. 2. Příchozí zpráva Aby byl uživatel informován o tom, že přišla zpráva od jednoho z jeho autorizovaných uživatelů, začne tlačítko reprezentující tohoto uživatele červeně blikat. Blikání se ukončí stiskem tohoto tlačítka nebo kliknutím na komunikační okno s klientem, který zprávu odeslal 44
(na libovolnou jeho komponentu). 5) Možné problémy a jejich řešení 1. Není možné se přihlásit nebo zaregistrovat Zkontrolujte připojení k internetu (lokální síti pokud je server zde), případně opravte. Zkontrolujte nastavení firewall, zda není tato aplikace mezi blokovanými programy, případně ji povolte (jedná se o výstupní porty 8080, 8082, 8083). Pokud předchozí změny nepomohly, pravděpodobně je problém na straně serveru. V tomto případě je možné, že je server nedostupný pouze dočasně a doporučuje se v rámci dalších pěti minut pokusit o opětovné přihlášení nebo registraci. 2. Chyba při odesílání souboru Zkontrolujte, že soubor nepožívá jiná aplikace nebo proces a že je povolené ho číst. Další možností je překročení kapacity úložiště tímto souborem. V tomto případě je uživatel informován a k nahrání souboru je nutné některý jiný soubor/soubory smazat. Dále mohlo dojít k chybě na straně serveru, v tom případě se aplikace sama odpojí a nastaví do stavu před připojením. Uživatel se může pokusit o opětovné přihlášení. 3. Chyba při příjmu souboru Nejpravděpodobnější příčina ukončení příjmu souboru je chyba na serveru. Uživatelská aplikace se automaticky odhlásí a klient má možnost pokusit se přihlásit znovu.
8.3 Programátorská dokumentace - server Základními funkcemi serveru jsou: • Zprostředkování komunikační služby pro připojené uživatele • Vytvoření a správa datového úložiště pro dvojice uživatelů • Správa databáze a offline zpráv v ní uložených Hlavní technologií použitou při implementaci serverové části je technologie WCF. Server implementuje kontrakt služby, který popisuje službu poskytovanou serverem. Tuto službu využívají uživatelé. Dále je server připojen pomocí technologie LINQ k databázi, se kterou pracuje.
Databáze Použitá databáze je typu MS SQL database a obsahuje tři tabulky: 45
User (User_ID, Name, Surname, Password, Status, Server) Authorization (User_ID, Authorized_ID, Nick) Pendings (Message_ID, User_ID, Sender_ID, Date, Message_type, Message) V tabulce Users jsou uloženy informace o všech uživatelích, kteří se zaregistrovali na serveru, v tabulce authorizations seznam autorizací a v tabulce Pendings seznam čekajících zpráv pro všechny uživatele. Typy zpráv v tabulce Pendings: „ME“ - Klasická zpráva, v položce TheMessage se nachází tělo zprávy „AR“ - Žádost o autorizaci „CM“ - Informace o změně stavu uživatele, „AA“ - Potvrzení žádosti o autorizaci v položce TheMessage se 0 pro odpojení a 1 pro připojení ◦ „IN“ - Informační typ zprávy, v položce TheMessage se nachází informace ◦ ◦ ◦ ◦
Práce s databází S databází se pracuje pomocí technologie LINQ, kde je reprezentant databáze vytvořen v souboru databaseRepresentant.dbml. Ten popisuje kontrakt s databází. Samotnou interakci s databází zprostředkovává třída (soubor) userDatabaseClass(.cs). Obsahuje nutné proměnné a metody pro korektní práci s databází. Po vytvoření třídy se v konstruktoru vytvoří nový kontext podle reprezentanta databáze. Dále třída obsahuje tři objekty sloužící jako zámky (inicializace po startu) jednotlivých tabulek, takže je možné pracovat paralelně s více tabulkami najednou, ale není možná práce více procesů v jedné tabulce. Z důvodu nutnosti kontroly stavu uživatelů obsahuje dále třída časovač, který v pravidelném intervalu spouští kontrolu uživatelů. Funkce třídy reprezentovány samostatnými metodami jsou: • Přidání uživatele do tabulky User addUserToDatabase (jméno, příjmení, heslo) Vytvoří nový objekt typu User podle zadaných parametrů, uzamkne tabulku User a vloží vytvořený objekt do zamčené tabulky a zjistí id přidaného řádku. Odemkne tabulku a vrací získanéID. Používá se pouze při registraci nového uživatele. •
Přidání nové dvojice do tabulky autorizací addAuthorization (id1, id2, přezdívka1, přezdívka2) Vytvoří dva nové objekty typu Authorization podle zadaných parametrů tak, že přezdívka 1 odpovídá přezdívce prvního uživatele zadaná druhým uživatelem a naopak. Uzamkne tabulku Authorization, přidá do ní vytvořené objekty a následně jí opět odemkne.
•
Kontrola hesla uživatele checkPassword (id, heslo) 46
Zkontroluje, zda se heslo zadané parametrem shoduje s heslem v databázi pro uživatele s id. Při získání hesla z databáze je nutné zamknout a následně odemknout tabulku User. Vrací True v případě, že si hesla odpovídají, False jinak. •
Získání informace o uživateli getUserInfo (id) Vrací objekt typu User ze shodné tabulky, kde id uživatele odpovídá parametru. Opět je nutné tabulku zamykat.
•
Získání informací o všech autorizovaných uživatelích getAuthorizedUsers (id) Nejprve získá id všech autorizovaných uživatelů z tabulky Authorized (tabulka musí být zamčena), kde id uživatele je shodné s parametrem. Všechny výsledky uloží do pole a poté pro každý výsledek získá samostatně informaci pomocí funkce získání informace o uživateli. Všechny takto získané objekty typu User uloží do pole a to vrací.
•
Změna stavu některého uživatele changeStatus (id, nový stav) Uzamkne tabulku User a změní stav uživatele se zadaným id na zadanou hodnotu.
•
Přidání zprávy do fronty addMessageToPendings (id, id odesilatele, typ zprávy, zpráva) Vytvoří nový objekt typu Pending (čekající zpráva) podle parametrů, uzamkne tabulku Pending a objekt do ní vloží. Nakonec tabulku odemkne.
•
Přidání zprávy všem přihlášeným autorizovaným uživatelům konkrétního uživatele addMessageToUsersOnlineAuthorized (id, typ zprávy, zpráva) Nejprve získá id všech uživatelů, které má uživatel se zadaným id ve svých autorizovaných z tabulky Authorization (nutné zamykat) a uloží je do pole. Poté z tabulky User získá informace o jejich stavu (nutné zamykat) a vyřadí z pole nepřipojené uživatele. Informace o jejich stavu je nejjednodušší získávat pomocí funkce získání informací o uživateli. Nakonec podle zbylých id v poli přidá do tabulky Pending nové objekty shodného typu (nutné zamykat).
•
Vyhledání uživatele searchUser (kritéria typu user) Uzamkne tabulku User a získá pole objektů typu User podle zadaných kritérií. Pokud je zadané id uživatele různé od hodnoty 0, vyhledává se pouze id. V opačném případě jsou vyhledávacími parametry jméno a příjmení a vyhledává se na částečnou shodu. Odemkne tabulku a vrátí získané pole.
47
•
Získání čekajících zpráv getPendingMessages (id) Uzamkne tabulku Pending a získá z ní pole objektů typu Pending, kde id příjemce odpovídá zadanému id. Odemkne tabulku a vrátí získané pole.
•
Změna přezdívky changeNick (id měnícího uživatele, id měněného uživatele, nová přezdívka) V tabulce Authorization změní v řádku, odpovídající parametrům přezdívku na zadanou přezdívku (nutné zamykání).
•
Kontrola autorizace isAuthorizedCouple (id1, id2) Zjistí, zda tabulka Authorized obsahuje dvojici (id1, id2). Vrací True v případě nálezu, jinak False).
•
Kontrola stavu uživatelů Ověří, zda Tabulka User neobsahuje jiné řádky se stavem True, než ty, které jsou uloženy v globálním seznamu online uživatelů. U všech uživatelů, kde je stav True, ale nejsou v globálním seznamu, nastaví stav na False a funkcí přidání zprávy všem online autorizovaným uživatelům předá zprávu typu CM se zprávou 0, která indikuje odpojení uživatele.
Start aplikace Po startu aplikace je vytvořena služba, která je poskytována na portu 8080 na adrese počítače, kde je aplikace spuštěna. Dále na portech 8082 a 8083 (na shodné adrese) je vytvořen koncový bod, na kterém aplikace přijímá spojení pro příjem a odesílání souborů.
Poskytovaná služba Služba je definována v interface DataContr.cs a dále implementována třídou ContractImpl.cs. Jak interface, tak jeho implementace novou třídou jsou nutnou podmínkou k fungování WCF aplikace poskytující službu. WCF umožňuje vzdáleně volat metody serveru a používat uživatelsky definované třídy jako parametry metod a návratové hodnoty. Poskytované serializovatelné třídy jsou: 1. Třída user Popisuje jednoho uživatele a jeho vlastnosti: Jméno, příjmení, id a přezdívku. Používá se jako návratový objekt po přihlašování a přijetí autorizace. Dále se také používá jako parametr při vyhledávání uživatelů. 2. Třída message Popisuje zprávu pro libovolného uživatele, obsahuje samotnou zprávu, její typ, id odesilatele a samotnou zprávu, v případě speciálních zpráv může být položka samotné zprávy prázdná. 3. Třída fileInfo 48
Obsahuje informace o souboru, který se má přijímat nebo odesílat. Obsahuje jméno souboru, jeho velikost v bytech, IP adresu a port serveru, na kterém je soubor uložen. Poskytované metody: •
Metoda přihlášení login (id, heslo) Vrací pole autorizovaných uživatelů nebo null. Nejprve proběhne porovnání zadaného hesla s heslem v databázi. V případě, že si hesla neodpovídají, vrací metoda null. V případě, že se hesla shodují, vrátí metoda seznam autorizovaných uživatelů (viz. Třída user), který získá dotazem z třídy databáze. Dále z databáze získá id všech přihlášených uživatelů autorizovaných přihlášeným uživatelem a do tabulky čekajících zpráv všem přidá novou zprávu s informací o přihlášení uživatele.
•
Metoda registrace register (jméno, příjmení, heslo) Slouží pro registraci nového uživatele. Vloží do databáze do tabulky uživatelů nový záznam podle parametrů a vrací id vloženého záznamu.
•
Metoda odhlášení logoff (id, heslo) V případě, že kontrola hesla s databází neproběhne v pořádku, metoda dále žádné nové příkazy neprovádí. V případě shody je všem přihlášeným autorizovaným uživatelům přidána čekající zpráva o odhlášení uživatele.
•
Metoda vyhledání uživatele search (kritéria typu user, id, heslo) Nejprve je kontrolováno heslo uživatele a v případě shody je do databáze zadán dotaz podle vloženého parametru. Podle získaných výsledků z databáze se vytvoří pole objektů typu uživatel a to je vráceno.
•
Metoda zpracování příchozí zprávy sendMessage (id, heslo, id cílového uživatele, zpráva) Po ověření hesla se zpráva přidá do databáze do tabulky čekajících zpráv.
•
Metoda žádosti o autorizaci sendAuthorizationRequest (id žádajícího, id žádaného, heslo) Nejprve je ověřeno heslo žadatele. V případě shody s databází se do tabulky čekajících zpráv přidá zpráva s informací o žádosti o autorizaci.
•
Metoda potvrzení autorizace authorize (id žadatele, id potvrzujícího, heslo potvrzujícího) Návratovou hodnotou je objekt typu uživatel. Po ověření hesla se do tabulky čekajících zpráv přidá zpráva pro žadatele informující ho o přijetí jeho žádosti žádaným uživatelem a do autorizací je přidána nová 49
dvojice podle parametrů potvrzení. Vrací objekt typu uživatel s informací o žadateli. •
Metoda získání informací o konkrétním uživateli getMyUser (id, heslo, id žádaného uživatele) Návratovou hodnotou je objekt typu user. Slouží k získání informací o uživateli po přijetí žádosti o autorizaci z důvodu fungování jako služby. Po kontrole hesla uživatele se provede kontrola, zda jsou uživatelé vzájemně autorizovaní. V případě, že ano, vrátí metoda informace o žádaném uživateli.
•
Metoda stažení čekajících zpráv getMessages (id, heslo) Návratovou hodnotou je pole objektů typu message reprezentující všechny čekající zprávy. Po ověření hesla získá metoda z databáze všechny zprávy čekající na uživatele se zadaným id a vrátí je.
•
Metoda změny přezdívky cahngeNick (id, id autorizovaného, heslo, nová přezdívka) Zkontroluje platnost hesla. Pokud heslo odpovídá databázi, změní přezdívku autorizovaného uživatele.
•
Metoda získání seznamu souborů dvojice uživatelů listFiles (id1, id2, heslo) Nejprve zkontroluje platnost hesla. Poté porovná id a případně prohodí hodnoty tak, aby id1 > id2. Dále zjistí informace o všech souborech v adresáři: files/id1xid2, vytvoří podle nich pole objektů typu fileInfo a ty vrátí.
•
Metoda smazání souboru deleteFile (id1, id2, heslo, jméno souboru) Podobně jako v předchozí metodě porovná heslo a případně prohodí id1 a id2. Poté se pokusí smazat soubor se zadaným jménem, pokud soubor neexistuje, zavolá tuto metodu u ostatních serverů. Vrací True, pokud uspěje sám, nebo libovolný z ostatních serverů, jinak False.
•
Žádost o odeslání souboru sendFileRequest (id1, id2, heslo, jméno soubor, délka souboru v bytech) Zkontroluje heslo, v případě, že je heslo v pořádku zkontroluje, zda velikost souboru v součtu s již uloženými soubory nepřesahuje nastavenou maximální mez datového úložiště. V případě, že mez přesahuje, vrátí False a skončí. V opačném případě přidá do globálního slovníku povolených příjmů novou položku identifikovanou id odesilatelem obsahující informace o souboru a vrátí True.
•
Připojení serveru serverHello (id serveru, IP adresa, port) Slouží pro připojení serveru a následné umožnění komunikace s ním. 50
Kontrakt reprezentující server je přidán do slovníku serverů. •
Ping serveru sreverPing (id serveru) Slouží pouze pro kontrolu, zda je danný server funkční.
Veřejné položky Veřejné položky jsou statické proměnné ve třídě Program(.cs) . Jedná se o: • Objekt reprezentující databázi (typu userDatabaseClass) Tento objekt je vytvořen pouze jednou a nemůže být vytvořena ve třídě implementující kontrakt, neboť ta se vytvoří samostatně pro každého uživatele. • Slovník žádostí o nahrání souboru • Slovník žádostí o stažení souboru • IP adresa a port, na kterých je poskytována služba a přijímání a stahování souboru • Maximální velikost souboru • Slovník ostatních serverů indexovaných podle jejich id Zpracování příjmu a odesílání souborů Probíhá v samostatném vlákně na portu 8082 a 8083. Pokud se některý z uživatelů pokusí navázat datové spojení, vytvoří speciální objekt typu filesReciever/filesSender a v novém vlákně začne v tomto objektu přijímat/odesílat soubor.
Třída pro příjem/odesílání dat (filesReciever/filesSender) Objekt tohoto typu se vytváří po spojení s uživatelem na portu 8082/8083. Ze vzniklého spojení se získá datový stream. První odeslanou zprávou je id uživatele, který žádá o odeslání/přijetí souboru. Podle id je získáno z globálního slovníku jméno souboru, případně jeho velikost. V případě odesílání zprávy začne server odesílat po částech (1024B, poslední je případně kratší). V případě třídy pro přijímání souborů obsahuje další metodu, která upraví jméno souboru tak, aby bylo unikátní oproti všem ostatním v adresáři. Řídí se základní konvencí vkládání čísla v závorce před příponu souboru. V případě jakékoliv chyby jak při příjmu, tak při odesílání souboru, se veškeré streamy uzavřou a v případě přijímání se stažená část smaže. Popis datového kontraktu a kontraktu databáze Konfiguračním souborem po datový kontrakt a kontrakt databáze je soubor App.config ve formátu XML. Popisuje přihlášení k databázi v položce ConnectionString. Vlastnosti WCF jsou zapsány v položce bindings.
8.4 Programátorská dokumentace – klient Základními funkcemi jsou: • Umožnit komunikaci s ostatními klienty • GUI • Zprostředkovat připojení k serveru • Ošetření nestandardních situací 51
Hlavní technologií použitou pro komunikaci se serverem je WCF. Server funguje jako služba, kterou klient vzdálené využívá pomocí datového kontraktu. Vlastnosti WCF jsou definovány souborem App.config, především nastavení koncového bodu, na kterém je poskytována služba. Samotná služba je nadefinována souborem ContractImpl(.cs). Tento soubor je vygenerován pomocí SvcUtil.exe na straně serveru. GUI je vytvořeno pomocí Windows forms.
Schéma aplikace Hlavní formulář aplikace (Form1(.cs)) Hlavním formulářem aplikace je třída Form1. Obsahuje menu s položkou Hlavní a dva panely pro zobrazení tlačítek online a offline uživatelů. Dalšími položkami jsou: • Slovník uživatelů s jejich id jako klíči • Id přihlášeného uživatele a jeho heslo • Časovač pro příjem zpráv • Objekt typu DataContr reprezentující datový kontrakt • Slovník s emotikony
Třída reprezentující uživatele (user) Každý autorizovaný uživatel je reprezentován objektem typu user. Ten obsahuje základní informace o uživateli (jméno, příjmení, id, stav, přezdívku), tlačítko, časovač ovládající blikání tlačítka a komunikační okno pro konverzaci s daným uživatelem. Dále obsahuje referenci na hlavní okno a slovník s emotikony a heslo pro kontrolu při odesílání a příjmu souborů. Dále obsahuje metody nezbytné pro práci s uživatelským tlačítkem: Přidání tlačítka do správného panelu addButton () Nastaví tlačítko uživatel (nápis, formát, zarovnání) a přidá ho do správného panelu podle stavu uživatele. Zařadí ho mezi tlačítka, která již v panelu jsou tak, že posune pozici všech tlačítek, které mají v alfabetickém uspořádání větší hodnotu o velikost přidávaného tlačítka dolů a na vzniklé volné místo vloží tlačítko. Změna stavu uživatele moveUser (Nový stav) Přesune tlačítko do správného panelu podobně jako v případě přidávání tlačítka. V panelu, ze kterého je tlačítko odebíráno, se posunou všechna tlačítka s vyšší hodnotou alfabetického uspořádání o výšku tlačítka vzhůru a do druhého panelu se přidá stejné jako v případě vkládání tlačítka. Rozblikání/ukončení blikání tlačítka startBlicking/stopBlicking () Tyto metody pouze spustí/zastaví časovač pro blikání tlačítka. Funkcí 52
časovače je měnění barevného podkladu tlačítka na červenou barvu a poté zpět na původní. Další metody zpracovávají příchozí/odchozí zprávy •
Zpracování příchozí zprávy getMessage (zpráva) Zpráva je předávána parametricky a je pouze předána dále komunikačnímu oknu, kde je následně zpracována a zobrazena v zobrazovacím poli.
•
Zpracování odchozí zprávy sendMessage (zpráva, datum a čas) Podobně jako v předchozím případě je zpráva předána dále. Zde je předána metodě hlavního formuláře. Ten zpracovává většinu požadavků ze strany klienta.
Hlavní částí jsou metody pro využívání služby poskytované serverem, jímž odpovídá vzdálené volání metod serveru pomocí datového kontraktu: •
Metoda registrace register (jméno, příjmení, heslo) Zavolá vzdáleně metodu registrace (register) na straně serveru s vloženými parametry registrace. V případě, že vzdálené volání nelze provést, zobrazí se chybové oznámení informující uživatele o nedostupnosti serveru. V případě, že metoda proběhne bez chyby, zobrazí se informace přijaté jako návratová hodnota vzdáleného volání.
•
Metoda odeslání zprávy sendMessage (zpráva, id cílového uživatele) Zavolá metodu odeslání zprávy na serveru se shodnými parametry jaké byly předány této metodě. V případě neúspěchu se zobrazí chybové hlášení a je zavolána metoda odhlášení.
•
Metoda přihlášení / přihlášení / změny přezdívky uživatele / žádosti o autorizaci / potvrzení žádosti o autorizaci Stejně jako v předchozím případě se pouze zavolá vzdálená metoda na serveru se shodnou funkcí.
•
Metoda příjmu zpráv recieveMessages () Tato metoda se spouští automaticky v pravidelných časových intervalech pomocí časovače. Zavolá se vzdálená metoda příjmu zpráv na serveru. Návratovou hodnotou je pole objektů typu message. V závislosti na typu každé konkrétní zprávy je zpracována. ◦ Klasická zprávy (typ zprávy = „ME“) Je předána odpovídajícímu uživateli. ◦ Požadavek o autorizaci (typ zprávy = „AR“) Zobrazí se informační okno, kde uživatel může autorizaci zamítnout nebo 53
potvrdit. V případě potvrzení je vzdáleně na serveru zavolána metoda potvrzení žádosti o autorizaci a zároveň získány informace o žadateli. ◦ Potvrzení žádosti o autorizaci (typ zprávy = „AA“) Vzdáleně se zavolá metoda pro přidání uživatele, který autorizaci potvrdil. ◦ Zpráva o změně stavu některého z uživatelů (typ zprávy = „CM“) V tomto případě se na objektu reprezentujícím uživatele zavolá metoda přesunutí jeho tlačítka do správného panelu. ◦ Informační zpráva (typ zprávy = „IN“) Text této zprávy se pouze zobrazí v novém informačním okně.
Třídy Spojené s hlavním formulářem (loginWindow(.cs), registerWindow(.cs)) Jedná se o formuláře pro přihlašování a registraci uživatele. Jsou vytvořeny (zobrazeny) po stisku tlačítka v menu. Slouží pro vkládání a kontrolu vložených dat uživatelem. Po potvrzení správnosti dat je zavolána odpovídající metoda hlavního formuláře. V obou případech je zadané heslo zašifrováno metodou MD5 hash a uloženo v hlavním formuláři pro použití dalšími metodami.
Třída komunikačního okna (commWindow(.cs)) Jedná se o formulář Windows forms a slouží pro komunikaci s jedním dalším klientem. Jeho vytvoření případně zobrazení je voláno stiskem tlačítka reprezentujícího konkrétního uživatele v hlavním formuláři. Obsahuje dvě textová pole pro zobrazování a zápis textu, dále objekt typu fileStorage pro správu datového úložiště, formulář pro čtení historie, datový kontrakt předaný od hlavního formuláře a informace o cílovém uživateli získané z vlastností uživatele. Dále obsahuje metody potřebné pro překlad emotikonů: Hlavní metoda dostává jako parametr text, který se má zobrazit ve čtecí části formuláře. V případě, že je zapnut překlad emotikonů, použije slovník s emotikony na postupné trojice znaků a pokud je trojice nalezena, je nahrazena emotikonem ze slovníku. V opačném případě se celá zpráva vloží do čtecí části. Další metodou je metoda vytvoření panelu pro zobrazení dostupných emotikonů: Pro každý emotikon ze slovníku je vytvořeno speciální tlačítko s obrázkem tohoto emotikonu. Akce jeho stisku je vložení kódu do vkládacího pole. Toto tlačítko je poté přidáno na malý panel. V případě odeslání zprávy je samotná zpráva předána objektu vlastnícímu tento formulář. Formulář obsahuje tři tlačítka •
Tlačítko historie Jeho stisk vytvoří nový formulář typu historyReader. V případě, že formulář existuje, přesune ho k pravé části komunikačního formuláře.
•
Tlačítko emotikonů Zobrazí nebo skryje formulář s tlačítky reprezentujícími jednotlivé emotikony.
54
•
Tlačítko datového úložiště V případě, že formulář správy datového úložiště není inicializován, vytvoří nový. V opačném případě formulář zobrazí.
Formulář pro zobrazení historie (historyReader(.cs)) Tento formulář obsahuje pouze okno pro zobrazení historie. Po vytvoření tohoto formuláře se ze souboru s historií identifikovaného id obou klientů načte historie po řádcích. V případě, že soubor s historií neexistuje nebo nelze přečíst, zobrazí se informační zpráva.
Třída správy datového uložiště (fileStorage(.cs)) Tento formulář se skládá ze seznamu objektů a tlačítek pro obnovení seznamu, nahrání souboru, smazání souboru a stažení souboru. Dále obsahuje informace o id obou uživatelů a datový kontrakt pro spojení se serverem. Fungování tlačítek je následující: •
Obnovení seznamu Z datového kontraktu zavolá vzdálenou metodu získání informací (ListAllFiles), která vrátí seznam informací o souborech. Po získání seznamu se položky v seznamu pro zobrazování nahradí získanými položkami.
•
Smazání vybraného souboru Pomocí datového kontraktu se vzdáleně zavolá metoda smazání souboru (deleteFile) se jménem vybraného souboru jako informací o souboru, který se má smazat. Server vrací odpověď, zda proběhla operace v pořádku. V případě chyby se zobrazí chybová informační zpráva. V opačném případě se zavolá metoda obnovení seznamu.
•
Nahrání souboru na server Nejprve se vytvoří klasický formulář průzkumníka Windows, ve kterém uživatel vybírá soubor, který má být na server nahrán. Po vybrání souboru se pomocí datového kontraktu zavolá vzdálená metoda na serveru s žádostí o odeslání souboru, parametry jsou jméno a velikost souboru v bytech. V případě, že návratová hodnota metody je False, zobrazí se varovná zpráva. V případě, že návratová hodnota je True, vytvoří se nová instance třídy pro odesílání souborů (fileUploader) a v novém vlákně se spustí metoda objektu pro odeslání souboru.
•
Stažení souboru z datového uložiště Podobně jako v případě nahrávání souboru se nejprve vzdáleně zavolá metoda serveru s žádostí o stažení souboru (recieveFileRequest), ta je přeposlána cílovému serveru. Jako parametr se použije jméno souboru vybraného v seznamu. Vytvoří se nová instance třídy pro přijímání souborů (fileDownloader) a v novém vlákně se spustí metoda pro přijímání souborů.
Třídy pro odesílání a přijímání souborů (fileUploader a fileDownloader) Tyto třídy slouží jako obal pro metodu odeslání/přijmutí souboru. Obsahují 55
informace o velikosti souboru, jméně a id žadatele. V obou případech se vytvoří datové spojení typu IP adresu serveru na port 8082/8083. Z datového spojení se serverem získá metoda datový stream, přes který bude odesílat/přijímat soubor. Jako první pole bytů pošle streamem id klienta. Nyní se v závislosti na tom, zda je soubor odesílán nebo přijímán, se prostřednictvím streamu začnou odesílat/přijímat části souboru (v případě odesílání se načítají z vybraného souboru, v případě přijímání se ukládají do souboru jehož jméno bylo definováno). Části jsou pole bytů o velikosti 1024 (1kB), kromě posledního, který může být kratší. Během odesílání/přijímání je v závislosti na počtu odeslaných bytů měněn stav ukazatele postupu při operaci. Při chybě nebo ukončení operace se uzavře spojení se serverem a se souborem, do kterého byla data ukládána nebo z kterého byla data čtena.
8.5 Přiložené CD Součástí práce je CD obsahující verzi textu ve formátu pdf a implementovaný program ECom. Pro případné testování aplikace je v adresáři Client-global spustitelná klientská část aplikace, která se připojuje k veřejnému serveru a funguje tedy globálně. Dále v adresáři Source jsou zdrojové kódy klientské a serverové části a SQL skript pro vytvoření databáze.
56
