realno-Časovne spletne aplikacije · realno-časovne spletne aplikacije 3 realno-Časovne spletne...

Matjaž Lipuš

REALNO-ČASOVNE SPLETNE APLIKACIJE

Diplomsko delo

Maribor, marec 2011

Realno-časovne spletne aplikacije 0

Diplomsko delo visokošolskega strokovnega študijskega programa


Š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


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.



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.


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.


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


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


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


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


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


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


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.


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].


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.


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.


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].


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

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23

http://www.feri.uni-mb.si/


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

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3







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.

http://www.w3.org/TR/CSS21/colors.html#propdef-color

http://www.w3.org/TR/CSS21/text.html#propdef-text-decoration


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.


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.


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.


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.

http://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Statements/var

http://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Operators/Special_Operators/new_Operator

http://www.w3.org/TR/XMLHttpRequest/

http://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Statements/function

http://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Statements/if...else

http://developer.mozilla.org/En/DOM/window.alert


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


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.


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.


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.


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


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].


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:


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

http://tools.ietf.org/html/rfc2076#section-3.3





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.


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].






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


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


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",


"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.


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

},


"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.


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",


"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].


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].


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.

http://dev.w3.org/html5/websockets/#dom-websocket

http://dev.w3.org/html5/websockets/#dom-websocket

http://dev.w3.org/html5/websockets/#dom-websocket-url

http://dev.w3.org/html5/websockets/#dom-websocket-connecting

http://dev.w3.org/html5/websockets/#dom-websocket-open

http://dev.w3.org/html5/websockets/#dom-websocket-closing

http://dev.w3.org/html5/websockets/#dom-websocket-closed

http://dev.w3.org/html5/websockets/#dom-websocket-readystate

http://dev.w3.org/html5/websockets/#dom-websocket-bufferedamount

http://dev.w3.org/html5/websockets/#handler-websocket-onopen

http://dev.w3.org/html5/websockets/#handler-websocket-onmessage

http://dev.w3.org/html5/websockets/#handler-websocket-onerror

http://dev.w3.org/html5/websockets/#handler-websocket-onclose

http://dev.w3.org/html5/websockets/#dom-websocket-protocol

http://dev.w3.org/html5/websockets/#dom-websocket-send

http://dev.w3.org/html5/websockets/#dom-websocket-close

http://dev.w3.org/html5/websockets/#websocket


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


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


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


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.







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











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.


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.


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.





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.






http://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Statements/throw


http://developer.mozilla.org/En/DOM/event.type

http://developer.mozilla.org/En/DOM/element.id


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.



http://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Global_Objects/String/split

http://developer.mozilla.org/En/Core_JavaScript_1.5_Reference/Statements/return

http://developer.mozilla.org/En/DOM/element.length






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


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.


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


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.


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.


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


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.


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.


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

http://en.wikipedia.org/wiki/AJAX

http://www.slideshare.net/matjazl/beyond-real-time-web

http://cometdaily.com/

http://en.wikipedia.org/wiki/Document_Object_Model

http://faye.jcoglan.com/

http://en.wikipedia.org/wiki/HTML

http://ajaxpatterns.org/HTTP_Streaming

http://en.wikipedia.org/wiki/HTTP

http://www.src.si/library_si/pdf/infosrc/2007-51/InovacijaWEB2.0_novi_modeli_integracije_in_sodelovanja.pdf

http://www.src.si/library_si/pdf/infosrc/2007-51/InovacijaWEB2.0_novi_modeli_integracije_in_sodelovanja.pdf

http://meteorserver.org/interaction-modes


[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

http://en.wikipedia.org/wiki/MIME#Multipart_messages

http://www.slideshare.net/matjazl/nodejs-and-websockets-with-faye

http://en.wikipedia.org/wiki/Real-time_web

http://slovar.ltfe.org/

http://svn.cometd.org/trunk/bayeux/bayeux.html

http://dev.w3.org/html5/websockets

http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-05

http://en.wikipedia.org/wiki/WebSockets

http://en.wikipedia.org/wiki/XMLHttpRequest

https://developer.mozilla.org/en/xmlhttprequest

http://www.kegel.com/c10k.html

http://en.wikipedia.org/wiki/Publish/subscribe


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


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: [email protected]


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 · realno-časovne spletne aplikacije 3 realno-Časovne spletne...

Documents