realno-Časovne spletne aplikacije · realno-časovne spletne aplikacije 3 realno-Časovne spletne...
Post on 17-Oct-2020
7 Views
Preview:
TRANSCRIPT
Matjaž Lipuš
REALNO-ČASOVNE SPLETNE APLIKACIJE
Diplomsko delo
Maribor, marec 2011
Realno-časovne spletne aplikacije 0
Diplomsko delo visokošolskega strokovnega študijskega programa
REALNO-ČASOVNE SPLETNE APLIKACIJE
Študent: Matjaž Lipuš
Študijski program: VS ŠP Računalništvo in informatika
Smer: Informatika
Mentor: viš. pred. mag. Boštjan Kežmah
Maribor, marec 2011
Realno-časovne spletne aplikacije 1
Realno-časovne spletne aplikacije 2
ZAHVALA
Zahvaljujem se mentorju mag. Boštjanu
Kežmahu za pomoč in nasvete pri opravljanju
diplomskega dela.
Posebna zahvala gre staršem, ki so mi
omogočili študij in vsem ostalim, ki so mi
tekom študija pomagali.
Realno-časovne spletne aplikacije 3
REALNO-ČASOVNE SPLETNE APLIKACIJE
Ključne besede: realno-časovni splet, Splet 2.0, Comet, reverse AJAX, HTML 5
UDK: 004.777(043.2)
Povzetek
V današnjem času vse prisotnosti spleta, se trendi zelo hitro spreminjajo. Splet 2.0 je
prinesel odprtost in sodelovanje vseh uporabnikov spleta in s tem odprl nove možnosti
deljenja informacij. Danes ni več dovolj, da preberemo članek, ko nanj naletimo, ampak
želimo biti o njem obveščeni takoj, ko je objavljen.
Potreba po takojšnjih informacijah zahteva razvoj novih tehnologij, ki omogočajo
pošiljanje podatkov k obiskovalcu, takoj ko se ti zgodijo. Govorimo o realno-časovnih
spletnih aplikacijah.
V diplomskem delu bomo pregledali tehnologije in tehnike, ki se danes uporabljajo za
dostavljanje informacij obiskovalcem, ter knjižnice, ki nam omogočijo enostavnejši razvoj
takšnih aplikacij, v praktičnem delu pa bomo s pomočjo opisanih tehnologij izdelali
preprosto igro Križci in krožci.
Realno-časovne spletne aplikacije 4
REAL-TIME WEB APPLICATIONS
Key words: real-time web, Web 2.0, Comet, reverse AJAX, HTML 5
UDK: 004.777(043.2)
Abstract
Nowadays, in the times of ubiquitous computing, especially the Internet, trends change
rapidly. Web 2.0 encourages openness and collaboration of all users, which in run
provided new opportunities for sharing information. For users it is not enough just to read
an article when they stumble upon it – they want to be notified as soon as the article is
published and available.
Need for instant information delivery requires development of new technologies, which
would provide means of sending relevant information to user as soon as it is available. In
this case we are dealing with real-time web applications.
In our thesis we examine the technologies available and techniques, which are used for
delivering information to visitors, we look at libraries allowing developers to easily
implement such applications. For practical part, we created a simple tic-tac-toe like game.
Realno-časovne spletne aplikacije 5
KAZALO VSEBINE
UVOD .................................................................................................................................. 10
2 SPLET 2.0 ................................................................................................................... 12
2.1 Tehnologije ........................................................................................................... 13
2.1.1 HTTP ............................................................................................................. 14
2.1.2 HTML ............................................................................................................ 17
2.1.3 CSS ................................................................................................................ 18
2.1.4 DOM in BOM ................................................................................................ 18
2.1.5 JavaScript ...................................................................................................... 19
2.1.6 AJAX ............................................................................................................. 20
2.1.7 Brskalniki ...................................................................................................... 22
3 REALNO-ČASOVNI SPLET ..................................................................................... 23
3.1 Tehnologije in tehnike .......................................................................................... 23
3.1.1 Povpraševanje (polling) ................................................................................. 24
3.1.2 Hkratni prenos (Piggybacking) ...................................................................... 25
3.1.3 Dolgo povpraševanje (long-polling) .............................................................. 26
3.1.4 Povpraševanje s povratnim klicem (callback-polling) .................................. 27
3.1.5 Pretok Iframe (Iframe stremaing) .................................................................. 27
3.1.6 Pretok Htmlfile (Htmlfile streaming) ............................................................ 28
3.1.7 Pretok XHR (XHR streaming) ...................................................................... 28
3.1.8 Večdelni pretok (Multipart streaming) .......................................................... 29
Realno-časovne spletne aplikacije 6
3.1.9 Razširitve brskalnika ..................................................................................... 30
3.1.10 Spletne vtičnice (WebSockets) ...................................................................... 31
3.1.11 Dogodki poslani iz strežnika (Server-sent events) ........................................ 31
3.1.12 Stanje danes ................................................................................................... 32
3.2 Dostavljanje sporočil preko kanalov ..................................................................... 33
3.2.1 Protokol Bayeux ............................................................................................ 34
4 UPORABA REALNO-ČASOVNIH TEHNOLOGIJ ................................................. 38
4.1 WebSockets .......................................................................................................... 38
4.1.1 API ................................................................................................................. 39
4.1.2 Protokol ......................................................................................................... 40
4.2 Knjižnice za poenostavljeno uporabo tehnologij in tehnik ................................... 40
4.2.1 Predstavitev knjižnice Faye .......................................................................... 41
4.3 Načrtovanje arhitekture aplikacije ........................................................................ 46
4.4 Izdelava aplikacije ................................................................................................ 47
4.5 Predstavitev aplikacije .......................................................................................... 50
4.5.1 Pregled aplikacije .......................................................................................... 51
4.5.2 Seznam iger ................................................................................................... 52
4.5.3 Seznam igralcev ............................................................................................. 53
4.5.4 Klepet ............................................................................................................ 54
4.5.5 Igra ................................................................................................................. 54
4.5.6 Komunikacija s strežnikom ........................................................................... 56
4.6 Ugotovitve ............................................................................................................ 56
Realno-časovne spletne aplikacije 7
5 SKLEP ......................................................................................................................... 58
6 VIRI IN LITERATURA .............................................................................................. 59
7 PRILOGE .................................................................................................................... 61
7.1 Kazalo slik ............................................................................................................ 61
7.2 Kazalo tabel .......................................................................................................... 61
7.3 Kazalo izvorne kode ............................................................................................. 61
7.4 Naslov študenta ..................................................................................................... 62
7.5 Kratek življenjepis ................................................................................................ 63
Realno-časovne spletne aplikacije 8
UPORABLJENE KRATICE
AJAX Asynchronous JavaScript and XML
API Application programming interface
BOM Browser object model
CSS Cascading Style Sheets
DOM Document object model
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
IDL Interface description language
IETF Internet Engineering Task Force
JSON JavaScript Object Notation
JSONP JSON with padding
MIME Multipurpose Internet Mail Extensions
OSI Open Systems Interconnection model
REST Representational State Transfer
RFC Request for Comments
RSS Really Simple Syndication
SOAP Simple Object Access Protocol
SSDP Simple Service Discovery Protocol
TCP Transmission Control Protocol
UDP User Datagram Protocol
Realno-časovne spletne aplikacije 9
URL Uniform Resource Locator
W3C World Wide Web Consortium
WSDL Web Services Description Language
XHR XMLHttpRequest
XHTML eXtensible HyperText Markup Language
XML Extensible Markup Language
Realno-časovne spletne aplikacije 10
UVOD
V zadnjih letih v računalniški industriji postaja splet vse prisoten. Splet 2.0 in nove
tehnologije omogočajo razvoj novih vrst aplikacij, ki v celoti tečejo v brskalnikih. Razvoj
brskalnikov in napredek standardov kot je HTML5, omogočajo gradnjo aplikacij, ki se zelo
približajo primerljivi uporabi namiznih aplikacij. Splet je bil v osnovi mišljen zgolj kot
pasivno orodje: ko je uporabnik zahteval stran, mu jo je spletni strežnik posredoval. S
selitvijo namiznih aplikacij na splet, pa se je pojavila potreba po aplikacijah, ki pošiljajo
sporočila od strežnika do uporabnika. Tehnologija AJAX omogoča, da lahko aplikacija
zahteva podatek s strežnika, ne da bi bilo potrebno osvežiti celo stran. Problem tega
pristopa je, da mora aplikacija zahtevati poizvedbo na strežnik, kar pomeni, da v
aplikacijah, kjer se podatki pogosto spreminjajo, t.j. spremembe na nekaj sekund ali še
pogosteje, uporabnik ne bo imel aktualnih podatkov, saj bo podatek, ki ga je sprejel od
strežnika, že zastarel. Zato se je pojavila potreba o pošiljanju podatkov v brskalnik (angl.
»server push«) brez predhodne zahteve.
Realno-časovne spletne aplikacije omogočajo strežniku pošiljanje podatkov odjemalcu,
takoj ko se ti spremenijo. Primera realno-časovnih aplikacij sta borza delnic in
klepetalnica. Takšne aplikacije zahtevajo neprestano odprto povezavo s strežnikom, kar pa
lahko pri današnjih strežnikih predstavlja problem, saj so načrtovani tako, da čim prej
postrežejo vsebino in nato zaprejo povezavo. Te težave odpravljajo nove tehnologije in
standardi, ki rešujejo ta problem. Nekatere so začeli implementirati ustvarjalci brskalnikov,
vendar smo še daleč od tega, da bi bile podprte v vseh najbolj priljubljenih brskalnikih.
Kljub temu je danes že mogoče graditi takšne aplikacije, ker najbolj pogosto uporabljeni
brskalniki podpirajo različne tehnike, s katerimi je mogoče doseči pošiljanje podatkov v
brskalnik.
V diplomski nalogi bomo predstavili tehnologije in standarde, ki omogočajo gradnjo
realno-časovnih spletnih aplikacij. Pogledali bomo različne možnosti, ki so trenutno na
Realno-časovne spletne aplikacije 11
voljo za implementacijo »server-push«, v najbolj uporabljenih brskalnikih. Na koncu bomo
izdelali spletno aplikacijo, ki omogoča realno-časovno komunikacijo.
Diplomska naloga bo prispevala k razumevanju možnosti uporabe tehnologij za realno-
časovne aplikacije in dala vpogled v trenutno stanje podpore v različnih brskalnikih.
Omejili smo se predvsem na trenutno uporabljene realno-časovne tehnike v brskalnikih,
realno-časovne standarde v razvoju organizacij W3C in IETF, pri uporabi tehnologij pa
smo se omejili na komunikacijo strežnik-brskalnik.
Realno-časovne spletne aplikacije 12
2 SPLET 2.0
Splet 2.0 je novodobni splet. Lastnosti spleta 2.0 so osredotočenost na uporabnika, odprtost
in uporaba odprto kodnih tehnologij, enostavnost, ter decentralizacija, porazdeljenost in
sodelovanje.
Splet 2.0 se osredotoča na uporabnika in vsebine, ki jih le-ti prispevajo. Dober primer je
Wikipedija, ki vsebuje milijone člankov v različnih jezikih mnogih avtorjev in vse je
brezplačno dostopno na spletu.
Med podjetji se je pojavil trend, ki nudijo svoje storitve preko spletnih aplikacijskih
vmesnikov (angl. API) ali spletnih mešank (angl. mashups). Podjetja svoje znanje in
izkušnje delijo z ostalimi preko blogov ali prispevajo k odprto-kodnim projektom.
Enostavnost je ena izmed lastnosti, ki se jo trenutno najbolj poudarja: kljub mnogim
funkcionalnostim produkti naj ne bodo preveč kompleksni, naj bodo preprosti, vendar z
odlično uporabniško izkušnjo, funkcionalnosti, ki jih nudijo, pa naj bodo izdelane do
popolnosti. V prid temu govori tudi to, da so t.i. de facto tehnologije nadvladale
kompleksnejše, na primer SOAP, WSDL, in XML sta v Spletu 2.0 nadomestila REST in
JSON. REST temelji na standardu HTTP, ki je osrčje spleta že od njegovega nastanka,
JSON pa je podmnožica jezika JavaScript, ki je danes podprt v vsakem brskalniku. Iz tega
lahko sklepamo, da so stare tehnologije, ki so močno razširjene in dovolj dobre, da se jih
da uporabiti za nove stvari. Fenomen je tudi AJAX, pri katerem gre zgolj za princip, kako
se vsebina spletne strani nalaga. V tem primeru ne gre za novo tehnologijo, saj so
tehnologije za to obstajale že pred desetimi leti. Tudi v razvojnih skupinah je videti trend
naraščanja koncentracije majhnih specializiranih ekip, ki uporabljajo agilne fleksibilne
metodologije razvoja programske opreme.
Razvile so se nove tehnologije, ki omogočajo deljenje vsebine s preprostimi protokoli kot
sta RSS in Atom. Takšno vsebino je enostavno obdelati, jo vključiti v druge spletne strani
in se na njo enostavno sklicevati ali razviti debato [10].
Realno-časovne spletne aplikacije 13
Različne tehnologije, odprtost, enostavnost, pri vsem tem pa smo v središču vsi uporabniki
spleta, ki dnevno prebiramo ali so-ustvarjamo vsebine - to je Splet 2.0.
2.1 Tehnologije
Tehnologije Spleta 2.0 se v primerjavi s Spletom 1.0 niso dosti spremenile, so zgolj
napredovale. Tako se kot osnova ohranja protokol HTTP, ki služi komunikaciji med
strežnikom in odjemalcem.
HTML je jezik za opis obogatenih besedil.
CSS je jezik za opisovanje izgleda označevalnih dokumentov (HTML).
DOM (angl. Document Object Model) in BOM (angl. Browser Object Model) sta
tehnologiji, ki prineseta interaktivnost na spletno stran. S pomočjo njiju lahko programsko
spreminjamo vsebino spletne strani.
JavaScript je jezik, ki ga podpirajo vsi sodobni brskalniki in povezuje zgoraj naštete
tehnologije v zelo uporabno platformo. Veliko rast je dosegel s pomočjo Spleta 2.0 in
razvoja AJAX aplikacij. Zadnje čase pa z gibanjem CommonJS in Node.js pridobiva
zanimanje tudi na strežniku.
AJAX (angl. asynchronous JavaScript and XML) je skupek tehnologij, ki je omogočil
razvoj novo dobnih aplikacij, ki s pomočjo asinhronega programiranja ponujajo boljšo
uporabniško izkušnjo.
Potrebno je še omeniti razvoj in napredek brskalnikov. Nove tehnologije in standardi ne
pomenijo veliko, dokler jih ne moremo uporabiti v aplikacijah, za poganjanje teh pa so so
kritično pomembni brskalniki. AJAX in nove tehnologije so uspele ravno zaradi
brskalnikov, ki so jih podprli. Zadnja leta je tržišče brskalnikov še posebej aktivno, posebej
po vstopu mogočnega igralca Googla z brskalnikom Chrome. V tem času je hitrost
izvajanja JavaScripta zrasla za večkrat. Podpora novim tehnologijam, kot so npr. HTML 5,
določanje geo lokacije, WebSockets, narašča v brskalnikih iz dneva v dan.
Realno-časovne spletne aplikacije 14
2.1.1 HTTP
HTTP je osrčje spleta in je osnovni protokol za prenos informacij. Podpira prenos HTML
dokumentov in ostale tekstovne, ter binarne vrste datotek. Razvoj protokola koordinira
W3C in IETF. Rezultat tega je mnogo RFC-jev, predvsem RFC 2616, ki opisuje HTTP
verzijo 1.1 - danes najbolj uporabljeno različico.
HTTP je komunikacijski protokol med odjemalci in strežniki po principu zahteva -
odgovor. Po naboru protokolov ISO/OSI spada v aplikacijsko plast. Za prenosno plast se
najpogosteje uporablja TCP, čeprav nekatere rešitve uporabljajo tudi UDP ali SSDP [9].
Odjemalec, najbolj razširjeni so spletni brskalniki, začne komunikacijo z vzpostavitvijo
povezave TCP s spletnim strežnikom. Privzeta vrata povezave so 80. Spletni strežnik
vzpostavi povezavo in čaka na zahtevo odjemalca. Odjemalec pošlje zahtevo, ki jo strežnik
obdela in pošlje odgovor. V večini primerov nato strežnik prekine povezavo.
Verzija 1.1 protokola je prinesla mnogo novosti. Med najbolj pomembnimi je bila ponovna
uporaba povezave TCP za več zahtev, tako se za spletno stran, ki vsebuje slike, lahko
uporabi ista poveza, kot za osnovni HTML dokument. S tem se prihrani precej časa, ki je
potreben za vzpostavitev TCP povezave, posledično se tudi spletne strani nalagajo hitreje.
2.1.1.1 Zahteva
Zahteva protokola HTTP je sestavljena iz treh delov: prva vrstica predstavlja zahtevo in je
sestavljena iz metode zahteve, vira zahteve, ter verzije protokola. Primer: GET / HTTP/1.1
V naslednjih vrsticah sledijo glave zahteve, ki vsebujejo dodatne informacije o zahtevi.
Glave so sestavljene iz ključa in vrednosti, ločena z dvopičjem. Primer: Acept-language: sl
Na koncu sledi neobvezno telo sporočila. Med telesom in glavami je ena prazna vrstica.
Novo vrstico predstavlja zaporedje znakov <CR> in <LF>. Prazna vrstica lahko vsebuje
samo ta dva znaka. Verzija 1.1 določa vse glave, razen tistih, ki vsebujejo ključno besedo
Host, kot neobvezne.
Realno-časovne spletne aplikacije 15
2.1.1.2 Metode zahteve
Metoda zahteve pove, kaj želi odjemalec storiti z zahtevanim virom.
Metoda GET zahteva vsebino iz strežnika in kot taka ne sme sprožiti sprememb na
strežniku.
Metoda POST pošlje podatke na strežnik (npr. HTML obrazec). Podatki se na strežniku
obdelajo in med obdelavo se lahko sproži dodatna akcija npr. shranjevanje podatkov v
podatkovno bazo ali pošiljanje elektronskega sporočila.
Ti dve metodi sta najbolj uporabljeni na spletu in brskalnikih, poznamo pa še druge
metode, ki jih delimo na več vrst.
Varne metode, so namenjene samo zahtevam vsebine in ne spreminjajo stanja na strežniku.
Takšne metode so: HEAD, GET, OPTIONS, TRACE.
Idempotentne metode so tiste, pri katerih ima več identičnih zahtev enak učinek kot prva
zahteva. Po definiciji med te spadajo tudi varne metode, poleg njih pa metodi PUT in
DELETE.
Metoda POST ni nujno idempotentna, saj lahko več klicev naredi različne akcije, ki so
popolnoma odvisne od aplikacije, ki zahtevo obdeluje. Primer je bančna transakcija, pri
kateri moramo isti zahtevek omogočiti samo prvič, ali dokler ne presežemo limita.
Obstajajo pa situacije, v katerih želimo, da se vsaka zahteva procesira enako, na primer
beleženje dnevnika [9].
Realno-časovne spletne aplikacije 16
2.1.1.3 Statusne kode
Odgovor strežnika v prvi vrstici vsebuje verzijo protokola in statusno kodo. Verzija določa
verzijo protokola, ki ga govori strežnik, statusna koda pa status odgovora.
Statusne kode so razdeljene v pet skupin.
1. 100-199 Informativne kode
2. 200-299 Uspeh
3. 300-399 Preusmeritev
4. 400-499 Napaka odjemalca
5. 500-599 Napaka strežnika
2.1.1.4 Stanje
Protokol HTTP je brez stanja. To pomeni, da si dve zahtevi, četudi sta narejeni z isto TCP
povezavo, ne delita stanja. Za potrebe ohranjanja stanja, se je uveljavila uporaba piškotkov,
za naprednejšo uporabo stanja se uporablja seja na strežniku, ki ima dodeljeni unikatni ID.
Odjemalec v vsakem zahtevku pošlje ta ID, tako strežnik ve, kateri odjemalec je poslal
zahtevo, in na podlagi tega lahko vzpostavi prejšnje stanje.
2.1.1.5 Primer
Sledi primer zahteve in odgovora FERI-jevega spletnega strežnika.
Zahteva:
GET / HTTP/1.1
Host: www.feri.uni-mb.si
Izvorna koda 1: Zahteva HTTP
Realno-časovne spletne aplikacije 17
Odgovor strežnika:
HTTP/1.1 302 Found
Date: Sat, 01 Jan 2011 00:00:00 GMT
Server: Microsoft-IIS/6.0
X-AspNet-Version: 1.1.4322
Location: http://www.feri.uni-mb.si/podrocje.aspx
Content-Type: text/html; charset=utf-8
Content-Length: 156
<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href='http://www.feri.uni-
mb.si/podrocje.aspx'>here</a>.</h2></body></html>
Izvorna koda 2: Odgovor HTTP
2.1.2 HTML
HTML je označevalni jezik s katerim ustvarimo spletne strani. HTML sestavljajo
označevalne značke, ki opisujejo spletno stran. HTML temelji na predhodnem
označevalnem jeziku SGML. Značke se nahajajo med lomljenimi oklepaji; tako zgleda
primer začetka značke <h1> in tako konec </h1>.
Dokumente HTML prikazuje brskalnik, ki posamezen dokument prebere, ga razčleni in na
podlagi značk interpretira vsebino strani. Brskalnik ne prikazuje značk, saj te služijo kot
meta podatki za vsebino in določajo njen prikaz v brskalniku ali enoto strukture vsebine
(npr. naslov, odstavek).
Značke HTML predstavljajo različne bloke, kot so na primer slike, obrazci, polja, gumbi
ali objekti, določajo strukturo dokumenta s semantičnim označevanjem npr. glava
dokumenta, odstavki, seznami, povezave, citati itd ali celo vsebujejo posebne skripte, ki
omogočajo dodatno interaktivnost spletnim stranem [7].
<!doctype html>
<html>
<head>
<title>HTML 5</title>
</head>
<body>
<p>HTML 5 dokument!</p>
</body>
</html>
Izvorna koda 3: Primer dokumenta HTML
Realno-časovne spletne aplikacije 18
2.1.3 CSS
CSS je jezik za označevanje stilov [16] in opisuje predstavitev semantike (izgled in
postavitev) dokumenta zapisanega v označevalnem jeziku. Najpogosteje se uporablja v
kombinaciji z dokumenti HTML, čeprav se lahko uporablja v drugih označevalnih jezikih.
Namenjen je ločevanju vsebine dokumenta od njegovega prikaza. Z ločevanjem dosežemo
večjo dostopnost vsebine z različnih odjemalcev, zagotovimo večjo fleksibilnost in različni
prikaz iste vsebine na različnih napravah, npr. za namiznem in tabličnem računalniku,
pametnem telefonu, ali celo tiskalniku.
Sintaksa jezika za določanje imena lastnosti uporablja angleške besede. Dokument je
sestavljen iz pravil, kjer vsako pravilo sestavlja eden ali več selektorjev ter blok deklaracij.
Vsaka deklaracija je sestavljena iz lastnosti in vrednosti, ločenih s podpičjem. Selektorji
lahko določajo vse elemente določenega tipa ali samo nekatere glede na njihove atribute.
Kaskadno jezika določa izbiro elementa glede na to kje so pozicionirani v označevalnem
jeziku. CSS podpira tudi psevdo-razrede, ki določajo elemente glede na njihovo obnašanje.
Tako lahko npr. izberemo element, ki je trenutno aktiven (psevdo-razred: “:active”) ali
povezavo, ki je že bila obiskana (psevdo-razredom “:visited”).
Primer CSS dokumenta, ki določa barvo in prikaz povezave. Povezava je bele barve in ni
podčrtana, kot so običajno podčrtane povezave.
a {
color: #fff;
text-decoration: none;
}
Izvorna koda 4: Primer dokumenta CSS
2.1.4 DOM in BOM
DOM (Document Object Model) je jezikovno neodvisen objektni model, podprt na več
platformah, ki predpisuje predstavite, ter delo z objekti v dokumentih HTML, XHTML in
XML.
Realno-časovne spletne aplikacije 19
DOM se je začel razvijati skupaj z brskalniki za omogočanje dostopanja in spreminjanja
dokumentov HTML preko programskega vmesnika. Nastal je t.i. “DOM Level 0”, ki ni bil
standardiziran, zato je imel vsak brskalnik svoj vmesnik za manipuliranje z dokumenti. Na
primer, do prvega obrazca v dokumentu je bilo možno priti le preko document.forms[0].
Organizacija W3C je DOM standardizirala leta 1998, vendar še nekaj časa po tem vsi
brskalniki niso podpirali prve standardizirane verzije. Danes lahko z uporabo modela DOM
dostopamo do poljubnega elementa znotraj dokumenta HTML, ustvarjamo nove elemente,
obstoječim elementom spreminjamo atribute, ali jih odstranjujemo. Poleg tega lahko
poizvedujemo po elementih s pomočjo selektorjev CSS in tako dobimo zbirka elementov,
ki jih lahko naprej obdelujemo [5].
BOM (Browser Object Model) podobno kot DOM določa dostop do objektov in lastnosti v
brskalniku. S pomočjo modela BOM izvemo URL naslov trenutne strani, preusmerimo
brskalnik na drugo stran, odpremo novo okno, ugotovimo velikost okna brskalnika in
druge osnovne informacije o brskalniku.
Čeprav uradno standard za to ne obstaja, večina brskalnikov implementira nekaj skupnih
lastnosti:
window
document
location
history
innerWidth, innerHeight
pageX, pageY
scrollTop, scrollLeft
open(), close()
navigator
2.1.5 JavaScript
Potreba po interaktivnosti spletnih straneh je pripeljala do razvoja jezika, ki omogoča
nadzor nad dokumentom in njegovo spreminjanje. JavaScript je razvilo podjetje Netscape,
kasneje pa je bil pri organizaciji Ecma international standardiziran kot ECMAScript oz.
ECMA-262.
Realno-časovne spletne aplikacije 20
JavaScript je prototipno objektno usmerjen jezik, je šibko tipiziran jezik, kar pomeni, da
spremenljivkam ni potrebno določiti tipa spremenljivke, zraven tega podpira funkcije
višjega razreda in zaprtja, zaradi tega ga lahko smatramo tudi kot funkcijski jezik. Je
interpretiran jezik, kar mu doda še večjo fleksibilnost in razširljivost. Vse je objekt, tudi
osnovni tipi se pretvorijo v objekt, kadar jih uporabimo tako. Vedno delamo z referencami,
zato lahko med izvajanjem programa spreminjamo, dodajamo in odstranjujemo metode,
funkcije in vrednosti objektov, funkcij in literatov. Funkcijam lahko dinamično
spreminjamo kontekst kjer se izvajajo, kar pomeni večjo ponovno uporabo kode.
JavaScript je najbolj podprt in razširjen jezik, podpira ga skoraj vsak brskalnik, saj se tam
tudi največ uporablja, čeprav v zadnjem času trend uporabe JavaScripta skokovito narašča
tudi na strežniški strani.
2.1.6 AJAX
AJAX pomeni asinhron JavaScript in XML. Ne gre za novo tehnologijo, ampak za novo
tehniko razvoja spletnih aplikacij, ki združuje medsebojno neodvisne tehnologije za
gradnjo interaktivnih spletnih aplikacij in sicer (X)HTML, CSS, DOM, JavaScript, ter
XMLHttpRequest. Posebnost te tehnike je, da lahko spletne aplikacije pridobijo podatke iz
strežnika asinhrono: ob spremembi dela strani ni več potrebno ponovno nalagati celotne
strani, AJAX omogoča, da se s strežnika v ozadju ponovno naloži le spremenjen del strani.
S pomočjo prej naštetih tehnologij se lahko tako pridobljena vsebina prikaže na spletni
strani [1].
2.1.6.1 Objekt XMLHttpRequest
S pomočjo tega objekta v brskalniku, lahko z JavaScript-om ustvarjamo asinhrone zahteve
na strežniku preko HTTP protokola. Objekt podpira različne zahteva HTTP (GET,
POST,...), in branje odgovora. Omogoča tudi vmesno preverjanje statusa in napake
zahteve. Pomembno pri tem je, da se to dogaja asinhrono, tako se lahko glavna
dogodkovna zanka v brskalniku izvaja nemoteno, spletna aplikacija pa ne daje znakov
neodzivnosti.
Realno-časovne spletne aplikacije 21
Objekt podpirajo sodobni spletni brskalniki, podprt pa je tudi v starejših verzijah Internet
Explorer-ja, vendar preko ActiveX objekta. Danes za te razlike poskrbijo knjižnice
JavaScript, tako razvijalcu ni potrebno skrbeti za njih [21, 22]. Nekaj najbolj uporabljenih
lastnosti objekta XMLHttpRequest je opisanih v spodnji tabeli (Tabela 1), naslednja tabela
(Tabela 2), pa vsebuje nekaj najpogosteje uporabljenih metod tega objekta.
Lastnost Opis
onreadystatechange Dogodek, ki se sproži ob spremembi stanja zahteve.
Dogodek v stanju interaktivno se lahko sproži večkrat.
readyState Stanje zahteve:
0 - zahteva ni inicializirana
1 - zahteva se nalaga
2 - zahteva je naložena
3 - zahteva je interaktivna
4 - zahteva je končana
responseText Odgovor strežnika predstavljen kot niz
responseXML Odgovor strežnika predstavljen kot DOM drevo
status Statusna koda odgovora
statusText Tekstovna predstavitev statusa odgovora Tabela 1: Najbolj uporabljene lastnosti objekta XMLHttpRequest
Metoda Opis
abort() Prekinitev trenutne zahteve.
getResponseHeader(name) Vrne vsebino določene glave.
open(method, URL, async, user,
password)
Vzpostavi povezavo s strežnikom. Metode so lahko
veljavne HTTP metode
send(body) Pošlje zahtevo. Opcijsko se pošlje tudi sporočilo
zahteve.
setRequestHeader(name, value) Doda poljubno HTTP glavo k zahtevi. Tabela 2: Najbolj uporabljene metode objekta XMLHttpRequest
2.1.6.2 Zahteva AJAX
Preden ustvarimo zahtevo AJAX, moramo najprej ustvariti objekt XMLHttpRequest.
Ker gre za asinhrono zahtevo, moramo določiti povratni klic (angl. callback), ki se izvede
ob spremembi stanja zahteve. Najpogosteje se preverja stanje (readyState) 4 - končano.
Kadar je zahteva v tem stanju, je zahteva končana, in v lastnosti responseText lahko
najdemo popolni odgovor strežnika. V kolikor je odgovor veljaven XML dokument, je v
lastnosti responseXML referenca na DOM drevo dokumenta.
Realno-časovne spletne aplikacije 22
Nato vzpostavimo povezavo s strežnikom s klicem metode open. Metoda sprejme kot prvi
parameter metodo HTTP, ki jo želimo klicati (GET, POST,...), drugi parameter je URL
vira, ki ga zahtevamo, in tretji parameter je zastavica, kjer določimo, da gre za asinhrono
zahtevo.
Na koncu želimo zahtevo še poslati. To naredimo z metodo send. V kolikor gre za zahtevo
POST, lahko kot parameter dodamo sporočilo zahteve [22]. Primer klica AJAX:
var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if (xhr.readyState === 4) {
alert("Odgovor: " + xhr.responseText);
}
};
xhr.open("GET", "/stanje", true);
xhr.send(null);
Izvorna koda 5: Primer klica AJAX
2.1.7 Brskalniki
Brskalniki imajo pri razvoju spleta zelo pomembno vlogo. Brez podpore novim
tehnologijam in inovacijam bi še danes obiskovali spletne strani z belim ozadjem in
oblikovanjem, ki si ga danes enostavno ne znamo več niti predstavljati. Brskalniki so tisti,
ki omogočajo napredek spleta in novih vrst aplikacij, ki do nedavnega na spletu niso bile
možne. Dober primer tega je podpora AJAX-a v najbolj priljubljenih brskalnik nekaj let
nazaj, danes pa opažamo podobno situacijo, kjer želijo brskalniki podpreti nove
tehnologije gibanja HTML 5.
V sodobnih brskalnikih lahko danes ugotovimo lokacijo obiskovalca, kar je še posebej
zanimivo pri mobilnih napravah. Na spletno stran lahko naložimo datoteko s preprostim
povleci in spusti, kar smo do nedavnega poznali samo pri namizni aplikacijah. Dalje
vzpostavimo lahko realno-časovno povezavo s strežnikom, kar nam omogoča nove vrste
aplikacij.
Realno-časovne spletne aplikacije 23
3 REALNO-ČASOVNI SPLET
S selitvijo namiznih aplikacij na splet se je pojavila potreba po novem tipu aplikacij, ki
omogoča realno-časovni prenos podatkov znotraj spletne aplikacije. To pomeni, da
uporabnik aplikacije vidi podatke v skoraj tistem trenutku, ko nastanejo, ne glede na to, ali
so ti podatki nastali na strežniku na drugi strani sveta. Največja zakasnitev nastane pri
pošiljanju podatkov po internetu.
V teh primerih je govora o spletne aplikacijskem modelu Comet ali Reverse-Ajax.
Primeri takšnih aplikacij so spremljanje delnic, klepetalnica, spremljanje napredka opravila
na strežniku ali igranje več igralske igre preko spleta. Skupna značilnost teh aplikacij je, da
želimo v vsakem trenutno vedeti zadnje stanje, ki ga ima strežnik. Le tako lahko
pravočasno reagiramo in dosežemo najboljšo uporabniško izkušnjo in rezultate [4, 15].
3.1 Tehnologije in tehnike
Za potrebe realno-časovne komunikacije v spletnih aplikacijah se je razvilo mnogo tehnik,
kako zagotoviti dostavljanje podatkov v brskalnik preko obstoječih tehnologij. Nekatere so
preproste, druge so zahtevne, tretje pa enostavno preveč kompleksne, da bi se uporabljale.
Vendar vse služijo namenu dostavljanja sporočil v brskalnik. Tako nekatere rešujejo težave
s posredovalnimi (proxy) strežniki, druge možne zgolj v določenih brskalnikih [11].
V osnovi se tehnike za izdelavo spletnih realno-časovnih aplikacij delijo na povpraševalne
(angl. polling), pretočne (angl. streaming) in novodobne.
Značilno za povpraševalne tehnike je, da lahko ena zahteva pošlje samo en dogodek, nato
pa se konča. Takoj po končanju zahteve se naredi nova. Postopek se lahko ponavlja, kar je
odvisno od aplikacije.
Pretočne tehnike omogočajo prenos več dogodkov znotraj ene zahteve. Podatki se pošiljajo
zaporedoma, tako kot se pojavijo na strežniku. Težave s to tehniko se pojavijo na
Realno-časovne spletne aplikacije 24
strežniškem delu, saj zahtevajo dlje časa odprte povezave z odjemalcem, kar pa današnji
spletni strežnike težko podpirajo. Težave se pojavijo tudi na poti do odjemalca, npr, če je
nekje na poti posredovalniški strežnik, saj lahko ti podatke pomnijo (angl. caching) in jih
odjemalcu ne posredujejo v realnem času. Prav tako se težave lahko pojavijo na odjemalcu,
npr. spuščanje spomina (angl. memory leaks), pa tudi podpora tem tehnikam v brskalnikih
je še zelo omejena ali je sploh ni.
Novodobne tehnike realno-časovnega prenosa podatkov v brskalnik je začela razvijati
organizacija W3C s pomočjo IETF. V nastajanju sta nova standarda WebSockets in Server-
sent events. Čeprav sta v osnovi podobna, se razlikujeta v podrobnostih. WebSockets
omogoča obojestransko komunikacijo med strežnikom in odjemalcem, podpiral bi naj tudi
binarni prenos podatkov, med tem ko Server-sent Events temelji na dogodkih na strežniku
in pošiljanju le teh odjemalcu.
3.1.1 Povpraševanje (polling)
Povpraševanje (polling) je najpreprostejša tehnika, za zahtevanje podatkov s strežnika.
Dejansko ne gre za realno-časovno komunikacijo. Ta tehnika se je uporabljala že preden se
je govorilo o Cometu.
Gre za preprosto HTTP zahtevo, ki je podana na določen interval. Strežnik odgovarja z
novimi podatki, če so ti na voljo (Slika 1). Za zahtevo se lahko uporabljata znački script ali
iframe ali objekt XMLHttpRequest. Ta tehnika je zelo potratna in neučinkovita glede na
zahtevnost procesiranja tako na odjemalcu kot strežniku in rezultat, ki ga prinese.
Recimo, da ima aplikacija, ki uporablja to tehniko, 1000 hkratnih obiskovalcev, ki
zahtevajo stanje vsako sekundo. To pomeni 1000 zahtev na strežnik vsako sekundo, ki so v
najslabšem primeru popolnoma nepotrebne, kar je dodatna nepotrebna obremenitev za
strežnik in procesiranje za odjemalce.
Ta tehnika se lahko uporablja v primerih, kjer ni kritično, daimamo na odjemalcu zadnjeg
stanje in kadar aplikacija nima velikega števila hkratnih uporabnikov.
Realno-časovne spletne aplikacije 25
Slika 1: Povpraševanje (polling)
3.1.2 Hkratni prenos (Piggybacking)
Hkratni prenos (angl. piggybacking) je tehnika, ki omogoča prenos podatkov v odgovoru
zahteve na neko drugo akcijo (Slika 2). Na primer: uporabnik A shrani sporočilo 1, za kar
se pošlje (AJAX) zahteva na strežnik. Prav tako je pred tem drugi uporabnik spremenil
sporočilo 2, o katerem še uporabnik A ni bil obveščen. Strežnik to ugotovi in pošlje
podatke o sporočilu 2 uporabniku A v odgovoru na akcijo za shranjevanje sporočila 1.
Ta tehnika omogoča pošiljanje podatkov odjemalcu brez eksplicitne zahteve. Seveda mora
biti odjemalec sposoben sprejeti te podatke in jih pravilno obdelati. Običajno se uporablja
skupaj s povpraševalno tehniko. Skupaj optimizirata potratnost virov in zmanjšata
obremenitev strežnika. Vendar, da se to doseže je potrebno implementirati sinhronizacijo
med tehnikama. Resetira se časovnik, kdaj se naredi povpraševalna zahteva glede na to,
kdaj so prišli zadnji podatki preko te tehnike.
Realno-časovne spletne aplikacije 26
Slika 2: Hkratni prenos (Piggybacking)
3.1.3 Dolgo povpraševanje (long-polling)
Tehnika dolgega povpraševanja (angl. long-polling) tehnika je sicer podobna
povpraševalni tehniki, vendar je med njima ena pomembna razlika. Strežnik ne odgovori
odjemalcu, dokler mu nima kaj poslati ali dokler ne poteče časovna omejitev. To je
trenutno najbolj razširjena tehnika, saj jo je enostavno implementirati, in trenutno velja kot
najbolj efektivna glede na podprtost v brskalnikih, težavnost implementacije ter
obremenitev na strežniku (Slika 3).
Zaradi težav, ki nastanejo z dolgo trajajočo zahtevo, je potrebno uvesti nekaj dodatnih
tehnik za zanesljivo komunikacijo. Ker je bil v osnovi HTTP protokol namenjen načinu
zahteva-odgovor, imajo nekateri odjemalci in posredovalni strežniki namenoma ali ne
namenoma, težave z dolgo odprtimi povezavami. Nekateri posredovalni strežniki prekinejo
povezavo po določenem času, npr. 60 sekundah. Strežniki rešujejo ta problem tako, da
povezavo prekinejo sami pred tem časom. Po navadi je ta čas ročno določen na strežniku,
ali pa se določi s testi povezave za vsakega uporabnika posebej.
Realno-časovne spletne aplikacije 27
Slika 3: Dolgo povpraševanje (long-polling)
3.1.4 Povpraševanje s povratnim klicem (callback-polling)
Povpraševanje s povratnim klicem (angl. calback-polling) je tehnika podobna prej opisani
tehniki dolgega povpraševanja. Dodatno omogoča komunikacijo čez različne domene s
pomočjo JSONP tehnike. JSONP omogoča enostavno pridobivanje podatkov iz poljubne
domene s pomočjo povratnega klica funkcije, ki kot parameter prejme podatke. Po navadi
so ti podatki v formatu JSON, in jih je enostavno obdelati z JavaScript-om.
Tudi za to tehniko veljajo iste omejitve kot za tehniko dolgega povpraševanja, dodatno se
pojavljajo še zapleti zaradi obravnavanja napak pri nalaganju podatkov. Ta tehnika se
uporablja v kolikor želimo naložiti podatke iz druge domene.
3.1.5 Pretok Iframe (Iframe stremaing)
Iframe pretok (angl. Iframe streaming) omogoča prejemanje več dogodkov znotraj ene
zahteve. Tako kot pri prejšnjih tehnikah tudi pri tej veljajo enake omejitve glede
Realno-časovne spletne aplikacije 28
posredovalnih strežnikov in brskalnikov. Strežnik pošilja podatke znotraj značke script, ki
se izvede takoj v brskalniku.
Slabost tehnike je, da se v brskalniku nabira zgodovina, ki jo ustvarja značka iframe. Poleg
tega brskalnik vedno prikazuje stanje 'nalagam', kadar je v uporabi ta tehnika. Težave
lahko povzroči tudi posredovalni strežnik, ki lahko zadrži (angl. caching) delni odgovor
strežnika, dokler ne preseže določene dolžine odgovora. To težavo odpravljajo tako, da se
pri tej tehniki pošlje en kB naključnega besedila odjemalcu , preden se začnejo pošiljati
podatki. Občasno je potrebno poskrbeti za ponastavitev okolja, ki ga lahko prinese
puščanje spomina [11].
3.1.6 Pretok Htmlfile (Htmlfile streaming)
Uporaba tehnike Iframe v brskalniku Internet Explorer povzroča dodatne nevšečnosti in
sicer indikator nalaganja strani in zvok klikanja, ko se iframe naloži. Da bi se temu izognili
so razvili tehniko Htmlfile, ki ta problema rešuje z razširitvijo objekta ActiveX, ki simulira
tehniko Iframe. Tehnika Htmlfile je podprta samo v brskalniku Internet Explorer [11].
3.1.7 Pretok XHR (XHR streaming)
Tehnika pretoka XHR je podobna rtehniki Iframe, vendar ne povzroča spreminjanja
zgodovine in zvoka klikanja. Za zahtevo na strežnik se uporablja objekt XHR in stanje
zahteve '3 - interaktivna'. Pri tej tehniki strežnik pošilja podatke v poljubnem protokolu,
edini pogoj je, da ga odjemalec razume.
Tehnika uporablja stanje 3 zahteve XHR, kjer je na voljo delni odgovor strežnika.
Odjemalec tako vsakokrat, ko se zgodi dogodek spremembe stanja, preveri, kaj je novega.
Odgovor strežnika se vsakokrat povečuje in z veliko podatki zaseda precej pomnilnika.
Zato je potrebno pri tej tehniki občasno prekiniti povezavo in ustvariti novo, da se ponilnik
sprosti. Kljub temu veljajo nekatere omejitve, npr. težava s posredovalnimi strežniki [11].
Realno-časovne spletne aplikacije 29
Slika 4: Pretok (streaming)
3.1.8 Večdelni pretok (Multipart streaming)
Tehnika večdelnega pretoka (angl. multipart streaming) omogoča pošiljanje več
dokumentov v enem odgovoru. Prav tako se lahko uporabi za pošiljanje več podatkov v eni
zahtevi do odjemalca. Za to se uporabi tip vsebine (angl. content type) “multipart/x-mixed-
replace”, ki pove brskalniku naj zamenja vsebino.
Zaradi težav, ki jih prinaša HTTP protokol in slabe podpore brskalnikov, se ta tehnika
skoraj ne uporablja [8, 12]. Primer večdelnega formata MIME:
Realno-časovne spletne aplikacije 30
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="time"
This is a message with multiple parts in MIME format.
--time
Content-Type: text/plain
dogodek1
--time
Content-Type: text/plain
dogodek2
--time--
Izvorna koda 6: Primer večdelnega formata MIME sporočila
3.1.9 Razširitve brskalnika
Brskalniki nudijo razširitve, ki brskalniku dodajo funkcionalnosti, ena izmed njih je recimo
gola povezava TCP preko razširitev.
Aplikacija inicializira razširitev, ta pa vzpostavi TCP povezavo s strežnikom, ki pošilja
podatke po poljubnem protokolu razširitvi. Razširitve omogočajo komuniciranje z
gostiteljskim okoljem (brskalnikom) s pomočjo JavaScripta in naprej do DOM-a. Tako
lahko podatke s strežnika prikažemo uporabniku v aplikaciji.
Dobra stvar pri tem je, da imamo popolni nadzor nad povezavo in protokolom ter da lahko
komunikacija poteka v obe smeri, vendar moramo zagotoviti robustno povezavo, ki se bo
znala ponovno vzpostaviti ob prekinitvi.
Slaba strani razširitev je, da izdelovalec spletne aplikacije nima nadzora nad tem, ali ima
obiskovalec nameščeno zahtevano razširitev. Čeprav lahko zaznamo ali je razširitev
nameščena in celo pozovemo uporabnika, da namesti razširitev, se ne moremo zanašati, da
bo to tudi storil. V kolikor spletna aplikacija teče na odjemalcih v nadzorovanem okolju, pa
lahko sprejmemo kompromis, in naredimo rešitev zgolj na določeni razširitvi. Najbolj
razširjene razširitve, ki podpirajo TCP povezavo, so:
Java - preko razreda java.net.Socket
Flash - preko razreda XMLSocket SilverLight - preko razreda System.Net.Sockets.Socket
Realno-časovne spletne aplikacije 31
3.1.10 Spletne vtičnice (WebSockets)
Websockets je standard v nastajanju, ki omogoča realno-časovno obojestransko
komunikacijo med strežnikom in odjemalcem. Glavna prednost Websockets je, da se
povezava vzpostavi preko navadne HTTP zahteve in se med komunikacijo s strežnikom
nadgradi v websockets povezavo. Tako se izognemo problemu, kadar so blokirana ostala
vrata razen vrat 80, kjer poteka komunikacija preko HTTP.
Podobno kot TCP povezava, tudi WebSockets omogoča vzpostavljanje komunikacije s
poljubnim strežnikom. WebSockets uporablja svoj protokol ki je tekstovni ali binarni. To
pomeni precejšnjo prednost, saj je žirije v primeru TCP povezave in WebSockets protokola
v primerjavi s HTTP protokolom precej manj.
Trenutno ga podpira manjšina brskalnikov, nekateri pa imajo podporo privzeto izklopljeno
zaradi skrbi okoli varnosti in spreminjajočega se protokola [4].
Prav tako šepa podpora na najbolj razširjenih spletnih strežnikih. Vendar, ker WebSockets
ponuja nove vrste aplikacij, se razvijajo tudi novi strežniki, ki te povezave omogočajo [20].
3.1.11 Dogodki poslani iz strežnika (Server-sent events)
Alternativa WebSockets je razvijajoči se standard server-sent events. Ta omogoča
prejemanje dogodkov s strežnika in temelji na protokolu HTTP. Podobno kot pri pretočnih
tehnikah, strežnik pošilja nize podatkov, ki jih odjemalec sprocesira. Dodatno lahko
strežnik pošlje identifikator (id) za vsak dogodek. Tako odjemalec v primeru prekinitve
povezave ve, kateri dogodek je nazadnje prejel, in ob ponovni HTTP zahtevi pošlje glavo
“Last-Event-ID”, ki je identifikator zadnjega dogodka. Tako strežnik ve, katere dogodke
mora poslati temu odjemalcu, ne da bi se kateri izmed njih izgubil.
Trenutno je ta tehnika podprta v zelo malem deležu brskalnikov, ostali niti ne kažejo
interesa, da bi jo podprli.
Realno-časovne spletne aplikacije 32
Primer odjemalca:
var source = new EventSource("/dogodki");
source.onmessage = function(e){
var data = e.data;
};
// zapremo povezavo kadar ne želimo več prejemati dogodkov
source.close();
Izvorna koda 7: Primer Server-sent events programčka
Strežnik, pošilja dogodke v dolgo trajajoči zahtevi.
id: 1
data: dogodek 1
id: 2
data: dogodek 2
Izvorna koda 8: Server-sent events dogodki
3.1.12 Stanje danes
Iz opisanih tehnik vidimo, da je razvoj realno-časovnih spletnih aplikacij danes lahko
precej zapleten. Poleg ukvarjanja z različno podporo tehnik v različnih brskalnikih se je
potrebno ukvarjati tudi z zanesljivostjo dostavljanja sporočil do odjemalca.
Poleg tega je potrebno omeniti problem C10K, o katerem je pisal Dan Kegel [23]. Govori o
številu odprtih povezav na strežnik pri takšni aplikaciji, ki zahteva neprestano odprto
povezavo. Realno-časovne spletne aplikacije spadajo mednje. S standardnim načinom
streženja zahtevam, kjer se za vsako zahtevo ustvari nova nit ali proces, strežnik ne zmore
velikega števila hkratnih povezav. Omejitve so tako na strani operacijskega sistema kot
tudi pri tehničnih zmogljivosti strežnika, saj nova nit ali proces zavzameta dodatni
procesorski čas, spomin, ter ročico (angl. file handle). Kegel predlaga uporabo
neblokiranih (asinhronih) načinov komunikacije, kjer lahko ena nit oz. proces streže več
povezavam. Pojavljati so se začeli spletni strežniki, ki sledijo temu principu in zmorejo
streči večjemu številu zahtev z manjšo porabo strežniških virov. Primeri takšnih strežnikov
so nginx, lighttpd, Tornado ter node.js [2].
Realno-časovne spletne aplikacije 33
3.2 Dostavljanje sporočil preko kanalov
Opisane tehnike omogočajo dostavljanje podatkov brskalniku. Kadar se podatki med seboj
ne razlikujejo, lahko pride do problemov. Mnogo realnih aplikacij zahteva, da se podatki
dostavijo samo določenim uporabnikom, lahko pa se uporabniki odločijo za dodatne
podatke med uporabo aplikacije.
Iz teh razlogov so razvili koncept objavi/naroči (angl. publish/subscribe, krajše pub/sub),
ki odjemalcem omogoča objavljanje in naročanje na določen vir preko ene končne točke
(angl. endpoint).
Kanal si lahko predstavljamo podobno kot mapo v datotečnem sistemu. V njem se nahajajo
sporočila, ki imajo skupne lastnosti. Kanale lahko organiziramo v hierarhije. Vsak
naročnik se lahko naroči na poljuben kanal, pri čemer lahko strežnik za določeni kanal
zahteva avtentikacijo ali drug mehanizem za odobritev naročnine [24].
Slika 5: Model objavi naroči
Realno-časovne spletne aplikacije 34
3.2.1 Protokol Bayeux
Bayeux je postal de facto standard aplikacije narejene s tehnologijami za Comet. Je
protokol namenjen izmenjavi sporočil med odjemalcem in strežnikom s pomočjo kanalov.
Po specifikacijah je zelo splošen, vendar ima tudi referenčno implementacijo poznano pod
imenom CometD. Koda implementacije je na voljo v več strežniških jezikih.
V osnovi omogoča pošiljanje sporočil preko več kanalov samo z eno HTTP povezavo, s
čimer se izognemo omejitvi hkratnega števila odprtih povezav na isti domeni, ki jo
določajo brskalniki.
Poimenovanje kanalov je precej poljubno. Izhaja iz datotečnega sistema Unix, na primer
“/klepet/soba1”. Tak stil poimenovanja omogoča organizacijo kanalov v hierarhijo, prav
tako omogoča iskanje kanalov s pomočjo nadomestnega znaka (angl. wildcard). Tako bi se
na primer na vsa sporočila vseh kanalov prijavili s “/klepet/*”. Ker je hierarhija lahko
poljubno globoka, se lahko naročimo na pod-kanale z dvojnim nadomestnim znakom, na
primer “/klepet/javni/**”. Potrebno je še omeniti, da tako kot Unix poti so tudi imena
kanalov občutljiva na velike in male črke, “/klepet” in “/Klepet” torej nista isti kanal.
Protokol uporablja format JSON za prenos podatkov. Sporočilo JSON običajno vsebuje:
podatke sporočila, ki je lahko poljuben JSON,
kanal v katerega je sporočilo poslano,
unikatni id odjemalca in
unikatni id, ki označuje sporočilo samo, po navadi je to preprosti števec.
Primer sporočila:
[{
"data": {
"tekst": "Pozdravljeni v klepetalnici!",
"avtor": "Matjaž"
},
"channel": "/klepet/pozdrav",
"clientld": "chmd0j3nu",
"id": "4"
}]
Izvorna koda 9: Primer Bayeux sporočila v klepetalnici
Realno-časovne spletne aplikacije 35
Iz sporočila lahko vidimo, da je format dokaj preprost. Vsebuje lahko enega ali več
sporočil, ki vsebujejo zgoraj naštete atribute. Strežnik na zgornje sporočilo odgovor na
naslednji način.
[{
"id": "4",
"successful": true,
"channel": "/klepet/pozdrav"
}, {
"id": "4",
"channel": "/klepet/pozdrav",
"data": {
"tekst": "Pozdravljeni v klepetalnici!",
"avtor": "Matjaž"
}
}]
Izvorna koda 10: Odgovor strežnika na sporočilo
Ponovno gre za preprosti format, kjer izvemo, ali je bilo sporočilo uspešno objavljeno na
kanalu. V tem primeru je strežnik poslal to isto sporočilo nazaj, saj je odjemalec prijavljen
na ta kanal. V odgovoru še lahko opazimo, da je lahko v enem odgovoru več sporočil.
Protokol definira tudi meta kanale. Kanali, ki se začnejo z /meta, so namenjeni interni
komunikaciji v protokolu, kot so pri sporazumevanju (angl. handshaking) med odjemalcem
in strežnikom, naročanju na kanale itd.
[{
"channel": "/meta/connect",
"connectionType": "long-polling",
"clientld": "chmd0j3nu",
"id": "6"
}]
Izvorna koda 11: Primer vzpostavljanja povezave
Vsi atributi so nam že znani, razen connectionType, ki določa tip povezave, ki jo
odjemalec podpira. Kot vidimo je ta tip dolgo povpraševanje, ki smo ga že obravnavali.
Protokol določa, da mora odjemalec podpirati dolgo povpraševanje in povpraševanje s
povratnim klicem, kot opcijska pa omenja pretok iframe, ter protokol Flash binary.
Poleg kanala /meta/connect, protokol določa tudi kanal /meta/handshake, preko katerega
odjemalec in strežnik najprej vzpostavita komunikacijo in se dogovorita za najprimernejši
tip povezave.
Realno-časovne spletne aplikacije 36
Kadar se odjemalec poveže na strežnik, najprej pošlje sledeče sporočilo:
[{
"version": "1.0",
"minimumVersion": "0.9",
"channel": "/meta/handshake",
"id": "0",
"ext": {
"json-comment-filtered": true
},
"supportedConnectionTypes": [
"long-polling",
"callback-polling"
]
}]
Izvorna koda 12: Sporočilo ob povezavi na strežnik
Strežnik odgovori, katero verzijo uporablja in katere tipe povezave podpira. Hkrati
odjemalcu priredi unikatni id, s katerim ga identificira, in ponudi nasvet, kako se povezati.
V primeru strežnik predlaga povezavo do 4 minute (240.000 milisekund) brez intervala
med ponovnim povezovanjem:
[{
"id": "0",
"minimumVersion": "0.9",
"supportedConnectionTypes": [
"long-polling",
"callback-polling"
],
"successful": true,
"channel": "/meta/handshake",
"advice": {
"reconnect": "retry",
"interval": 0,
"timeout": 240000
},
"clientld": "chmd0j3nu",
"version": "1.0"
]}
Izvorna koda 13: Predlog načina povezave strežnika
Odjemalec nato odgovori z drugim sporočilom na kanal /meta/handshake, kjer obvesti
strežnik o izbranem tipu povezave, ki ga je ponudil strežnik in ga podpira odjemalec.
Realno-časovne spletne aplikacije 37
Sporočilu doda svoj unikatni id, da strežnik ve, za kateri odjemalec gre.
Sporočilo v katerem odjemalec obvesti strežnik o izbranem tipu povezave:
[{
"channel": "/meta/connect",
"clientld": "chmd0j3nu",
"connectionType": "long-polling",
"id": "1"
}]
Izvorna koda 14: Izbrani način povezave odjemalca
Strežnik na to sporočilo odgovori z uspehom ali napako, v kolikor ni mogel sprejeti
odjemalčeve povezave:
[{
"id": "1",
"successful": true,
"advice": {
"reconnect": "retry",
"interval": 0,
"timeout": 240000
},
"channel": "/meta/connect"
}]
Izvorna koda 15: Potrditev strežnika ob povezavi
Strežnik enostavno ponovi predlog povezave in označi ali je bilo rokovanje uspešno, kar
določa lastnost successful.
Poleg meta kanalov protokol definira tudi storitvene kanale, ki se nahajajo na /service/**.
Storitveni kanali služijo komunikaciji tipa zahteva/odgovor. Sporočila objavljena na
servisnih kanalih so dostavljena samo lokalnim naročnikom, ne tudi oddaljenim. Naročniki
lahko na zahtevo reagirajo z objavo na isti kanal, vendar bo to sporočilo dostavljeno samo
odjemalcu, ki je poslal izvorno sporočilo. S takšnim mehanizmom zagotovimo
komunikacijo zahteva/odgovor [3, 17].
Realno-časovne spletne aplikacije 38
4 UPORABA REALNO-ČASOVNIH TEHNOLOGIJ
Tehnologije, ki omogočajo realno-časovne aplikacije, so še v nastajanju in v postopku
standardizacije, vendar obstajajo različne tehnike, s katerimi lahko dosežemo pošiljanje
sporočil v brskalnike, ki so danes najbolj razširjeni. Problem teh tehnik je, da izrabljajo
obstoječe tehnologije, ki temu niso namenjene zaradi česar prihaja do različnih
komplikacij.
V naši aplikaciji bomo uporabili WebSockets, in knjižnico Faye. WebSockets je že v
osnovi namenjen obojestranski realno-časovni komunikaciji in ob pošiljanju sporočil
predstavlja kar se da najmanj dodatnega procesiranja ter prenosa podatkov. Knjižnica Faye
omogoča hitro in enostavno grajenje realno-časovnih aplikacij po principu objavi/naroči.
4.1 WebSockets
WebSockets je razdeljen na API, ki definira programski vmesnik, ki predpisuje, kako
ustvarimo povezavo in upravljamo komunikacijo, ter protokol, ki določa način
komunikacije in okvirjanje sporočil. WebSockets podpirajo najsodobnejši brskalniki [20].
Realno-časovne spletne aplikacije 39
4.1.1 API
Po standardu WebSockets [20] je API definiran s pomočjo IDL:
[Constructor(in DOMString url, in optional DOMString
protocols)]
[Constructor(in DOMString url, in optional DOMString[]
protocols)]
interface WebSocket {
readonly attribute DOMString url;
const unsigned short CONNECTING = 0;
const unsigned short OPEN = 1;
const unsigned short CLOSING = 2;
const unsigned short CLOSED = 3;
readonly attribute unsigned short readyState;
readonly attribute unsigned long bufferedAmount;
attribute Function onopen;
attribute Function onmessage;
attribute Function onerror;
attribute Function onclose;
readonly attribute DOMString protocol;
void send(in DOMString data);
void close();
};
WebSocket implements EventTarget;
Izvorna koda 16: IDL definicija WebSockets API-ja
Iz definicije IDL lahko razberemo da obstajata dva konstruktorja, ki oba sprejmeta dva
parametra. Pri obeh je prvi parameter URL naslov, kjer se WebSockets strežnik nahaja,
drugi parameter je opcijski in predstavlja pod-protokol protokola WebSockets. Lahko je
niz ali polje nizov, ki jih strežnik podpira. Povezava se vzpostavi takoj ob klicu
konstruktorja.
API definira dogodke za prestrezanje sporočil strežnika. Tako z dogodkom onmessage
prejemamo podatke iz strežnika. Atributu onmessage priredimo povratni klic, ki kot
parameter sprejme objekt event, kateri vsebuje atribut data. Prestrezamo lahko tudi
dogodke ko je povezava odprta, zaprta in ko pride do napake pri povezavi. Za pošiljanje
podatkov uporabimo metodo send, ki sprejme parameter data, ki je običajno serializiran
niz JSON. Povezavo prekinemo s klicem metode close.
Realno-časovne spletne aplikacije 40
4.1.2 Protokol
Protokol ima dva dela: rokovanje in prenos podatkov. Rokovanje omogoča predstavitev
odjemalca strežniku, slednjega pa omejuje pri sprejemanju povezav odjemalcev glede na
mesto, od koder se povezujejo. Tako lahko strežnik na podlagi glave Sec-WebSocket-
Origin preveri mesto odjemalca. Pri rokovanju se lahko določi pod-protokol, ki ga bosta za
komunikacijo uporabljala strežnik in odjemalec.
Rokovanje odjemalca:
GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Izvorna koda 17: WebSockets protokol: rokovanje odjemalca
Strežnik odgovori:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Nonce: AQIDBAUGBwgJCgsMDQ4PEC==
Sec-WebSocket-Protocol: chat
Izvorna koda 18: WebSockets protokol: rokovanje strežnika
Po uspešnem rokovanju se lahko začne prenos podatkov med strežnikom in odjemalcem.
Oba lahko poljubno pošiljata podatke drugemu in jih enako prejemata. Podatki se
oblikujejo v sporočila. Protokol WebSockets z okvirjem določa za kakšen tip sporočila gre
in njegovo dolžino. Obstajajo tri vrste sporočil: tekstovna, binarna in kontrolna. Tekstovna
sporočila podpirajo prenos vseh znakov kodne tabele UTF, medtem ko binarna sporočila
lahko vsebujejo poljubne bajte. Kontrolni tip sporočila omogoča protokolu nemoteno
komunikacijo. Protokol definira tri kontrolne okvire: close, ping in pong [19].
4.2 Knjižnice za poenostavljeno uporabo tehnologij in tehnik
Knjižnice omogočajo poenoten programski vmesnik za uporabo različnih tehnologij in
tehnik, ki jih omogoča odjemalec. Podobno kot knjižnica jQuery, ki omogoča enotno delo
Realno-časovne spletne aplikacije 41
z modelom DOM, so se razvile tudi knjižnice za delo s tehnikami za realno-časovno
komunikacijo.
S pomočjo teh knjižnic lahko z enotnim programskim vmesnikom vzpostavimo povezavo
do strežnika, ne da bi se ukvarjali še s tem, katero tehniko bomo uporabili. Za omenjene
težave poskrbi knjižnica, nam pa je na voljo enostavna uporaba knjižnice za komunikacijo.
Ena izmed takšnih je knjižnica Faye.
4.2.1 Predstavitev knjižnice Faye
Faye je knjižnica za enostavno uporabo objavi/naroči sistema za obveščanje. Temelji na
protokolu Bayeux. Omogoča grajenje strežnikov tipa objavi/naroči s pomočjo Node.js in
Rack. Prav tako podpira odjemalce za Node in Ruby programe, ter podporo za brskalnike
[6].
4.2.1.1 Arhitektura
Arhitektura knjižnice Faye je zastavljena modularno in uporablja znane programske vzorce
(angl. design patterns). Dobra značilnost je prav tako, da je mnogo modulov istih na
strežniku in odjemalcu.
Seznam razredov, ki uporabljajo programske vzorce:
Deferrable
Observable
Extensible
Timeouts
Logging
Set
Realno-časovne spletne aplikacije 42
Poleg vzorcev je arhitektura razredov knjižnice Faye, logičen potek komunikacije strežnik-
odjemalec s pomočjo kanalov. Seznam glavnih razredov knjižnice Faye:
Server
Connection
Client
Transport
o HttpTransport
o LocalTransport - in process
o WebSocket
o XHR - long polling
o JSONP - callback polling
Channel
Subscription
S to arhitekturo lahko opišemo komunikacijo na sledeč nači: strežnik nudi povezavo
odjemalcem, ki se povezujejo z različnim načinom transporta. Način transporta je lahko
interni, dolgo povraševanje, povpraševanje s povratnim klicem, ter WebSockets.
Odjemalec se lahko ob vzpostavljeni povezani naroči na kanale.
Poleg glavnih razredov Faye vsebuje tudi t.i. razrede adapter, ki implementirajo
funkcionalnosti za različne platforme. Tako vsebuje adapterja NodeAdapter, ter
RackAdapter, ki izpostavita funkcionalnost strežnika preko enotnega programskega
vmesnika ne glede na platformo, na kateri se Faye uporablja [13].
4.2.1.2 Strežnik Node.js
Strežnik služi kot centralni vmesnik sistema za obveščanje. Je glavni del, ki pošilja
sporočila odjemalcem. Podpira HTTP komunikacijo z dolgim povpraševanjem in
povpraševanjem s povratnim klicem, ter tehnike WebSockets za realno-časovno
komuniciranje. Strežnik Faye ustvarimo v okolju Node.js s pomočjo razreda
Faye.NodeAdapter. Razred sprejme kot parameter konfiguracijski objekt.
Konfiguracija vsebuje dve lastnosti:
mount, določa pot na kateri Faye strežnik odgovarja
timeout, določa časovno omejitev po kateri prekine povezavo za povpraševalno
tehniko
Realno-časovne spletne aplikacije 43
Primer strežnika, ki odgovarja na /faye poti s časovno omejitvijo 45 sekund, povezave
sprejema na vratih 80 (privzeta HTTP vrata):
var Faye = require("faye");
var bayeux = new Faye.NodeAdapter({
mount: "/faye",
timeout: 45
});
bayeux.listen(80);
Izvorna koda 19: Primer Faye Node.js strežnika
Strežnik podpira odjemalca, kateri komunicira s strežnikom znotraj procesa. Tako se
prihrani odvečno komuniciranje preko HTTP, ki je potrebno za odjemalce v brskalniku.
bayeux.getClient().publish("/email/new", {
text: "Prispela je nova pošta!",
inboxSize: 34
});
Izvorna koda 20: Objava sporočila na strežniku s pomočjo internega odjemalca
4.2.1.3 Odjemalec
Odjemalec omogoča naročanje in objavljanje sporočil. Da lahko uporabljamo odjemalca,
moramo najprej zagnati strežnik. Nato v spletno aplikacijo vključimo kodo odjemalca
Faye. Za zgornji primer strežnika se koda nahaja na naslovu http://localhost/faye.js.
Novega odjemalca naredimo s pomočjo razreda Faye.Client, ki sprejme kot parameter pot
do strežnika Faye.
var client = new Faye.Client("http://localhost/faye", {
timeout: 50
});
Izvorna koda 21: Kreiranje Faye odjemalca, s časovno omejitvijo 50 sekund
Časovna omejitev odjemalca mora biti večja kot tista na strežniku, saj moramo upoštevati
čas, ki je potreben, da strežnik dostavi sporočilo. Odjemalec transparentno podpira tudi
komunikacijo s strežnikom Faye, ki teče na drugi domeni s pomočjo tehnike povpraševanja
s povratnim klicem.
Odjemalec vsebuje metodo subscribe, ki omogoča naročanje na kanal. Tako je odjemalec
obveščen o vseh sporočilih objavljenih na tem kanalu. Metoda vrne objekt tipa
Subscription. Razred Subscription ima metodi cancel, ki prekliče naročnino na kanal in
metodo callback, ki sprejme dogodek, ki je aktiviran ob potrditvi strežnika o naročnini.
Realno-časovne spletne aplikacije 44
var subscription = client.subscribe("/pozdrav",
function(sporocilo) {
// sporočilo je JSON objekt, ki ga je poslal objavitelj
});
// dogodek ob potrditvi naročnine na strežniku
subscription.callback(function() {
console.log("Naročnina je sedaj aktivna!");
});
// preklic naročnine
subscription.cancel();
Izvorna koda 22: Primer naročnine na kanala /pozdrav
Odjemalec objavi sporočilo na kanalu s preprostim klicem metode publish. Prvi parameter
je ime kanala, drugi pa sporočilo, ki je običajno objekt JSON.
client.publish("/pozdrav", {
text: "Lep pozdrav!"
});
Izvorna koda 23: Primer objave sporočila na kanalu
4.2.1.4 Razširitve
Tako strežnik kot tudi odjemalec podpirata razširitve. Razširitve so dogodki, ki omogočajo
dodatno obdelavo prihajajočih in odhajajočih sporočil na strežniku ali odjemalcu.
Prihajajoča sporočila so tista, ki prispejo oz. so jih objavili drugi, odhajajoča pa tista, ki jih
objavljamo mi. Strežnik in odjemalec imata metodi addExtension in removeExtension.
Metodi sprejmeta kot atribut razširitveni objekt, ki lahko vsebuje metode:
incomming(message, callback), se kliče ob prihajajočih sporočilih
outgoing(message, callback), se kliče ob odhajajočih sporočilih
added(), se kliče kadar je razširitev dodana v gostitelja (strežnik oz. odjemalec)
removed(), se kliče kadar je razširitev odstranjena iz gostitelja
Parameter message je celotno sporočilo Bayeux, ki ga lahko dodatno obdelujemo in
spreminjamo. Po obdelavi je vedno potrebno poklicati funkcijo callback, ki sprejme kot
parameter obdelano sporočilo.
Realno-časovne spletne aplikacije 45
4.2.1.5 Avtentikacija
Vsaka več uporabniška aplikacija potrebuje avtentikacijo. Faye s pomočjo razširitev
omogoča enostavno implementacijo le-te.
Recimo, da želimo omejiti naročnino na poljuben kanal. To naredimo v dveh korakih.
Najprej dodamo razširitev na strežnik, ki preverja ali gre za naročnino in ali ima uporabnik
dostop. Drugi korak je dodajanje razširitve na odjemalca, ki zahtevi za naročnino doda
informacije o uporabniku, na podlagi katerih strežnik preveri dostop.
var serverAuth = {
incoming: function(message, callback) {
if (message.channel === "/meta/subscribe") {
checkAuth(message, function(authorized) {
if (!authorized) {
message.error = "Access denied";
}
callback(message);
});
} else {
callback(message);
}
}
};
server.addExtension(serverAuth);
Izvorna koda 24: Strežniška razširitev za avtentikacijo
client.addExtension({
outgoing: function(message, callback) {
if (message.channel === "/meta/subscribe") {
if (!message.ext) {
message.ext = {};
}
message.ext.auth = "c4f3b4b3";
}
callback(message);
}
});
Izvorna koda 25: Odjemalčeva razširitev za avtentikacijo
Razširitev na strežniku pregleduje prihajajoča sporočila in preverja ali, so zahteva za
naročnino na kanal. V tem primeru pokliče funkcijo checkAuth, ki sprejme sporočilo in
povratni klic funkcije ki sprejme parameter authorized, z vrednostima true ali false.
Povratni klic izvrši funkcija checkAuth, ko preveri podatke iz sporočila v bazi ali kjerkoli
Realno-časovne spletne aplikacije 46
se dela avtentikacija. V kolikor avtentikacija ni uspela, razširitev doda sporočilu lastnost
error. Protokol Bayeux določa v kolikor vsebuje sporočilo lastnost error, da se trenutna
zahteva obravnava kot napaka. Razširitev mora v vsakem primeru na koncu poklicati
funkcijo callback [13].
Obratno kot pri strežniku, razširitev na odjemalcu pregleduje odhajajoča sporočila in na
enak način preverja, ali gre za zahtevo naročnine. V tem primeru doda sporočilu lastnost
ext, ki kot razširitev sporočila nosi v sebi podatke o avtentikaciji (npr. id seje). Na koncu se
pokliče funkcija callback.
4.3 Načrtovanje arhitekture aplikacije
Izdelali smo aplikacijo Križci in krožci. Gre za enostavno igro, kjer igralca izmenično
postavljata križec ali krožec na mrežo velikosti 20x20 polj. Zmaga tisti, ki prvi postavi 5
likov v vrsto. Poleg osnovne funkcionalnosti igra omogoča prikaz seznama igralcev in iger
ter javni klepet.
Kot vsaka spletna aplikacija potrebuje HTML strukturo in CSS stile. Mi smo se
osredotočili na načrtovanje komunikacije odjemalec-strežnik. Ker smo uporabili knjižnico
Faye imamo dostop do Bayeux protokola, ki omogoča objavljanje sporočil na kanalih.
Najprej je potrebno definirati kanale za aplikacijo. Za potrebe objavljanja potez smo imeli
kanal /igra/[:igra_id], kjer oba igralca objavljata in spremljata poteze. Aplikacija podpira
tudi klepet med igralcema, zato smo definirali kanal /igra/[:igra_id]/klepet. Na te kanale se
lahko prijavita samo igralca, ki igrata igro. Aplikacija ponuja tudi javni klepet, kanal za to
je /klepet, na katerega se lahko prijavijo vsi. Seznam iger se nahaja na kanalu
/seznam/[:igralec_id], saj ima vsak igralec svoj seznam iger. Na ta kanal se lahko naroči
samo lastnik seznama, na njem pa se objavljajo povabila na novo igro, ter zavrnitev
povabil. Spremembe aktivnih igralcev se objavljajo na kanalu /aktivni, na katerega se
lahko prijavijo vsi prijavljeni igralci. V tabeli Tabela 3: Seznam kanalov v aplikaciji so
predstavljeni našteti kanali.
Realno-časovne spletne aplikacije 47
Kanal Namen Dostop
/igra/[:igra_id] Narejene poteze v igri Samo sodelujoča igralca
/igra/[:igra_id]/klepet Klepet znotraj igre Samo sodelujoča igralca
/seznam/[:igralec_id] Spremembe v seznamu iger Samo lastnik kanala
/aktivni Prijave in odjave igralcev Vsi prijavljeni igralci
/klepet Javni klepet Vsi prijavljeni igralci
Tabela 3: Seznam kanalov v aplikaciji
Poleg kanalov potrebujemo določene storitve, ki omogočajo pridobivanje podatkov iz
podatkovne baze. Bayeux omogoča komunikacijo strežnik/odjemalec preko kanalov
/service/**. To nam omogoča, da strežnik odgovarja na zahteve odjemalca. S pomočjo
servisnih kanalov smo implementirali pridobivanje obstoječih podatkov. Pri tem je
potrebno poudariti, da vsak odjemalec dobi drugačen odgovor glede na avtentikacijo.
Servis Pomen
/service/seznam Seznam obstoječih iger
/service/igralci Seznam registriranih igralcev
/service/igralci/aktivni Seznam aktivnih igralcev
/service/igralci/[:id] Podrobnosti o igralcu
Tabela 4: Seznam servisnih kanalov
Ker gre za več-uporabniško aplikacijo, je potrebna avtentikacija. Pri kanalih smo že
določili pravice, kdo lahko objavlja in spremlja določeni kanal. Dostop do servisov imajo
vsi prijavljeni igralci. Odjemalec pri vsaki objavi na servisni kanal pošlje identifikator seje,
ki uporabnika unikatno identificira. Tako servis ve, s kom se pogovarja, in lahko temu
primerno pošlje odgovor [14].
4.4 Izdelava aplikacije
Aplikacija je razdeljena na dva glavna dela in sicer na strežniški del in odjemalca. Na
strežniku je implementirana logika servisov in avtentikacija. Odjemalec skrbi za
komunikacijo s strežnikom ter celotni uporabniški vmesnik. Glavni programski jezik
aplikacije je JavaScript, vmesnik pa se izrisuje s pomočjo HTML in CSS.
Realno-časovne spletne aplikacije 48
Z načrtovanjem smo identificirali dva glavna razreda, in sicer Igralec in Igra. Poleg teh
razredov smo potrebovali še kontrolni razred, ki je skrbel za interakcijo glavnih razredov in
implementiral poslovno logiko aplikacije.
Strežnik sestavljata dva glavna dela in sicer razširitev, ki avtenticira uporabnike, ter
servisni del, ki podpira poslovno logiko aplikacije, ter omogoča dostop do baze.
Avtentikacija uporablja isto kodo, kot smo jo že videli v poglavju o avtentikacijo s
pomočjo knjižnice Faye (Izvorna koda 24: Strežniška razširitev za avtentikacijo, Izvorna
koda 25: Odjemalčeva razširitev za avtentikacijo). Sledi implementacija funkcije
checkAuth, ki preveri identifikator seje v bazi in na podlagi veljavnega identifikatorja vrne
objekt uporabnika ali null v kolikor je identifikator neveljaven.
function checkAuth(message, callback)
{
var token = message.ext && message.ext.auth;
User.getByToken(token, function(user) {
callback(!!user);
});
}
Izvorna koda 26: Implementacija funkcije checkAuth.
Implementacija servisnega dela je obsežnejša, saj poleg avtentikacije zahteva tudi
veljavnost in normalizacijo vhodnih parametrov. Za ta namen smo razvili razširitev, ki
omogoča tri korake: avtentikacijo, veljavnost in normalizacijo, ter izvršitev poslovne
logike servisa. Avtentikacija uporablja že omenjeno funkcijo checkAuth. Veljavnost je
skupina pravil, ki določajo, kakšnega tipa so lahko vhodni parametri in kakšna je njihova
zaloga vrednosti. Pri normalizaciji lahko v nekaterih primerih te parametre popravimo. V
kolikor so bili vsi parametri veljavni, ter normalizirani, se izvrši poslovna logika storitve,
ki na koncu pošlje rezultat odjemalcu. Spodnji primer prikazuje storitvi za povabilo na
novo igro in postavljanje poteze.
Realno-časovne spletne aplikacije 49
XOGameService.addServices({
newGame: function(params, callback)
{
var game = Game.create(params);
XOGameService.sendToClient(game.getOpponent(), game);
callback(game);
},
makeMove: function(params, callback)
{
var game = Game.get(params.id);
if (!game.isParticipant())
{
throw new ClientError("401");
}
game.makeMove(params.user.id, params.move);
callback();
}
});
Izvorna koda 27: Servisni metodi za novo igro, ter postavljanje poteze
S to kodo smo definirali metodi, ki izpostavita poslovno logiko aplikacije. Vidimo, da
poleg klicev metod razreda Game, pošiljata tudi podatke nasprotniku in preverjata ali ima
igralec dostop do igre. Poleg definicije storitev je potrebno definirati tudi veljavnost
parametrov vseh metod.
XOGameService.addRules({
newGame: {
opponent: ["r", "integer"],
type: ["r", "game_type"],
size: ["r", "game_size"]
},
makeMove: {
id: ["r", "integer"],
move: ["r", "game_move"]
}
});
Izvorna koda 28: Definicija veljavnosti servisnih parametrov
Vidimo, da so za metodo newGame določeni parametri opponent, type, ter size. Desno so
našteta imena metod, preko katerih se izvede veljavnost. Metodi »r« in »integer« sta
vgrajeni, ostale pa so specifične za našo aplikacijo in jih je potrebno implementirati.
Realno-časovne spletne aplikacije 50
XOGameService.addValidators({
game_move: function(val) {
var move = val.split("_"), x = move[0], y = move[1];
return move.length === 2 && x > 0 && x <=20 && y > 0
&& y <= 20;
},
game_size: function(val) {
return val >= 15 && val <= 20;
},
game_type: function(val) {
return val >= 1 && val <= 3;
}
});
Izvorna koda 29: Definicija veljavnostnih metod
Metoda game_move definira, da mora vrednost vsebovati koordinati X in Y v formatu x_y,
kjer sta x in y lahko med 1 in 20. Podobno velja za metodi game_size in game_type.
4.5 Predstavitev aplikacije
Aplikacija je zastavljena kot spletna aplikacija s poslovno logiko na odjemalcu (angl. fat
client). Naloga odjemalca je izrisovanje celotnega uporabniškega vmesnika, izvajanje
poslovne logike ter upravljanje dogodkov, s katerimi se izvajajo uporabniške akcije.
Strežnik skrbi le za shrambo in preverjanje veljavnosti podatkov prejetih od odjemalca.
Strežnik sestavljajo komponente (modeli) za delo s podatki, storitveni del za komuniciranje
z odjemalcem in del, ki skrbi za poslovno logiko aplikacije.
Za pomoč pri odjemalcu smo uporabili knjižnico ExtJS, ki ponuja komponente, s katerimi
je možno enostavno in konsistentno graditi uporabniški vmesnik. Poleg komponent
vmesnika ponuja knjižnica komponente za delo s podatki ter komunikacijo. Za vmesnik
smo uporabili komponente Window, Panel, Grid, Tree, Toolbar, Desktop, TaskBar,
ViewPort. Za potrebe aplikacije smo razvili nekaj svojih, te so: GameWindow,
GameListWindow, PlayerListWindow, GamePanel, ChatPanel. Za hrambo in organizacijo
podatkov na odjemalcu smo uporabili komponenti Store in Record, razvili pa smo tudi
svoje modele, ki ovijejo podatke s poslovno logiko aplikacije. Za komunikacijo smo
uporabili komponente knjižnice Faye, ki omogoča komunikacijo objavi/naroči s
strežnikom.
Realno-časovne spletne aplikacije 51
4.5.1 Pregled aplikacije
Aplikacija je razdeljena na strežniški in odjemalčev del. Celotni vmesnik igre je zastavljen
kot aplikacija z okni. Tako lahko ima igralec hkrati odprtih več iger in igra hitreje. Celoten
uporabniški vmesnik se izrisuje na odjemalcu s pomočjo knjižnice ExtJS, ki ponuja mnogo
komponent, s katerimi si poenostavimo razvoj spletne aplikacije. Aplikacija zraven
osnovnih funkcionalnosti, seznama iger, prikaza mreže igre, delanja potez, omogoča še
prikaz seznama aktivnih in vseh registriranih igralcev, simulacijo igre, javni in zasebni
klepet znotraj igre, pregled poteka igre, ter zvočna opozorila ob potezi in novem sporočilu.
Pri razvoju smo uporabili komponente knjižnice ExtJS. Celotno okno brskalnika
predstavlja komponenta ViewPort, ki služi kot vsebnik za ostale komponente. Aplikacijo
sestavljajo okna. Za to smo uporabili komponento Window, ki je vsebovana znotraj
komponente Desktop. Poleg tega aplikacija vsebuje tudi meni Start in opravilno vrstico, za
kateri skrbita komponenti StartMenu in Taskbar, ki sta vsebovani znotraj komponente
ViewPort. Vsaka komponente Window predstavlja svojo okno aplikacije. Pri zagonu
aplikacije se odprejo okna s seznamov iger, seznamom igralcev, ter klepet. Vsaka nadaljnja
entiteta, kot sta npr. igra in profil igralca, se odpre v svojem oknu. Vsako izmed oken je
specifična razširitev komponente Window, ki implementira poslovno logiko in se odziva
na dogodke igralca. V nadaljevanju so predstavljene glavne komponente aplikacije.
Slika 6: Vmesnik celotne aplikacije
Realno-časovne spletne aplikacije 52
4.5.2 Seznam iger
Seznam iger je osrednji del igre, saj se vse vrti okoli iger. Razdeljen je na tri dele oz. -
zavihke. Predstavljen je tabelarično in ima določene stolpce. Dalje je razdeljen je na strani,
kjer je na stran prikazanih 20 iger. Navigacija po straneh se nahaja v nogi seznama, s
pomočjo katere se lahko premaknemo na prvo/zadnjo, prejšnjo/naslednjo stran, ali ročno
vpišemo stran, na katero se želimo premakniti. Uporabimo lahko tudi smerne tipke na
tipkovnici. V zgornjem desnem kotu lahko vklopimo ali izklopimo zvočno obvestilo o
potezi v igri.
Slika 7: Seznam iger
Seznam iger je implementiran v komponenti GameListWindow. Sestavljajo jo pod
komponente, ki predstavljajo zavihke, seznam iger ter listanje po straneh.
Realno-časovne spletne aplikacije 53
Zavihke implementira komponenta TabPanel, ki sprejme polje pod-komponent, ki
predstavljajo vsebino zavihkov. V našem primeru je to komponenta GameListPanel. Vsak
zavihek ima svojo instanco te komponente.
Seznam iger implementira komponenta GameListPanel. Komponenta vsebuje referenco do
seznama iger, ki ga predstavlja komponenta Store. Store vsebuje seznam komponent
Record, ki predstavljajo eno igro v seznamu. GameListPanel vsebuje tudi komponento
PagingToolbar, ki preko komponente Store pridobi podatke o številu iger v seznamu, sama
komponenta, pa vodi stanje na kateri strani se trenutno nahaja in primerno temu prilagaja
vmesnik, ter proži dogodke komponente GameListPanel, za prikazovanje iger na izbrani
strani. Potrebno je poudariti, da vsak zavihek vsebuje svojo instanco komponente Store, saj
je ena igra hkrati lahko samo v enem seznamu.
4.5.3 Seznam igralcev
Seznam igralcev je razdeljen na dva zavihka, ki omogočata hiter dostop do profila
določenega igralca.
Slika 8: Seznam igralcev
Podobno kot pri seznamu iger, seznam igralcev, ki ga implementira komponenta
PlayerListWindow, vsebuje komponento TabPanel. Razlika je pri seznamu aktivnih
Realno-časovne spletne aplikacije 54
igralcev, kjer TabPanel vsebuje komponento TreePanel, ki igralce prikaže v pogledu
drevesa. Komponenta implementira dogodek ob kliku, kateri ustvari novo komponento
PlayerWindow, v kateri so podrobnosti igralca.
4.5.4 Klepet
Igra omogoča realno-časovno izmenjevanje sporočil med vsemi igralci. Okno za klepet, ki
se odpre ob prijavi, je namenjeno javnemu klepetu. Znotraj igre lahko udeleženca klepetata
tudi v zasebnem pogovoru. Vklopimo ali izklopimo lahko zvočno opozorilo ob novem
sporočilu.
Slika 9: Okno za klepet
Komponenta ChatPanel vsebuje dve preprosti komponenti Textarea in InputText. Poleg
standardnih gumbov minimiziraj in zapri, komponenta implementira gumb zvok, s katerim
se vklopijo ali izklopijo zvočna opozorila. Komponenta InputText implementira dogodek
ob pritisku tipke enter, ki objavi sporočilo na kanalu javnega klepeta preko komponente
ServiceClient, ta pa služi za komunikacijo s strežnikom.
4.5.5 Igra
Osrednji del igre je okno igre, v katerem se dogaja večina stvari. Okno igro predstavlja
mreža in orodna vrstica. Potezo naredimo s klikom na mreži. Nad mrežo igre se nahaja
orodna vrstica, v kateri so na voljo različni pripomočki, kot so pregled zadnje poteze,
vklop in izklop simulacije, klepeta in pregled poteka igre.
Realno-časovne spletne aplikacije 55
Slika 10: Okno končane igre, z odprtim klepetom in potekom igre
Okno igre implementira komponenta GameWindow in vsebuje več komponent.
Komponenta Toolbar omogoča dodajanje gumbov. V našem primeru je ta komponenta na
vrhu okna. Pod to komponento se nahaja komponenta GameGrid, ki predstavlja mrežo
igre. Implementira tudi dogodke, ki omogočajo igranje igre. Desno je uporabljena
komponenta GameMovesList, ki prikazuje seznam narejenih potez igre. Podatki o igri so
shranjeni v modelu Game, katerega referenca je shranjena v komponenti GameWindow.
Pod mrežo igre se nahaja klepet, ki ga implementira komponenta ChatPanel, ki smo jo že
opisali.
Realno-časovne spletne aplikacije 56
4.5.6 Komunikacija s strežnikom
Vsa komunikacija s strežnikom poteka s pomočjo knjižnice Faye in storitvijo
XOGameService. Na odjemalcu se nahaja komponenta ServiceClient, ki omogoča
oddaljeni klic storitev ter objavljanje sporočil na kanalih.
S pomočjo te komponente, lahko ostale komponente prožijo metode, ki nato tvorijo
oddaljen klic na strežnik. Komponenta s pomočjo knjižnice Faye ob zagonu aplikacije
vzpostavi povezavo s strežnikom. V brskalniku, ki podpira WebSockets, je vzpostavljena
neprekinjena povezava s strežnikom, ki zagotavlja najmanjšo zakasnitev in količino
prenesenih podatkov. V ostalih brskalnikih se vzpostavi povezava preko tehnike dolgega
povpraševanja.
4.6 Ugotovitve
Pri izdelavi aplikacije smo se srečali z nekaj novostmi. Vredno je omeniti asinhrono
programiranje in razvoj spletne aplikacije. Poleg tega je pri delu s tehnologijami v
nastajanju, ki še niso standardizirane, potrebna pazljivost in redno spremljanje razvoja le-
teh. Takšen primer je pred kratkim onemogočena podpora protokola WebSockets v
brskalniku Firefox. Kot vzrok so navedli pomanjkljivost varnosti pri vzpostavljanju
povezave v protokolu.
Pri asinhronem programiranju je potrebno spremeniti miselni tok, kako se program izvaja.
Velja, da vsaka dolga operacija, kot je npr. branje datoteke, dostop do baze, dolgotrajne
operacije zahteva povratni klic, ki se izvede ob rezultatu. Zato je potrebno tem operacijam
podati povratni klic, znotraj katerega se obdela rezultat ter nadaljuje izvajanje poslovne
logike.
Razvoj spletnih aplikacij zahteva poleg znanja tehnologij HTML, CSS, JavaScript tudi
dodatna znanja, ki prinesejo boljšo uporabniško izkušnjo. Spletne aplikacije se običajno
naložijo v začetku in nato tečejo znotraj brskalnika, brez ponovnega nalaganja. Pri
obsežnejših aplikacijah velja, da je večina poslovne logike na odjemalcu, strežnik pa služi
kot shramba in zagotavlja konsistentnost podatkov.
Z razvojem realno-časovne spletne aplikacije smo ugotovil, da lahko v brskalnik
učinkovito in veliko hitreje dostavimo sporočilo, ki se zgodi na strežniku ali pri drugemu
Realno-časovne spletne aplikacije 57
uporabniku aplikacije. S tehnologijo WebSockets lahko učinkoviteje dostavljamo sporočila
v brskalnik, kot npr. s tehniko dolgega povpraševanja. Ta ugotovitev temelji na dejstvu, da
je pri tehniki dolgega povpraševanja potrebno ponovno vzpostavljati povezavo s
strežnikom. Za ponovno vzpostavitev povezave je potreben dodaten čas in nova HTTP
zahteva, kar dodatno prinese k daljšemu odzivnemu času in k večji količini prenesenih
podatkov. Pri povezavi z WebSockets odpade ponovno vzpostavljanje povezave, kar
pomeni, da lahko v enakem času prenesemo več sporočil z večjo velikostjo, saj je
zakasnitev dostavljanja sporočil manjša.
Realno-časovne spletne aplikacije 58
5 SKLEP
Realno-časovne spletne aplikacije postajajo del našega vsakdanjika. Verjetno se njihove
uporabe niti ne zavedamo. Dober primer sta spletni aplikaciji Gmail in Google Talk. Videli
smo, da je današnja podpora realno-časovnim tehnologijam v brskalnikih še precej
omejena oziroma v razvoju. Kljub temu lahko s pomočjo opisanih tehnik dosežemo
pošiljanje sporočil k odjemalcu že v danes, sploh v najbolj uporabljenih brskalnikih.
Čeprav so opisane tehnike dokaj zapletene, si z uporabo knjižnice lahko razvoj aplikacije
precej poenostavimo, saj knjižnica odpravi težave, ki jih določena tehnika prinaša,
razvijalcu aplikacije pa izpostavi le programski vmesnik, preko katerega razvija aplikacije,
neodvisno od uporabljene tehnike.
Pri razvoju aplikacije Križci in krožci smo spoznali, da lahko s principom naroči/objavi
zelo enostavno implementiramo obveščanje ostalih uporabnikov, ki jih določeni dogodek
zadeva. S pomočjo protokola Bayeux in knjižnice Faye smo razvili razširitev, ki omogoča
avtentikacijo uporabnikov. Poleg tega smo razvili storitve, ki zagotavljajo dostop do
podatkov shranjenih v podatkovni bazi. Storitve zagotavljajo tudi poslovno logiko
aplikacije, ki omogoča igranje igre.
Realno-časovne spletne aplikacije 59
6 VIRI IN LITERATURA
[1] Ajax (programming):
http://en.wikipedia.org/wiki/AJAX, obiskano 15.1.2011
[2] Beyond Real Time Web:
http://www.slideshare.net/matjazl/beyond-real-time-web, obiskano 9.2.2011
[3] D. Crane, P. McCarthy, Comet and Reverse Ajax: The Next-Generation Ajax 2.0,
Apress, 2008
[4] Comet Daily:
http://cometdaily.com, obiskano 6.2.2011
[5] Document Object Model
http://en.wikipedia.org/wiki/Document_Object_Model, obiskano 15.1.2011
[6] Faye: Simple pub/sub messaging for the web
http://faye.jcoglan.com, obiskano 7.2.2011
[7] HTML
http://en.wikipedia.org/wiki/HTML, obiskano 15.1.2011
[8] HTTP Streaming
http://ajaxpatterns.org/HTTP_Streaming, obiskano 7.2.2011
[9] Hypertext Transfer Protocol
http://en.wikipedia.org/wiki/HTTP, obiskano 15.1.2011
[10] Inovacija WEB 2.0
http://www.src.si/library_si/pdf/infosrc/2007-
51/InovacijaWEB2.0_novi_modeli_integracije_in_sodelovanja.pdf, obiskano 15.1.2011
[11] Meteor
http://meteorserver.org/interaction-modes, obiskano 6.2.2011
Realno-časovne spletne aplikacije 60
[12] MIME
http://en.wikipedia.org/wiki/MIME#Multipart_messages, obiskano 7.2.2011
[13] Node.JS and WebSockets with Faye
http://www.slideshare.net/matjazl/nodejs-and-websockets-with-faye, obiskano 9.2.2011
[14] P. Lubbers, B. Albers, F. Salim, Pro HTML5 Programming: Powerful APIs for Richer
Internet Application Development, Apress, 2010
[15] Real-time web
http://en.wikipedia.org/wiki/Real-time_web, obiskano 6.2.2011
[16] Slovar telekomunikacij in informacijskih tehnologij
http://slovar.ltfe.org, obiskano 1.2.2011
[17] The Bayeux Protocol
http://svn.cometd.org/trunk/bayeux/bayeux.html, obiskano 9.2.2011
[18] The WebSocket API
http://dev.w3.org/html5/websockets, obiskano 7.2.2011
[19] The WebSocket protocol
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-05, obiskano 7.2.2011
[20] WebSockets
http://en.wikipedia.org/wiki/WebSockets, obiskano 7.2.2011
[21] XMLHttpRequest
http://en.wikipedia.org/wiki/XMLHttpRequest, obiskano 4.2.2011
[22] XMLHttpRequest - MDC Doc Center
https://developer.mozilla.org/en/xmlhttprequest, obiskano 4.2.2011
[23] The C10K problem
http://www.kegel.com/c10k.html, obiskano 6.2.2011
[24] Publish/subscribe
http://en.wikipedia.org/wiki/Publish/subscribe, obiskano 9.2.2011
Realno-časovne spletne aplikacije 61
7 PRILOGE
7.1 Kazalo slik
Slika 1: Povpraševanje (polling) ......................................................................................... 25
Slika 2: Hkratni prenos (Piggybacking) .............................................................................. 26
Slika 3: Dolgo povpraševanje (long-polling) ...................................................................... 27
Slika 4: Pretok (streaming) .................................................................................................. 29
Slika 5: Model objavi naroči ............................................................................................... 33
Slika 7: Vmesnik celotne aplikacije .................................................................................... 51
Slika 8: Seznam iger ............................................................................................................ 52
Slika 9: Seznam igralcev ..................................................................................................... 53
Slika 10: Okno za klepet ...................................................................................................... 54
Slika 11: Okno končane igre, z odprtim klepetom in potekom igre .................................... 55
7.2 Kazalo tabel
Tabela 1: Najbolj uporabljene lastnosti objekta XMLHttpRequest .................................... 21
Tabela 2: Najbolj uporabljene metode objekta XMLHttpRequest ...................................... 21
Tabela 3: Seznam kanalov v aplikaciji ................................................................................ 47
Tabela 4: Seznam servisnih kanalov ................................................................................... 47
7.3 Kazalo izvorne kode
Izvorna koda 1: Zahteva HTTP ........................................................................................... 16
Izvorna koda 2: Odgovor HTTP .......................................................................................... 17
Izvorna koda 3: Primer dokumenta HTML ......................................................................... 17
Izvorna koda 4: Primer dokumenta CSS ............................................................................. 18
Izvorna koda 5: Primer klica AJAX ................................................................................... 22
Izvorna koda 6: Primer večdelnega formata MIME sporočila ............................................ 30
Izvorna koda 7: Primer Server-sent events programčka ...................................................... 32
Realno-časovne spletne aplikacije 62
Izvorna koda 8: Server-sent events dogodki........................................................................ 32
Izvorna koda 9: Primer Bayeux sporočila v klepetalnici ..................................................... 34
Izvorna koda 10: Odgovor strežnika na sporočilo ............................................................... 35
Izvorna koda 11: Primer vzpostavljanja povezave .............................................................. 35
Izvorna koda 12: Sporočilo ob povezavi na strežnik ........................................................... 36
Izvorna koda 13: Predlog načina povezave strežnika .......................................................... 36
Izvorna koda 14: Izbrani način povezave odjemalca........................................................... 37
Izvorna koda 15: Potrditev strežnika ob povezavi............................................................... 37
Izvorna koda 16: IDL definicija WebSockets API-ja .......................................................... 39
Izvorna koda 17: WebSockets protokol: rokovanje odjemalca ........................................... 40
Izvorna koda 18: WebSockets protokol: rokovanje strežnika ............................................. 40
Izvorna koda 19: Primer Faye Node.js strežnika ................................................................. 43
Izvorna koda 20: Objava sporočila na strežniku s pomočjo internega odjemalca ............... 43
Izvorna koda 21: Kreiranje Faye odjemalca, s časovno omejitvijo 50 sekund ................... 43
Izvorna koda 22: Primer naročnine na kanala /pozdrav ...................................................... 44
Izvorna koda 23: Primer objave sporočila na kanalu .......................................................... 44
Izvorna koda 24: Strežniška razširitev za avtentikacijo ...................................................... 45
Izvorna koda 25: Odjemalčeva razširitev za avtentikacijo .................................................. 45
Izvorna koda 26: Implementacija funkcije checkAuth. ....................................................... 48
Izvorna koda 27: Servisni metodi za novo igro, ter postavljanje poteze ............................. 49
Izvorna koda 28: Definicija veljavnosti servisnih parametrov ............................................ 49
Izvorna koda 29: Definicija veljavnostnih metod................................................................ 50
7.4 Naslov študenta
Matjaž Lipuš
Zagrebška 79/b
2250 Ptuj
E-pošta: matjazl@gmail.com
Realno-časovne spletne aplikacije 63
7.5 Kratek življenjepis
Rojen: 5. 7. 1984 na Ptuju
Šolanje: 1991 – 1999 Osnovna šola Breg Ptuj
1999 – 2003 Srednja elektro-računalniška šola Maribor, smer Tehniška
gimnazija
2006 – 2011 Fakulteta za elektrotehniko in informatiko, Univerza v
Mariboru, Visokošolski študij, Računalništvo in informatika,
smer Informatika
Realno-časovne spletne aplikacije 64
Realno-časovne spletne aplikacije 65
Realno-časovne spletne aplikacije 66
top related