4. ledna 2011
eské vysoké u£ení technické v Praze Fakulta elektrotechnická
Diplomová práce
Okamºité sledování polohy
Bc. Michal ábela
Vedoucí práce: Ing. Jan Kubr
Studijní program: Elektrotechnika a informatika (magisterský), strukturovaný Obor: Výpo£etní technika
leden 2011
ii
Pod¥kování Ing. Janu Kubrovi, vedoucímu této diplomové práce za rady a vst°ícný p°ístup, který mi v¥noval. Také bych rád pod¥koval panu Tomá²i Petrºilkovi, zástupci rmy Sport-door s.r.o. za návrh zajímavého tématu.
iii
iv
Prohlá²ní Prohla²uji, ºe jsem svou diplomovou práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon). V Hluboké nad Vltavou dne 3. ledna 2011 ........................................................
v
vi
Abstrakt Práce obsahuje p°ehled o technologii GPS, jsou rozebrány r·zné p°ístupy k práci s daty geogra cké polohy a jejich distribuce ostatním uºivatel·m pomocí sít¥ mobilních telefon·. Stru£n¥ jsou popsány existující aplikace zabývající se tímto problémem. Na základ¥ sebraných zku²eností je vytvo°en návrh a poté i implementace prost°edí p°enosu t¥chto informací, v návrhu je kladen d·raz na optimalitu p°enosového protokolu.
Abstract This work contains review of GPS technologies, there are described dierent approaches for manipulating with data which contain geographic coordinates and distributing these data via cellphones network for other users. There are brie y described existing systems working on same ground. With these experiences is built a concept and than implementation of new system, which provides transfering of these data. In this concept is accentuated the transfer protocol.
vii
viii
Obsah 1 Úvod
1
1.1
Cíle práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.3
Podrobné poºadavky na výslednou aplikaci
1.4
Vymezení pojmu GPS
. . . . . . . . . . . . . . .
2
. . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2 Technologické moºnosti
8
2.1
GPS komunika£ní standardy GPRS . . . . . . . . . . . . . . . . . . . .
2.2
Moºnosti klientských za°ízení
2.3
2.4
9
. . . . . . . . . . . . . . . . . . . . . . .
11
. . . . . . . . . . . . . . . . . . . . . . . . .
11
2.2.1
Opera£ní systémy
2.2.2
Srovnání oper£ních systém·
. . . . . . . . . . . . . . . . . . .
14
Technologie p°enosu dat . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.3.1
Protokoly transportní vrstvy
15
2.3.2
Protokol aplika£ní vrstvy - HTTP
2.3.3
Webové sluºby, RPC technologie
. . . . . . . . . . . . . . . . .
16
2.3.4
Vývoj vlastních protokol· . . . . . . . . . . . . . . . . . . . . .
19
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Distribuce a vizualizace dynamických dat 2.4.1
16
. . . . . . . . . . . . . . . .
20
AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3 Existující °e²ení
22
3.1
Dostupné komer£ní a volné aplikace
. . . . . . . . . . . . . . . . . . .
22
3.2
Analýza moºností . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
3.3
Aplikace rozhodnutí
25
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Návrh vlastního systému LiveTracking 4.1
4.2 4.3
27
Klientská aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.1.1
Uºivatelské rozhraní
. . . . . . . . . . . . . . . . . . . . . . . .
27
4.1.2
Spojení se serverem
. . . . . . . . . . . . . . . . . . . . . . . .
4.1.3
Obsluha bluetooth za°ízení
4.1.4
Vnit°ní struktura klientské aplikace
. . . . . . . . . . . . . . . . . . . .
28 30
. . . . . . . . . . . . . . .
30
Protokol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
Serverová aplikace
44
4.3.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vnit°ní struktura serverové aplikace
. . . . . . . . . . . . . . .
44
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
4.4
Databáze
4.5
Webová aplikace
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Testování navrºeného systému
46
47
5.1
Testy datové náro£nosti
. . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.2
Testy stálosti p°ipojení . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
ix
6 Uºivatelská p°íru£ka
49
6.1
Klientská aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
6.2
Webové rozhraní
52
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Záv¥r
53
7.1
Zhodnocení práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
7.2
Dal²í vývoj
53
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
x
1
Úvod
1.1
Cíle práce
Cílem této práce je p°inést p°ehled o systémech umoº¬ující sledování polohy za°ízení, o jejich moºnostech a p°edpokládaném dal²ím vývoji. Druhým úkolem je seznámení s technologiemi umoº¬ujícími roz²í°ení pasivních za°ízení pro sledování polohy do aktivní podoby, tedy s technologiemi p°enosu dat mezi klientskou a serverovou aplikací. Dále zhodnocení, která z t¥chto technologií je pro daný problém nejvhodn¥j²í. T°etím úkolem je zanalyzovat a ve form¥ krátké re²er²e p°edstavit existující °e²ení podobných systém·. Posledním úkolem je zhodnocení v²ech sebraných dat a návrh systému, který bude optimáln¥ pokrývat pot°eby sluºby aktivního sledování. Momentáln¥ je na internetu moºné nalézt v¥t²í mnoºství aplikací pracujícím na principech aktivního sledování, jsou to aplikace komer£ní i voln¥ ²i°itelné. V²echny tyto aplikace v²ak implementují r·zn¥ sloºité a hlavn¥ r·zné typy protokol·. N¥které aplikace vyuºí-
1
vají standardizované cesty pro spojení klienta a serveru pomocí RPC metod , jiné jdou cestou vývoje vlastního p°enosového protokolu. Tyto protokoly jsou v²ak vºdy zam¥°ené pouze pro pouºití v jedné konkrétní aplikaci a není moºné je vyuºít v jiné, která vyºaduje charakteristický p°ístup k dat·m. Proto se cílem této práce stává p°edev²ím návrh takového protokolu, který by se mohl stát tv·rcem standardu na základ¥ jeho univerzálnosti, p°ehlednosti, jednozna£nosti a subtilnosti.
1.2
Motivace
Vznik této práce byl podpo°en my²lenkou vytvo°ení sluºby p°enosu v²eobecných informací, p°edev²ím v²ak informací o poloze mobilního za°ízení a tedy i jeho uºivatele. Tyto informace mohou být velice prosp¥²né pro dohled nad zranitelnými osobami (d¥ti, senio°i...), pro získání informací o dopravních komplikacích a plynulosti provozu, pro organizaci akcí s více osobami. Dále pro p°enos dat mezi jednotlivými aktivními uºivateli tém¥° zdarma a pro mnoho dal²ích aplikací, které implementují výsledky této práce. Vzorovými aplikacemi, pro které by výsledky této práce byly p°ínosem a na základ¥ kterých by mohly stav¥t sv·j systém mohou být následující:
Elektronická kniha jízd umoº¬uje vypsání knihy jízd d°íve, neº °idi£ zaparkuje v garáºi. Celá trasa cesty je zaznamenána do souboru, jsou ur£eny klí£ové body cesty, její délka a doba trvání, to v²e bez práce. Výhodou m·ºe být také moºnost zji²t¥ní aktuální polohy remních automobil· a komunikace s nimi. Elektronická ch·va pomocí této aplikace bychom mohli sledovat pohyb d¥tí (vlast-
1 RPC
(Remote Procedure Calling) je technika vzdáleného volání procedur, více v kapitole 2.3.3
1
ních) v p°ed²kolním a mlad²ím ²kolním v¥ku, kdy jsou nejvíce zranitelné a zárove¬ za£ínají samostatn¥ poznávat okolní sv¥t. V kaºdý moment bychom v¥d¥li, kde se na²e dít¥ nachází i kdyº není v daný okamºik vid¥t z okna. Elektronický hlída£ auta pro dohled nad vozidlem lze také pouºít systém vystav¥ný na základech této práce, p°i umíst¥ní jednoduchého modulu obsahujícím GPS p°ijíma£ a schopného komunikace s mobilní sítí kamkoliv do vozidla, získáme p°ehled nad aktuální pozicí tohoto vozidla. V p°ípad¥ krádeºe nenahraditelný pomocník. Bez
Kolon komplexní systém vyuºívající interakci více uºivatel·. Kaºdý uºivatel systemu pohybující se automobilem je vybaven touto aplikací, která na základ¥ jeho umíst¥ní a rychlosti pohybu v²ech uºivatel· dokáºe automaticky predikovat, p°ípadn¥ de novat konkrétní dopravní komplikace jako jsou zácpy, nehody aj. Pokud se automobily na dálnici pohybují rychlostí ch·ze, je pravd¥podobné, ºe tento úsek je obtíºn¥ pr·jezdný. Na základ¥ sdílení informací je kaºdý uºivatel informován o vý²e zmín¥ných komplikacích.
Moºností vyuºití znalosti polohy libovolného po£tu uºivatel· nebo p°ístroj· £i stroj· je nespo£et, jist¥ lze na tomto základ¥ vytvo°it i zajímavé interaktivní hry v terénu.
1.3
Podrobné poºadavky na výslednou aplikaci
Cílem této práce je p°edev²ím návrh nového protokolu pro p°enos dat mezi za°ízeními v systému aktivního sledování polohy. Pokud chceme tento protokol uvést do ºivota a prezentovat jeho schopnosti, je t°eba navrhnout také odpovídající koncové aplikace a uºivatelská rozhraní, proto se tyto £ásti stávají nedílnou sou£ástí práce. Z poºadavku správného chodu p°enosového protokolu, který zajistí dostupnost v²ech sluºeb, vyplývají také poºadavky na aplikace s tímto protokolem pracující. Protokol samotný by m¥l mít následující vlastnosti:
Moºnost snadné roz²i°itelnosti protokolu v rámci de novaných sluºeb i v rámci
2
sluºeb nových
2V
Odolnost proti podvrhu zprávy p°ípad¥ vyuºití protokolu jiným vývojá°em je moºné, ºe jej budou chtít vyuºít pro p°enos dat
v jiném formátu, který nebude odpovídat ºádné dosud implementované £ásti, proto je nutné vytvo°it protokol, který toto roz²í°ení bezbolestn¥ umoºní.
2
Moºnost kombinovat zprávy jednotlivých sluºeb Jednozna£ná identi kace uºivatele Nejmen²í moºná reºie k p°ená²eným dat·m
Dále jsou pro bezchybný p°enos informací a moºnost vyuºití obousm¥rné komunikace (klient - server) klí£ové tyto vlastnosti prost°edí:
Zabezpe£ení stálého komunika£ního kanálu mezi serverovou a klientskou aplikací i v prost°edí nestálé dostupnosti datových sluºeb
Moºnost buerování
3 zpráv v p°ípad¥ nedostupnosti komunika£ního kanálu.
Moºnost prom¥nného £asového intervalu odesílání zpráv
Následuje soupis poºadovaných vlastností jednotlivých sou£ástí systému, které prezentují práci p°enosového protokolu
Klientská aplikace
Intuitivní uºivatelské gra cké ovládání
Moºnost výb¥ru z dostupných bluetooth za°ízení
Moºnost odesílat a p°ijímat zprávy uºivatel·
Moºnost uchovávat p°ihla²ovací údaje a údaje o naposledy p°ipojeném za°ízení pro vyuºití p°i dal²ím spu²t¥ní
Moºnost minimalizace na pozadí
Zabezpe£ení stálého spojení TCP kanálem
Ukládání v²ech datových zpráv pro pozd¥j²í odeslání v p°ípad¥, ºe není
4 se serverovou aplikací
5
k dispozici sí´ operátora , nebo není moºné se p°ipojit z jiných d·vod· a jejich zaslání v okamºiku sestavení spojení
3 Buerování
dat spo£ívá ve vytvo°ení zásobníku zpráv, které je²t¥ nebyly odeslány. Odeslané
zprávy se z tohoto zásobníku odstra¬ují. V p°ípad¥ neschopnosti aplikace zprávu odeslat se zprávy hromadí v tomto zásobníku a v okamºiku dostupného spojení jsou odeslány v²echny naráz.
4 Jedná
se o spojové spojení pomocí protokolu TCP. Více o této technice je uvedeno v kapitole
2.3.1
5 Sítí
operátora je v tomto kontextu my²lena p°ístupová sí´ poskytovatele spojení mobilních tele-
fon· do vn¥j²ích sítí. V sou£asnosti se v R jedná p°edev²ím o rmy Vodafone, O2 a T-mobile.
3
Moºnost vzdáleného °ízení aplikace na základ¥ podn¥tu daného serverovou aplikací zm¥nit frekvenci zasílání zpráv
1.4
Serverová aplikace
Moºnost obsluhovat zárove¬ více uºivatel·
Moºnost vzdáleného °ízení klientských aplikací
Komunikace s webovým rozhraním sluºby
Webové rozhraní sluºby
Visuální prezentace dat doru£ených klientskými aplikacemi
Uºivatelsky diferencovaný p°ístup
Zasílání textových zpráv uºivatel·m v terénu
Vymezení po jmu GPS
GPS neboli Global Positioning Systém je vojenský systém umoº¬ující zji²t¥ní geogra cké polohy kdekoliv na sv¥t¥. Je provozován Ministerstvem obrany Spojených stát· amerických. P°esnost ur£ení polohy se ve vojenském sektoru po£ítá na centimetry, ve ve°ejném sektoru na metry. Systém GPS byl vystav¥n na p·vodním systému NAVSTAR GPS a za£átek jeho vývoje lze umístit do sedmdesátých let minulého století. V sou£asnosti je v provozu
°
31 druºic, jejihº dráhy jsou od sebe posunuty o 60 , na kaºdé dráze je umíst¥no 5-6 druºic za sebou ve vý²ce 20200km, viz obrázek 1.
4
Obrázek 1: Vizualizace rozmíst¥ní GPS satelit· na ob¥ºné dráze, zdroj [40]
Nyní je moºné si ve zkratce p°edstavit princip ur£ování geogra cké polohy. P°edpokládejme, ºe známe rychlost ²í°ení sv¥tla ve vakuu, pokud bychom pot°ebovali de novat svoji polohu v jednorozm¥rném prostoru, tedy ur£it polohu na úse£ce, posta£ily by nám dva vysíla£e signálu na obou koncích této úse£ky. Vzhledem ke známé dob¥ ²í°ení signálu dokáºeme p°esn¥ de novat na²i polohu triviálním zp·sobem. Ilustrace tohoto p°ípadu je na obrázku 2.
Obrázek 2: Ur£ení polohy v 1D prostoru, zdroj [36]
Toto je v²ak pouze teoretický základ, který p°i ur£ení polohy na Zemi nikdy nevyuºijeme, pokud bychom roz²í°ili pokusný jednorozm¥rný prostor do plochy a pokou²eli se ur£it polohu uºivatele stále pouze pomocí dvou vysíla£·, získali bychom nekone£né mnoºství moºných bod· výskytu p°ijíma£e signálu, tyto body by byly prvky hyperboly, jejíº jedna z vlastností je stejný rozdíl vzdáleností bod· na ní leºících od obou jejích ohnisek. Ilustrace tohoto p°ípadu je na následujícím obrázku 3.
5
Obrázek 3: Ur£ení polohy ve 2D prostoru, zdroj [36]
Ani tento výsledek není uspokojivý a nedává uºivateli p°esnou p°edstavu o jeho konkrétní poloze. Proto je t°eba do soustavy p°idat dal²í vysíla£ signálu, coº zp·sobí moºnost de novat dal²í dv¥ hyperboly na jejihº pr·se£íku leºí pozorovatel. Tímto tedy získáme konkrétní p°edstavu o poloze, ov²em pouze v plo²e. Ilustrace tohoto p°ípadu je na obrázku 4.
6
Obrázek 4: Pr·se£ík t°í hyperbol, zdroj [36]
Chceme-li tedy získat p°edstavu o poloze v prostoru, je t°eba získat informace alespo¬ ze 4 r·zných vysíla£·. V praxi toto znamená následující pokud má za°ízení zi²´ující geogra ckou polohu signál ze £ty° a více vysíla£· (satelit·), dokáºe vypo£ítat svoji polohu v prostoru, tedy i nadmo°skou vý²ku, pokud má tento p°ístroj k dispozici signál pouze ze t°í vysíla£· satelit·, pro ur£ení se jako referen£ní veli£ina uºije povrch Zem¥, tedy není moºné zjistit aktuální nadmo°skou vý²ku (za p°edpokladu, ºe p°ístroj nedisponuje dodate£ným zdrojem informací). V p°ípad¥ signálu z mén¥ neº t°í vysíla£· satelit· není moºné ur£it polohu. P°i m¥°ení polohy je t°eba zahrnout do výpo£tu korekce na speciální a obecnou teorii relativity vzhledem k rozdílnému chodu hodin na palub¥ rychle se pohybujícího satelitu a na Zemi, dal²í korekce zahrnují korekce na nepravidelný tvar (elipsoid) Zem¥, ²í°ení signálu po k°ivce vlivem zpoºd¥ní v ionosfé°e a dal²í. Pokud £tená°e tato problematika zajímá, doporu£uji literaturu [27], nebo´ zmín¥né téma není nosným prvkem této práce.
7
2
Technologické moºnosti
Konven£ní zp·soby sledování polohy
S konven£ním zp·sobem sledování polohy
a p°ístroji toto umoº¬ující jist¥ kaºdý oby£ejný £lov¥k p°ichází £asto do styku, nej£ast¥ji v podob¥ osobních naviga£ních p°ístroj· pro volný £as, p°ípadn¥ pro silni£ní navigaci. Tyto p°ístroje jsou v drtivé v¥t²in¥ pouze pasivními p°íjemci signálu GPS, který dokáºí transformovat na aktuální pozici. P°ípadn¥ také dokáºí ur£it dal²í infor-
6 a v p°ípad¥ dostate£ného po£tu viditelných 7 GPS satelit·, tedy takových od kterých dokáºe p°ístroj získat validní signál , je mace jako je rychlost pohybu, azimut
moºné ur£it také nadmo°skou vý²ku. Tyto p°ístroje dokáºí data pouze p°ijímat, n¥které vy²²í modely silni£ních naviga£ních p°ístroj· dokáºí p°ijímat také signál pozemních stanic, který de nuje problémová místa z hlediska plynulosti provozu, tato data jsou v²ak vygenerována na základ¥ podn¥t· vzniklých jinou cestou, tedy ne na základ¥ zp¥tné vazby pasivních GPS p°ístroj·.
Aktivní p°ístup ke sledování
Znát vºdy p°esn¥ svoji polohu je vºdy p°íjemné a
uºite£né, a´ jiº p°i vysokohorské tú°e nebo p°i hledání správné ulice ve velkom¥st¥. Ov²em pro n¥které aplikace je velice d·leºité a výhodné znát polohu ú£astník· systému, m·ºe se jednat o online sledování vozidel, zam¥stnanc·, p°átel, d¥tí atd. Pro moºnost vzdáleného sledování je t°eba, aby za°ízení poskytovalo kanál nejen pro p°íjem GPS dat, ale také pro odesílání t¥chto dat uºivateli, který ºádá o polohu sledovaného za°ízení. S dostupnými technologiemi se tento komunika£ní kanál vytvá°í pomocí spojení za°ízení do internetu, resp. na konkrétní server dané sluºby, kde jsou data distribuována konkrétním uºivatel·m. Z vý²e uvedeného vyplývá, ºe za°ízení, která poskytují aktivní sledování uºivatele, musí obsahovat modul spojení s internetem, tento modul je ve v¥t²in¥ p°ípad· zastoupen modulem mobilního telefonu se SIM kartou, který poskytuje GPRS
8 /3G 9
p°ípadn¥ jinou technologii p°ipojení. Alternativou k tomuto spojení m·ºe být p°ipojení pomocí WiFi technologie, toto spojení je v²ak nevyuºívané z d·vodu omezeného roz²í°ení p°ístupových bod· a tedy je moºné se p°ipojit pouze na p°edem de novaných místech. Schematické vyjád°ení systému aktivního sledování naleznete na níºe uvedeném obrázku 5.
6 Azimut je orientovaný úhel, který svírá sm¥r pohybu od sm¥ru severního [28] 7 Signál je t°eba získat alespo¬ od 4 satelit·, viz kapitola 1.4 8 GPRS (General Packet Radio Service) je technologie pro paketový p°enos dat [30]
9 3G
je ozna£ení pro t°etí generaci mobilních telefon· [29]
8
pomocí sít¥ GSM
Obrázek 5: P°enos informace v systému aktivního sledování, zdroj vlastní a internet
Prost°edky aktivního sledování
V p°edcházejících odstavcích jsme si uvedli moºnosti
sledování polohy uºivatel·, bylo °e£eno, ºe klientská aplikace bude jako hostitelské za°ízení vyuºívat mobilní telefon s moºností p°íjmu GPS signálu, data jsou zasílána serverové aplikaci sluºby a zobrazena webovým rozhraním. Následující odstavce pojednávají o moºnostech a technologiích pot°ebných ve v²ech krocích p°enosu informace.
2.1
GPS komunika£ní standardy GPRS
Komunikace mezi GPS moduly a ostatními uºivatelskými za°ízeními probíhají v drtivé v¥t²in¥ pomocí protokolu NMEA 0183. Alternativu poskytuje protokol GPS-
10 pod-
200A, který v²ak není b¥ºnými za°ízeními jako jsou GPS bluetooth moduly
porován, proto jej zde dále nezmi¬uji a zam¥°ím se výhradn¥ na komunika£ní protokol NMEA 0183
11 .
10 B¥ºné uºivatelsky dostupné za°ízení v cen¥ do 2000K£ 11 NMEA (National Marine Electronics Association)
9
(leden 2011)
NMEA 0183
P°i komunikaci uºívající protokol NMEA (National Marine Elec-
tronics Association) 0183 jsou klientská aplikaci doru£ovány NMEA sentences, tedy v¥ty podle standardu NMEA, které lze rozd¥lit na dotazovací v¥ty, proprietární v¥ty a v¥ty mluv£ího, tyto jednotlivé moºnosti si nyní postupn¥ rozebereme.
Dotazovací v¥ty NMEA
Pomocí t¥chto v¥t m·ºe poslucha£ zaslat podn¥t
vysíla£i k odesílání v¥t pouze ur£itého typu, Obecná stavba této v¥ty je následující: $ttllQ,sss
, kde znak dolaru ($) uvozuje novou v¥tu, následující dva znaky (tt) identi kují ºádající stranu, dal²í dva znaky jsou ozna£ení dotazovanou stranu, dal²í znak Q de nuje, ºe se jedná o dotazovací v¥tu, tedy tento znak je p°ítomen vºdy, dal²í t°i znaky de nují kód v¥ty o který poslucha£ ºádá a následuje pouze dvojité od°ádkování. Tímto je tedy moºné vysíla£i NMEA v¥t ur£it, které v¥ty chce poslucha£ p°ijímat.
Proprietarní v¥ty NMEA
Tyto v¥ty jsou v reºii výrobc· a poskytují jim
prostor pro de nici vlastních v¥t, tyto v¥ty jsou uvozeny znaky $P, v na²í implementaci se s t¥mito v¥tami nesetkáme, proto ani zde je nebudu více zmi¬ovat.
V¥ty mluv£ího NMEA
Posledním, ov²em nejd·leºit¥j²ím typem v¥t jsou v¥ty
mluv£ího, které p°ená²í konkrétní informace o poloze, po£tu satelit·, rychlosti atd. Tyto v¥ty mají následující obecnou skladbu: $ttsss,d1,d2,.... . Op¥t jsou uvozeny znakem dolar ($), následující dva znaky (tt) p°edstavují identi kaci mluv£ího, následující t°i znaky (sss) popisují typ v¥ty, která následuje, dal²í údaje jsou jiº samotné v¥ty de nované podle typu konkrétní v¥ty, jednotlivé údaje vety jsou vºdy odd¥lené znakem , (£árka), pokud je p°ed znakem uveden znak * (hv¥zdi£ka), následující údaj je kontrolním sou£tem, který je proveden operací XOR
12 ze v²ech
znak· mezi znaky $ a *. P°íklad nej£ast¥ji vyuºívané v¥ty RMC - Recommended Minimum Navigation Information
13 :
$GPRMC,170138.615,A,4912.2525,N,01635.0378,E,0.04,16.43,280705*32 V²echny údaje jsou odd¥lené £árkami, jak jiº bylo zmín¥no a tyto údaje de nují následující: £as, stav, zem¥pisná ²í°ka, rozli²ení severní - jiºní ²í°ky, zem¥pisná délka,
12 XOR je binární operace de novaná na dvou vstupech, 13 Minimální doporu£ená informace pro navigaci
10
je funkcí sou£tu modulo 2
rozli²ení východní - západní délky, rychlost, azimut, datum, deklinace, rozli²ení deklinace východ - západ, kontrolní sou£et.
Obrázek 6: Ukázkový záznam NMEA komunikace pomocí programu Nmeamon, zdroj [41]
2.2
Moºnosti klientských za°ízení
2.2.1 Opera£ní systémy Trh s chytrými telefony, tedy t¥mi, o kterých °ízení se stará n¥který z opera£ních systém·, zaznamenává neustálý vzestup. Prodeje mobilních telefon· jsou na neustálém vzestupu, který je zap°i£in¥n jist¥ také konstantním sniºováním po°izovací ceny takovýchto za°ízení. K dne²nímu dni (prosinec 2010) je moºné zakoupit mobilní telefon s opera£ním systémem Symbian resp. Android za cenu p°ibliºn¥ 3500k£.[21, 22] Z nejznám¥j²ích a nejvyuºívan¥j²ích opera£ních systém· (dále OS) vybereme následující zástupce, které lehce p°edstavím a uvedu charakteristiku OS v kontextu vyuºití pro aplikace aktivního sledování polohy.
Symbian
Symbian S60 (nejroz²í°en¥j²í verze tohoto OS) pouºívá mnoho p°ístroj·
Nokia, jmenovit¥ celá °ada N a °ada E, také n¥které p°ístorje °ady C a X a také n¥které p°ístroje °ady 5 a 6. Tedy v²echny aktuáln¥ vyráb¥né chytré telefony výrobce Nokia vyuºívají opera£ní systém Symbian S60. Firma Samsung vyrábí jen men²í mnoºství model· pouºívající tento opera£ní systém, v¥t²ina mobilních telefon· tohoto výrobce disponuje jiº novým, na Linuxu zaloºeném OS Bada. Vzhledem je jeho prozatmnímu minoritnímu zastoupení na trhu jej dále nezmi¬uji. Sony Ericsson vyuºívá tento opera£ní systém p°edev²ím ve své t°íd¥ U, dále u svých historichkých model·. Dal²í výrobci uºívající tento opera£ní systém jsou jen okrajoví hrá£i, nabízí pouze n¥kolik model· s tímto opera£ním systémem, p°ípadn¥ se v eské republice na trhu vyskytují
11
pouze v malém procentu. OS Symbian je momentáln¥ nejroz²í°en¥j²í opera£ní systém pro mobilní za°ízení na sv¥t¥, hlavn¥ díky vyuºití pro mobilní telefony Nokia. Na konci roku 2009 jej vyuºívalo 46,9% chytrých telefon·.[20] Trend dominantního hrá£e na trhu je v sou£asné dob¥ mírn¥ ohroºen posilováním pozice OS Android, který zabírá stále v¥t²í podíl trhu.
Charakteristika OS Symbian[23]
podpora multitaskingu
14
obrovská základna uºivatel· p°edpokládané udrºení dominantního zastoupení v rámci OS pro mobilní telefony
vývoj v jazyku Pearl
15 aplikací
podpora J2ME
Velkou výhodou tohoto OS je bezproblémový chod aplikací zaloºených na J2ME, není tedy nutné vyuºívat pouze nativní prost°edí pro dopl¬ující aplikace.
Windows mobile
Na za£átku roku 2010 byl p°edstaven nový systém Windows
Mobile 7 (dále jen OS WM7). Pro p°ípadný vývoj má tedy smysl uvaºovat tuto platformu a nikoli zastaralý WM6. OS WM7 vyuºívá více r·zných výrobc· mobilních za°ízení nejedná se pouze o mobilní telefony, ale také palmtopy. Jediní výrobci zam¥°ující se £ist¥ na OS WM7 a mající nezanedbatelné procento svých výrobk· na trhu je rma HTC a £áste£n¥ Samsung. Tito výrobci se zam¥°ují na úpravu OS WM7 do podoby vyhovující jejich výrobk·m pomocí nejr·zn¥j²ích nadstaveb a dopl¬k·. OS WM7 má n¥kolik z°ejmých nevýhod [24]: chyb¥jící multitasking, který aplikaci pozastaví a v¥t²inu výkonu p°id¥lí nové aplikaci. Aplikace je mnoºné instalovat pouze p°es sluºbu Marketplace. A£ se OS WM7 pomalými kroky vyvíjí, jednotlivé verze na sebe nechávají £ekat stále déle a lze o£ekávat jeho pomalý zánik. Firma Microsoft za£íná spolupracovat s výrobcem mobilních telefon· Nokia a vytvá°í pro OS Symbian (který pouºívá drtivá v¥t²ina chytrých telefon· této zna£ky) kancelá°ský balík O ce, donedávna dostupný pouze pro platformu OS WM7, tímto vytvá°í rma Microsoft sama sob¥ konkurenci
14 Multitasking
je schopnost systému spou²t¥t pseudoparaleln¥ 2 a více proces·, pokud hardware,
který je systémem vyuºíván disponuje více jádry výpo£etní jednotky, kaºdý proces b¥ºí na svém jádru
15 J2ME
(Java Micro Edition)je jednou ze základních platforem jazyku Java, nabízí API pro vývoj
software pro malá za°ízení jako jsou mobilní telefony
12
a odborníky utvrzuje v postupném zániku platformy, zvlá²t¥ v p°ípad¥ odklon¥ní zájmu výrobc· HTC a Samsung, kte°í jiº nyní promý²lejí p°estup na OS Android rmy Google.
Android
Jedná se o velmi mladý OS první ohlá²ení na konci roku 2007 vyvinutý
rmou Google na linuxové platform¥ . V sou£asné dob¥ OS Android instalují do n¥kterých svých produkt· výrobci HTC, Samsung, Sony Ericsson, LG a dal²í, na evropském trhu mén¥ významní výrobci. P°echod produkt· HTC a Samsung z OS Windows Mobile na OS Android by zp·sobilo pravd¥podobn¥ de nitivní zánik OS Windows Mobile a naopak by posílilo pozici jiº nyní velmi dynamicky se rozvíjejícího trhu mobilních za°ízeních pracujících s OS Android. [20]
Charakteristika OS Android
Multitasking Moºný vývoj aplikací v J2ME s ur£itým omezením - nevyuºívá se standardní JVM (Java Virtual Machine), ale Dalvik virtual machine[25, 26]
16
Lze p°edpokládat strmý nár·st zastoupení na trhu[20]
BlackBerry
OS BlackBerry je speci cký svým roz²í°ením pouze v p°ístrojích ste-
jnojmenné zna£ky, podobn¥ jako je tomu nap°íklad u opera£ního systému pro iPhone. V porovnání s p°ístroji iPhone v²ak toto za°ízení vyuºívá jiná skupina uºivatel·, kte°í vlastní tento mobilní telefon zvlá²t¥ kv·li snadnému p°ístupu ke své emailové schránce a dal²ím kancelá°ským funkcím a nejsou tedy tolik nad²enými uºivateli feature aplikací. Toto kritérium je t°eba pro vývoj budoucích aplikací jist¥ také zváºit.
Charakteristika OS BlackBerry
Multitasking Moºný vývoj aplikací v J2ME Pom¥rn¥ silná základna uºivatel· s vý²e uvedeným omezením
16 Software
vyvinutý v jazyku Java je spou²t¥n na virtálním stroji, který nabízí rozhraní mezi Java
prost°edím a prost°edím systému. Pro standardní systémy se vyuºívá JVM (Java Virtual Machine).
13
iPhone (iOS)
Jedná se o dal²í Unix-like opera£ní systém, orientuje se pouze na
výrobky rmy Apple. Tento opera£ní systém je v r·zných modi kacích pouºit v mobilních telefonech iPhone, tabletech iPad a n¥kterých multimediálních p°ehráva£ích iPod.
Charakteristika OS iPhone (iOS)
vývoj v jazyku Objective-C prodej aplikací pomocí AppStore v p°ístrojích integrovaný GPS NEpodporuje aplikace v programovacím jazyku Java Silná a stále siln¥j²í základna uºivatel· [20]
Produkty rmy Apple zaºívají v posledních n¥kolika letech silné posilování pozice na trhu. IPhone OS pomalu sniºuje náskok OS Symbian. Podle pr·zkum· agentury AdMob jsou uºivatelé iPhone OS (spolu s uºivateli OS Android) nejaktivn¥j²í uºivatelé mobilních sluºeb a aplikací.
2.2.2 Srovnání oper£ních systém· Podle dosavadního vývoje trhu opera£ních systém· pro mobilní telefony, je moºné zavrhnout vývoj zam¥°ený p°ímo na platformu Windows Mobile kv·li její pochybné stálosti na trhu. V p°ípad¥ p°echodu spole£ností HTC a Samsung na platformu OS Android se z OS Windows Mobile stane okrajový a málo vyuºívaný systém. Donedávna nejmén¥ zastoupený opera£ní systém na trhu, av²ak velmi intenzivn¥ vyvýjející se a prosazující se systém Android je z pohledu efektivnosti investice do budoucna zajímavou alternativou. Tento systém podporuje pln¥ a efektivne multitasking, aplikace lze vytvá°et v programovacím jazyku Java (p°i optimalizaci pro Dalvik VM) a poskytuje mnoho knihoven pro práci se systémem. V neposlední °ad¥ také pro práci s GPS za°ízeními. Tichým hrá£em, ov²em nikterak slabým jsou p°ístroje BlackBerry vyuºívající stejnojmenný opera£ní systém. Tyto p°ístroje jsou svými majiteli vyhledávány p°edev²ím pro své nesporné klady v kancelá°ské oblasti. Ov²em i tyto p°ístroje ve své nejvy²²í t°íd¥ nabízí zabudovaný GPS modul. Výhodou OS BlackBerry je moºnost programování nových aplikaci v jazyku Java a plný multitasking.
14
Momentáln¥ nejsiln¥j²í pozici na trhu mobilních telefon·, resp. jejich opera£ních systém· má OS Symbian. Programování aplikací pro tuto platformu probíhá v programovacím jazyku Pearl a obsahuje API
17 pro práci s externími i interními GPS
moduly. OS Symbian disponuje plným multitaskingem a také bezproblémovou podporou J2ME. Opera£ní systém pro p°ístroje iPhone a jiné od zna£ky Apple se velice rychle blíºí p°ebrání dominantní role na trhu opera£ních systém· pro mobilní aplikace. Nové verze systému jiº podporují multitasking. P°i programování aplikací pro iPhone se vyuºívá C-like programovací jazyk, lze pracovat i s interním GPS modulem. V následující tabulce je uvedeno shrnutí a prognóza zastoupení jednotlivých opera£ních systém· v následujících letech. [20] OS
2009
2010
2011
2012
Symbian
46,9%
40,1%
34,2%
30,2%
Android
3,9%
17,7%
22,2%
29,6%
iOS
14,4%
15,4%
17,1%
14,9%
Windows Mobile 7
8,7%
4,7%
5,2%
3,9%
Tabulka 1: Procentuální zastoupení jednotlivých OS nov¥ prodaných mobilních telefon· s predikcí dat v následujících letech[20]
Z vý²e uvedené tabulky je z°ejmé, ºe v p°ípad¥ pot°eby vývoje aplikace v jednom programovacím jazyce a p°i pot°eb¥ maximálního moºného roz²í°ení je optimální vyvinout tuto aplikaci v J2ME, v p°ípad¥ optimalizace pro Dalvik VM, který vyuºívá OS Android bude do jisté míry zaji²t¥na teoretická moºnost pokrytí více neº 50% trhu nyní i v následujících letech.
2.3
Technologie p°enosu dat
2.3.1 Protokoly transportní vrstvy Sí´ová komunikace mezi dv¥ma za°ízeními (po£íta£i) probíhá obvykle na sedmi vrstvách modelu
18 ISO OSI, kdy se kaºdá vrstva od p°edcházející li²í úrovní abstrakce, násle-
dující protokoly se nachází p°ibliºn¥ ve st°edu modelu a sice na £tvrté transportní vrstv¥.
UDP
Jedná se o nespojovou sluºbu, kaºdý odesílatel ode²le datagram pro p°íjemce
a jiº se nikterak nestará o jeho správné a v£asné doru£ení, o toto se musí postarat n¥který z aplika£ních protokol·. Jeho charakteristika se hojn¥ vyuºívá p°i tvorb¥ ob¥ºník·, nap°íklad ve sluºb¥ ProgresiveRealAudio a obecn¥ ve sluºbách, kde nevadí
17 API (Application Programming Interface) je rozhraním pro 18 ISO/OSI obsahuje sadu vrstev (7) protokol· z nihº kaºdá sluºby nad°azené vrstv¥
15
programování aplikací ur£uje míru abstrakce a poskytuje
výpadek n¥kterých ztracených nebo po²kozených datagram·. Pokud konkrétní aplikace vyºaduje garanci doru£ení informace a je z n¥jakého d·vodu t°eba vyuºít UDP protokol, je nutné aplikovat n¥který z potvrzovacích princip· doru£ených datagram·, nap°íklad metodou klouzavého okénka.
TCP
Je spojovou sluºbou vytvá°ející na dobu spojení dvou aplikací mezi nimi vir-
tuální pln¥ duplexní okruh, tedy data mohou být sou£asn¥ p°ená²ena ob¥ma sm¥ry. P°i vyuºití protokolu TCP odpadá aplikaci starost o doru£ení nebo korektnosti doru£ených dat, pokud jsou n¥která data ztracena £i po²kozena, jsou na základ¥ protokolu znovu vyºádána. Adresace probíhá na základ¥ IP adresy za°ízení a portu na kterém stanice naslouchá a vysílá. Velkou výhodou oproti protokolu UDP p°i realizaci komunikace mezi serverem a mobilním za°ízením je moºnost dvoustranné komunikace, tedy odeslání dat nejen ve sm¥ru klient
server, ale také ve sm¥ru server
klient.
2.3.2 Protokol aplika£ní vrstvy - HTTP Aplika£ní vrstva, neboli pátá vrstva ISO OSI modelu zahrnuje velké mnoºství protokol· ze kterých pro na²e vyuºití vybereme pouze jeden v²eobecn¥ známý protokol HTTP. Jedná se o hypertextový protokol prvotn¥ ur£ený pro vým¥nu dokument· ve formátu HTML. Tento protokol spolupracuje na niº²í vrstv¥ s protokolem TCP. Jedná se o bezstavový protokol, jehoº komunikace probíhá na principu dotaz odpov¥¤. Tento protokol je £asto pouºíván také pro p°enos dat webových sluºeb, viz dal²í odstavec. Více o tomto protokolu se dozvíte v literatu°e.
2.3.3 Webové sluºby, RPC technologie RPC je technologie, umoº¬ující p°enesení výpo£etní zát¥ºe na externí server a vytvo°ení jistého black boxu, od kterého po zaslání vstupních dat obdrºíme výstup, aniº bychom se museli starat o výpo£etní, p°ípadn¥ jiné mechanismy, které vedly k obdrºenému výstupu. Klientské aplikace vyuºívající tyto technologie lze nazvat tenkými klienty, nebo´ klientské prost°edí poskytuje pouze rozhraní pro zadávání dotaz· a prezentaci výsledk· proces·, které byly vykonány vzdálen¥ na (výpo£etn¥ siln¥j²í) serverové stran¥. Alternativou tenkého klienta je tlustý klient, kde dochází nejen ke generování vstupních a výstupních událostí, ale také k výpo£t·m s daty získanými ze serverové strany systému. Na serverové stran¥ systému m·ºeme tedy nalézt pouze systém °ízení báze dat. Alternativní moºné tlou²´ky klient· de nuje obrázek.
16
Obrázek 7: Moºnosti rozloºení zát¥ºe mezi klentem a serverem, zdroj [42]
XML-RPC
Jedná se o jednu z nej£ast¥ji pouºívaných technologií na poli RPC.
Pro p°enos dat se vyuºívá zapouzd°ení zna£kovacím jazykem XML, díky tomuto je zaji²t¥na kompatibilita mezi r·znými vývojovými platformami. Knihovny XML-RPC lze nalézt u mnoha vývojových jazyk· a proto není problém s p°izp·sobením. P°i práci s xmlrpc není t°eba se zabývat samotným XML o coº se stará automatická serializace. Ale vzhledem k p°enosu dat pomocí xml v²ak tato technologie není vhodná pro p°enos v¥t²ích soubor·. Komunikace pomocí XML-RPC probíhá p°es protokol HTTP. Datová náro£nost p°enosu pomocí XML-RPC uvaºuji pouze data nad TCP segmentem. I p°i minimální komunikaci pomocí XML-RPC je t°eba p°ená²et dohromady HTTP hlavi£ku a XML-RPC. Formát XML dokumentu pro spu²t¥ní metody pomocí XML-RPC:
POST /server.cz HTTP/1.0 Host: xmlrpc.server.cz Content-Type: text/xml Content-length: 314 <methodCall> <methodName>trida.jmenoMetody <params> <param> 10 Jedná se pouze o p°enos minimálních informací, tedy spu²t¥ní metody jmenoMetody s jedním jednoduchým parametrem. Tento jednoduchý dotaz zabere p°ibliºn¥ 250B, odpov¥¤ serveru a návrat hodnoty výstupu zabere p°ibliºn¥ 200B, tedy p°enos
17
jedné informace mezi klientskou aplikací a serverovou aplikací si vy výsledku vyºádá cca 500B.
SOAP
Neboli Simple Object Access Protocol spadá do kategorie webová sluºba
stejn¥ jako XML-RPC a zaji²´uje vým¥nu zpráv zaloºených na XML v¥t²inou pomocí standardního HTTP. Protokol SOAP je zam¥°en pouze na kódování dat a jejich p°enos, tedy je dokonale nezávislý na programovacím jazyku a platform¥. Pro kaºdou webovou sluºbu by m¥l být k dispozici popis v jazyce WSDL
19 ,
pomocí tohoto popisu je moºné automaticky generovat poºadavek v SOAP. Je moºné tuto sluºbu zaregistrovat v UDDI (zase poznamka pod carou) registru.
Obrázek 8: Souvislosti mezi SOAP, WSDL a UDDI, zdroj [43]
Ukázka zprávy typu poºadavek vypadá následovn¥:
POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="Some-URI"> <symbol>DIS 19 WSDL
popisuje co nabízí webová sluºba za funkce a zp·sob, jak se jí na to zeptat
18
První £ást obsahuje standardní hlavi£ku http, následuje samotný SOAP. Tento se skládá z následujících £ástí:
SOAP Envelope obálka pro de nici obsahu zprávy, oprávn¥ní, volitelné poloºky SOAP Body p°enos informace pro de nici volané sluºby, p°edávání parametr· a de nice návratových hodnot
Ve vý²e zmín¥né ukázce poºadavku de novaného pomocí SOAP je z°ejmá náro£nost na datový p°enos i pro p°enos minimální informace, v tomto p°ípad¥ se jedná p°ibliºn¥ o 400 B jen pro poºadavek, odpov¥¤ sluºby je p°ibliºn¥ podobn¥ rozsáhlá, tedy p°i aktualizaci informovanosti klienta je t°eba p°enést alespo¬ 800B dat.
Dal²í protokoly Hessiantento
Dále do této kategorie spadají protokoly jako Hessian nebo Burlap.
Jedná se o binární protokol, díky tomuto je mnohem úsporn¥j²í,
neº protokoly zaloºené na XML, p°ená²ená data i reºie je vyjád°ena úsporn¥ji. Protokol Hessain je moºné pouºít pro RPC volání, ale také pro pouhé asynchronní zasílání zpráv, které mohou, ale nemusí být potvrzeny. Na stran¥ serveru protokol Hessian komunikuje se servletem. Pro p°enos protokolu Hessian se pouºívá protokol HTTP, kterým se v²ak zvy²uje datový tok mezi za°ízeními. HTTP je nutností, nebo´ sluºba, pro kterou jsou data ur£ena je de nována p°ímo v url dotazu
Burlap
20 .
Je jednoduchý protokol vyuºívající pro komunikaci XML, p°itom z XML
se vyuºívá pouze ta nejnutn¥j²í £ást z d·vodu úspory. Je zam¥°en speciáln¥ na spolupráci s Enterprise Java Bean na serverové stran¥. Tuto spolupráci nabízí i nejavovským klient·m. Pro p°enos protokolu Burlap je vyuºit protokol HTTP tedy p°enosová reºie je op¥t navý²ena o hlavi£ku tohoto protokolu.
2.3.4 Vývoj vlastních protokol· V p°edcházejících kapitolách jsme si uvedli technologie vhodné pro p°enos dat v architektu°e klient server, tyto techniky jsou obecn¥ velmi roz²í°ené a jejich pouºití je nenáro£né, knihovny podporující n¥kterou z vý²e uvedených RPC metod jsou k dispozici pro v¥t²inu programovacích jazyk·. Tedy jednoduchý vývoj aplikací
20 Url
dotazu je internetová adresa na které se nachází daná sluºba, url m·ºe obsahovat také dal²í
volitelné poloºky v GET polích
19
postavených na t¥chto technologiích je nesporným kladem. Ov²em tato jednoduchost je vyváºena, v intencích této práce nep°ijatelným, zvý²eným tokem dat mezi klientskou a serverovou aplikací. Pokud bereme v úvahu uºivatele, který chce pouºívat aplikaci sledování jen nárazov¥ a jinak datové p°enosy nevyuºívá, je pro tohoto uºivatele jist¥ nep°ijatelné platit svému mobilnímu operátorovi desítky korun za denní pouºívání této aplikace. Proto pokud chceme získat i tyto uºivatele, je t°eba minimalizovat datový tok na nezbytné minimum. Vývojá°i zabývající se podobnými aplikacemi pouºívají v¥t²inou dv¥ techniky vý²e zmín¥né RPC metody, p°ípadn¥ jiné, datov¥ stejn¥ náro£né (mnoho protokol· je skrytých a lze se pouze domnívat podle objemu p°ená²ených dat, jaké techniky vyuºívají), dal²í alternativou pro aplikace, které pot°ebují také minimální datový tok je odesílání pouze holých dat bez jakéhokoliv zapouzd°ení, pouze v de novaném po°adí. Cesta takovýchto minimálních informací zaru£uje doopravdy minimální moºný datový tok a tedy i minimální náklady na provoz aplikace, ov²em velkou nevýhodou tohoto druhu p°enosu je nemoºnost zobecn¥ní p°ená²ených dat, nemoºnost p°ená²ení jiných dat, neº jsou de nována v jednom balíku, nemoºnost odhalení chyby, nebo neúplnosti doru£ené informace a v drtivé v¥t²in¥ p°ípad· nulové zabezpe£ení proti podvrhu zprávy. Vý²e uvedené d·vody ukazují na pot°ebu tvorby protokolu, moºného tv·rce standardu p°i tomto stylu komunikace, tedy potvrzují pot°ebu tvorby protokolu, který dokáºe kombinovat poºadavky na minimální datový tok a maximální informovanost koncových aplikací o typu a formátu dat. Tento protokol musí být snadno roz²i°itelný pro dal²í sluºby a musí vºdy p°ená²et pouze opravdu relevantní a poºadované informace. Návrhem tohoto protokolu se zabývá kapitola £íslo 4 a 5.
2.4
Distribuce a vizualizace dynamických dat
Pro komfortní prezentaci uºivatelských dat je zapot°ebí poskytnout p°ehledné a snadno ovladatelé webové rozhraní. Pro vizualizaci map na základ¥ geogra ckých údaj· se jako optimální jeví p°enesení t¥chto dat p°ímo do mapového podkladu, tímto aplikace nabídne uºivateli místo nep°ehledné haldy £ísel záznam sledování ve form¥ k°ivky zakreslené v map¥. S p°ihlédnutím k faktu, ºe se data m¥ní s postupným pohybem uºivatele v terénu, je t°eba tato data automaticky obnovovat a na£ítat stále aktuální hodnoty. Triviálním °e²ením budiº na£ítání celé internetové stánky, coº je uºivatelsky velice nekomfortní, pomalé a náro£né na datový tok. Proto je t°eba klí£ové údaje, které se mohou m¥nit obnovovat selektivn¥ a zi²´ovat jejich aktuální hodnotu na pozadí aplikace. Pro °e²ení tohoto problému se jako optimální °e²ení jeví technologie AJAX viz odstavec níºe.tento
2.4.1 AJAX Pod pojmem Ajax, neboli Asynchronous Javascript And Xml, se neskrývá jedna
20
jedna technologie, nebo implementace, pod pojem AJAX lze zahrnout Document Object Model (DOM), XMLHttpRequest, HTML, CSS, JavaScript. Na rozdíl od konven£ního webového modelu, kde je pro kaºdou zm¥nu zobrazovaného obsahu obnovit obsah celé na£tené strany, tato akce je náro£ná z pohledu p°enosu dat s £ímº úzce
21 ,
souvisí i £asová náro£nost obnovení celého prost°edí. P°i pouºití XMLHttpRequest
který je základem technologie AJAX, je moºné získat aktuální data pouze pro ur£ité £ásti jiº na£tené strany pomocí libovolného po£tu nezávislých poºadavk·. Princip komunikace klienta a serveru p°i vyuºití AJAXu je z°ejmý z následujícího obrázku.
Obrázek 9: Srovnání klasického p°ístupu k obnov¥ dat webové aplikace a pomocí AJAX technologie, zdroj vlastní a [44]
Pro zobrazování hodnot dynamicky se m¥nících je proto velmi prosp¥²né p°i implementaci uºivatelského rozhraní vyuºít technologie AJAX, která v kombinaci s obnovováním dat v cyklu zabezpe£í uºivateli komfortní zobrazení stále aktuálních hodnot doru£ovaných od klientských aplikací v terénu.
21 XMLHttpRequest
je rozhraní umoº¬ující webovým aplikacím komunikaci mezi serverem a klien-
tem prost°ednictvím protokolu HTTP [34]
21
3
Existující °e²ení Spolu se zp°ístupn¥ním datových sluºeb operátor· ²iroké ve°ejnosti, technologick-
ému vývoji GPS p°ijíma£· a jejich b¥ºná implementace p°ímo do mobilních telefon·, p°ípadn¥ do drobných externích za°ízení se na trhu komer£ních i voln¥ ²i°itelných aplikací objevuje v¥t²í mnoºství projekt·, které s touto prací spojuje my²lenka p°enosu zaznamenané geogra cké polohy na server a její zobrazení, p°ípadn¥ uchování pro pozd¥j²í vyuºití. S touto my²lenkou operuje jiº více aplikací, které v²echny nabízí tém¥° shodné sluºby, li²ící se pouze formou zpracování aplikace a cílovou skupinou pro kterou je ur£ena. Zde uvádím zástupce t°í hlavních skupin aplikací - tak jak jsou uvedeny dále - do první skupiny pat°í aplikace zi²´ování polohy v map¥ a zobrazení ostatních uºivatel·. Druhá skupina zahrnuje mén¥ náro£né aplikace umoº¬ující komplexní pasivní navigaci a aktivní sledování. Ve t°etí skupin¥ se ocitají aplikace zam¥°ené výhradn¥ na aktivní sledování polohy bez dal²ích roz²í°ení.
3.1
Dostupné komer£ní a volné aplikace
Google Latitude http://latitude.google.com
Tato aplikace spadá do první
skupiny. Sluºba umoº¬uje uºivatel·m p°ená²et údaje o vlastní poloze do stejných aplikací spu²t¥ných na jiných mobilních telefonech, p°ípadn¥ pevných stanicích. Pro zobrazení polohy zp°átelených uºivatel· je vyuºito rozhraní Google maps. Implementace pro iPhone, J2ME, Android, Symbian.
Výhody
Známost a pov¥st rmy Google
Provázání s aplikací Google Maps
Aplikace dostupná pro v²echny opera£ní systémy
Navigace k cíli pomocí Google Maps
Nevýhody
Uzav°ený protokol
Nedostupné API
Pom¥rn¥ náro£né na datový p°enos jedna aktualizace polohy znamená p°enos ~ 10kB dat
22
Obrázek 10: Ukázka b¥hu aplikace Google Latitude, zdroj [45]
Tato aplikace nabízí komfort, který je aplikacím, jejihº autorem je rma Google, vlastní. Ov²em tento komfort má také svoji cenu a to dosti náro£nou datovou komunikaci, toto má za následek nejen pot°ebu stálého datového pau²álu ze strany poskytovatele spojení, ale také zvý²enou energetickou náro£nost, coº není ºádoucí nap°íklad p°i del²ích událostech, kdy není moºné dobít baterii.
TrackMyJourney - http://www.trackmyjourney.co.uk/
Tato aplikace spadá
do druhé skupiny. Jedná se o komplexní projekt, pokrývající navigaci v mobilním za°ízeních, zobrazení textových i gra ckých informací, moºnost live trackingu. Tato aplikace je zam¥°ena spí²e na pasivní sledování, tedy pouze pro informování uºivatele o jeho poloze a jeho dal²í navigace. Toto rozhraní je velice so stikované a nabízí slu²ný komfort za rozumnou cenu (náro£nost na výkon za°ízení). Implementace je pouze v J2ME. Aktivní sledování probíhá pomocí jednoduchého protokolu, viz níºe.
Výhody
Komplexní aplikace ur£ená pro navigaci pomocí mobilního telefonu
Pokro£ilé funkce zobrazení polohy v map¥ a dal²ích geogra ckých údaj·
23
Nevýhody
Nedostupné API
Jednostranná komunikace sm¥rem klient
server.
Obrázek 11: Ukázka b¥hu aplikace TrackMyJourney, zdroj [46]
Protokol komunikace se serverem projektu se skládá pouze ve vyjmenování údaj· o
22 a dal²ích geogra ck-
konkrétní hodnot¥, identi kace podle IMEI mobilního telefonu
ých údaj·. Tyto údaje obsahuje kaºdá zasílaná zpráva. Zprávy tedy není moºné nikterak modi kovat, p°ená²et aplternativní data atp. Komunikace také probíhá pouze principem sb¥ru dat, tedy neexistuje zp¥tná vazba, kterou by bylo moºno doru£it informace do klientské aplikace.
XCTtrack - http://live.xcontest.org/
Tato aplikace spadá do t°etí skupiny.
Jedná se o projekt pro online sledování záv¥sných kluzák·, PG k°ídel a jiných letoun·. Gra cké i funk£ní provedení je tomuto p°izp·sobeno zobrazovány informace uºite£né pro navigaci za letu, pokud se za°ízení nachází v oblasti mimo signál GSM sít¥, pozice ukládá pro pozd¥j²í odeslání. Implementace pouze pro J2ME.
Výhody
Buerování záznam·, pokud se uºivatel nachází v oblasti mimo GPRS pokrytí
22 IMEI
(International Mobile Equipment Identity) je patnáctimístné identi ka£ní £ísko, mobilního
telefonu. Kaºdý jednotlivý p°ístroj má toto £íslo unikátní
24
Úsporný reºim pro p°enos dat
Nevýhody
Velmi omezený komunika£ní protokol, který se skládá pouze balíku dat nezbytných pro lokaci
Nemoºnost zasílat jiná neº GPS data
Pouze jednostranná komunikace ve sm¥ru Klient
Server
Tato aplikace je zam¥°ena p°edev²ím na minimalizaci p°ená²ených dat, proto formát p°ená²ených zpráv je tém¥° shodný s aplikací ve skupin¥ 2. Není moºná zp¥tná komunikace ve sm¥ru server -> klient ani zm¥na typu p°ená²ených dat.
3.2
Analýza moºností
Jak jiº bylo uvedeno, vý²e jsou uvedení pouze zástupci nabídky aplikací nabízející sledování mobilních telefon·. T¥chto aplikací je po celém sv¥t¥ k dispozici v¥t²í mnoºství, n¥které jsou voln¥ dostupné, jiné je pot°eba zakoupit za (v¥t²inou) rozumnou cenu. Drtivá v¥t²ina aplikací v²ak nenabízí p°enos i jiných dat neº je GPS poloha a informace s ní spojené, toto je zap°i£in¥no v¥t²inou nedostate£n¥ vyvinutým komunika£ním protokolem, který neumoº¬uje dal²í r·st aplikace. Mnoho aplikací má své komunika£ní protokoly skryté, ale vzhledem k pr·m¥rné datové zát¥ºi b¥hem p°ipojení je moºné p°edpokládat, ºe tyto aplikace budou vyuºívat pro komunikaci se serverem n¥který z RPC protokol·. V kaºdém p°ípad¥ v²ak od uºivatele p°edpokládají neomezený datový tarif od poskytovatele mobilní sít¥ pro p°enos v¥t²ího objemu dat. P°enos více dat také více vy£erpává baterii mobilního za°ízení a proto tyto aplikace nejsou vhodné pro dlouhodob¥j²í sledování.
3.3
Aplikace rozhodnutí
Vzhledem k vý²e uvedeným skute£nostem se jeví jako rozumné °e²ení návrh vlastního komunika£ního protokolu, který bude velice subtilní pro udrºení datového toku pouze na nezbytn¥ nutné vý²i a zárove¬ bude dostate£n¥ robustní, poskytne vývojá°i moºnost zasílání nejen GPS informací, bude schopen p°ená²et data ob¥ma sm¥ry. V optimáním p°ípad¥ se tento protokol m·ºe stát tv·rcem standardu pro p°enos informací mezi mobilními za°ízeními a serverem. Tento protokol a aplikace jej vyuºívající jsou p°edm¥tem této práce. Konkrétní parametry systému budou následující.
Vývoj v prost°edí klientské aplikace J2ME - nejv¥t²í moºné potenciální roz²í°ení jedné verze klientské aplikace, více kapitola 2.2.2.
25
P°enosový protokol pransportní vrstvy bude TCP - bezproblémové duplexní spojení klientské a serverové aplikace, více kapitola 4.1.2. Zapouzd°ení konkrétních dat bude probíhat na základ¥ nov¥ vytvo°eného protokolu, více kapitola 2.3.4.
26
4
Návrh vlastního systému LiveTracking V p°edcházejících kapitolách jsme se dozv¥d¥li, jaké jsou moºnosti navázání kon-
taktu v architektu°e klient server, na jakých principech je v této architektu°e moºno p°ená²et data na aplika£ní úrovni, tedy jaké standardní sluºby jsou k dispozici. Také jsme si p°edstavili zástupce systém·, poskytujících uºivatel·m podobné sluºby sledování polohy. Na základ¥ získaných zku²eností jsme do²li k záv¥ru, ºe pro dosaºení na²ich poºadavk· na systém (tyto poºadavky jsou uvedeny v kapitole 1.) je t°eba vyvinout zcela nový p°enosový protokol a klientské, serverové i prezenta£ní aplikace, tyto jednotlivé £ásti systému si nyní podrobn¥ p°edstavíme. V kaºdé podkapitole naleznete nejprve zd·vodn¥ní rozhodnutí pro konkrétní technologii nebo sluºbu a poté její popis.
4.1
Klientská aplikace
Na základ¥ p°edchozí analýzy jsme dosp¥li k záv¥ru, ºe optimálním jazykem a prost°edím vývoje aplikace pro mobilní za°ízení je Java, resp. její odnoº J2ME ur£ená p°ímo pro mobilní za°ízení s omezeným výkonem. Pro implementaci v tomto jazyce hovo°í vý²e zmín¥né roz²í°ení JVM na v¥t²in¥ stávajících mobilních telefon· a tedy moºnost potenciálního roz²í°ení mezi ²iroké spektrum uºivatel·. JVM £asto implemntují i mobilní telefony bez opera£ního systému, tedy p°i vývoji aplikace v J2ME je je moºné tuto aplikaci distribuovat i uºivatel·m s levn¥j²ími mobilními telefony a tedy zp°ístupnit sluºbu co nej²ir²ímu spektru uºivatel·. Klientská aplikace musí implementovat tyto základní prvky: uºivatelské rozhraní, automat garantující stálost navázaného spojení se serverovou aplikací, obsluhu bluetooth externího za°ízení a získávání dat z tohoto za°ízení a v neposlední °ad¥ implementace navrºeného p°enosového protokolu
4.1.1 Uºivatelské rozhraní Uºivatelské rozhraní je to první s £ím se uºivatel v kaºdé aplikaci setká, proto je t°eba dbát na jednoduchost, p°ehlednost a logické °azení ovládacích prvk·, je tedy nutno zajistit jistou ergonomi£nost tohoto prost°edí. Klientská aplikace ve verzi 1.0 obsahuje pouze textové menu, nedisponuje tedy so stikovaným gra ckým rozhraním, které v²ak ani nebylo tématem této práce a v p°ípad¥ aplikace od které o£ekáváme v prvé °ad¥ p°ehlednost a nenáro£nost na výkon výpo£etní jednotky mobilního za°ízení, není v n¥kterých p°ípadech ani ºádoucí. Uºivatelská aplikace je spou²t¥na pomocí JVM mobilního za°ízení jako Midlet, je to struktura podobná Java Applet·m ov²em ur£ená pro mobilní za°ízení. Midlety v mobilních za°ízeních mají omezené pole p·sobnosti jejich b¥h je omezen do tzv. Sandboxu, neboli pískovi²t¥, které nesm¥jí opustit. Toto v praxi znamená, ºe midlet m·ºe vyuºívat pouze mnoºinu t°íd a knihoven de novanou konkrétním za°ízením, tedy programátor nemá moºnost roz²í°it okruh podporovaných knihoven vyjma ty, které
27
jsou v konkrétním za°ízení p°edde novány. Kaºdý midlet má n¥kolik stav· ve kterých se m·ºe nacházet po spu²t¥ní se ocitá ve stavu passivate, dokud není zavolána metoda startApp(), která zp·sobí aktivaci a zahájení b¥hu midletu. Dal²í moºné p°echody mezi stavy aº do ukon£ení a zru²ení midletu jsou z°ejmé z následujícího obrázku
Obrázek 12: ivotní cyklus midletu
Uºivatelské rozhraní je vytvo°eno pomocí vysokoúrov¬ových komponent, £ímº je dosáhnuto pom¥rn¥ rychlého vývoje prost°edí a jeho korektního chování prost°edí, ov²em za cenu rozli²né interpretace zobrazení jednotlivých komponent na r·zných za°ízeních. Funkce v²ak z·stává na v²ech za°ízeních zachována v nezm¥n¥né podob¥. Více informací o konkrétní nabídce moºností, vzhledu a chování aplikace naleznete v p°íloze A uºivatelské p°íru£ce, nyní si pro ilustraci uve¤me pouze pohled na základní obrazovku aplikace po p°ihlá²ení, viz následující obrázek.
4.1.2 Spojení se serverem Bude vyuºito spojového TCP spojení se serverem, na toto rozhodnutí má nejv¥t²í vliv fakt, ºe od systému poºadujeme nejen komunikaci ve sm¥ru klient ale také opa£ným sm¥rem, tedy server
server,
klient. Pokud bychom cht¥li vyuºít data-
gramovou sluºbu UDP nastal by problém se zp¥tným p°ístupem na mobilní za°ízení. P°i návrhu p°enosové sluºby je t°eba brát v úvahu umíst¥ní klientské aplikace za NATem, tedy, ºe toto za°ízení je adresováno v rámci privátní sít¥ a je tedy obtíºné s tímto za°ízením udrºovat duplexní komunika£ní kanál p°i pouºití nespojového protokolu UDP. Cestou pro uskute£n¥ní takového spojení m·ºe být vyuºití protokolu STUNT. Av²ak i p°i pouºití tohoto protokolu by bylo t°eba periodicky obnovovat otev°ený komunika£ní kanál p°ibliºn¥ kaºdých 30 sekund. Dal²í nevýhodou p°i vyuºití UDP protokolu je pot°eba potvrzování doru£ených zpráv v p°ípad¥, ºe vyºadujeme garanci doru£ení odeslané zprávy. Tento potvrzovací mechanismus, který by v p°ípad¥ navrhovaného systému byl nutný by zbyte£n¥ zvý²il °eºii p°ená²ených dat. V p°ípad¥ vyuºití spojové sluºby TCP odpadá problém s navázáním zp¥tného spojení. Klientská aplikace se tedy pokusí vytvo°it spojení se serverovou aplikací zaloºením TCP socketu. Tento socket je po ur£itou dobu povaºován za aktivní a je moºné
28
jej n¥jakou dobu nevyuºívat bez pot°eby nového navázání spojení p°i události generující datový tok socketem libovolným sm¥rem. Tato doba po kterou je socket aktivní je velmi variabilní a li²í se nej£ast¥ji podle výrobc· mobilních telefon· a tedy i JVM, kterou pouºívají. V následující tabulce jsou uvedeny pr·m¥rné £asy rozpadu socketu a tím ztracení spojení se serverovou aplikací, jedná se pouze o hodnoty zm¥°ené na za°ízeních, které jsem m¥l v dob¥ testování stálosti spojení k dispozici. Výrobce mobilního za°ízení / OS
Pr·m¥rná doba rozpadu socketu
Sony Ericsson / Symbian
22 minut
Nokia / Symbian
4 minuty
BlackBerry / BlackBerry OS
20 minut
Sony Ericsson / bez OS
12 minut
Tabulka 2: pr·m¥rná doba rozpadu TCP socketu
Z vý²e uvedené tabulky je z°ejmé, ºe £asy garantovaného spojení se velmi li²í a je tedy nutné po£ítat s nejslab²ím £lánkem °et¥zu, tedy z mobilními za°ízeními zna£ky Nokia, které ztrácejí kontrolu nad p°ipojením jiº po £ty°ech minutách. Pro£ nás v²ak zajímá doba po kterou je kanál spojující klientskou aplikaci se serverovou? Jedná se o napln¥ní poºadavku na vý²e zmín¥nou moºnost zasílání informací ob¥ma sm¥ry, v modelovém p°ípad¥ tedy nap°íklad doru£ení zprávy mezi uºivateli, p°ípadn¥ moºnost vzdáleného °ízení b¥hu klientské aplikace. Pokud bude spojení nefunk£ní, data mohou být na klientskou aplikaci zaslána teprve po jeho op¥tovném spojení se serverovou aplikací a v této dob¥ jiº zmín¥ná data mohou být irelevantní, p°ípadn¥ poºadavek na aktuální zaslání polohy m·ºe být nevysly²en v okamºiku jeho poloºení. Z t¥chto d·vod· je t°eba do klientské aplikace implementovat mechanismus, který systému garantuje stálost spojení. Tento mechanismus je zastoupen automatem, který v uºivatelem, p°ípadn¥ systémem daných intervalech kontroluje aktivitu p°ipojení, tento interval, nazv¥me ho timeout se za£íná po£ítat vºdy od okamºiku odeslání poslední uºivatelem nebo systémem vygenerované zprávy. Tedy pokud je timeout nastaven na vý²e de nované 4 minuty a po uplynutí této doby se v bueru dat k odeslání (popis tohoto principu viz níºe v kapitole 5.2 )neobjeví ºádná zpráva, bude kanálem odeslán jeden refresh byte
23 , který je na serveru de-
tekován. Po odeslání tohoto refresh byte je znova po£ítána doba timoutu. Schéma automatu, který obsluhuje zde uvedené spojení je na následujícím obrázku.
23 odesláním refresh byte se rozumí zaslání pouze jednoho nulového bytu pro obnovení TCP socketu
29
Obrázek 13: Automat garantující stálost spojení se serverem a odesílající zprávy
4.1.3 Obsluha bluetooth za°ízení Modul obsluhy GPS modulu zahrnuje metody navázání kontaktu s externím bluetooth za°ízením, kdy je nutné nejprve vyhledat dostupná za°ízení v okolí, po vyhledání seznamu dostupných za°ízení uºivatel vybere jedno konkrétní se kterým aplikace dále spolupracuje. Pro objevení dostupných za°ízení je vyuºito API DiscoveryListener[35] pro J2ME, pomocí jehoº metod obdrºí klient jména a fyzické adresy okolích za°ízení. Následná komunikace s GPS modulem, tedy £tení NMEA v¥t probíhá pomocí socketové komunikace, kdy je vytvo°eno socketové spojení mezi klientskou aplikací a externím GPS modulem, p°ijatá data jsou zpracována na základ¥ syntaxe v¥t NMEA, která je popsána v kapitole 2.3.1., výsledná data obsahující geogra ckou polohu jsou ur£ena k dal²ímu zpracování, které podléhá komunikaci podle protokolu de novaného v kapitole 5.2. O obsluhu bluetooth za°ízení se starají klientské t°ídy Bluetooth_service.java, Btdiscovery.java a Bluetooth.java.
4.1.4 Vnit°ní struktura klientské aplikace V této kapitole uvedu princip fungování klientské aplikace a v²e pot°ebné pro programátora, který by rád vyuºil sluºby níºe uvedeného protokolu. Klientská aplikace je vytvo°ena jako midlet pro JVM mobilních za°ízení, po jeho spu²t¥ní je automaticky volána metoda startApp(), která je také volána po jeho op¥tovném vyvolání na pop°edí, pokud dojde k minimalizaci aplikace. Pokud to uºivatel vyºaduje, je moºné po spu²t¥ní aplikace p°esko£it krok p°ihlá²ení, který prob¥hne automaticky na základ¥ jiº d°íve provedeného úsp¥²ného p°ihlá²ení. Tato sluºba je
30
zaji²t¥na implementací RMS (Record Management System). Jedná se v podstat¥ o velice jednoduché databázové prost°edí nabízející uchování dat aplikace i po jejím ukon£ení. O konzistentní p°ipojení, které je uvedeno jako jeden z poºadavk· protokolu se stará t°ída Library, která je po startu aplikace spu²t¥na ve zvlá²tním vláknu. Tato t°ída obsahuje implementaci automatu uvedeného na obrázku 11. Pokud se toto vlákno nachází ve stavu wait a tedy nevykonává ºádnou £innost, je moºné jej probudit vláknem obsluhujícím odchozí data. Tedy po vloºení dat do odchozího bueru dojde k probuzení uspaného vlákna a to následn¥ obslouºí poºadavek uloºený v odchozím bueru. Pokud b¥hem obsluhy zprávy dojde k vloºení dal²í zprávy do odchozího bueru, je i tato ihned zpracována a teprve po vyprázdn¥ní bueru je toto vlákno uspáno na dobu vycházející z test· stálosti p°ipojení. Tato doba by m¥la garantovat stálost komunika£ního kanálu. Pokud i p°esto dojde k rozpadu spojení, je toto, nejpozd¥ji po dob¥ uvedené vý²e, op¥t navázáno. Níºe naleznete ukázku zdrojového kódu implementující vý²e uvedený mechanismus (t°ída Library.java).
... while(continue_thread){ if(isOnline()){ //funkce isOnline() zistí, zda je spojení aktivní, pokud není, ihned spojí if(emptyQueue(queue)){ TIME=30000; }else{ TIME=1; sendLastQueued(queue); } }else{ TIME=1; } waitt(TIME); } } ... Pokud je spu²t¥no GPS sledování, je v uºivatelsky de novaných intervalech aktivováno £tení dat vysílaných GPS modulem. Tato data jsou dostupná pomocí streamového spojení s adresou daného modulu. P°íchozí data mají formátování podle protokolu NMEA 0183, který je popsán vý²e. Po rozklí£ování pot°ebných informací je vytvo°en objekt t°ídy GPS, který obsahuje v²echny poºadované informace. Pokud je t°eba p°enést dal²í informace spole£n¥ s t¥mito daty, nap°íklad £asovou známku nebo data zabezpe£ení, jsou vytvo°eny objekty t¥chto sluºeb. Tyto objekty tvo°í pole objekt·,
31
které je p°edáno t°íd¥ Protocol.java. Obsluha poºadavku na vytvo°ení zprávy je spu²t¥na v novém vlákn¥ a tedy nijak neomezuje uºivatele v jeho p°ípadné práci s klientským programem. Data pro spu²t¥ní vytvo°ení nové zprávy jsou p°edána metod¥ packData(Object [], int[], int[]) , která obsahuje t°i vstupní parametry, prvním je vý²e zmín¥né pole objekt·, dále pole dostupných sluºeb korespondující s polem objekt·. Pokud je v dané implementaci dostupná sluºba £íslo 1 (p°ihla²ování), obsahuje na první (index 0) pozici hodnotu 1, pokud by tato sluºba dostupná nebyla, bude hodnota 0 a tato sluºba bude ignorována. Posledním parametrem je pole uºivatelem poºadovaných sluºeb, pracující na stejném principu jako p°edchozí parametr. Pro korektní fungování aplikace je t°eba aby pole poºadovaných sluºeb bylo vºdy podmnoºinou dostupných sluºeb. Po vstupu dat do t°ídy Protocol.java dojde k vytvo°ení zprávy a její následné vloºení do bueru odchozích zpráv de novaných v p°edchozím kroku. Poºaduje-li programátor implementaci odchozích zpráv ve formátu tohoto protokolu je tedy nutné vyuºít vý²e zmín¥né t°ídy Protocol.java a její £lenské funkce packData. De nice bueru odchozích zpráv se obsluºné t°íd¥ p°edává pomocí funkce setBuer(Vector), z této de nice vyplývá, ºe výstupní buer je de nován jako vektor. Ukázka zdrojového kódu zpracovávající data z objektu Login (data pro p°ihlá²ení), který lze nalézt ve t°íd¥ Protocol:
switch (i){ case 0: //vrati pole bytu o presne delce, obsahujici data k prihlaseni - jmeno a heslo tmp_byte = getLogDataBytes(services[i]); //pokud jsme nepresahli maximalni velikost ramce if(tmp_byte.length<MAX_SIZE){ //vytvorim pole intu, kazdy prvek je jeden bit hlavicky, predavam delku dat, offset a celkovou //delku hlavicky, resp. vraceneho pole int [] tmp_header =convertInt2Bits(tmp_byte.length,2,18); //vytvori celou hlavicku loginu - doplni delku dat a dalsi hlavicku (zadna) tmp_header=getLogHeader(tmp_header,services[i]); //posklada se cela zprava Loginu do jednoho pole bytu pripraveneho pro odeslani out_byte=completeMsg(tmp_header,tmp_byte); //pridani globalni hlavicky out_byte=sendableMsg(out_byte,"100000"); //kontrola,zda mam nejakou dalsi zretezenou hlavicku Login l = (Login)services[i];
32
String next=l.getNext(); int nextInt=0; if(next!="000000"){ //prevedu hodnotu next na cele cislo nextInt=convertBin2Dec(next); //do celkove zpravy pridam dalsi hlavicku a jeji data nebo hlavicky out_byte=addNextMessage(services,out_byte,nextInt); //addNextMessage(services,out_byte,nextInt); } //vytvorim novou zpravu, pro odeslani msg=new Message(out_byte); //synchronizace lock=lib.getMonitor(); synchronized ( lock ) { //vlozim zpravu do fronty k odeslani lib.queue.addElement(msg); //probudim proces odeslani lib.notifyAll(); } } break; Pro implementaci zpracování p°íchozích zpráv je k dispozici t°ída Listener.java, které b¥h je odd¥len od b¥hu aplikace novým vláknem. Tato t°ída implementuje sou£asn¥ naslouchání na de novaném socketu a vyvolání konkrétních událostí de novaných v midletu po p°íjmu konkrétní zprávy. Ve verzi protokolu 1.0 se jedná pouze o p°íjem zprávy a p°íjem úpravy snímané frekvence. Po p°íjmu zprávy je tedy volána metoda deliveredMsg(String) v rodi£ovské t°íd¥ (Main.java), která v aktuální verzi klientské aplikace zp·sobí výpis doru£ené zprávy. Po p°íjmu zm¥ny nastavení je volána metoda deliveredSett(String) v rodi£ovské t°íd¥ (Main.java), která upraví momentáln¥ nastavenou snímací frekvenci.
4.2
Protokol
Návrh nového protokolu se ukázal jako nezbytnou nutností, p°i rozhodování o jeho struktu°e, která hraje klí£ovou roli pro napln¥ní v²ech poºadavk· uvedených v kapitole 1. byl vybrán jako typový vzor protokol Ipv6
24 , resp. jeho princip z°et¥zených
hlavi£ek, který p°esn¥ pokrývá v²echny pot°eby tohoto systému. Popis protokolu je uveden ve form¥ RFC-like dokumentu
24 IPv6
(Internet Protocol version 6) je nástupcem protokolu IPv4
33
RFC-like popis leden 2011
LTprotocol , verze 1.0
Abstrakt Tento dokument popisuje komunika£ní protokol uºívaný pro p°enos informací mezi mobilními klientskými za°ízeními a serverovou aplikací. Copyright Protokol byl navrºen v rámci diplomové práce pro VUT FEL, katerdu po£íta£·. Rok 2011 Obsah
1.
Úvod
2.
Formát LTprotocol hlavi£ky
3.
Formát roz²i°ujících hlavi£ek LTprotocol
(a)
Login hlavi£ka
(b)
GPS hlavi£ka
(c)
Text hlavi£ka
(d)
Servis hlavi£ka
(e)
Date hlavi£ka
(f )
Secure hlavi£ka
(g)
Null hlavi£ka
34
1. Úvod Tento dokument vznikl na základ¥ pot°eby vytvo°ení protokolu pro normovanou komunikaci mezi klientskou aplikací, která jako hostující za°ízení vyuºívá nej£ast¥ji mobilní telefon, p°ípadn¥ jiné mobilní za°ízení a do ve°ejné sít¥ je p°ipojeno pomocí sít¥ operátora poskytujícího také telefonní spojení. LTprotocol pokrývá následující poºadavky
minimální cena za p°enos informace jednozna£né vyjád°ení informace p°enos r·zných druh· dat pro r·zné aplika£ní sluºby odolnost proti podvrhu zprávy 3. Formát LTprotocol hlavi£ky +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ver| session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | lenght | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | next | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ver - 2bit hodnota, udávající verzi protokolu Session ID - 16bit hodnota, udávající £íslo session, pod kterým probíhá komunikace Lenght - 16bit hodnota, udávající délku dat Next - 6bit hodnota, definující následující z°et¥zenou hlavi£ku, m·ºe nabývat hodnot 0 63 (dec), p°i£emº hodnota 0 definuje ºádnou následující hlavi£ku.
35
Data maximáln¥ 65535 B dlouhá, která musí za£ínat hlavi£kou sluºby, které £íslo je uvedeno v poli Next
4. Formát roz²i°ujících hlavi£ek LTprotocol (a) Login hlavi£ka Tato hlavi£ka má bitové ozna£ení 000001, tedy pro identifikaci Login dat jako následujících p°edchozím dat·m (resp. globální hlavi£ce) je t°eba v poli next v hlavi£ce p°edchozích dat (resp. globální hlavi£ce) uvést tuto hodnotu. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |st.| lenght | next | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
St. - 2bit hodnota stavu p°ihla²ování. Lenght - 8bit hodnota, udávající délku dat Next - 6bit hodnota, definující následující z°et¥zenou hlavi£ku, m·ºe nabývat hodnot 0 63 (dec), p°i£emº hodnota 0 definuje ºádnou následující hlavi£ku.
P°ihla²ovací proces pomocí protokolu probíhá na základ¥ 4-stavového handshake, jehoº jednotlivé fáze popisuje stav pole Stav, viz níºe. Stav p°ihlá²ení definuje následující hodnoty: 00 První pokus o spojení, pole data obsahuje p°ihla²ovací jméno a heslo, heslo je zabezpe£eno metodou md5, jméno se skládá pouze ze základních znak· abecedy a £ísel, poloºky jméno a heslo jsou navzájem odd¥lené znakem ; (st°edník) 36
01 Odpov¥¤ serverové aplikace na p°íchozí spojení. Pokud je p°ístup autorizován, pole data obsahuje £íslo session pod kterou tento uºivatel b¥hem tohoto p°ipojení bude vystupovat. Toto £íslo nabývá hodnot 1 65535 (dec). Pokud je hodnota session rovna 0, je p°ístup neautorizován a p°ihlá²ení neprob¥hlo úsp¥²n¥. 10 Probíhá kontrola dostupnosti serveru a korektnosti p°ihlá²ení pro zabezpe£ení bezchybovosti dal²ího p°enosu dat. Pole data neobsahuje ºádná data, jedná se pouze o odeslání dat, nyní jiº s uvedeným session ID v základní hlavi££e a je o£ekávána odpov¥¤ serveru potvrzující správnost spojení. 11 Odpov¥¤ serveru na ºádost o potvrzení sestaveného spojení, pole data neobsahuje ºádná data, pokud není odpov¥¤ doru£ena po uplynutí timeout £asu (10sec.) od odeslání ºádosti o potvrzení (stav 10), je spojení prohlá²eno za nefunk£ní a je t°eba jej navázat znovu.
(b)GPS hlavi£ka Tato hlavi£ka má bitové ozna£ení 000010, tedy pro identifikaci GPS dat jako následujících p°edchozím dat·m (resp. globální hlavi£ce) je t°eba v poli next v hlavi£ce p°edchozích dat (resp. globální hlavi£ce) uvést tuto hodnotu. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type | lenght | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | next | s | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type - 4bit hodnota definující typ a formát p°ená²ených dat Lenght - 12bit hodnota, udávající délku dat Next - 6bit hodnota, definující následující z°et¥zenou hlavi£ku, m·ºe nabývat hodnot 0 63 (dec), p°i£emº hodnota 0 definuje ºádnou následující hlavi£ku. 37
S - 2bit hodnota slouºí pro vyrovnání dat na celé byty, toto pole má hodnotu vºdy 00
Data p°ená²ená v poli Data m·ºou mít rozdílné parametry, viz níºe, vºdy se v²ak jedná o £íselné vyjád°ení hodnot, p°ípadn¥ znakové vyjád°ení typu hodnot (nap°. rozli²ení severní N a jiºní S zem¥pisné ²í°ky). Pro odd¥lení definovaných hodnot se vyuºívá primárn¥ odd¥lova£ ; (st°edník) a sekundárn¥ odd¥lova£ , (£árka). Typ dat definuje následující hodnoty
0000 Tato hodnota definuje základní a také minimální p°ená²ená data, formát dat je následující: [ddmm.mmssss,N/S;dddmm.mmssss,E/W] , tedy [zem¥pisná ²í°ka, severní / jiºní ; zem¥pisná délka, východní / západní]. 0001 Tato hodnota definuje roz²í°ení p°edchozích hodnot o nadmo°skou vý²ku, tedy data mají následující formátování: [ddmm.mmssss, N/S; dddmm.mmssss, E/W; mmmm] , tedy [zem¥pisná ²í°ka, severní / jiºní ; zem¥pisná délka, východní / západní; nadmo°ská vý²ka]. 0010 Tato hodnota definuje roz²í°ení p°edchozích hodnot o azimut, tedy sm¥r pohybu, data mají následující formátování: [ddmm.mmssss, N/S; dddmm.mmssss, E/W; mmmm;ddd.mm] , tedy [zem¥pisná ²í°ka, severní/jiºní ; zem¥pisná délka, východní/západní; nadmo°ská vý²ka; azimut]. 0011 Tato hodnota definuje roz²í°ení p°edchozích hodnot o rychlost pohybu, data mají následující formátování: [ddmm.mmssss, N/S; dddmm.mmssss, E/W; mmmm; ddd.mm; mmm] , tedy [zem¥pisná ²í°ka, severní/jiºní ; zem¥pisná délka, východní/západní; nadmo°ská vý²ka; azimut; rychlost v m/s].
Jiné moºné hodnoty typu dat budou p°i°azeny aº v dal²í verzi protokolu.
(c) Text hlavi£ka Tato hlavi£ka má bitové ozna£ení 000011, tedy pro identifikaci Text dat jako následujících p°edchozím dat·m (resp. globální hlavi£ce) je t°eba v
38
poli next v hlavi£ce p°edchozích dat (resp. globální hlavi£ce) uvést tuto hodnotu. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type | lenght | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | next | p | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type - 4bit hodnota definující typ a formát p°ená²ených dat Lenght - 12bit hodnota, udávající délku dat Next - 6bit hodnota, definující následující z°et¥zenou hlavi£ku, m·ºe nabývat hodnot 0 63 (dec), p°i£emº hodnota 0 definuje ºádnou následující hlavi£ku. P - 2bit hodnota slouºí pro definici p°ítomnosti p°edch·dc· nebo následovník· aktuálního textu v poli data
Data p°ená²ená v poli Data mohou být libovolné znaky ASCII, jejich délka je omezena 65535 B, pokud je pot°eba p°ená²et del²í text, definuje se pomocí pole P z°et¥zení dat, viz níºe. Typ dat lze rozd¥lit na jednotlivé bity, kaºdý bit definuje jinou skupinu, které chci data doru£it
první bit - X000 ur£uje, zda budou data zobrazena uºivatel·m webového rozhraní, 0 = nebudou, 1 = budou. druhý bit - 0X00 ur£uje, zda budou data odeslána uºivatel·m, jejihº klientské aplikace jsou p°ipojeny 0 = nebudou, 1 = budou. t°etí bit - 00X0 ur£uje, zda budou data zobrazena v²em uºivatel·m, kte°í na tato data mají nárok podle p°edchozích definic, nebo jestli budou zobrazena pouze zp°áteleným uºivatel·m. 0 = v²ichni, 1 = p°átelé.
39
£tvrtý bit - 000X ur£uje, zda jsou data adresována p°ímo konkrétním uºivatel·m, seznam uºivatel· je uveden na za£átku zprávy ve form¥ uºivatelských £ísel odd¥lených odd¥lova£em , (£árka), soubor adresát· je od samotné zprávy odd¥len dvojznakem ;; (dva st°edníky) 0 = nebudou p°ímo adresována, 1 = budou p°ímo adresována.
Pokud je textová informace del²í neº maximální moºná hodnota (65535 B), bude rozd¥lena na £ásti o velikosti maximáln¥ 65535 B. V p°ípad¥ rozloºení zpráv do více balík· dat bude zm¥n¥na implicitní hodnota poloºky P podle seznamu níºe Poloºky P m·ºe nabývat t¥chto hodnot:
00 Tato hodnota ur£uje, ºe po této zpráv¥ nenásleduje ºádná dal²í, které data by byla z°et¥zena se aktuální zprávou. Toto je implicitní nastavení. 01 Tato hodnota ur£uje, ºe po této zpráv¥ následuje zpráva, které data je t°eba z°et¥zit s aktuální zprávou pro sestavení kompletní zprávy. Zárove¬ tato hodnota znamená, ºe tato zpráva nemá ºádnou p°edcházející zprávu, se kterou by bylo t°eba ji z°et¥zit. 10 Tato hodnota ur£uje, ºe tato zpráva má p°edch·dce ve form¥ zprávy, které data p°edcházejí aktuální zpráv¥ a proto je t°eba tyto dv¥ zprávy z°et¥zit pro sestavení kompletní zprávy. Tato hodnota také znamená, ºe tato zpráva jiº nemá ºádného následovníka, tedy je to poslední zpráva z balíku dat, který pat°í dohromady 11 Tato hodnota ur£uje, ºe tato hodnota má p°edch·dce i následovníka, tedy je t°eba ji z°et¥zit s p°edcházející i s následující zprávou.
(d) Servis hlavi£ka Tato hlavi£ka má bitové ozna£ení 000100, tedy pro identifikaci Servis dat jako následujících p°edchozím dat·m (resp. globální hlavi£ce) je t°eba
40
v poli next v hlavi£ce p°edchozích dat (resp. globální hlavi£ce) uvést tuto hodnotu. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type | lenght | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | next | n | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type - 6bit hodnota definující typ a formát p°ená²ených dat Lenght - 10bit hodnota, udávající délku dat Next - 6bit hodnota, definující následující z°et¥zenou hlavi£ku, m·ºe nabývat hodnot 0 63 (dec), p°i£emº hodnota 0 definuje ºádnou následující hlavi£ku. N - pouze výpl¬ pro zarovnání dat na celé byty, má vºdy hodnotu 00
Data p°ená²ená v poli Data mohou mít prom¥nlivou strukturu, v této verzi 1.0 je podporován pouze jeden typ dat, viz níºe. Poloºka type ve verzi protokolu 1.0 m·ºe nabývat t¥chto hodnot:
000001 Tato hodnota definuje formát dat pro nastavení nové snímací frekvence, pole Data má v tomto p°ípad¥ následující formát: ssss interval mezi jednotlivými zasílanými zprávami v sekundách.
(e) Date hlavi£ka Tato hlavi£ka má bitové ozna£ení 001001, tedy pro identifikaci Date dat jako následujících p°edchozím dat·m (resp. globální hlavi£ce) je t°eba v
41
poli next v hlavi£ce p°edchozích dat (resp. globální hlavi£ce) uvést tuto hodnotu. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | t | lenght | next | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T - 2bit hodnota definující formát p°ená²ených dat Lenght - 8bit hodnota, udávající délku dat Next - 6bit hodnota, definující následující z°et¥zenou hlavi£ku, m·ºe nabývat hodnot 0 63 (dec), p°i£emº hodnota 0 definuje ºádnou následující hlavi£ku.
Hodnota poloºky T ve verzi protokolu 1.0 ur£uje formát data, které obsahuje pole data, ve verzi protokolu 1.0 je to pouze jedna implicitní hodnota: 00 tato hodnota ur£uje, ºe v poli Data se nachází datum ve formátu po£tu sekund od 1.1.1970, tedy standardní UNIX timestamp.
(f) Secure hlavi£ka Tato hlavi£ka má bitové ozna£ení 001010, tedy pro identifikaci Secure dat jako následujících p°edchozím dat·m (resp. globální hlavi£ce) je t°eba v poli next v hlavi£ce p°edchozích dat (resp. globální hlavi£ce) uvést tuto hodnotu. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | t | lenght | next | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
42
T - 2bit hodnota definující formát p°ená²ených dat Lenght - 8bit hodnota, udávající délku dat Next - 6bit hodnota, definující následující z°et¥zenou hlavi£ku, m·ºe nabývat hodnot 0 63 (dec), p°i£emº hodnota 0 definuje ºádnou následující hlavi£ku.
Hodnota poloºky T ur£uje formát data, které obsahuje pole data, ve verzi protokolu 1.0 je to pouze jedna implicitní hodnota:
00 tato hodnota ur£uje, ºe v poli Data se nachází md5 otisk dat sloºených z celé zasílané zprávy a hesla uºivatele. Tento md5 otisk je pro kaºdou zprávu unikátní, po doru£ení zprávy obsahující Secure hlavi£ku je vytvo°en zku²ební otisk md5 podle vý²e popsaného principu a pokud se shoduje s doru£eným otiskem, je zpráva validní, v opa£ném p°ípad¥ se jedná o podvrhnutou zprávu, která není akceptována.
(g) Null hlavi£ka Jedná se pouze o hypotetickou hlavi£ku, která má sm¥rovací kód 000000, pokud je tedy uveden v poli next tento kód, je ukon£eno £tení zprávy po p°e£tení celých dat hlavi£ky, která uvádí jako svoji následující hlavi£ku Null.
Zde kon£í RFC-like popis komunika£ního protokolu.
Z popisu protokolu je
tedy z°ejmé, ºe na jeho základ¥ dokáºeme vygenerovat zprávu, která neobsahuje mnoho nadbyte£ných informací, ale zárove¬ zaji²´uje exaktní vyjád°ení dat, která p°ená²í. Po implementaci tohoto protokolu do klientské aplikace a vygenerování zprávy, kterou je t°eba odeslat serverové aplikaci je tato zpráva (reprezentovaná polem byt·) vloºena do bueru zpráv k odeslání, který cyklicky kontroluje automat zaji²´ující stálost spojení se serverovou aplikací. V okamºiku zji²t¥ní nenulové délky bueru se tento automat snaºí zprávu odeslat serverové aplikaci. V p°ípad¥, ºe není úsp¥²ný se o toto snaºí ve stále se prodluºujících intervalech, které v²ak nejsou nikdy del²í
43
neº nastavený timeout. Tento princip je pot°eba implementovat z d·vodu nestálosti komunika£ního kanálu zp·sobeného vn¥j²ími vlivy jako je absence signálu mobilní sít¥, p°ípadn¥ neschopnost sít¥ v daný okamºik zabezpe£it datový p°enos. V tomto p°ípad¥ se ve výstupním bueru hromadí zprávy, které by klientská aplikace ráda odeslala, v p°ípad¥, ºe se poda°í klientské aplikaci op¥tovn¥ navázat spojení okamºit¥ dochází k odesílání zpráv dokud se výstupní buer nevyprázdní p°i odeslání zprávy se tato z výstupního bueru nenávratn¥ vymaºe, ov²em její kopie se uchovává centráln¥ v databázi serverové aplikace.
4.3
Serverová aplikace
Pro návrh serverové aplikace, která obsluhuje p°íchozí spojení a zprávy doru£ené p°es tato spojení jsem jednozna£n¥ zvolil jazyk C++, který dokáºe této aplikaci zajistit dostate£nou efektivitu a rychlost zpracování poºadavk·. Princip fungování serverové aplikace lze vyjád°it následujícím modelem: P°i spu²t¥ní serverové aplikace je vytvo°eno vlákno, které obsluhuje odchozí zprávy a vlákno, které obsluhuje p°íchozí zprávy, detailn¥ budou tato vlákna popsána níºe. Serverová aplikace naslouchá na de novaném portu a o£ekává p°íchozí spojení, v okamºiku jeho uskute£n¥ní je vytvo°en socket a reference na n¥j uloºena do vektoru socket·. Nad tímto vektorem socket· pracuje jiº d°íve zmín¥né vlákno hlídající p°íchozí zprávy. Pro detekci p°íchozích zpráv je vyuºita blokující metoda epoll[37], která vrací pole referencí na sockety na kterých do²lo k n¥jaké zm¥n¥, v tomto p°ípad¥ tedy p°ijetí zprávy, p°ípadn¥ uzav°ení socketu. Vzhledem k tomu, ºe serverová aplikace se skládá v podstat¥ ze dvou odd¥lených aplikací, tedy samotného TCP serveru a webového rozhraní celé sluºby, je pot°eba vytvo°it buer zpráv, které je t°eba odeslat konkrétním klient·m a který je dostupný ob¥ma aplikacím,kdy kaºdá pracuje na odli²né platform¥. Tento buer je de nován v databázi serverové aplikace jako jedna tabulka ur£ující identi kátor socketu, pro který jsou data ur£ena, bytový záznam celé zprávy k odeslání a p°esný £as jejího vloºení do bueru. Databáze se jeví jako nejoptimáln¥j²í sty£ný bod t¥chto dvou samostatn¥ fungujících aplikací. Pokud se odeslání zprávy nepoda°í, je tato zpráva p°esunuta do neodeslaných zpráv a uºivatel je o této zkute£nosti informován. Neschopnost doru£ení zprávy m·ºe být zap°í£in¥na p°edev²ím rozpadem komunika£ního kanálu na základ¥ ztráty signálu, neo£ekávaného ukon£ení klientské aplikace a jiných vn¥j²ích vliv·.
4.3.1 Vnit°ní struktura serverové aplikace V této kapitole uvedu princip fungování serverové aplikace a v²e pot°ebné pro programátora, který by rád vyuºil sluºby vý²e uvedeného protokolu. Po spu²t¥ní serverové aplikace jsou vytvo°eny mimo hlavního vlákna dal²í dv¥
44
vlákna. Jedno vlákno má na starost obsluhu p°ijatých zpráv a druhé hlídá buer výstupních zpráv (do poznamky,ze to je v DB), které odesílá adresát·m. Hlavní mate°ské vlákno má na starosti p°íjem nových spojení. Nová vlákna vznikají pomocí POSIX knihovny. Mate°ské vlákno vykonává kód main.cpp, po spu²t¥ní jsou zaloºeny ob¥ vý²e zmín¥ná vlákna a program o£ekává navázání socketového spojení. Pro detekci zm¥n na hlavním socketu je vyuºita blokující metoda epoll_wait(), která de nuje p°esné zm¥ny na socketu. Pokud je zaloºeno nové spojení mezi serverovou a klientskou aplikací, dojde k uloºení identi kátoru socketu do vektorové struktury a také p°idání identi kátoru socketu do mnoºiny socket· se kterou pracuje epoll vlákna pro obsluhu p°íchozích zpráv. Pokud je zji²t¥na zm¥na na n¥kterém z p°íchozích socket·, je z n¥j p°ectena vstupní informace a tato zpráva ve form¥ pole byt· je p°edána t°íd¥ zaji²´ující p°e£tení zprávy dle standardu vý²e uvedeného protokolu. Tuto úlohu má na starosti metoda decodeInput() t°ídy protocol, které je t°eba p°edat následující parametry: pole p°ijatých byt·, po£et p°ijatých byt· a identi kátor socketu ze kterého byla data p°ijata. P°ijatá data jsou poté zpracována na základ¥ jejich charakteru v kaºdém p°ípad¥ jsou v²ak uloºena do databáze. GPS data jsou uloºena do zvlá²tní tabulky pro zobrazení tracklog·, data zpráv jsou uloºena do tabulky historie p°ijatých zpráv a v p°ípad¥, ºe jsou ur£eny k rozeslání uºivatel·m mobilních aplikací je také vytvo°en a uloºen záznam do tabulky reprezentující výstupní buer zpráv. Druhé vlákno serverové aplikace, které bylo vytvo°eno po jejím startu obsluhuje vý²e zmín¥ný buer výstupních zpráv reprezentovaný databázovou tabulkou. Toto vlákno cyklicky kontroluje napln¥ní této tabulky, pokud se v tabulce objeví nový záznam ihned je odeslán pomocí de novaného socketu uºivateli. Serverová aplikace obsahuje implementaci protokolu prostoupenou do celé své struktury, tedy nelze vyjmout pouze její £ást pomocí které lze de novat sluºby protokolu. Tento model byl vyuºit pro serverovou aplikaci protoºe v p°ípad¥ roz²í°ení tohoto systému o£ekávám p°ipojování klientských aplikací pouze k této serverové aplikaci, proto není nezbytn¥ nutné vytvá°et nyní speciální knihovnu. Vytvo°ení této knihovny v²ak bude logickým vývojovým stupn¥m tohoto systému. Také vytvo°ení java knihovny pro implementaci komunika£ního protokolu do klientské aplikace bude následovat jako jeden z dal²ích krok· vývoje tohoto protokolu.
4.4
Databáze
V p°edchozím odstavci jsme si databázi de novali jako sty£ný bod TCP serveru a webového rozhraní sluºby. Je vyuºita databáze MySQL umíst¥ná na stejném po£íta£i jako b¥ºí ob¥ vý²e zmín¥né aplikace. Serverová aplikace obsluhující p°ijaté zprávy m·ºe vkládat data do libovolných tabulek a £iní tak v p°ípad¥ záznamu p°íchozí zprávy (tabulka `messages`), p°íchozí informaci o pozici uºivatele (tabulka `location`) a upravuje tabulky de nující dostupnost jednotlivých klientských za°ízení (tabulky
45
`logged` a `connected`). Serverová aplikace také p°istupuje k tabulce `data_for_send`, ve které se mohou nacházet zprávy, které je t°eba odeslat klientským za°ízením. Po odeslání zprávy je tato zpráva z tabulky odebrána. Ideální stav tedy znamená, ºe tato tabulka je prázdná.
4.5
Webová aplikace
Webová aplikace není p°edm¥tem této práce, slouºí pouze pro vizualizaci p°enesených dat a pro komunikaci mezi klientskými aplikacemi a serverovou aplikací. Prost°edí webové aplikace je pro uºivatele vstupní branou pro zobrazení zaznamenaných údaj· o pohybu uºivatel·, p°ípadn¥ pro ºivé sledování aktivních za°ízení. Webová stránka této sluºby je dostupná na internetové adrese livetrack.indesk.cz a poºaduje po náv²t¥vníkovi autentizaci pomocí jména a hesla. Pro sledování uºivatel· je vyuºito Google Maps API[38], které poskytuje zobrazení mapy de nované geogra cké oblasti, dále je moºné pomocí tohoto API do zobrazené mapy zakreslovat údaje jako je aktuální poloha uºivatele a trasa, kterou urazil. Webové rozhraní také umoº¬uje komunikaci s klientskou aplikací, resp. s uºivatelem, který ji vyuºívá na základ¥ textových zpráv, které je moºné kaºdému uºivateli s aktivním klientským za°ízením zaslat. Dále toto rozhraní umoº¬uje °ízení klientské aplikace, ve verzi 1.0 je moºné zasílat pouze poºadavky na zm¥nu frekvence odesílaných dat. Tyto funkce komunikace mezi serverem a klientskou aplikací vyuºívají databázovou tabulku, do které vkládají dle protokolu vytvo°ené zprávy. Obsah této tabulky hlídá jedno vlákno serveru komunikujícím p°ímo s klientskými aplikacemi a v p°ípad¥ objevení nové hodnoty, je tato ihned odeslána. Pro práci s protokolem, tedy tvo°ení zpráv dle protokolu je de nován soubor protocol.php, který po vloºení do webového systému poskytuje funkce sendMgs(String, String, String), kde prvním parametrem je °et¥zec obsahující data zprávy, druhým °et¥zec obsahující identi kátor odesílatele a posledním parametrem je °et¥zec obsahující identi kátor adresát·. Dal²í funkcí, která je po vloºení souboru protocol.php do projektu k dispozici je funkce setInterval(String,int). Prvním parametrem je °et¥zec obsahující identi kátor uºivatele, jehoº klientské aplikace se zm¥na týká a druhým parametrem je celo£íselná hodnota de nující délku intervalu zasílání zpráv, jednotkou je po£et sekund.
46
5
Testování navrºeného systému
5.1
Testy datové náro£nosti
Nejprve jsem se p°i testování protokolu, resp. aplikací s ním svázaných zam¥°il na test datové náro£nosti protokolu. Toto je ihned po funkcionalit¥ p°enosového protokolu nejd·leºit¥j²í aspekt, který byl jedním z d·vod· tvorby vlastního protokolu a nevyuºití nap°íklad n¥které RPC metody. V²echny testy jsem provád¥l na mobilním telefonu Sony Ericsson G800, který vyuºívá OS Symbian
25 , p°ipojení poskytl mobilní operátor Vodafone. M¥°ení byla
provád¥na na území hlavního m¥sta Prahy a m¥sta Hluboká nad Vltavou. Datový tok, který aplikace generuje samoz°ejm¥ závisí na mnoha faktorech, jsou to p°edev²ím vzorkovací frekvence a formát, resp. obsah zpráv. Testy probíhaly za následujících podmínek.
Odesílání jednoduchých GPS sou°adnic ve formátu ddmm.mmmm, N/S; dddmm. mmmm, E/W
Voliteln¥ dopln¥ní o zabezpe£ující data Voliteln¥ dopln¥ní o £asová data Vzorkovací frekvence se m¥ní v následujícím intervalu - 1s, 10s, 30s, 1min, 5min, 10min, 15min
Byly provedeny celkem 2 m¥°ení pro kaºdou kombinaci vý²e uvedených prom¥nných hodnot o délce trvání 5-30 minut v závislosti na délce vzorkovací frekvence. Pr·m¥rné zatíºení p°enosového kanálu vztaºené na p°enos jedné sou°adnice je v následující tabulce. pouze GPS
GPS data +
GPS data +
data
zabezpezpe£ení
zabezpezpe£ení + £as
Pr·m¥rná velikost
93B
126B
139B
p°ená²ené zprávy Tabulka 3: Pr·m¥rná datová zát¥º kanálu na jednu p°enesenou zprávu
Pro porovnání pokud bychom stejná data p°ená²eli pomocí XML-RPC, datová zát¥º by se pohybovala p°ibliºn¥ v rozmezí 600-700B na jednu zprávu. Tedy je zde z°ejmá úspora p°ená²ených dat oproti XML-RPC p°ibliºn¥ ²estinásobná, coº dokáºe
25 Toto
je d·leºitý fakt, protoºe r·zní výrobci poskytují r·zné JVM do svých za°ízení a ne v²echny
se chovají naprosto identicky, speciáln¥ v kontextu socketového spojení.
47
uºivateli uspo°it jiº znatelnou £ást prost°edk· pot°ebných pro chod aplikace, a´ jiº energetických nebo nan£ních. Pokud bychom si p°edstavili modelový p°ípad uºivatele pracujícím 5 hodin s touto aplikací a interval mezi vzorky je nastaven na 60 sekund, tedy bude p°eneseno celkem p°ibliºn¥ 27kB dat. Tento datový p°enos bude uºivatele stát p°i vyuºití nejnevýhodn¥j²ího tarifu
26 p°ibliºn¥ 1,674 K£. V porovnání s p°enosem teoreticky vyuºívajícím
technologii XML-RPC, kdy by tento p°enos stál uºivatele 11,70 K£. I tato cena se zdá být akceptovatelná, ov²em v p°ípad¥ £ast¥j²ího vyuºití, p°ípadn¥ zvý²ení snímací frekvence m·ºe velmi nar·st. Mnoho uºivatel· by vysoká cena za datový p°enos mohla odradit od vyuºívání této sluºby, proto lze dosaºený výsledek hodnotit kladn¥.
5.2
Testy stálosti p°ipojení
Test stálosti p°ipojení nelze nijak £ísly popsat, aplikace byla vyzkou²ena v mnoha podmínkách nestálého signálu mobilní sít¥. Po op¥tovném p°ipojení mobilního telefonu byla automaticky navázána komunikace se serverovou aplikací a pokud byly v dob¥ stavu bez p°ipojení vygenerovány n¥jaké zprávy, byly tyto ihned po navázání spojení se serverovou aplikací odeslány. Systém tedy garantuje dostupnost uºivatele v p°ípad¥, ºe se nachází v zón¥ signálu mobilí sít¥.
26 Kaºdý
mobilní operátor poskytuje stálé p°ipojení s neomezeným p°enosem dat, ov²em je t°eba
platit pau²ální platby, toto uºivatel·m vyuºívajícím datové sluºby nevyhovuje, proto vyuºívají nabídku jednorázového zpoplatn¥ní konkrétního datového p°enosu cca 0,06 K£ za kB. [47]
48
6
Uºivatelská p°íru£ka
6.1
Klientská aplikace
Úvod
Pro práci s klientskou aplikací je nutné vyuºití mobilního telefonu nebo jiného
27 je
mobilního za°ízení s podporou Java prost°edí. S vyjímkou enter-level model·
v²ak toto prost°edí implementováno v drtivé v¥t²in¥ za°ízení. klientská aplikace ve verzi 1.0 nemá podporu pro za°ízení BlackBerry a za°ízení vyuºívající opera£ní systém Android. Podpora i pro tato za°ízení bude uvedena v n¥které z dal²ích verzí klientské aplikace.
Získání aplikace
Klientskou aplikaci ve form¥ .jar souboru je moºné stáhnout z in-
ternetových stránek projektu. Je moºné tento archiv uloºit do pam¥ti osobního po£íta£e a teprve z n¥j p°esunout do mobilního za°ízení. Pro verzi klientské aplikace 1.0 je moºné vyuºít p°ímý odkaz http://livetrack.indesk.cz/ download/LiveTracking.jar, doporu£uji v²ak rad¥ji nav²tívit internetovou stranu http://livetrack.indesk.cz/?list=stazeni, kde naleznete aktuální uvoln¥nou stabilní verzi. Alternativní p°esun aplikace do mobilního za°ízaní p°edstavuje p°ímá instalace, kdy po zadání vý²e uvedené adresy (.jar souboru) do internetového prohlíºe£e va²eho mobilního za°ízení dojde ke staºení a instalaci aplikace.
První kroky
P°ed prvním spu²t¥ním je nutné se zaregistrovat do sluºby na interne-
tových stránkách projektu http://livetrack.indesk.cz, kde budete poºádáni o vypln¥ní n¥kolika osobních údaj·. Po úsp¥²né registraci je moºné spustit klientskou aplikaci.
P°ihlá²ení
Po prvním spu²t¥ní aplikace budete vyznáni k vloºení va²ich p°ihla²o-
vacích údaj·. Jako jméno zvolte va²i p°ezdívku, kterou jste uvedli p°i registraci na internetovém portálu. Pokud nechcete p°i p°í²tím spu²t¥ní aplikace tyto údaje jiº zadávat, za²krtn¥te volbu pamatovat si uºivatele, tímto budou vámi vypln¥ní údaje uloºeny do databáze klientské aplikace a p°i p°í²tím spu²t¥ní budou pouºity. Pokud si p°ejete se serverovou aplikací komunikovat zabezpe£en¥, tedy mít jistotu, ºe va²e zprávy nebudou podvrhnuty, za²krtn¥te poloºku zabezpe£ené spojení. Tato volba v²ak zp·sobí v¥t²í náro£nost na p°enesená data. Pokud tedy nedisponujete stálým internetovým p°ipojením, doporu£uji tuto poloºku nechat nezatrºenou.
27 Jako
entery-level modely lze ozna£it za°ízení, která nabízejí pouze základní sumu funkcí, které
uºivatel o£ekává od za°ízení, v tomto p°ípad¥ mobilního telefonu. Tyto modely jsou extrémn¥ levné a jsou £asto vyuºívány uºivateli, kte°í od mobilního telefonu o£ekávají pouze funkci telefonování, p°ípadn¥ psaní SMS zpráv.
49
Nastavení
Po korektním p°ihlá²ení bude zobrazeno textové pole, ve kterém naleznete
informace o stávajícím stavu aplikace, tedy po p°ihlá²ení zde bude uvedeno jsem p°ihlá²en. P°ed spu²t¥ním aplikace je nutné nastavit zdroj GPS signálu. Verze 1.0 podporuje pouze bluetooth externí GPS moduly. P°ipravte si tedy tento modul, zapn¥te jej, spárujte jej s va²ím mobilním za°ízením a ponechte aktivní bluetooth adaptér. Pro nalezení va²eho GPS modulu vejd¥te do Menu/Nastavení/Vybrat zdroj signálu/ a klikn¥te na jednu ze zde uvedených voleb. V závislosti na po£tu bluetooth aktivních za°ízení ve va²em okolí bude d°íve £i pozd¥ji zobrzen seznam dostupných za°ízení. Z uvedeného seznamu vyberte GPS za°ízení a potvr¤te. Ve výpisu aplikace uvidíte potvrzení va²eho výb¥ru. Pokud chcete smazat v²echny vámi uloºené údaje aplikace klikn¥te na Menu/ Nastavení/Smazat uloºené údaje o uºivateli. Chcete-li zm¥nit frekvenci se kterou budou odesílány zprávy na server, klikn¥te na Menu/Nastavení/Nastavit vzorkovací interval a vyberte z uvedených hodnot. ím krat²í interval, tím p°esn¥j²í sledování va²í polohy, ov²em za cenu zvý²ené náro£nosti na p°enesená data a tedy i zvý²enou energetickou náro£nost - baterie mobilního telefonu se rychleji vybije. Pro sledování pomalej²ích p°esun· jako je ch·ze posta£uje nastavení snímání v °ádu minut, pro rychlej²í pohyb, nap°. jízdu automobilem je výhodn¥j²í volit krat²í interval.
Zprávy
Ve verzi aplikace 1.0 je moºné rozesílat zprávy, které se zobrazí v²em ak-
tivním uºivatel·m i uºivatel·m p°ihlá²eným na webové stránce sluºby. Pokud chcete odeslat zprávu, klikn¥te na Menu/Odeslat zprávu/Napsat & odeslat zprávu, do zobrazeného textového pole napi²te va²i zprávu a ode²lete. Budete automaticky vráceni na hlavní stranu aplikace, kde se zobrazí informace o odeslané zpráv¥. Pokud vám bude doru£ena zpráva, v hlavním výpisu bude tato zpráva zobrazena.
50
Obrázek 14: Výpis p°ijaté zprávy v prost°edí klientské aplikace
GPS monitoring
Jádrem aplikace je online sledování a zaznamenávání polohy uºi-
vatele, pokud jste provedli nastavení zdroje signálu GPS m·ºete kliknout na Menu/Spustit monitoring. Budete p°esm¥rováni na hlavní stranu aplikace, kde bude zobrazen £as odeslání poslední zprávy s GPS údaji, tento údaj je pr·b¥ºn¥ aktualizován. Pokud je monitoring aktivní, uºivatelé p°ihlá²ení k webovému rozhraní mohou sledovat vá² pohyb.
Obrázek 15: Výpis odeslané GPS informace v prost°edí klientské aplikace
51
Skrytí aplikace
Pokud pot°ebujete s mobilním za°ízením dále pracovat, m·ºete
b¥ºící aplikaci minimalizovat a umoºnit tak dal²í práci se za°ízením. Po kliknutí na Menu/Skrýt aplikaci dojde ke skrytí této aplikace. Pokud chtete aplikaci op¥t obnovit, u£i¬te tak stejným zp·sobem jako jste aplikaci spou²t¥li.
6.2
Webové rozhraní
Webové rozhraní sluºby naleznete na internetové stránce http://livetrack. indesk.cz. Pokud jste na této stránce poprvé, je t°eba se zaregistrovat a vytvo°it tak nového uºivatele. po p°ihlá²ení vidíte v pravé £ásti obrazovky seznam aktuáln¥ aktivních uºivatel·, pokud kliknete na podrobnosti u daného uºivatele, máte moºnost spustit sledování tohoto uºivatele, zaslat mu zprávu nebo zm¥nit jeho frekvenci zasílání zpráv. Pod tímto zobrazením naleznete historii aktivity uºivatel· i va²i, v p°ípad¥, ºe se jedná o doru£enou zprávu, je moºné tuto zprávu otev°ít a p°e£íst, je-li uºivatel stále aktivní, je moºné na tuto zprávu p°ímo reagovat. Ve spodní £ásti pravého sloupce naleznete volbu pro odhlá²ení uºivatele. Pokud zadáte volbu sledování uºivatele bude zobrazena jeho aktuální poloha v map¥, tato hodnota je aktualizována v £asovém intervalu de novaném daným uºivatelem - v p°ípad¥ pot°eby je moºné tento interval zm¥nit - viz vý²e. P°i pohybu uºivatele je zaznamenávána i jiº pro²lá trasa.
Obrázek 16: Uºivatelské webové rozhraní po p°ihlá²ení
52
7
Záv¥r
7.1
Zhodnocení práce
V této práci jsem se snaºil dosáhnout v²ech stanovených cíl·, tedy pokusil jsem se zanalyzovat technologie a postupy, které jsou pot°ebné pro p°enos informací mezi dv¥ma systémy z nihº jeden se nachází na mobilním za°ízení a proto má omezené výpo£etní a spojové vlastnosti. Mobilní za°ízení jsou velmi r·znorodá a poskytují uºivateli £asto velmi rozdílné pracovní prost°edí, která nabízí £asto velmi odli²né moºnosti co se týká návrhu nových aplikací. Na základ¥ zhodnocení dostupnosti jednotlivých technologií bylo jako implementa£ní prost°edí zvoleno J2ME, které nabízí jistou p°enositelnost aplikace mezi r·znými systémy. V prost°ení J2ME byl navrhnut a implementován zcela nový p°enosový protokol, který se snaºí nabídnout uºivateli komfort p°enosu r·zných typ· informací za cenu minimální moºné reºie a tedy náklad· spojených s p°enosem dat. Programátorovi nabízí jednoduchou cestu k roz²í°ení protokolu o sluºbu a typ dat, která pot°ebuje p°ená²et. Tento protokol je také zabezpe£en proti podvrhu zprávy jednoduchým av²ak pom¥rn¥ silným zabezpe£ením, toto zabezpe£ení dat je v£ak také volitelné a uºivatel nedisponující stálým datovým p°ipojením tak m·ºe naprosto minimalizovat náklady na provoz aplikací zaloºených na tomto protokolu. Dále byl navrhnut server obsluhující klienty komunikující pomocí TCP spojení a vý²e uvedeným protokolem, tato aplikace dokáºe obslouºit i více klient· zárove¬ a úzce spolupracuje s webovou uºivatelskou aplikací prost°ednictvím databázových tabulek. Pro prezentaci dat byla vytvo°ena webová aplikace, pomocí které je moºné sledovat p°ipojené uºivatele, zasílat jim zprávy a °ídit chod jejich klientské aplikace. Tato aplikace je nutným prvkem pro pouºívání celého systému, je nutné se zde registrovat a pod registra£ními údaji obsluhovat i klientskou aplikaci v mobilním za°ízení.
7.2
Dal²í vývo j
Ukon£ením této práce vývoj systému LiveTracking rozhodn¥ nekon£í. Tento systém bude i nadále rozvíjen na dobrých základech poloºených touto prací. Dal²í plánované roz²í°ení aplikace zahrnuje následující kroky, které by mely být v pr·b¥hu první poloviny roku 2011 realizovány.
Moºnost zasílání zpráv pouze konkrétním (a online) uºivatel·m Spolupráce aplikace s interním GPS modulem
53
Vytvo°ení knihovny pro J2ME a C++ poskytující v této práci implemntované sluºby protokolu pro snadn¥j²í p°enositelnost
P°eklad protokolu do Anglického jazyka a zve°ejn¥ní na SourceForge Vytvo°ení systému pro trasování, tedy vytvo°ení databáze objekt· a stav·, které budou de novány pro kaºdý typ trasování, jako p°íklad lze uvést monitoring vodního toku, kde p°i postupu korytem uºivatel bude moci jednodu²e zaznamenávat katalogové údaje, tedy nap°íklad jez, padlý strom, budova, nebezpe£né pe°eje aj., tento katalog bude moºné aktualizovat pomocí servisních zpráv. Vytvo°ený listening bude moºné online doplnit o up°es¬ující informace
Vývoj nové klientské aplikace pro mobilní telefony iPhone rmy Apple Implementace prost°edí Google maps do klientské aplikace pro zobrazení aktuální polohy i polohy ostatních uºivatel·
Vytvo°ení systému pro tvo°ení automatické knihy jízd Vytvo°ení systému Bez kolon, který na základ¥ doru£ených anonymních dat od uºivatel· dokáºe analyzovat hustotu dopravního provozu a detekovat kolony, p°ípadn¥ jiné problémy silni£ního provozu pln¥ automaticky a ihned. Detekce bude probíhat na základ¥ rychlosti pohybu uºivatel·, kte°í tuto aplikaci budou vyuºívat v modu Bez kolon. Distribuce problémových míst ihned v²em online uºivatel·m. Dále moºnost ur£it reálnou dobu dojezdu do cíle i s p°ihlédnutím k aktuální pr·jezdnosti trasy.
Upravení stávající aplikace pro sledování d¥tí (vlastních), zabrán¥ní zatoulání dít¥te, v p°ípad¥ únosu nebo jiné trestné £innosti moºnost sledovat stopu alespo¬ do chvíle neº dojde k vypnutí p°ístroje.
Z vý²e uvedeného seznamu je z°ejmé, ºe aplikací postavených na základ¥ zde implementovaného protokolu je obrovské mnoºství a lze vymý²let stále nové a nové moºnosti uplatn¥ní pro znalost polohy osoby £i stroje. Proto p°edpokládám a doufám, ºe výsledky této práce se stanou dobrým základem mnoha zajímavých aplikací.
54
Rejst°ík UDDI, 18
, 4
UDP, 15 AJAX, 20 Android, 13
Windows mobile, 12
Apple, 14
WSDL, 18
Bada, 11
XML-RPC, 17
BlackBerry, 13
XMLHttpRequest, 21
Burlap, 19 C++, 44 Google.Maps API, 46 GPS, 4 GPS-200A, 9 Hessian, 19 HTML, 16 HTTP, 16 iOS, 14 Ipv6, 33 ISO OSI, 15 J2ME, 27 JVM, 27, 30 MySQL, 45 NMEA, 30 NMEA 0183, 10, 31 POSIX, 45 RMC, 10 RMS, 31 RPC, 16 SOAP, 18 Symbian, 11 TCP, 3, 16, 17, 28, 29, 45, 53
55
Seznam obrázk· 1
Vizualizace rozmíst¥ní GPS satelit· na ob¥ºné dráze, zdroj [40]
2
Ur£ení polohy v 1D prostoru, zdroj [36]
3
Ur£ení polohy ve 2D prostoru, zdroj [36] . . . . . . . . . . . . . . . . .
6
4
Pr·se£ík t°í hyperbol, zdroj [36] . . . . . . . . . . . . . . . . . . . . . .
7
5
P°enos informace v systému aktivního sledování, zdroj vlastní a internet
9
6
Ukázkový záznam NMEA komunikace pomocí programu Nmeamon, zdroj [41]
. . .
5
. . . . . . . . . . . . . . . . .
5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
7
Moºnosti rozloºení zát¥ºe mezi klentem a serverem, zdroj [42] . . . . .
17
8
Souvislosti mezi SOAP, WSDL a UDDI, zdroj [43]
18
9
. . . . . . . . . . .
Srovnání klasického p°ístupu k obnov¥ dat webové aplikace a pomocí AJAX technologie, zdroj vlastní a [44] . . . . . . . . . . . . . . . . . .
21
10
Ukázka b¥hu aplikace Google Latitude, zdroj [45] . . . . . . . . . . . .
23
11
Ukázka b¥hu aplikace TrackMyJourney, zdroj [46] . . . . . . . . . . . .
24
12
ivotní cyklus midletu . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
13
Automat garantující stálost spojení se serverem a odesílající zprávy
.
30
14
Výpis p°ijaté zprávy v prost°edí klientské aplikace
. . . . . . . . . . .
51
15
Výpis odeslané GPS informace v prost°edí klientské aplikace . . . . . .
51
16
Uºivatelské webové rozhraní po p°ihlá²ení
52
56
. . . . . . . . . . . . . . . .
Obsah p°iloºeného CD Adresá° ./live_tracking
Obsah Data J2ME klientské aplikace
/src /build
Zdrojové kódy P°eloºené soubory
/dist /nbproject
JAR soubory NetBeans project soubory
./server
Data serverové aplikace
./web_server
Data webové prezentace
/src /screens ./text /src /pdf /ps ./readme.txt
Zdrojové kódy Snímky obrazovek Data této práce Zdrojový kód pro LYX Text v Pdf formátu Text v PostScript formátu Soubor s obsahem a pokyny k instalaci
57
Reference [1] ECKEL Bruce: Myslíme v jazyku C++ 2.díl. Praha: Grada, první vydání, 2006, ISBN 80-247-1015-3
[2] DOSTÁLEK Libor, KABELOVÁ Alena: Velký pr·vodce protokoly TCP/IP a systémem DNS, Praha: Computer Press, první vydání, 2000, ISBN 80-7226-3234 [3] MAHMOUD Qusay H. :Nau£te se Java 2 Micro Edition, Praha: Grada, první vydání, 2002, ISBN 80-247-0444-7 [4] PRATA Stephen: Mistrovství v C++, Praha: Computer Press, t°etí vydání, 2007, ISBN: 978-80-251-1749-1 [5] HEROUT Pavel: U£ebnice jazyka Java. eské Bud¥jovice: KOPP, první vydání, 2004, ISBN 80-7232-115-3. [6] BITTNEROVÁ Lucie: Seriál Kdo si J2ME, nezlobí [online] 2005 [cit. 11 2010] [7] Mobil.cz:
Samsung
p°edstavil
vlastní
OS
Bada,
[online],
11.11.2009,
[cit.
9.10.2010] [8] Mobilmania.cz: Windows Mobile má nakro£eno k zániku, [online],20. 8. 2009, [cit. 9.10.2010] [9] Android developers: What is Android, [online], 22.9.2010, [cit. 20.12.2010] [10] Reuters: Nokia pact helps Microsoft, [online], 17.8.2009, [cit. 20.12.2010], [11] SOAP: Popis technologie, [online], 8.1.2002, [cit. 15.11.2010] [12] Mobilmania.cz: Výrobci a opera£ní systémy, [online], 24.5.2010, [cit. 18.11.2010] [13] Embedded Interaction: Accessing GPS receiver, [online], [cit. 8.12.2010] [14] P°edm¥t internetové technologie: Web services, [online], [cit. 20.12.2010]
58
[15] Google Maps API Tutorial: The Basics, [online], [cit. 26.11.2010] [16] Google Maps API: Elevation, [online], 2010, [cit. 30.11.2010] [17] Dione: Java, [online], 4.1.2001, [cit. 28.10.2010] [18] NetBeans: Webservices, [online], 3.5.2009, [cit. 5.11.2010] [19] Root: Ajax, [online], 3.10.2005, [cit. 9.12.2010] [20] Gartner: Forecast OS sales, [online], srpen 2010, [cit. 8.9.2010] [21] Alza: Nabídka zboºí, [online], [cit. 28.12.2010] http://www.alza.cz/huawei-u8100-d195456.htm [22] Alza: Nabídka zboºí, [online], [cit. 28.12.2010] http://www.alza.cz/nokia-c5-sedy-d159160.htm [23] Symbian portál: Symbian, základní p°ehled, [online], 7.12.2006, [cit. 8.10.2010] [24] PCCgeeks: Windows Phone 7, [online], 6.2.2010, [cit. 10.10.2010] [25] Java rants: Android dalvik vm, [online], 2.2010, [cit. 7.12.2010] [26] CTO Edge: How dalvik vm works, [online], 3.2010, [cit. 7.12.2010] [27] Wagner Vladimír: P°esnost atomových hodin, GPS a teorie relativity, [online], [cit. 25.10.2010] [28] Wikipedia: Azimut, [online], [cit: 26.10.2010] [29] Marigold: Standardy není jen UMTS, [online], 5.2.2010, [cit.13.12.2010] [30] Mobilní telefony: GPRS, [online], [cit. 13.12.2010] [31] Wikipedia: Java ME, [online], [cit. 10.11.2010]
59
[32] Sít¥: Model ISO/OSI, [online], [cit. 15.11.2010] [33] W3: WSDL, [online], 15.3.2001, [cit. 28.12.2010] [34] W3: XMLHttpRequest, [online], 3.8.2010, [cit. 28.12.2010] [35] Oracle: DiscoveryListener class, [online], 2006, [cit. 15.11.2010] [36] ABClinuxu: GPS a komunika£ní protokol nmea, [online], 6. 9. 2006, [cit. 28.11.2010] [37] Die: Epoll, [online], [cit. 8.11.2010] [38] Google: Maps API, [online], [cit.15.11.2010] [39] Hejna Martin: STUN, [online], 30.5.2006, [cit. 29.12.2010] [40] Bailey Graham: SATELLITE NAVIGATION, [online], 2005, [cit.10.11.2010] [41] Matrix Mariner: Nmeamon, [online], [cit. 10.11.2010] [42] COMET, [online], 21.10.2010, [cit. 2.11.2010] [43] Kosek: Webové sluºby, [online], [cit.5.12.2010] [44] Cidamon: Ajax, [online], [cit. 8.12.2010] [45] Google: Latitude, [online], [cit. 20.12.2010] <www.google.com/latitude> [46] Trackmyjourney, [online], [cit. 20.12.2010] [47] Vodafone: Tarify, [online], [cit. 1.1.2011]
60
