TECHNICK ´ A UNIVERZITA V LIBERCI Fakulta mechatroniky, informatiky a mezioborov´ ych studi´ı
DIPLOMOV ´ A PR ´ ACE
V Liberci, 18. kvˇetna 2013 Bc. Jakub Ponikelsk´y
TECHNICK ´ A UNIVERZITA V LIBERCI
Fakulta mechatroniky, informatiky a mezioborov´ ych studi´ı
Studijn´ı program: N2612 – Elektronika a informatika Studijn´ı obor: 1802T007 – Informaˇcn´ı technologie
Ovl´ ad´ an´ı zabezpeˇ covac´ı kamery EYE-02 protokolem XMPP
Control of security camera EYE-02 via XMPP protocol
Bc. Jakub Ponikelsk´ y
Vedouc´ı pr´ace: doc. RNDr. Pavel Satrapa, Ph.D.
Konzultant: Ing. Jan Halama, JABLOCOM s. r. o.
Pracoviˇstˇe: Ustav nov´´ ych technologi´ı a aplikovan´e informatiky
Prohl´ aˇ sen´ı
Byl(a) jsem sezn´amen(a) s t´ım, ˇze na mou diplomovou pr´aci se plnˇe vztahuje z´akon ˇc. 121/2000 Sb., o pr´avu autorsk´em, zejm´ena § 60 – ˇskoln´ı d´ılo.
Beru na vˇedom´ı, ˇze Technick´a univerzita v Liberci (TUL) nezasahuje do m´ych autorsk´ych pr´av uˇzit´ım m´e diplomov´e pr´ace pro vnitˇrn´ı potˇrebu TUL.
Uˇziji-li diplomovou pr´aci nebo poskytnu-li licenci k jej´ımu vyuˇzit´ı, jsem si vˇedom povinnosti informovat o t´eto skuteˇcnosti TUL; v tomto pˇr´ıpadˇe m´a TUL pr´avo ode mne poˇzadovat ´uhradu n´aklad˚u, kter´e vynaloˇzila na vytvoˇren´ı d´ıla, aˇz do jejich skuteˇcn´e v´yˇse.
Diplomovou pr´aci jsem vypracoval(a) samostatnˇe s pouˇzit´ım uveden´e literatury a na z´akladˇe konzultac´ı s vedouc´ım diplomov´e pr´ace a konzultantem.
Datum:
18. kvˇetna 2013
Podpis:
. . . . Bc. Jakub Ponikelsk´y
Podˇ ekov´ an´ı
Touto cestou bych r´ad podˇekoval vedouc´ımu diplomov´e pr´ace doc. RNDr. Pavlu Satrapovi, Ph.D., za jeho cenn´e pˇripom´ınky pˇri vytv´aˇren´ı a dokonˇcov´an´ı pr´ace. R´ad bych tak´e podˇekoval spoleˇcnosti JABLOCOM s. r. o. za zprostˇredkov´an´ı pr´ace a jme- novitˇe pak Ing. Janu Halamovi a Ing. Pavlu Vikovi, Ph.D., za rady a veˇskerou pomoc pˇri konzultac´ıch.
D´ale bych velmi r´ad podˇekoval sv´e rodinˇe za oporu, kterou mi poskytovala bˇehem cel´eho studia, konkr´etnˇe pak za mor´aln´ı podporu bˇehem kompletov´an´ı t´eto diplomov´e pr´ace a vytvoˇren´ı potˇrebn´eho z´azem´ı pro klidn´e studium na vysok´e ˇskole.
Pouˇ zit´ y software
Tato pr´ace byla vys´azena pomoc´ı syst´emu LATEX (prosˇred´ı Eclipse Juno ve verzi 4.2.1, plugin TeXlipse a s´azec´ı syst´em MiKTeX ve verzi 2.9) a programu Software Ideas Modeler (v´yvojov´e a dalˇs´ı diagramy) pod operaˇcn´ım syst´emem Microsoft Windows 7 Professional 64b. Jako n´astroj pro tvorbu zdrojov´ych k´od˚u bylo pouˇzito Microsoft Visual Studio 2010 Ultimate.
Kontakt
E-mail: jakub.ponikelsky@tul.cz
Abstrakt
C´ılem t´eto diplomov´e pr´ace je rozˇs´ıˇrit mnoˇzinu komunikaˇcn´ıch kan´al˚u slouˇz´ıc´ıch pro ovl´ad´an´ı bezpeˇcnostn´ı kamery EYE-02 o protokol XMPP. V teoretick´e ˇc´asti je struˇcnˇe pˇredstaven zadavatel projektu spoleˇcnost Jablocom s. r. o. a z´akladn´ı cha- rakteristick´e vlastnosti jej´ıho produktu – kamery EYE-02. D´ale je zde sezn´amen´ı se z´akladn´ımi mechanismy protokolu XMPP, jejichˇz pochopen´ı je d˚uleˇzit´e k vybudov´an´ı sluˇzby, kter´a by mˇela nahrazovat XMPP klienta pro vybranou kameru.
V praktick´e ˇc´asti je nejdˇr´ıve pops´an v´ybˇer XMPP serveru a jeho nastaven´ı tak, aby byla zaruˇcena maxim´aln´ı ´uroveˇn zabezpeˇcen´ı pˇren´aˇsen´ych dat ale i sa- motn´eho syst´emu. D´ale je zde navrˇzena podoba datab´aze, kter´a tvoˇr´ı prostˇredn´ıka mezi sluˇzbou a existuj´ıc´ı infrastrukturou spoleˇcnosti Jablocom s. r. o. K t´eto datab´azi je pak navrˇzena a implementov´ana WCF sluˇzba pro pˇrid´av´an´ı povel˚u do datab´aze a naopak z´ısk´av´an´ı a filtrov´an´ı poˇzadavk˚u v datab´azi.
N´aslednˇe je zde navrˇzena a implementov´ana sluˇzba, kter´a umoˇzˇnuje pˇren´aˇset uˇzivatelsk´e zpr´avy (poplachy, stavov´e zpr´avy, chyby) z kamery na IM klienta uˇzivatele a naopak od nˇej pˇreb´ır´a ovl´adac´ı povely a zobrazuje aktu´aln´ı stav kamery (watch, sleep). Sluˇzba m´a tak´e implementov´any z´akladn´ı postupy pro pˇrenos soubor˚u a video- hovor˚u prostˇrednictv´ım protokolu XMPP. D´ale je pak implementov´ana hlavn´ı sluˇzba, kter´a kontroluje spr´avnost chodu jednotliv´ych vl´aken a v periodick´ych intervalech spouˇst´ı nebo naopak ukonˇcuje vl´akna vybran´ych kamer. Posledn´ı vytvoˇrenou aplikac´ı je pak webov´a str´anka slouˇz´ıc´ı k administraci cel´eho syst´emu.
Kl´ıˇcov´a slova:
XPPP protokol, bezpeˇcnostn´ı kamera, pˇrenos zpr´av,
XMPP server, XMPP sluˇzba
Abstract
The objective of this thesis is to add XMPP protocol into a set of communi- cation channels used to control security camera EYE-02. The theoretical part presents the project submitter Jablocom ltd. and basic properties of the product – EYE-02.
Then there is the introduction to the basic mechanisms of the protocol XMPP, whose understanding is important to build a service that would replace XMPP client for the selected camera.
The practical part of the thesis describes selection of the XMPP server and configuration of the XMPP server to ensure the safety of transmitted data as well as the system itself. Then there is a database designed, which is an intermediary be- tween the service and the infrastructure of Jablocom ltd. and WCF Service for adding commands to the database and retrieving and filtering commands from the database.
Then there is a service designed and implemented. The service allows to transmit messages (alarms, status messages, errors) from the camera to the IM client of user and to take control command from the user and to display the current status of the camera (watch, sleep). The service has also implemented the basic procedures for transferring files and making video calls via XMPP protocol. There is also main service implemented. Main service checks the runtime of individual fibers in periodic intervals and launches or terminates fibers of selected cameras. Last created application is a webpage that is used to administer the whole system.
Keywords:
XMPP protocol, security camera, instant messaging, XMPP server, XMPP service
Obsah
Prohl´aˇsen´ı . . . . 3
Podˇekov´an´ı . . . . 4
Abstrakt . . . . 5
Abstract . . . . 6
Obsah . . . . 7
Seznam obr´azk˚u a tabulek . . . . 9
Seznam zkratek . . . . 10
1 Uvod´ . . . . 12
2 Sezn´amen´ı s prostˇred´ım . . . . 14
2.1 Spoleˇcnost Jablocom a jej´ı produkty . . . 14
2.1.1 Kamera EYE-02 . . . 15
2.2 XMP protokol (XMPP) . . . 17
2.2.1 Vlastnosti XMPP . . . 18
2.2.2 Adresa XMPP (JID) . . . 20
2.2.3 Princip navazov´an´ı relace . . . 21
2.2.4 Spr´ava kontakt˚u v XMPP . . . 22
2.2.5 Pˇrenos stavov´e informace v XMPP . . . 25
2.2.6 Spr´ava povolen´ı stavov´e informace v XMPP . . . 26
2.2.7 Pˇrenos zpr´av v XMPP . . . 28
3 Specifikace zad´an´ı . . . . 29
4 Realizace sluˇzby . . . . 31
4.1 V´ybˇer XMPP serveru . . . 32
4.1.1 Openfire . . . 32
4.1.2 Ejabberd . . . 34
4.1.3 Jabberd 2.x . . . 35
4.1.4 Tigase XMPP server . . . 36
4.1.5 Prosody . . . 37
4.1.6 Shrnut´ı a v´ybˇer . . . 38
4.1.7 Nastaven´ı . . . 40
4.2 Datab´aze . . . 42
4.2.1 WCF sluˇzba . . . 44
4.3 Vl´akno kamery . . . 47
4.3.1 Zpracov´av´an´ı poˇzadavk˚u . . . 49
4.3.2 Odesl´an´ı zpr´avy klientovi . . . 50
4.3.3 Zabezpeˇcen´ı pˇren´aˇsen´ych zpr´av . . . 51
4.3.4 Zmˇena stavu kamery . . . 54
4.3.5 Pˇrid´an´ı XMPP adresy do kontakt listu . . . 55
4.3.6 Odebr´an´ı XMPP adresy z kontakt listu . . . 57
4.3.7 Odesl´an´ı zpr´avy se soubory . . . 58
4.3.8 Pˇrenos videa protokolem XMPP . . . 61
4.4 Hlavn´ı sluˇzba . . . 65
4.5 Administr´atorsk´e rozhran´ı . . . 69
4.6 Uˇzivatelsk´e rozhran´ı . . . 71
5 Z´avˇer . . . . 73
Seznam pouˇzit´e literatury . . . . 75
Pˇr´ıloha A – Obsah CD . . . . 78
Seznam obr´ azk˚ u
Obr´azek 1: Princip XMPP pˇrenosu . . . 19
Obr´azek 2: Diagram otev´ır´an´ı XMPP relace . . . 22
Obr´azek 3: Sch´ema v´ysledn´e aplikace . . . 31
Obr´azek 4: Openfire – admin console – relace s XMPP servery . . . 33
Obr´azek 5: Schema datab´aze vyv´ıjen´e sluˇzby . . . 44
Obr´azek 6: Zivotn´ı cyklus vl´ˇ akna kamery . . . 48
Obr´azek 7: Vl´akno kamery – Zpracov´an´ı poˇzadavk˚u . . . 49
Obr´azek 8: Vl´akno kamery – Odesl´an´ı zpr´avy . . . 50
Obr´azek 9: Vl´akno kamery – Zmˇena stavu . . . 55
Obr´azek 10: Vl´akno kamery – Pˇrid´an´ı adresy klienta do kontakt listu . . . . 56
Obr´azek 11: Vl´akno kamery – Odebr´an´ı adresy klienta z kontakt listu . . . 57
Obr´azek 12: Vl´akno kamery – Odesl´an´ı zpr´avy se soubory . . . 58
Obr´azek 13: Vl´akno kamery – Vl´akno odes´ılaj´ıc´ı soubory . . . 59
Obr´azek 14: Princip videohovoru . . . 62
Obr´azek 15: Vl´akno kamery – Videohovor od kamery . . . 63
Obr´azek 16: Vl´akno kamery – Videohovor od klienta . . . 65
Obr´azek 17: ˇZivotn´ı cyklus hlavn´ıho vl´akna . . . 65
Obr´azek 18: Hlavn´ı vl´akno – Inicializace . . . 66
Obr´azek 19: Hlavn´ı vl´akno – Kontrola vl´aken . . . 67
Obr´azek 20: Hlavn´ı vl´akno – Spr´ava vl´aken . . . 68
Obr´azek 21: Uk´azka administr´atorsk´eho rozhran´ı . . . 69
Obr´azek 22: Uk´azka ovl´ad´an´ı sluˇzby – Klient Google chat . . . 72
Seznam tabulek
Tabulka 1: Uk´azka XMPP komunikace . . . 21Tabulka 2: Srovn´an´ı XMPP server˚u – Obecn´e informace . . . 39
Tabulka 3: Srovn´an´ı XMPP server˚u – Moˇznosti nastaven´ı . . . 39
Tabulka 4: Srovn´an´ı XMPP server˚u – Podpora standard˚u . . . 40
Tabulka 5: Vyv´ıjen´a aplikace – Druhy poˇzadavk˚u . . . 43
Tabulka 6: Vyv´ıjen´a aplikace – F´aze zpracov´an´ı poˇzadavku . . . 43
Seznam zkratek
AGP L Affero General Public License
AOL America Online
AP I Application Programming Interface ASP Active Server Pages
CD Compact Disc
CN N Cable News Network
DB Database/Datab´aze
DN S Domain Name System
F QDN Fully Qualified Domain Name GP L GNU General Public License
GSM Global System for Mobile Communications, Groupe Sp´ecial Mobile GU I Graphical user interface
HSQLDB Hyper Structured Query Language Database HT M L HyperText Markup Language
HT T P Hypertext Transfer Protocol
HT T P S Hypertext Transfer Protocol Secure
ICQ I seek you
IET F Internet Engineering Task Force
IM Instant Messaging
IP Internet Protocol
IRC Internet Relay Chat J DK Java Development Kit J ID Jabber Identifier
M IT Massachusetts Institute of Technology M M S Multimedia Messaging Service
M SN Microsoft Network M S SQL Microsoft SQL Server M V C Model-view-controller
ODBC Open Database Connectivity P I sensor Passive infrared sensor RF C Request for Comments RF module Radio Frequency Module RT CP RTP Control Protocol
RT P Real-time Transport Protocol
SASL Simple Authentication and Security Layer SIP Session Initiation Protocol
SM S Short Message Service
SQL Structured Query Language SSL Secure Sockets Layer
ST U N Session Traversal Utilities for NAT T CP Transmission Control Protocol T LS Transport Layer Security U DP User Datagram Protocol U RI Uniform Resource Identifier U SB Universal Serial Bus
U T F UCS Transformation Format V OIP Voice over Internet Protocol
W CF Windows Communication Foundation XEP XMPP Extension Protocol
XM L Extensible Markup Language
XM P P Extensible Messaging and Presence Protocol XSF XMPP Standard Foundation
1 Uvod ´
Komunikace je jednou z nejd˚uleˇzitˇejˇs´ıch souˇc´ast´ı lidsk´eho ˇzivota. Je na n´ı z´avisl´e
´
uplnˇe vˇse, od uspokojov´an´ı tˇech nejz´akladnˇejˇs´ıch lidsk´ych potˇreb (napˇr. obstar´av´an´ı potravy), pˇres naˇse obl´ıben´e ˇcinnosti ˇci zabezpeˇcen´ı naˇsich majetk˚u a ˇzivot˚u, aˇz po discipl´ıny d˚uleˇzit´e pro budouc´ı v´yvoj lidstva (vzdˇel´av´an´ı, v´yzkum aj.). Proto se ko- munikac´ı neboli pˇrenosem informac´ı lidstvo aktivnˇe zab´yv´a a snaˇz´ı se tuto discipl´ınu co nejv´ıce vylepˇsovat a pˇrizp˚usobovat ji sv´ym poˇzadavk˚um. V´ysledkem tˇechto snah jsou nov´e komunikaˇcn´ı kan´aly a to jak ty dnes jiˇz d´avno pˇrekonan´e (kouˇrov´e sign´aly, domluven´e m´av´an´ı atd.), tak ty relativnˇe modern´ı (telegraf, telefon).
S n´astupem poˇc´ıtaˇc˚u a internetu se lidstvu otevˇrela neb´yval´a moˇznost komu- nikace. P˚uvodnˇe sice bylo moˇzn´e pˇred´avat informace pouze v podobˇe textov´ych sou- bor˚u, ale lid´e velmi brzy potenci´al internetu objevili a tak zaˇcaly vznikat kan´aly, kter´e se pˇr´ımo zamˇeˇrovaly na komunikaci mezi lidmi. Jedn´ım z nejstarˇs´ıch z´astupc˚u je napˇr´ıklad elektronick´a poˇsta, decentralizovan´y syst´em pro pˇred´av´an´ı zpr´av, kter´y dnes pouˇz´ıv´a snad kaˇzd´y, kdo vlastn´ı poˇc´ıtaˇc s pˇr´ıstupem do internetu. Ovˇsem i elek- tronick´a poˇsta m´a sv´e nev´yhody, jako je napˇr. nevyˇz´adan´a poˇsta ˇci podvrhnut´ı zpr´avy tˇret´ı stranou a nav´ıc je zde st´ale probl´em, ˇze je cel´a sluˇzba takzvanˇe offline. Tedy uˇzivatel odeˇsle zpr´avu a nev´ı, zda si ji uˇzivatel na druh´e stranˇe pˇreˇcte ihned ˇci aˇz za nˇejakou dobu, tedy zdali je druh´y uˇzivatel pr´avˇe u poˇc´ıtaˇce.
Reakc´ı na tento probl´em jsou takzvan´e IRC s´ıtˇe, jedn´a se o jednu z prvn´ıch variant komunikace v re´aln´em ˇcase. Znamen´a to, ˇze co jeden uˇzivatel nap´ıˇse, druh´y vid´ı ihned na sv´em poˇc´ıtaˇci (prostˇrednictv´ım prohl´ıˇzeˇce nebo pˇr´ımo IRC klienta).
Ovˇsem i IRC m´a sv´e nedostatky. Zejm´ena nemoˇznost smˇerov´an´ı zpr´avy, jedinou va- riantou je vyuˇz´ıt nˇekterou z funkc´ı IRC a vytvoˇrit si takzvanˇe soukrom´y kan´al dvou uˇzivatel˚u, ve kter´em si tak mohou tito dva uˇzivatel´e svobodnˇe komunikovat. IRC pro to m´a nezbytn´e prostˇredky, jako je spr´ava opr´avnˇen´ı jednotliv´ych uˇzivatel˚u (moderovan´e kan´aly, heslovan´e kan´aly ˇci tzv. ban pro urˇcit´eho uˇzivatele v urˇcit´em kan´alu).
V´ysledkem snah o to, aby mˇel kaˇzd´y uˇzivatel svou soukromou schr´anku do kter´e je mu moˇzn´e adresovat zpr´avu a z´aroveˇn komunikace v re´aln´em ˇcase je instant messa- ging. V pˇr´ıpadˇe IM m´a kaˇzd´y uˇzivatel jedineˇcnou adresu, kter´a je unik´atn´ı v cel´em internetu a tak´e m´a moˇznost vybran´e adresy ukl´adat do sv´eho seznamu (buddylist, ros- ter apod.). Ovˇsem v ˇcem je oproti sv´ym pˇredch˚udc˚um unik´atn´ı je pr´ace s aktu´aln´ım stavem uˇzivatele tzv. presence. D´ıky tomu m˚uˇze uˇzivatel IM, dˇr´ıve neˇz odeˇsle svou
zpr´avu, zjistit, zdali je druh´y uˇzivatel pr´avˇe u sv´eho poˇc´ıtaˇce ˇci zda nen´ı aktu´alnˇe zanepr´azdnˇen apod. I IM m´a sv´e nedostatky, mezi kter´e patˇr´ı napˇr´ıklad nevyˇz´adan´e zpr´avy ˇci nekompatibilita r˚uzn´ych IM protokol˚u. I proto vznikla a st´ale vznik´a cel´a ˇrada r˚uzn´ych IM, napˇr´ıklad: ICQ, AOL instant messenger, Yahoo! messenger, MSN messenger ˇci Jabber/XMPP.
IM lze vyuˇz´ıt i k jin´ym vˇecem neˇz je promluva dvou a v´ıce uˇzivatel˚u. V dobˇe, kdy je internet st´ale v´ıce tak´e pr˚umyslov´ym n´astrojem, lze IM vyuˇz´ıt k poskytov´an´ı nˇekter´ych druh˚u sluˇzeb. Napˇr´ıklad mohou b´yt uˇzivateli zas´ıl´any aktu´aln´ı v´ysledky z´apas˚u jeho obl´ıben´eho sportovn´ıho t´ymu ˇci aktu´aln´ı informace o poˇcas´ı ve vybran´e oblasti apod.
Toto je i motivac´ı vzniku t´eto pr´ace, tedy spojit veˇrejnˇe dostupn´y kan´al pro pˇrenos textov´ych zpr´av, kter´y pouˇz´ıv´a velk´a skupina lid´ı, a bezpeˇcnost jeho uˇzivatele ˇ
ci majetku tohoto uˇzivatele. Spoleˇcnost Jablocom s. r. o. se zamˇeˇruje na ˇreˇsen´ı v ob- lasti GSM technologi´ı a jedn´ım z jej´ıch produkt˚u je i zabezpeˇcovac´ı kamera s n´azvem EYE-02. V t´eto pr´aci tak bude navˇzena a implementov´ana sluˇzba, kter´a umoˇzn´ı, aby si uˇzivatel pˇridal svou bezpeˇcnostn´ı kameru do sv´eho jiˇz existuj´ıc´ıho IM klienta a ta ho informovala o sv´em aktu´aln´ım stavu a stavu sv´eho okol´ı.
Stejnˇe tak bude moci uˇzivatel kameru ovl´adat pomoc´ı pˇr´ıkaz˚u v podobˇe ode- slan´ych textov´ych zpr´av. D˚uleˇzit´e je tak´e br´at na zˇretel charakter zaˇr´ızen´ı, tedy maxi- malizovat snahu o bezpeˇcnost odes´ılan´ych informac´ı a tak´e snahu o ovˇeˇren´ı doruˇcen´ı zpr´avy od kamery ke klientovi.
Prostˇrednictv´ım IM klient˚u lze v dneˇsn´ı dobˇe tak´e odes´ılat soubory a vyuˇz´ıvat pˇr´ım´eho video spojen´ı. Proto by bylo dobr´e diskutovat i tuto oblast tak, aby uˇzivatel mohl pˇr´ımo ve sv´em IM klientu vidˇet v re´aln´em ˇcase, co se dˇeje v okol´ı jeho kamery, nebo mohl obdrˇzet fotografii z doby, kdy doˇslo k naruˇsen´ı stˇreˇzen´eho prostoru.
2 Sezn´ amen´ı s prostˇ red´ım
V n´asleduj´ıc´ıch kapitol´ach dojde k pˇredstaven´ı prostˇred´ı, ve kter´em bude sluˇzba vyv´ıjena. Bude pˇredstavena spoleˇcnost Jablocom s. r. o. s jej´ım produktem EYE-02 (2.1) a tak´e pouˇzit´y IM kan´al XMPP (2.2).
2.1 Spoleˇ cnost Jablocom a jej´ı produkty
Hlavn´ı z´ajmovou oblast´ı firmy Jablocom s. r. o. je v´yroba a dod´av´an´ı GSM te- lekomunikaˇcn´ıch a zabezpeˇcovac´ıch zaˇr´ızen´ı. Vznik spoleˇcnosti se datuje do roku 2004, kdy byla z rodinn´e spoleˇcnosti Jablotron vyˇclenˇena mal´a skupina konstrukt´er˚u, kter´a se zamˇeˇrila na inovace a vyuˇz´ıv´an´ı netradiˇcn´ıch ˇreˇsen´ı v oblasti zabezpeˇcen´ı pod n´azvem Aplikovan´y v´yzkum. Zkuˇsenosti, kter´e skupina z´ısk´avala pˇri v´yvoji GSM komunik´ator˚u pro ovl´ad´an´ı zabezpeˇcovac´ıch syst´em˚u, vyvrcholily v inovativn´ı pro- jekt stoln´ıho GSM telefonu. Prvn´ı model, jenˇz byl oznaˇcen jako GDP-02, byl po- prv´e ofici´alnˇe pˇredstaven na svˇetov´e v´ystavˇe elektroniky, kter´a se uskuteˇcnila v ˇr´ıjnu roku 2004 v Hongkongu. Pˇrevratn´a novinka sklidila obrovsk´y komerˇcn´ı ´uspˇech, a to i d´ıky s´erii report´aˇz´ı, kter´e byly odvys´ıl´any televizn´ı stanic´ı CNN, a tak spoleˇcnost z´ıskala prvn´ı objedn´avku od oper´atora GSM s´ıtˇe jeˇstˇe pˇred koncem roku 2004. Vzhle- dem k tomuto ´uspˇechu a tak´e odliˇsnosti oproti hlavn´ı z´ajmov´e oblasti firmy Jablot- ron bylo rozhodnuto o vytvoˇren´ı dceˇrin´e spoleˇcnosti Jablocom s. r. o., zab´yvaj´ıc´ı se v´yhradnˇe oborem telekomunikaˇcn´ıch syst´em˚u. [1]
V souˇcasnosti je hlavn´ı aktivitou firmy st´ale prodej a v´yvoj v oblasti aplikovan´e elektroniky s d˚urazem na pˇrekvapiv´a a neotˇrel´a ˇreˇsen´ı, vyuˇz´ıv´an´ı nejmodernˇejˇs´ıch cenovˇe dostupn´ych technologi´ı, jednoduchost uˇzivatelsk´e obsluhy a vysokou kvalitu dod´avan´ych produkt˚u. Spoleˇcnost Jablocom nab´ız´ı ˇctyˇri hlavn´ı produktov´e ˇrady: [1]
• EYE-02 / Eye See – GSM bezpeˇcnostn´ı kamera – zabezpeˇcovac´ı zaˇr´ızen´ı ve tvaru mal´e kamery obsahuj´ıc´ı ˇradu senzor˚u s moˇznost´ı rozˇs´ıˇren´ı o dalˇs´ı bezdr´atov´e detektory. Velkou v´yhodou kamery je schopnost informovat uˇzivatele o nastal´e situaci uˇzit´ım nˇekolika r˚uzn´ych komunikaˇcn´ıch kan´al˚u.
• BlueSynergy – Bluetooth stoln´ı telefon – tvarem je podobn´y JabloPhone, ale funguje jin´ym zp˚usobem. BlueSynergy se prostˇrednictv´ım bluetooth automaticky sp´aruje s mobiln´ım telefonem uˇzivatele a v´ysledkem je, ˇze je uˇzivatel dostupn´y st´ale pod stejn´ym mobiln´ım ˇc´ıslem, ale vyuˇz´ıv´a pˇrednosti pevn´e linky.
• JabloPhone – GSM stoln´ı telefon – bˇeˇzn´y mobiln´ı telefon komunikuj´ıc´ı pˇres GSM s´ıt’ s designem telefonu stoln´ıho. Je vybaven displejem, QWERTY kl´avesnic´ı,
reproduktorem, tlaˇc´ıtky rychl´eho vyt´aˇcen´ı ˇci internetov´ym pˇripojen´ım. Telefon podporuje tak´e pokroˇcil´e kancel´aˇrsk´e funkce, jako jsou pˇresmˇerov´an´ı hovor˚u, konferenˇcn´ı hovory ˇci nadstandardn´ı spr´ava kontakt˚u.
• JabloPhone kits – n´astavba k JabloPhone, kter´a nab´ız´ı radiofrekvenˇcn´ı spojen´ı s dalˇs´ımi zaˇr´ızen´ımi. Uˇzivatel tak napˇr´ıklad jedn´ım stiskem tlaˇc´ıtka na sv´em ˇret´ızku ˇci hodink´ach pˇrivol´a l´ekaˇrskou pomoc ˇci m˚uˇze vzd´alenˇe ovl´adat svoje dom´ac´ı spotˇrebiˇce a pˇredej´ıt tak ˇskod´am nebo si jen zapnout topen´ı dˇr´ıve neˇz dojde dom˚u.
2.1.1 Kamera EYE-02
Kamera EYE-02 je bezpeˇcnostn´ı GSM kamera, poskytuj´ıc´ı kompletn´ı ochranu stˇreˇzen´eho prostoru v jednom zaˇr´ızen´ı. D˚ukazem tohoto tvrzen´ı je nˇekolik z´ıskan´ych ocenˇen´ı (napˇr. Global Mobile Awards 2011). Mezi z´akladn´ı vlastnosti kamery EYE-02 patˇr´ı: [1]
• Pˇet z´akladn´ıch senzor˚u – senzor PIR (detekuje tepeln´e vyzaˇrov´an´ı napˇr. lidsk´eho tˇela), akustick´y senzor (nadpr˚umˇern´y hluk v oblasti kamery), senzor tˇr´ıˇstˇen´ı skla (rozpozn´av´a tento specifick´y zvuk), senzor pohybu (zaznamen´av´a pohyb v obraze) a senzor n´aklonu a um´ıstˇen´ı (ochrana proti manipulaci s kamerou).
• Bezdr´atov´y pˇr´ıstup – kamera je vybavena GSM, RF modulem a z´aloˇzn´ı bateri´ı.
• Pamˇet’ov´a karta – moˇznost uchov´avat data po dlouhou dobu pˇr´ımo v kameˇre.
• GSM modul – kamera je v podstatˇe mobiln´ı telefon, um´ı telefonovat, pos´ılat a pˇrij´ımat SMS i MMS nebo pˇristupovat k internetu a odes´ılat tak data na server ˇci pos´ılat e-maily.
• RF modul – moˇznost rozˇs´ıˇren´ı kamery o dalˇs´ı zaˇr´ızen´ı (d´alkov´e ovl´ad´an´ı, detek- tory kouˇre atd.).
• Noˇcn´ı vidˇen´ı – kamera je schopna nahr´avat video i v noci ˇci temn´ych oblastech.
Kamera EYE-02 m´a nˇekolik z´akladn´ıch reˇzim˚u. Prvn´ım z nich je reˇzim Odjiˇstˇeno (Sleep) – jedn´a se o klidov´y stav kamery, ve kter´em nesn´ım´a hl´ıdanou ob- last. V tomto reˇzimu jsou aktivov´any pouze detektory br´an´ıc´ı neˇz´adouc´ı manipulaci s kamerou. D´ale reˇzim Zajiˇstˇeno (Watch) – v tomto reˇzimu jsou aktivov´any vˇsechny senzory kamery a kamera tak stˇreˇz´ı hl´ıdanou oblast. Reˇzim Nastaven´ı slouˇz´ı ke zmˇenˇe vlastnost´ı kamery a jeho souˇc´ast´ı jsou dalˇs´ı reˇzimy: Uˇcen´ı (pˇrid´an´ı nov´eho zaˇr´ızen´ı ˇ
ci pˇrid´an´ı telefonn´ıho ˇc´ısla do kamery), Test (slouˇz´ı k ovˇeˇren´ı funkˇcnosti vˇsech detek- tor˚u bez vyhl´aˇsen´ı neˇz´adouc´ıch poplachov´ych zpr´av), Report (odeˇsle umˇele vytvoˇrenou
zpr´avu na vˇsechny kontakty sp´arovan´e s kamerou) a USB (stav kamery, kdy se chov´a jako standardn´ı USB disk). [1]
Kameru lze ovl´adat a nastavovat nˇekolika zp˚usoby. Prvn´ım je ovl´ad´an´ı z poˇc´ı- taˇce uˇzivatele, k tomu slouˇz´ı webov´e rozhran´ı Jablotool (dostupn´e na webov´e str´ance www.jablotool.com). Toto rozhran´ı poskytuje nˇekolik z´akladn´ıch aplikac´ı (nˇekter´e jsou zpoplatnˇeny): [1]
• Access & Back-up – prohl´ıˇzen´ı ud´alost´ı z kamery bez nutnosti pˇr´ım´eho pˇr´ıstupu pˇr´ımo na Jablotool serveru, kam jsou ud´alosti automaticky zaznamen´av´any.
• Picture Link – hl´aˇsen´ı zas´ılan´a uˇzivateli, obsahuj´ı odkaz na obrazovou informaci.
• Messenger Service – veˇsker´a hl´aˇsen´ı (SMS, MMS, e-maily) jsou odes´ıl´ana Jablo- tool serverem a k jejich pˇr´ıjmu tak staˇc´ı pouze datov´y tarif.
• Watch Dog – kamera zas´ıl´a pravideln´a hl´aˇsen´ı, zda je v poˇr´adku.
• Web Camera – sn´ımky z kamery lze pomoc´ı vytvoˇren´eho API zobrazit na webu.
• Live Streaming – moˇznost sledovat video z kamery pˇr´ımo v prohl´ıˇzeˇci.
• Timers – automatick´a zmˇena stavu kamery v z´avislosti na ˇcase (zajiˇstˇen´ı o v´ıkendech, odjiˇstˇen´ı na zaˇc´atku pracovn´ı doby apod.).
• Flexi Limit – nastaven´ı mˇes´ıˇcn´ıho limitu SMS, MMS ˇci e-mail˚u, kter´e kamera odeˇsle.
Tyto funkce lze ovl´adat tak´e pomoc´ı desktopov´e aplikace, kter´a je k dispozici na CD um´ıstˇen´em v balen´ı kamery EYE-02. Dalˇs´ı moˇznost´ı ovl´ad´an´ı kamery je zad´av´an´ı pˇr´ıkaz˚u pomoc´ı SMS. Kamera pomoc´ı SMS informuje uˇzivatele o sv´em stavu, zas´ıl´a obr´azky z kamery (MMS), zas´ıl´a reporty o posledn´ıch nˇekolika ud´alostech, zobrazuje informace o aktu´aln´ı v´yˇsi kreditu a uˇzivatel naopak m˚uˇze pˇrep´ınat stavy Zajiˇstˇeno a Odjiˇstˇeno, pˇrid´avat kontakty do kamery, mˇenit jazyk kamery apod. [1]
Dalˇs´ı moˇznost´ı je kameru ovl´adat pomoc´ı telefonn´ıch hovor˚u. Pokud je te- lefonn´ı ˇc´ıslo, kter´e na kameru vol´a, uvedeno v jej´ım seznamu kontakt˚u, je hovor pˇrijat a pˇrehraje se z´akladn´ı sada funkc´ı: poslech z mikrofonu kamery, vyˇz´ad´an´ı MMS s aktu´aln´ım obr´azkem, vyˇz´ad´an´ı MMS posledn´ı ud´alosti typu Poplach, zmˇena stavu kamery (Zajiˇstˇeno/Odjiˇstˇeno) atd. Novinkou je pak ovl´ad´an´ı kamery pomoc´ı mobiln´ı aplikace, kter´a je vytvoˇrena pomoc´ı jazyka HTML 5 a je tak dostupn´a pro mobiln´ı zaˇr´ızen´ı se vˇsemi operaˇcn´ımi syst´emy (iOS, Windows Phone ˇci Android). I tato apli- kace umoˇzˇnuje z´akladn´ı ovl´ad´an´ı kamery – pˇr´ıjem obr´azk˚u, zmˇenu stavu kamery ˇci pˇr´ıjem poplachov´ych zpr´av. [1]
2.2 XMP protokol (XMPP)
The Extensible Messaging and Presence Protocol ve zkratce XMPP je otevˇren´a technologie, jej´ımˇz prim´arn´ım zamˇeˇren´ım je komunikace v re´aln´em ˇcase. XMPP je tud´ıˇz z´akladn´ım stavebn´ım kamenem mnoha aplikac´ı (napˇr. Google Talk, Pidgin, Mi- randa, Trillian a mnoho dalˇs´ıch.), kter´e v souˇcasnosti vyuˇz´ıvaj´ı miliony uˇzivatel˚u po cel´em svˇetˇe, a to nejen ke komunikaci s pˇr´ateli ˇci rodinou, ale tak´e napˇr´ıklad pro vnitro- firemn´ı komunikaci. Vˇsechny tyto aplikace velmi ˇcasto spojuj´ı n´asleduj´ıc´ı term´ıny: [2]
• Instant messaging (IM) – velmi rychl´e doruˇcov´an´ı textov´ych zpr´av od odesilatele k adres´atovi prostˇrednictv´ım s´ıtˇe internet, tzv. komunikace v re´aln´em ˇcase.
• Informace o dostupnosti – indik´ator toho, jestli je osoba se kterou by se mˇelo komunikovat schopn´a ˇci ochotn´a komunikovat, tzv. status.
• Multi-party chat – vz´ajemn´a komunikace mezi v´ıce jak dvˇema uˇzivateli, tzv.
konference ˇci skupinov´a komunikace.
• Hlasov´e a videohovory – tedy pˇr´ım´a komunikace mezi uˇzivateli pomoc´ı hlasu pˇr´ıpadnˇe i zraku.
• Groupware – moˇznost spolupr´ace (komunikace, odes´ıl´an´ı soubor˚u . . . ) mezi nˇekolika lidmi za ´uˇcelem dosaˇzen´ı spoleˇcn´eho c´ıle.
• Middleware – spojen´ı nˇekolika r˚uzn´ych aplikac´ı v jeden vˇetˇs´ı celek, napˇr´ıklad uˇzivatel vyuˇz´ıvaj´ıc´ı Pidgin je schopen komunikovat i s uˇzivateli vyuˇz´ıvaj´ıc´ı jinou aplikaci ˇci jin´y protokol.
• Syndik´ator obsahu – uˇzivatel nemus´ı kontrolovat, kdo a kdy mu zaslal zpr´avu, aplikace ho na to sama upozorn´ı.
• Odes´ıl´an´ı dat ve form´atu XML – intern´ı komunikace mezi klientem a serverem ˇ
ci serverem a serverem prob´ıh´a ve form´atu XML.
Samotn´a technologie XMPP, kter´e se v minulosti ˇr´ıkalo Jabber, byla vytvoˇrena jiˇz v roce 1998 v´yvoj´aˇrem jm´enem Jeremie Miller (ke spuˇstˇen´ı prvn´ıho ofici´aln´ıho XMPP serveru ovˇsem doˇslo aˇz na zaˇc´atku roku 1999). Technologie slavila ´uspˇech a tak vznikla jej´ı vlastn´ı komunita (Jabber open-source community), kter´a ji v letech 1999–
2000 nad´ale zdokonalovala. V letech 2002–2003 tak byla technologie ofici´alnˇe zfor- mulov´ana komunitou IETF a v roce 2004 vzniklo nˇekolik RFC t´ykaj´ıc´ıch se XMPP (RFC 3920, RFC 3921 a dalˇs´ı). [2]
V souˇcasn´e dobˇe je standard XMPP udrˇzov´an nez´avislou a neziskovou organi- zac´ı XMPP Standard Foundation (XSF), kter´a definuje dalˇs´ı standardy v oblasti IM, signalizace statusu a obecnˇe komunikace v re´aln´em ˇcase nebo tak´e nab´ız´ı informace a infrastrukturu pro vˇsechny osoby zaj´ımaj´ıc´ı se o XMPP (v´yvoj´aˇre, poskytovatele i koncov´e uˇzivatele). [2]
Vˇsechny standardy t´ykaj´ıc´ı se XMPP jsou aktu´alnˇe definov´any v nˇekolika r˚uzn´ych form´ach: [2]
• RFC, vydan´e IETF, popisuj´ıc´ı j´adro protokolu XMPP (RFC 6120, nahrazuj´ıc´ı RFC 3920, definuj´ıc´ı j´adro XMPP, RFC 6121, nahrazuj´ıc´ı RFC 3921, definuj´ıc´ı IM a stavovou informaci a RFC 6122, definuj´ıc´ı form´at XMPP adresy).
• Nˇekolik dalˇs´ıch doplˇnuj´ıc´ıch RFC (Definice URI pro XMPP, ˇsifrov´an´ı XMPP . . . )
• Internet-Drafts (internetov´e koncepty), kter´e popisuj´ı dalˇs´ı moˇznosti rozˇs´ıˇren´ı XMPP technologie. Ty jsou navrhovan´e tˇret´ımi stranami (skupinami IETF ˇci nez´avisl´ymi uˇzivateli XMPP) a schvalov´any samotnou IETF.
• Standardy t´ykaj´ıc´ı j´adra XMPP, kter´e jsou vyd´avan´e XSF ve formˇe takzvan´ych XMPP Extension Protocol (XEP).
2.2.1 Vlastnosti XMPP
Jak bylo zm´ınˇeno dˇr´ıve, XMPP protokol je technologie podporuj´ıc´ı instant messaging, uˇzivatelskou stavovou informaci a dalˇs´ı funkce, kter´y je spravov´an XMPP Standard Foundation (dˇr´ıve Jabber Software Foundation). Technologie byla vytvoˇrena jako reakce na tehdejˇs´ı konkurenˇcn´ı protokoly (ICQ, Microsoft Messenger . . . ), kter´e byly uzavˇren´e a uˇzivatele mnohdy
”zasyp´avaly“ neˇz´adouc´ı reklamou. Vzhledem k tˇemto fakt˚um XMPP nab´ız´ı tyto charakteristick´e vlastnosti: [2, 3]
• Klient-server – XMPP klienti (uˇzivatel´e) spolu nekomunikuj´ı pˇr´ımo (v´yjimkou jsou speci´aln´ı pˇr´ıpady), ale prostˇrednictv´ım serveru, kter´y zprostˇredkov´av´a ko- munikaci a tak´e udrˇzuje seznam kontakt˚u a dalˇs´ı informace o uˇzivatel´ıch.
• Decentralizovanost – XMPP raz´ı podobnou cestu jako sluˇzba e-mail, tedy ne- vyuˇz´ıv´a jeden server, kter´y by obstar´aval vˇsechny poˇzadavky. Nam´ısto toho m´a kaˇzd´y uˇzivatel sv˚uj jedineˇcn´y identifik´ator, jehoˇz prostˇrednictv´ım jsou mu smˇerov´any XMPP pakety pˇres jeho domovsk´y XMPP server (viz obr´azek 1). To je v´yhodn´e zejm´ena ve chv´ıl´ıch, kdy nen´ı dostupn´a jeho IP adresa, nebo se IP adresa mˇen´ı (napˇr´ıklad pˇri pouˇz´ıv´an´ı mobiln´ıho telefonu ˇci tabletu).
D´ıky tomuto principu si m˚uˇze doslova kaˇzd´y vytvoˇrit sv˚uj vlastn´ı XMPP ser- ver, coˇz je velmi v´yhodn´e zejm´ena pro firmy, kter´e tak mohou firemn´ı komunikaci libovolnˇe upravovat na m´ıru sv´ym poˇzadavk˚um.
Technologie XMPP standardnˇe komunikuje prostˇrednictv´ım TCP spojen´ı na portech 5222 a 5223 (klient – server) a 5269 (server – server).
Obr´azek 1: Princip XMPP pˇrenosu
• Bezpeˇcnost – XMPP server m˚uˇze b´yt izolovan´y od vnˇejˇs´ı s´ıtˇe a jeho pro- stˇrednictv´ım pak lze komunikovat pouze uvnitˇr priv´atn´ı s´ıtˇe, coˇz pˇrin´aˇs´ı efek- tivn´ı bezpeˇcnostn´ı mechanismus pro firemn´ı intranet. V XMPP jsou definov´any bezpeˇcnostn´ı mechanismy SASL ˇci TLS, kter´e tak umoˇzˇnuj´ı zlepˇsit bezpeˇcnost pˇren´aˇsen´ych dat. V´yhodou je tak´e ˇsirok´a z´akladna v´yvoj´aˇr˚u aktivnˇe pracuj´ıc´ıch na XMPP, d´ıky kter´e vznikaj´ı dalˇs´ı a dalˇs´ı bezpeˇcnostn´ı mechanismy.
• Otevˇrenost – XMPP je veˇrejnˇe dostupn´y bezplatnˇe, ve formˇe kter´a je dobˇre ˇ
citeln´a pro v´yvoj´aˇre. V´ysledkem je mnoho implementovan´ych knihoven, klient˚u a server˚u.
• Standardizovanost – J´adro XMPP protokolu zaloˇzen´e na dotazech v XML formˇe je pops´ano v dokumentech RFC, rozˇs´ıˇren´a funkcionalita pak v dokumen- tech XEP.
• Osvˇedˇcenost – Od roku 1998 tuto technologii vylepˇsuj´ı stovky v´yvoj´aˇr˚u, v s´ıti Internet existuj´ı tis´ıce XMPP server˚u a miliony uˇzivatel˚u vyuˇz´ıvaj´ı XMPP sluˇzby jako je napˇr´ıklad Google Talk.
• Rozˇsiˇritelnost a flexibilita – Standardizov´any jsou pouze pˇrenosov´e mechanismy, takˇze si kdokoli m˚uˇze funkcionalitu rozˇs´ıˇrit o dalˇs´ı poˇzadovan´e funkce. Nˇekter´e
jsou jiˇz pops´any v rozˇs´ıˇren´ıch XEP (sd´ılen´ı soubor˚u, pˇrenos videa, signalizace zpr´av atd.). Neznamen´a to ovˇsem, ˇze si kdokoli nem˚uˇze upravit funkcionalitu podle sv´e potˇreby.
• Rozmanitost – Jestliˇze si v´yvoj´aˇr nechce vytv´aˇret pˇr´ımo sv´e vlastn´ı ˇreˇsen´ı, exis- tuje velk´e mnoˇzstv´ı veˇrejnˇe dostupn´ych implementac´ı XMPP server˚u ˇci klient˚u.
V n´asleduj´ıc´ıch kapitol´ach bude bl´ıˇze pˇredstaven obsah RFC dokument˚u po- pisuj´ıc´ıch j´adro XMPP technologie. Toto je d˚uleˇzit´e k zjiˇstˇen´ı jak´ym zp˚usobem jsou form´atov´any XML dotazy odes´ılan´e a pˇrij´ıman´e pˇri poˇzadavku uˇzivatele o odesl´an´ı zpr´avy, zmˇenu informace o jeho aktu´aln´ı dostupnosti apod.
2.2.2 Adresa XMPP (JID)
XMPP entitou neboli ˇclenem komunikaˇcn´ıho procesu m˚uˇze b´yt kaˇzd´y prvek, kter´y je moˇzn´e v s´ıti adresovat a podporuje zm´ınˇenou XMPP technologii. Z histo- rick´ych d˚uvod˚u se adresa entity oznaˇcuje jako JID (Jabber Identifier). Validn´ı JID je pak ˇretˇezec Unicode znak˚u, k´odovan´y pomoc´ı UTF-8, kter´y splˇnuje nˇekter´e dalˇs´ı de- finice (typicky odvozen´e od
”stringprep“ – RFC 3454 nebo
”nameprep“ – RFC 3491) a skl´ad´a se ze tˇr´ı ˇc´ast´ı (localpart, domainpart a resourcepart). [4]
Domainpart je jedin´a ˇc´ast, kter´a je povinn´a pro vˇsechny JID, a to znamen´a, ˇze i samotn´a domainpart je funkˇcn´ı JID. Domainpart typicky identifikuje dom´ac´ı server, tedy server ke kter´emu se klienti pˇripojuj´ı kv˚uli odes´ıl´an´ı XML poˇzadavk˚u i dalˇs´ıch dat, ale m˚uˇze pˇredstavovat i nˇekter´e dalˇs´ı sluˇzby. D˚uleˇzitou podm´ınkou na domainpart je, aby byla FQDN (tedy ˇretˇezec rozliˇsiteln´y pomoc´ı DNS), IP adresa verze 4, IP adresa verze 6 nebo minim´alnˇe ˇretˇezec rozliˇsiteln´y v lok´aln´ı s´ıti. [4]
Localpart je nepovinn´a souˇc´ast adresy vloˇzen´a pˇred domainpart (oddˇelena
”@“).
Typicky identifikuje entitu, kter´a se pˇripojuje k serveru, ale m˚uˇze tak´e pˇredstavovat n´azev m´ıstnosti ve sluˇzbˇe pro hromadnou komunikaci. Dalˇs´ı nepovinn´a ˇc´ast XMPP adresy je resourcepart, ta je um´ıstˇena za domainpart (oddˇelena
”/“) a slouˇz´ı k rozˇs´ıˇren´ı (v´ysledn´a adresa je oznaˇcov´ana full JID) moˇznost´ı z´akladn´ı adresy ve form´atu
”local- part@domainpart“ (bare JID). Typicky identifikuje specifick´e pˇripojen´ı, d´ıky ˇcemuˇz m˚uˇze b´yt uˇzivatel pˇripojen v jednom okamˇziku z v´ıce zaˇr´ızen´ı (kaˇzd´e z nich je odliˇseno jinou resourcepart) nebo objekt asociovan´y s localpart (nick uˇzivatele v m´ıstnosti pro hromadnou komunikaci). Resourcepart m˚uˇze obsahovat i znaky
”/“ a
”@“, ovˇsem je tˇreba br´at na zˇretel, ˇze skl´ad´an´ı znak˚u
”/“ v XMPP nepˇredstavuje hierarchick´e uspoˇr´ad´an´ı jako napˇr´ıklad v HTTP. [4]
Z´ˇadn´a ze zm´ınˇen´ych poloˇzek nesm´ı b´yt b´yt pr´azdn´a (ˇretˇezec d´elky nula) a tak´e jej´ı d´elka nesm´ı pˇres´ahnout 1023 byt˚u, coˇz znamen´a, ˇze maxim´aln´ı d´elka XMPP ad- resy je 3071 byt˚u (vˇcetnˇe znak˚u
”@“ a
”/“). D˚uleˇzit´e je tak´e podotknout, ˇze JID je jedin´a adresa, kter´a je pouˇziteln´a pro adresov´an´ı v XMPP s´ıti, existuj´ı sice i dalˇs´ı moˇznosti adresov´an´ı, jako XMPP-URI, ale ty jsou urˇceny pouze pro pouˇzit´ı mimo kontext XMPP s´ıtˇe, napˇr. pˇri pˇripojov´an´ı k JID z webov´e str´anky. V´ysledn´a JID tedy vypad´a n´asledovnˇe:
JID: [ localpart "@" ] domainpart [ "/" resourcepart ] Napˇr.: kamera161681@jablocom.com/vlakno kamery nebo jablocom.com. [4]
2.2.3 Princip navazov´an´ı relace
XMPP ke komunikaci vyuˇz´ıv´a protokol TCP. Prvn´ı akc´ı klienta ˇci serveru, kter´y
Initial stream Response stream
<stream>
<stream>
<presence/>
<message/>
<iq type=’get’/>
<iq type=’result’/>
. . .
. . .
</stream>
</stream>
Tabulka 1: Uk´azka XMPP komunikace chce komunikovat s jinou entitou v s´ıti
mus´ı b´yt proto vytvoˇren´ı TCP spo- jen´ı. N´aslednˇe se k vymˇeˇnov´an´ı infor- mac´ı pouˇz´ıvaj´ı takzvan´e XML streamy a XML stanza. XML stream je jed- nosmˇern´y kontejner obsahuj´ıc´ı vˇsechny elementy proud´ıc´ı mezi dvˇema entitami ze strany inici´atora (
”initial stream“) a pokud chce druh´a entita zas´ılat od- povˇedi, mus´ı vytvoˇrit vlastn´ı stream (tj.”response stream“). K otev´ır´an´ı ˇci zav´ır´an´ı streamu se pouˇz´ıv´a XML ele- ment <stream/>. XML stanza jsou z´akladn´ı XMPP elementy, kter´e jsou
z pohledu XML streamu na prvn´ı ´urovni a n´aleˇz´ı do jmen´eho prostoru
”jabber:client“
nebo ”jabber:server“, tedy jmenovitˇe <message/>, <presence/> a <iq/>. Zjed- noduˇsen´y pˇr´ıklad komunikace je naznaˇcen v tabulce ˇc´ıslo 1. [5]
Entita, kter´a vytvoˇren´y stream pˇrij´ım´a, funguje jako spr´avce dom´eny, sluˇzeb na serveru apod. Proto m˚uˇze poˇzadovat splnˇen´ı nˇekter´ych vlastnost´ı (feature) dˇr´ıve, neˇz umoˇzn´ı vstupuj´ıc´ı entitˇe pˇr´ıstup. Napˇr´ıklad pokud vytvoˇr´ı stream XMPP klient, mus´ı b´yt pˇred odes´ıl´an´ım poˇzadavk˚u na server patˇriˇcnˇe autentizov´an. Je tak´e nutn´e m´ıt na pamˇeti, ˇze vlastnosti se mohou vztahovat k r˚uzn´ym vrstv´am (TCP, TLS, SASL,
XMPP . . . ) a proto je splnˇen´ı vlastnost´ı nˇekolika´urovˇnov´y proces, u kter´eho mohou b´yt nˇekter´e vlastnosti pˇrid´any po splnˇen´ı vlastnosti pˇredchoz´ı a u kter´eho jsou nˇekter´e vlastnosti povinn´e a jin´e pouze dobrovoln´e. Diagram otevˇren´ı XML streamu je zobra- zen na obr´azku ˇc. 2. [5]
Standard popisuj´ıc´ı XMPP protokol nˇekter´e z´akladn´ı vlastnosti definuje. Patˇr´ı mezi nˇe napˇr´ıklad STARTTLS (zabraˇnuje odposlouch´av´an´ı a manipulaci se streamem vyuˇzit´ım ˇsifrovac´ı vrstvy TLS), SASL (metoda pro autentizov´an´ı streamu vzhledem k specifick´emu XMPP profilu pomoc´ı SASL), Resource Binding (pot´e co je klient autentizov´an, mus´ı b´yt streamu pˇriˇrazena resourcepart, tak aby server mohl pˇrij´ımat XML stanza paralelnˇe od dvou ˇci v´ıce XMPP klient˚u). [5]
Obr´azek 2: Diagram otev´ır´an´ı XMPP relace
2.2.4 Spr´ava kontakt˚u v XMPP
V XMPP m˚uˇze uˇzivatel˚uv kontakt list (nebo nˇekolik kontakt list˚u) obsahovat neomezen´y poˇcet kontakt˚u. Tento list se udrˇzuje jako souˇc´ast profilu uˇzivatele, kter´y je uloˇzen nejˇcastˇeji pˇr´ımo na dom´ac´ım XMPP serveru (server, pomoc´ı kter´eho klient vstupuje do XMPP s´ıtˇe, urˇcen´y pomoc´ı domainpart klientova JID). Tento fakt uˇzivateli umoˇzˇnuje pˇrid´avat/upravovat kontakty na server a ten je povinen si tyto zmˇeny
ukl´adat, pokud moˇzno v nemodifikovan´e podobˇe. Server pak na vyˇz´ad´an´ı poskytne tento list uˇzivateli a ten je tak schopen pˇripojit se z jak´ehokoli zaˇr´ızen´ı (notebooku, telefonu . . . ) a vˇzdy m´ıt aktualizovan´y kontakt list. Zde je d˚uleˇzit´e pˇripomenout, ˇze uˇzivatel˚uv list obsahuje d˚uvˇern´a data a proto pˇrid´avat, upravovat ˇci mazat kontakty sm´ı pouze opr´avnˇen´y uˇzivatel (typicky pouze majitel ´uˇctu). [6]
Manipulace s kontakt listem se prov´ad´ı pomoc´ı elementu <iq/> respektive jeho potomka <query/>, kter´y je definovan´y ve jmenn´em prostoru
”jabber:iq:roster“.
Souˇc´ast´ı elementu <query/> je pak ˇz´adn´y, jeden nebo v´ıce element˚u <item/>, kde kaˇzd´y z nich obsahuje informaci o jednom kontaktu uˇzivatele. Pro manipulaci s kontakt listem se pak pouˇz´ıvaj´ı ˇctyˇri specifick´e pˇr´ıkazy roster get, result, set a push. [6]
Element <item/> m˚uˇze obsahovat nˇekolik r˚uzn´ych atribut˚u a element˚u. Atri- buty approved a ask slouˇz´ı k informov´an´ı o stavu ˇci potvrzen´ı tzv. presence subscription (viz 2.2.6), atribut jid pˇredstavuje identifik´ator dan´eho kontaktu/itemu a nepovinn´y atribut name pˇredstavuje n´astroj pro fyzick´eho uˇzivatele, d´ıky kter´emu si m˚uˇze dan´y kontakt
”pˇrejmenovat“ tak, aby vˇedˇel o koho se jedn´a. Element <group/> se m˚uˇze uvnitˇr <item/> vyskytovat v´ıcekr´at v z´avislosti na tom, v kolika skupin´ach je uˇzivatel um´ıstˇen. Skupiny pak prim´arnˇe slouˇz´ı k rozliˇsen´ı r˚uzn´ych druh˚u kontakt˚u z pohledu uˇzivatele. [6]
Posledn´ım atributem, kter´y m˚uˇze element <item/> obsahovat, je atribut sub- scription. Tento atribut je velmi d˚uleˇzit´y, urˇcuje aktu´aln´ı stav tzv. presence sub- scription, tedy kter´ym smˇerem mohou proudit informace o zmˇenˇe stavu a kter´ym nikoli. M˚uˇze nab´yvat ˇctyˇr r˚uzn´ych hodnot. Prvn´ı je
”none“, tato hodnota je tak´e v´ychoz´ı (nemus´ı tedy b´yt vyplnˇena) a v tom okamˇziku neproud´ı informace o stavu ˇ
z´adn´ym smˇerem. Jestliˇze je hodnoty
”to“, tak informace o stavu proud´ı pouze smˇerem k uˇzivateli, kontakt tak st´ale uˇzivatele vid´ı offline. Hodnota
”from“ pˇredstavuje opaˇcn´y smˇer, kontakt vid´ı uˇzivatel˚uv stav a ten vid´ı sv˚uj kontakt offline. Pˇri hodnotˇe
”both“
pak stavov´a informace proud´ı obˇema smˇery. Posledn´ı speci´aln´ı hodnotou je
”remove“, ta se vyskytuje pouze v pˇr´ıkazech typu set (odebr´an´ı kontaktu z listu) a push (infor- mace ostatn´ım resource o odebr´an´ı kontaktu). [6]
Chce-li uˇzivatel z´ıskat obsah sv´eho kontakt listu, napˇr´ıklad protoˇze se pr´avˇe pˇrihl´asil na sv˚uj ´uˇcet z dalˇs´ıho zaˇr´ızen´ı, mˇel by jeˇstˇe pˇred odesl´an´ım initial pre- sence (viz 2.2.5) odeslat na server pˇr´ıkaz roster get obsahuj´ıc´ı pouze pr´azdn´y element
<query/>: [6]
<iq from=’kamera568@jablocom.com/vlakno’ id=’bv1bs71f’ type=’get’ >
<query xmlns=’jabber:iq:roster’ />
</iq>
T´ım se z nˇej st´av´a tak´e tzv.
”interested resource“, coˇz znamen´a, ˇze ho bude server pr˚ubˇeˇznˇe informovat o zmˇen´ach v jeho listu, pomoc´ı pˇr´ıkaz˚u roster push. Server mu odpov´ı pomoc´ı pˇr´ıkazu roster result, jehoˇz souˇc´ast´ı je aktu´aln´ı obsah kontakt listu klienta nebo pomoc´ı elementu <iq/> obsahuj´ıc´ıho element <error/>, pokud z nˇejak´eho d˚uvodu nen´ı schopen sestavit odpovˇed’. Element <query/> pˇr´ıkazu roster result obsahuje pˇr´ısluˇsn´y poˇcet element˚u <item/>. Tento poˇcet m˚uˇze b´yt roven i nule v okamˇziku, kdy klient nem´a ve sv´em listu ˇz´adn´y kontakt. Odpovˇed’ roster result vypad´a n´asledovnˇe: [6]
<iq id=’bv1bs71f’ to=’kamera568@jablocom.com/vlakno’ type=’result’ >
<query xmlns=’jabber:iq:roster’ ver=’ver11’ >
<item jid=’klient3@example.net’ name=’Klient3’ subscription=’both’ >
<group>Jablocom customers</group>
</item>
<item jid=’klient8@example.com’ name=’Klient8’ subscription=’to’ />
<item jid=’klient4@example.cz’ name=’Klient4’ subscription=’both’ />
</query>
</iq>
Pˇrid´av´an´ı, upravov´an´ı a maz´an´ı kontakt˚u, pak uˇzivatel prov´ad´ı odes´ıl´an´ım pˇr´ıkaz˚u roster set, jehoˇz element <query/> obsahuje pr´avˇe jeden <item/>, kter´y je modifikov´an. Pˇri pˇrid´an´ı a ´upravˇe kontaktu jsou souˇc´ast´ı pˇr´ıkazu vybran´e hodnoty atribut˚u, dle kter´ych je kontakt modifikov´an a v pˇr´ıpadˇe odebr´an´ı je vloˇzen pouze atribut subscription s hodnotou remove, na coˇz server zareaguje odesl´an´ım pˇr´ıkaz˚u presence unsubscribe, unsubscribed nebo obou (viz 2.2.6). Server je pak tak´e povinen odeslat odpovˇed’, a to v podobˇe elementu <iq/> typu result nebo error, pokud je nˇekter´y z parametr˚u v nepoˇr´adku. Uk´azka pˇr´ıkazu na odebr´an´ı kontaktu: [6]
<iq from=’kamera568@jablocom.com/vlakno’ id=’cevre484vre’ type=’set’ >
<query xmlns=’jabber:iq:roster’ >
<item jid=’klient14@example.cz’ subscription=’remove’ />
</query>
</iq>
Posledn´ım druhem pˇr´ıkazu je push. Jeho form´at je stejn´y jako form´at pˇr´ıkazu set, jedin´y rozd´ıl je ve smˇeru odesl´an´ı. Pˇr´ıkaz push informuje uˇzivatele o zmˇenˇe nˇekter´eho jeho kontaktu. V´yznam toho pˇr´ıkazu spoˇc´ıv´a v tom, ˇze pokud je uˇzivatel pˇripojen v jednu chv´ıli z v´ıce zaˇr´ızen´ı a v jednom z nich provede zmˇenu, bude tato zmˇena odesl´ana vˇsem ostatn´ım zaˇr´ızen´ım (rozliˇsen´ym podle resourcepart adresy JID). [6]
2.2.5 Pˇrenos stavov´e informace v XMPP
Z´ısk´an´ı stavov´e informace je zajiˇstˇeno pomoc´ı elementu <presence/>, pln´y tvar vypad´a napˇr´ıklad takto: [6]
<presence from=’kamera568@jablocom.com/vlakno’ type=’unavailable’
to=’klient14@example.cz/mobil’ >
<show>dnd</show> <status>Sleep</status>
<priority>1</priority>
</presence>
Atributy to a from urˇcuj´ı odesilatele a pˇr´ıjemce, atribut type urˇcuje druh ele- mentu. Vloˇzen´e elementy pak specifikuj´ı stav - show urˇcuje vybran´y XMPP stav (away, chat, dnd, xa nebo NONE), status stav obecnˇe a priority pak stanovuje prioritu dan´eho resource. [6]
Pro pˇrenos stavov´e informace existuje nˇekolik mechanism˚u. Prvn´ım je tak- zvan´y
”initial presence“, kter´y slouˇz´ı k ozn´amen´ı o tom, ˇze se pˇrihl´asil nov´y resource uˇzivatele – jeho XMPP klient po proveden´ı z´akladn´ıch pˇrihlaˇsovac´ıch mechanism˚u odeˇsle element presence bez atribut˚u to a type. Ten je pak servery uˇzivatele i kontakt˚u odesl´an vˇsem dostupn´ym kontakt˚um a t´ım jim ozn´am´ı aktu´aln´ı stav novˇe pˇripojen´eho resource. Opakem tohoto mechanismu je
”unavailable presence“, kde element neobsa- huje atribut to, ale obsahuje type unavailable – tento mechanismus se vyuˇz´ıv´a k infor- mov´an´ı vˇsech kontakt˚u o tom, ˇze se resource uˇzivatele odpojuje a jiˇz nebude dostupn´y a m˚uˇze obsahovat element status s vysvˇetlen´ım proˇc se uˇzivatel odpojuje. [6]
Dalˇs´ı je
”presence probe“, tedy zasl´an´ı elementu presence s typem probe a defi- novan´ymi atributy to a from. Tento mechanismus je klienty vyuˇz´ıv´an jen minim´alnˇe – ˇ
castˇeji jej zas´ıl´a server, kter´y tak zjiˇst’uje aktu´aln´ı stavovou informaci dan´eho kontaktu.
Napˇr´ıklad proto mohl tuto informaci odeslat novˇe pˇrihl´aˇsen´emu resource uˇzivatele.
Posledn´ım je
”presence broadcast“. Tento mechanismus je obdobou
”initial presence“, tedy odesl´an´ı elementu presence bez atribut˚u to a type. Slouˇz´ı k tomu, aby uˇzivatel˚uv
XMPP klient mohl kdykoli bˇehem relace zmˇenit stav uˇzivatele. Tento element je n´aslednˇe prostˇrednictv´ım server˚u uˇzivatele i klient˚u odesl´an vˇsem dostupn´ym resource vˇsech klient˚u i vˇsem ostatn´ım resource uˇzivatele. Opakem je pak
”directed presence“, ten je vyuˇz´ıv´an nejˇcastˇeji ke sdˇelen´ı aktu´aln´ıho stavu kontaktu, kter´y nem´a stavovou informaci povolenu (napˇr´ıklad protoˇze uˇzivatel a klient aktivnˇe komunikuj´ı). [6]
2.2.6 Spr´ava povolen´ı stavov´e informace v XMPP
Aby bylo ochr´anˇeno soukrom´ı uˇzivatele protokolu XMPP, je stavov´a informace zas´ıl´ana pouze uˇzivatel˚um, kteˇr´ı byli pˇredem schv´aleni (kontakt˚um). K tomu slouˇz´ı tak- zvan´e subscription opr´avnˇen´ı. Doba trvanlivosti tˇechto opr´avnˇen´ı je nekoneˇcn´a a nen´ı tedy omezena pouze na jednu relaci jako napˇr. v protokolu SIP. Z toho plyne, ˇze pro odebr´an´ı tohoto opr´avnˇen´ı je nutn´e, aby uˇzivatel manu´alnˇe vzal sv´e povolen´ı zpˇet.
Spr´ava tˇechto opr´avnˇen´ı prob´ıh´a stejnˇe jako zas´ıl´an´ı stavov´ych informac´ı pomoc´ı ele- mentu <presence/>, a to konkr´etnˇe typu
”subscribe“,
”unsubscribe“,
”subscribed“
a”unsubscribed“. [6]
Z´ˇadost o z´ısk´an´ı stavov´e informace se zas´ıl´a pomoc´ı elementu <presence/> typu subscribe:
<presence id=’creg51re1’ to=’klient14@example.cz’ type=’subscribe’ />.
Atribut to mus´ı obsahovat bare JID, tedy JID sloˇzen´e pouze z localpart a domainpart z d˚uvodu zjednoduˇsen´ı cel´e ˇz´adosti – uˇzivatel ˇz´ad´a o povolen´ı stavov´e informace pro vˇsechny komunik´atory kontaktu (tzn. pro vˇsechny resourcepart). Server uˇzivatele pak provede kontrolu JID (napˇr. odebr´an´ı resourcepart z JID), a pokud se nejedn´a o validn´ı JID, bude vr´acena chyba typu <jid-malformed/>. N´aslednˇe je do poˇzadavku pˇrid´an atribut from s hodnotou bare JID uˇzivatele a ten je odesl´an serveru kontaktu. Po odesl´an´ı tohoto poˇzadavku doch´az´ı k odesl´an´ı pˇr´ıkazu roster push (viz 2.2.4, hodnota atributu subscribtion je none – zat´ım nen´ı stavov´a informace schv´alena v ˇz´adn´em smˇeru a hodnota atributu ask je subscribe – ˇz´adost byla odesl´ana) vˇsem resourcepart uˇzivatele. Odesl´an´ı poˇzadavku subscribe by mˇel server opakovat do doby, neˇz pˇrijde schv´alen´ı/odm´ıtnut´ı (ˇcetnost z´aleˇz´ı na zvolen´e strategii). [6]
Server kontaktu ˇz´adost bud’ automaticky schv´al´ı (napˇr. pokud jiˇz uˇzivatel po- volen´ı z´ıskal v minulosti, nebo m´a kontakt nastaveno automatick´e schvalov´an´ı pro vˇsechny), uloˇz´ı a odeˇsle ji kontaktu pozdˇeji (pokud jsou vˇsechny resource kontaktu offline) nebo ji poskytne ke schv´alen´ı kontaktu. Kontakt pak na tento poˇzadavek m˚uˇze reagovat schv´alen´ım:
<presence id=’1h6rv’ to=’kamera568@jablocom.com’ type=’subscribed’ />.
Tedy odesl´an´ım elementu presence typu subscribed. Po schv´alen´ı mus´ı server kontaktu upravit poloˇzku subscribtion v z´aznamu uˇzivatele na from (pˇr´ıpadnˇe both, pokud jiˇz doˇslo ke schv´alen´ı z druh´e strany) a informovat o tom vˇsechny interested resource kontaktu. D´ale informace putuje k serveru uˇzivatele spoleˇcnˇe s informac´ı o aktu´aln´ım stavu kontaktu, ten uprav´ı z´aznam kontaktu (subscribtion na to/both) a odeˇsle jak informaci o zmˇenˇe tak aktu´aln´ı stav kontaktu vˇsem interested resource uˇzivatele. [6]
Nebo kontakt poˇzadavek zam´ıtne odesl´an´ım presence typu unsubscribed:
<presence id=’9de’ to=’kamera568@jablocom.com’ type=’unsubscribed’ />.
Ten je odesl´an uˇzivatelovu serveru, kter´y na nˇej reaguje odebr´an´ım hodnoty atributu ask a odesl´an´ım roster push vˇsem interested resource. [6]
Presence unsubscribed m˚uˇze b´yt odesl´an i mimo kontext schvalov´an´ı ˇz´adosti o stavovou informaci. V tomto pˇr´ıpadˇe pak zajiˇst’uje ukonˇcen´ı platnosti pˇredschv´alen´ı ˇ
ci odebr´an´ı opr´avnˇen´ı na stavovou informaci. Server na tento poˇzadavek reaguje ak- tualizac´ı stavu kontaktu (z both na to, ˇci z from na none) vˇsem interested resource uˇzivatele (roster push) a odesl´an´ım presence unsubscribed spoleˇcnˇe s presence unavai- lable serveru kontaktu:
<presence from=’kamera568@jablocom.com’ id=’e6’ type=’unavailable’ />.
Server kontaktu zareaguje postupn´ym pˇreposl´an´ım presence unsubscribed, roster push (zmˇena smˇeru stavov´e informace) a presence unavailable vˇsem dostupn´ym interested resource kontaktu (pokud nen´ı ˇz´adn´y resource kontaktu dostupn´y, mˇel by ˇz´adost uloˇzit a o odebr´an´ı opr´avnˇen´ı kontakt informovat pˇri prvn´ım pˇrihl´aˇsen´ı). [6]
Posledn´ım typem presence elementu je unsubscribe:
<presence id=’e6rn4te’ to=’klient14@example.cz’ type=’unsubscribe’ />.
Ten uˇzivatel odes´ıl´a v pˇr´ıpadˇe, ˇze jiˇz nad´ale nechce dost´avat informaci o aktu´aln´ım stavu kontaktu. Jeho server zareaguje zasl´an´ım roster push vˇsem interested resource (zmˇena subscribtion z both na from, ˇci z to na none) a pˇreposl´an´ım ˇz´adosti serveru kon- taktu. Server kontaktu pak ˇz´adost pˇrepoˇsle vˇsem interested resource kontaktu spoleˇcnˇe s roster push (zmˇena z both na from, ˇci z to na none) a opaˇcn´ym smˇerem zaˇsle presence unavailable za kaˇzd´y online resource kontaktu. [6]
2.2.7 Pˇrenos zpr´av v XMPP
Po autentizaci a proveden´ı dalˇs´ıch nezbytn´ych mechanism˚u je uˇzivateli po- voleno odes´ıl´an´ı ˇci pˇrij´ım´an´ı XMPP zpr´av, prob´ıhaj´ıc´ı prostˇrednictv´ım elementu
<message/>: [6]
<message from=’kamera568@example.com/vlakno’ id=’cebc61vc’
to=’klient14@example.cz’ type=’headline’ >
<subject>Poplach</subject>
<body>Ve strezenem objektu doslo k˜poplachu</body>
</message>
Atribut from identifikuje odesilatele zpr´avy a mˇel by obsahovat full JID, tedy vˇcetnˇe resourcepart. Atribut to identifikuje pˇr´ıjemce zpr´avy a nejˇcastˇeji obsahuje pouze bare JID (adresa bez resourcepart), tak aby nebylo nutn´e pˇredem rozhodnout o tom, kam bude zpr´ava zasl´ana (pokud si uˇzivatel s kontaktem vymˇeˇnuj´ı vˇetˇs´ı mnoˇzstv´ı zpr´av, doch´az´ı k c´ılen´ı a tedy i to obsahuje full JID). Atribut type urˇcuje typ zpr´avy – chat (zpr´ava je souˇc´ast´ı komunikace dvou klient˚u), error (informace o chybˇe pˇri odesl´an´ı zpr´avy), groupchat (komunikace v´ıce uˇzivatel˚u), normal (osamocen´a zpr´ava, u kter´e se oˇcek´av´a odpovˇed’) ˇci headline (upozornˇen´ı, hl´aˇsen´ı – osamocen´a zpr´ava, bez oˇcek´av´an´ı odpovˇedi). Element body obsahuje sdˇelen´ı, kter´e zpr´ava obsahuje. Je moˇzn´e, aby zpr´ava obsahovala v´ıce element˚u body, ty jsou pak oznaˇceny
”xml:lang“ a obsa- huj´ı lokalizaci zpr´avy do v´ıce jazyk˚u. Element Subject obsahuje upˇresˇnuj´ıc´ı informaci o t´ematu zpr´avy. [6]
3 Specifikace zad´ an´ı
Navrˇzen´ı a vytvoˇren´ı sluˇzby, kter´a bude pˇren´aˇset uˇzivatelsk´e zpr´avy z bez- peˇcnostn´ı kamery EYE-02 na IM klienta uˇzivatele a tak´e bude umoˇzˇnovat pomoc´ı tohoto klienta kameru ovl´adat a zobrazovat jej´ı aktu´aln´ı stav, je velmi obecn´e zad´an´ı probl´emu. Pˇri pohledu na z´akladn´ı a zejm´ena rozˇsiˇruj´ıc´ı funkcionalitu protokolu XMPP je patrn´e, ˇze lze sluˇzbu rozˇsiˇrovat o celou ˇradu mechanism˚u poskytuj´ıc´ıch r˚uzn´e sluˇzby. D´ale je tak´e tˇreba m´ıt na zˇreteli, ˇze spoleˇcnost Jablocom s. r. o. m´a existuj´ıc´ı infrastrukturu pro pr´aci s daty, kter´a jsou zas´ıl´ana smˇerem od kamery ke klientovi a tak´e smˇerem od klienta ke kameˇre a nebylo by tedy vhodn´e navrhnout sluˇzbu v rozporu s tˇemito postupy. Proto bylo po konzultaci se zadavatelem projektu navrˇzeno n´asleduj´ıc´ı upˇresnˇen´ı zad´an´ı:
1. Realizace datab´aze, kter´a bude prostˇredn´ıkem mezi infrastrukturou spoleˇcnosti Jablocom s. r. o. a vytvoˇrenou sluˇzbou. Do t´eto datab´aze by mˇelo b´yt moˇzn´e uloˇzit vˇsechny pˇr´ıchoz´ı ud´alosti: zpr´ava od klienta, zpr´ava od kamery, zmˇena stavu kamery, pˇrid´an´ı adresy klienta do kontakt listu kamery, odesl´an´ı souboru z ´uˇctu kamery, ˇz´adost klienta o videohovor, . . . a dalˇs´ı doplˇnuj´ıc´ı informace jako je stav zpracov´an´ı ud´alosti a tak´e podrobnosti zpracov´an´ı.
2. Navrˇzen´ı a implementace WCF sluˇzby zajiˇst’uj´ıc´ı z´apis ud´alost´ı pˇrich´azej´ıc´ıch ze strany spoleˇcnosti do datab´aze a jej´ıˇz prostˇrednictv´ım bude moˇzn´e z´ısk´avat informace o ud´alostech ze strany klienta a ty filtrovat v z´avislosti na r˚uzn´ych parametrech. Pomoc´ı sluˇzby by tak´e mˇelo b´yt umoˇznˇeno sledovat stav zadan´e ud´alosti a reagovat tak napˇr´ıklad na jej´ı nedoruˇcen´ı nebo z´ıskat seznam vˇsech aktu´alnˇe vytvoˇren´ych ´uˇct˚u kamer a jejich stav (bˇeˇz´ıc´ı/zastaven´y).
3. V´ybˇer dom´ac´ıho XMPP serveru, pˇres kter´y bude sluˇzba komunikovat s vnˇejˇs´ım svˇetem, v z´avislosti na potˇrebn´e funkcionalitˇe a poˇzadavc´ıch spoleˇcnosti Jablo- com.
4. Zprovoznˇen´ı a nastaven´ı XMPP serveru na testovac´ım serveru spoleˇcnosti Jablo- com tak, aby bylo umoˇzˇneno testov´an´ı vytvoˇren´e sluˇzby a z´aroveˇn byla zaruˇcena maxim´aln´ı bezpeˇcnost pˇren´aˇsen´ych dat i serveru samotn´eho.
5. Prozkoumat moˇznosti protokolu XMPP smˇerem k ovˇeˇren´ı pˇren´aˇsen´ych dat – tedy ovˇeˇren´ı, zda odeslan´a data skuteˇcnˇe dorazila na IM klienta uˇzivatele.
6. Implementace vl´akna kamery, kter´e bude v periodick´ych intervalech pˇreb´ırat jemu urˇcen´e ud´alosti z datab´aze a na z´akladˇe tˇechto z´aznam˚u odes´ılat urˇcen´e
XML stanza serveru (odesl´an´ı zpr´avy klientovi, zmˇena stavu, pˇrid´an´ı/odebr´an´ı adresy klienta z kontakt listu nebo navaz´an´ı videohovoru), ˇci ve speci´aln´ıch pˇr´ıpadech komunikovat pˇr´ımo s klientem (odes´ıl´an´ı souboru). Vl´akno kamery tak´e mus´ı asynchronnˇe reagovat na pˇr´ıchoz´ı XML stanza – pˇr´ıchoz´ı zpr´ava, ˇ
z´adost o videohovor, potvrzen´ı ˇz´adosti presence subscribtion aj. a v z´avislosti na nich zapisovat ud´alosti do datab´aze.
7. Provˇeˇrit moˇznosti uskuteˇcˇnov´an´ı videohovoru prostˇrednictv´ım protokolu XMPP se zamˇeˇren´ım na XMPP klienty spoleˇcnosti Google Inc. – Google talk ˇci Google chat.
8. N´avrh a implementace hlavn´ı sluˇzby, kter´a se bude starat o spouˇstˇen´ı a ukon- ˇ
cov´an´ı vl´aken kamer v z´avislosti na tom zda m´a vl´akno ve sv´em kontakt listu adresu nˇekter´eho z klient˚u spoleˇcnosti Jablocom s. r. o. D´ale by sluˇzba mˇela v periodick´ych intervalech kontrolovat bˇeh spuˇstˇen´ych vl´aken a v pˇr´ıpadˇe, ˇze naraz´ı na probl´em, vl´akno restartovat a uloˇzit o tom zpr´avu do logu.
9. Vytvoˇren´ı webov´e str´anky, kter´a bude demonstrovat funkcionalitu zm´ınˇen´e WCF sluˇzby. Webov´a str´anka bude umoˇzˇnovat dvoj´ı pˇrihl´aˇsen´ı: jednak jm´enem a hes- lem kamery, kde si bude moˇzn´e prohl´ednout pouze ´udaje z vybran´e kamery a pak tak´e administr´atorsk´ym jm´enem a heslem, kde bude moˇzn´e celou aplikaci spravo- vat – vytv´aˇret ´uˇcty kamer, zad´avat jim pˇr´ıkazy ˇci zobrazovat pˇr´ıchoz´ı a odchoz´ı ud´alosti a filtrovat je dle zadan´ych krit´eri´ı.
K vytvoˇren´ı vˇsech aplikac´ı bude pouˇzito v´yvojov´e prostˇred´ı Microsoft Visual Studio a platforma .NET. Konkr´etnˇe pro v´yvoj hlavn´ı sluˇzby, vl´akna kamery a WCF rozhran´ı bude pouˇzit programovac´ı jazyk C# a webov´a str´anka bude kombinac´ı C#, JavaScript a HTML pomoc´ı frameworku ASP.NET MVC. Jako datab´azov´y syst´em bude pouˇzit Microsoft SQL Server. Sluˇzba pak mus´ı fungovat na syst´emech Microsoft Windows, konkr´etnˇe pak na Windows Server.
4 Realizace sluˇ zby
Na z´akladˇe upˇresnˇen´eho zad´an´ı (viz 3) je tedy celkov´e sch´ema sluˇzby n´asleduj´ıc´ı:
Obr´azek 3: Sch´ema v´ysledn´e aplikace
Informace z kamery (poplachy, reˇzim kamery, obr´azky z kamery a dalˇs´ı) jsou spoleˇcnˇe s nastaven´ım z´ıskan´ym od klienta (povolen´ı sluˇzby XMPP, zad´an´ı XMPP adresy pro komunikaci s kamerou apod.) uchov´av´any v
”Jablotool DB“ (datab´aze spoleˇcnosti Jablocom). Vybran´e informace (typicky ty, u kter´ych si uˇzivatel zvol´ı, ˇze je chce z´ısk´avat prostˇrednictv´ım XMPP klienta), jsou pak pˇreb´ır´any sluˇzbou, zde po- jmenovanou
”Sender“ – ta je prostˇrednictv´ım WCF rozhran´ı zapisuje do datab´aze vytvoˇren´e sluˇzby
”XMPP messages DB“. Odtud informace/povely putuj´ı k vytvoˇren´e sluˇzbˇe (
”XMPP service“), kter´a je zpracov´av´a a na jejich z´akladˇe prov´ad´ı pˇr´ısluˇsn´e operace jako je spuˇstˇen´ı vl´akna kamery (hlavn´ı sluˇzba) nebo odesl´an´ı zpr´avy uˇzivateli (vl´akno kamery). Komunikace s klientem je pak realizov´ana sestaven´ım pˇr´ısluˇsn´eho XML stanza, kter´e je pˇred´ano dom´ac´ımu XMPP serveru. Ten vytvoˇr´ı spojen´ı s XMPP serverem klienta a data mu pˇred´a. XMPP server klienta tyto informace pˇred´a pˇr´ımo klientovi, kter´y m˚uˇze b´yt pˇripojen napˇr´ıklad ze sv´eho mobiln´ıho telefonu ˇci notebooku.
Komunikace samozˇrejmˇe stejnˇe m˚uˇze prob´ıhat i z druh´e strany, kde domovsk´y XMPP server zas´ıl´a z´ıskan´a XML stanza vl´aknu kamery a to reaguje jejich zpra- cov´an´ım – zmˇenou sv´eho vnitˇrn´ıho stavu (odebr´an´ı klienta z kontakt listu) nebo zaps´an´ım pˇr´ısluˇsn´e ud´alosti do
”XMPP messages DB“ (pˇr´ıchoz´ı zpr´ava, ˇz´adost o vi-
deohovor), odkud je prostˇrednictv´ım WCF rozhran´ı pˇreb´ır´a sluˇzba
”Observer“ a pˇres
”Jablotool DB“ doch´az´ı k jejich zpracov´an´ı a odesl´an´ı na kameru.
4.1 V´ ybˇ er XMPP serveru
V nˇekolika n´asleduj´ıc´ıch podkapitol´ach dojde k pˇredstaven´ı (vybran´e infor- mace, popis instalace a moˇznosti konfigurace) vybran´ych open source XMPP ser- ver˚u, kter´e by mohly b´yt vyuˇzity pro ´uˇcely spojen´ı sluˇzby s okoln´ım svˇetem – Open- fire (4.1.1), Ejabberd (4.1.2), Jabberd 2.x (4.1.3), Tigase (4.1.4) a Prosody (4.1.5).
D´ıky otevˇrenosti technologie XMPP to samozˇrejmˇe nejsou vˇsechny moˇznosti a XMPP server˚u existuje cel´a ˇrada – ofici´aln´ı seznam je moˇzn´e nal´ezt na webov´em port´alu tech- nologie XMPP http://xmpp.org/xmpp-software/servers/. Ovˇsem tyto zm´ınˇen´e servery spojuje nˇekolik fakt˚u – jejich v´yvoj st´ale pokraˇcuje, jsou dostupn´e bezplatnˇe a jejich pouˇzit´ı v komerˇcn´ıch aplikac´ıch je moˇzn´e.
V podkapitole 4.1.6 dojde k porovn´an´ı vlastnost´ı tˇechto server˚u a tak´e k v´ybˇeru serveru, kter´y bude pouˇzit v t´eto aplikaci. V podkapitole 4.1.7 bude pak pops´ano jak server nastavit s ohledem na plnou funkˇcnost a maxim´aln´ı bezpeˇcnost dat pˇren´aˇsen´ych vyv´ıjenou sluˇzbou i sluˇzby samotn´e.
4.1.1 Openfire
Openfire je XMPP server spravovan´y open source komunitou Ignite Realtime vedenou odborn´ıky ze spoleˇcnosti Jive Software. Komunita se zamˇeˇruje na zm´ınˇenou technologii XMPP a spravuje nˇekolik projekt˚u, mezi kter´e patˇr´ı server Openfire, klient Spark, jeho webov´a verze SparkWeb ˇci knihovny slouˇz´ıc´ı k vytvoˇren´ı vlastn´ı XMPP aplikace – Smack (Java), XIFF (Flash). [7]
Server openfire je napsan´y v programovac´ım jazyce Java a je vydan´y pod licenc´ı Apache 2.0, coˇz umoˇzˇnuje jeho neomezen´e (m´ıstnˇe i ˇcasovˇe) pouˇzit´ı a to i v oblasti komerˇcn´ı sf´ery. Aktu´aln´ı verze serveru je 3.8.1 vydan´a 3. 3. 2012. [7] Samotn´a instalace tohoto serveru je velmi snadn´a (dostupn´a v ˇceˇstinˇe), uˇzivatel je dot´az´an pouze na souhlas s licenc´ı serveru a na sloˇzku kam m´a b´yt server nainstalov´an. Po instalaci se server s´am automaticky spust´ı a po pˇrechodu do
”admin console“ pˇri stisku
”Launch Admin“ doch´az´ı k ´uvodn´ı konfiguraci.
Zde si uˇzivatel nejdˇr´ıve zvol´ı pˇreklad admin console (k dispozici je opˇet i ˇceˇstina), n´aslednˇe vypln´ı dom´enu serveru na kter´em Openfire pobˇeˇz´ı a dva porty, kter´e jsou pouˇz´ıv´any k obsluze admin console zvenˇc´ı. Dalˇs´ım krokem je volba datab´aze, kterou
server bude pouˇz´ıvat pro uchov´av´an´ı nastaven´ı ˇci dat o klientech – lze vyuˇz´ıt ve- stavˇenou datab´azi nebo urˇcit datab´azi vlastn´ı – pak je nutn´e vyplnit typ datab´aze, jm´eno a heslo pro pˇr´ıstup a dalˇs´ı parametry (maxim´aln´ı poˇcet soubˇeˇzn´ych pˇripojen´ı, ˇ
casov´y limit pˇripojen´ı apod.). N´asleduje moˇznost propojit server s adres´aˇrov´ym serve- rem (OpenLDAP, Active Directory apod.) ˇci technologi´ı Clearspace, kter´e podporuj´ı pokroˇcilou spr´avu uˇzivatelsk´ych ´uˇct˚u – opˇet nutn´e vyplnit autorizaˇcn´ı ´udaje a dalˇs´ı
´
udaje jako mapov´an´ı klient˚u na adres´aˇre. Posledn´ım ´udajem je administr´atorsk´y ´uˇcet, pomoc´ı kter´eho se pak lze pˇripojit do admin console a prov´adˇet zmˇeny nastaven´ı ser- veru Openfire.
Obr´azek 4: Openfire – admin console – relace s XMPP servery
Admin console m´a pˇet hlavn´ıch kategori´ı, ve kter´ych lze sledovat aktu´aln´ı chod serveru a prov´adˇet pˇr´ısluˇsn´e zmˇeny. Kategorie
”Plugins“ slouˇz´ı k rozˇsiˇrov´an´ı funkc´ı serveru, kde se nach´az´ı seznam aktu´alnˇe nainstalovan´ych rozˇs´ıˇren´ı a tak´e seznam do- stupn´ych rozˇs´ıˇren´ı – v nˇemˇz jsou ofici´alnˇe schv´alen´a a podporovan´a rozˇs´ıˇren´ı, kter´a jsou uˇzivateli pouˇz´ıv´ana nejˇcastˇeji a samozˇrejmˇe je tu i moˇznost pˇridat rozˇs´ıˇren´ı vlastn´ı.
Kategorie
”Group chat“ slouˇz´ı k vytv´aˇren´ı a spr´avˇe konferenˇcn´ıch m´ıstnost´ı na ser- veru, prostˇrednictv´ım kter´ych lze uskuteˇcˇnovat napˇr´ıklad hromadn´e vnitrofiremn´ı kon- ference.
Kategorie
”Sessions“ obsahuje aktu´alnˇe pˇripojen´e aplikace, tedy klienty pˇripo- jen´e na sv˚uj ´uˇcet, ale i nav´azan´e spojen´ı s ostatn´ımi XMPP servery (viz obr. ˇc. 4). Zde lze tak´e odeslat hromadnou zpr´avu vˇsem klient˚um serveru. V kategorii
”Users/Groups“
je moˇzn´e spravovat skupiny – pˇrid´avat/mazat aj. nebo ´uˇcty klient˚u na serveru –
vytv´aˇret ˇci mazat ´uˇcty, pˇriˇrazovat jim ´udaje (email, jm´eno), mˇenit jejich heslo, pˇrid´avat/odeb´ırat jim kontakty z kontakt listu, blokovat je ˇci je pˇrid´avat do skupin.
Kategorie
”Server“ pak slouˇz´ı k nastaven´ı vybran´ych vlastnost´ı serveru, ˇci ke zmˇenˇe parametr˚u zadan´ych pˇri inicializaci.
4.1.2 Ejabberd
Ejabberd je dalˇs´ı server, kter´y je spravov´an svou vlastn´ı komunitou za pod- pory komerˇcn´ı spoleˇcnosti. Jeho v´yvoj zaˇcal v roce 2002 program´ator jm´enem Alexey Shchepin, d´ıky jeho pˇredchoz´ımu ´uspˇechu s XMPP klientem Tkabber a chuti pracovat s programovac´ım jazykem Erlang, ve kter´em je Ejabberd vytvoˇren. V souˇcasnosti se do jeho v´yvoje intenzivnˇe zapojuje spoleˇcnost ProcessOne, kter´a podnik´a pr´avˇe v oboru instant messagingu se zamˇeˇren´ım na technickou podporu, ˇskolen´ı, konzultace a v´yvoj software na zak´azku. [8]
Jak bylo zm´ınˇeno Ejabberd je vytvoˇren v jazyce Erlang a je publikov´an pod licenc´ı GPL v2, kter´a se vztahuje prim´arnˇe na upravov´an´ı a dalˇs´ı ˇs´ıˇren´ı d´ıla, ale jeho pouˇz´ıv´an´ı a provoz nen´ı upraven a to ani v oblasti komerˇcn´ı sf´ery. Aktu´aln´ı verze serveru Ejabberd je 2.1.11 vydan´a 4. 5. 2012. Server je moˇzn´e st´ahnout v podobˇe zdrojov´ych k´od˚u nebo instal´atoru pro vybran´y operaˇcn´ı syst´em (Windows, Linux ˇci Mac OS). [8] Instalace serveru pˇri pouˇzit´ı instal´atoru pro Windows je pomˇernˇe jed- noduch´a, i kdyˇz bohuˇzel nen´ı k dispozici ˇcesk´a lokalizace. Bˇehem instalace je uˇzivatel dot´az´an na nˇekolik ´udaj˚u – souhlas s licenc´ı, c´ılov´a sloˇzka, dom´ena serveru, na kter´em pobˇeˇz´ı, jm´eno a heslo administr´atorsk´eho ´uˇctu a zda bude server ˇc´ast´ı clusteru XMPP server˚u (v pˇr´ıpadˇe ˇze ano tak i na jeho oznaˇcen´ı). Po instalaci je moˇzn´e server ihned provozovat pomoc´ı vytvoˇren´ych aplikac´ı Start/Stop.
Konfigurace serveru m˚uˇze prob´ıhat dvˇema zp˚usoby. Prvn´ı moˇznost´ı je vyuˇzit´ı grafick´eho
”admin interface“ (po spuˇstˇen´ı serveru je spuˇstˇen´a webov´a str´anka s odka- zem). Zde je pˇet z´akladn´ıch nab´ıdek. V nab´ıdce
”Seznamy pˇr´ıstupov´ych pr´av (ACL)“
lze povolit/zak´azat pˇr´ıstup vybran´ym uˇzivatel˚um a tˇem povolen´ym pˇriˇradit urˇcitou skupinu, na z´akladˇe kter´e budou moci v budoucnu pˇristupovat k vybran´ym sluˇzb´am serveru. V druh´e nab´ıdce
”Pravidla pˇr´ıstup˚u“ pak lze pˇrid´avat opr´avnˇen´ı pˇr´ıstupu uˇzivatel˚u k vybran´ym sluˇzb´am serveru.
V nab´ıdce
”Virtu´aln´ı hostitel´e“ pak lze zjistit poˇcet registrovan´ych a online uˇzivatel˚u k dan´e JID dom´enˇe. Po otevˇren´ı pˇr´ısluˇsn´e JID dom´eny se zobraz´ı nab´ıdka specifick´a pr´avˇe pro danou dom´enu. Jej´ım prostˇrednictv´ım lze upravit v´yˇse zm´ınˇen´e
