tehnike potiskanja podatkov spletnim odjemalcem · iv web client data push techniques key words:...

Marko Bertoncel

TEHNIKE POTISKANJA PODATKOV SPLETNIM ODJEMALCEM

Diplomsko delo

Maribor, september 2013

TEHNIKE POTISKANJA PODATKOV SPLETNIM

ODJEMALCEM

Diplomsko delo

Študent: Marko Bertoncel

Študijski program: Visokošolski strokovni, Informatika in tehnologije

komuniciranja

Smer: Razvoj informacijskih sistemov

Mentor: mag. Boštjan Keţmah, univ. dipl. inţ.

ii

ZAHVALA

Zahvaljujem se mentorju viš. pred. mag. Boštjanu

Keţmahu za strokovno svetovanje in vodenje pri

opravljanju diplomske naloge.

Posebna zahvala velja staršem in drugim bliţnjim,

ki so mi omogočili študij in me spodbujali.

iii

Tehnike potiskanja podatkov spletnim odjemalcem

Ključne besede: splet v realnem času, dolgo povpraševanje, dogodki poslani s streţnika,

spletne vtičnice, SignalR

UDK: 004.6:004.777(043.2)

Povzetek

V današnjem času se na spletu soočamo z vedno večjimi količinami podatkov. Ob tem se

poraja vprašanje, kako uporabnikom zagotoviti čim boljši dostop do vsebin in izboljšati

uporabniško izkušnjo. Namen diplomske naloge je raziskati obstoječe tehnike potiskanja

podatkov spletnim odjemalcem in jih na podlagi testiranj in analiz kritično ovrednotiti s

stališča razvijalca. Ugotoviti želimo, katere tehnologije so najprimernejše za uporabo in

najbolj poenostavijo razvoj novih spletnih aplikacij.

iv

Web client data push techniques

Key words: Real time web, Websockets, Server-sent events, Ajax Longpolling, SignalR

UDK: 004.6:004.777(043.2)

Abstract

In today's world we are faced with ever-increasing amounts of data online. Thus, the

question arises how to provide users with the best possible access to content and improve

the user experience. The purpose of the thesis is to explore the existing Push techniques

and on the basis of tests and analyzes critically evaluate them from developer's point of

view. We want to determine which technologies are best suited for use and further simplify

the development of new web applications.

v

UPORABLJENE KRATICE

AJAX – Asynchronous JavaScript and XML

API – Application programming interface

ASP.NET – Active Server Pages .NET

CSS – Cascading Style Sheets

FTP – File transfer protocol

HTML – HyperText Markup Language

HTTP – HyperText Transfer Protocol

IETF – Internet Engineering Task Force

IIS – Internet Information Services

IP – Internet protocol

JSON – JavaScript Object Notation

MVC – Model – View – Controler

REST – Representational state transfer

RPC – Remote procedure call

SQL – Structured Query Language

TCP – Transmission Control Protocol

URL – Uniform Resource Locator

W3C – World Wide Web Consortium

WCF – Windows Communication Foundation

WCF RIA – Windows Communication Foundation Rich Internet application

XHR – XMLHttpRequest

XML – Extensible Markup Language

vi

KAZALO

1 UVOD ........................................................................................................................ 1

2 SPLET V REALNEM ČASU ....................................................................................... 3

2.1 Primerjava tehnik povpraševanja in potiskanja podatkov .................................... 5

3 TEHNOLOGIJE ......................................................................................................... 8

3.1 HTTP protokol .................................................................................................... 8

3.1.1 HTTP zahteve .............................................................................................. 9

3.2 TCP protokol ....................................................................................................... 9

3.3 ASP.NET MVC 4 ...............................................................................................10

3.4 Knjiţnica jQuery .................................................................................................12

4 TEHNIKE POTISKANJA PODATKOV SPLETNIM ODJEMALCEM ..........................13

4.1 Tehnika dolgega povpraševanja (Long polling) ..................................................13

4.2 Tehnologija dogodkov poslanih s streţnika (Server - sent events) .....................15

4.3 Tehnologija spletnih vtičnic (Websockets) .........................................................17

4.4 Knjiţnica SignalR ...............................................................................................18

5 PODPRTOST TEHNOLOGIJ V BRSKALNIKIH ........................................................22

6 IMPLEMENTACIJA TEHNOLOGIJ V ASP.NET MVC ...............................................26

6.1 Dolgo povpraševanje (Long polling) ...................................................................27

6.2 Dogodki poslani s streţnika (Server – sent events) ...........................................28

6.3 Spletne vtičnice (Websockets) ...........................................................................30

6.4 Knjiţnica SignalR ...............................................................................................31

7 TESTIRANJE TEHNIK IN TEHNOLOGIJ ..................................................................34

7.1 Poraba procesorskih virov .................................................................................35

7.2 Poraba pomnilnika .............................................................................................38

8 SKLEP ......................................................................................................................42

9 VIRI IN LITERATURA ...............................................................................................44

10 PRILOGE ..............................................................................................................46

vii

KAZALO SLIK

Slika 2.1 Uporabniško orientiran pristop[14] ...................................................................... 3

Slika 2.2 Streţniško orientiran pristop[14] ......................................................................... 4

Slika 2.1.1 Primerjava tehnik povpraševanja in potiskanja podatkov[14] ........................... 7

Slika 3.3.1 Ogrodje ASP.NET MVC[10]............................................................................10

Slika 3.3.2 Načrtovalski vzorec MVC[10] ..........................................................................11

Slika 4.1.1 Delovanje tehnike dolgega povpraševanja[15] ...............................................14

Slika 4.2.1 Delovanje tehnike dogodkov poslanih s streţnika ...........................................15

Slika 4.3.1 Delovanje tehnike spletnih vtičnic[15] .............................................................17

Slika 4.4.1 Umeščenost tehnologije SignalR v ogrodje ASP.NET ....................................19

Slika 4.4.2 Podprte tehnologije SignalR ...........................................................................19

Slika 4.4.3 Arhitektura knjiţnice SignalR ..........................................................................21

Slika 6.1 Spletna aplikacija simulacije parkirišča ..............................................................26

KAZALO TABEL

Tabela 5.1 Podprtost tehnike dolgega povpraševanja v spletnih brskalnikih ....................22

Tabela 5.2 Podprtost tehnologije dogodkov poslanih s streţnika v brskalnikih[12] ...........23

Tabela 5.3 Podprtost tehnologije spletnih vtičnic[13] ........................................................24

Tabela 5.4 Podprtost knjiţnice SignalR v brskalnikih[19] .................................................25

KAZALO IZVORNE KODE

Izvorna koda 4.2.1 Vzpostavitev povezave dogodkov poslanih s streţnika ......................16

Izvorna koda 4.2.2 Metode tehnologije dogodkov poslanih s streţnika ............................16

Izvorna koda 6.1.1 Dolgo povpraševanje: vzpostavitev povezave ....................................27

Izvorna koda 6.1.2 Dolgo povpraševanje: obvestimo nit o zaključku operacije .................27

Izvorna koda 6.1.3 Dolgo povpraševanje: pošiljanje odgovora .........................................27

Izvorna koda 6.1.4 Dolgo povpraševanje: pošiljanje zahtevkov odjemalca .......................28

Izvorna koda 6.2.1 Dogodki poslani s streţnika: vzpostavitev povezave ..........................28

Izvorna koda 6.2.2 Dogodki poslani s streţnika: kreiranje novega odjemalca ..................29

Izvorna koda 6.2.3 Dogodki poslani s streţnika: obveščanje odjemalcev .........................29

Izvorna koda 6.2.4 Dogodki poslani s streţnika: prejemanje odgovorov ..........................29

Izvorna koda 6.3.1 Spletne vtičnice: kreiranje nove povezave .........................................30

Izvorna koda 6.3.2 Spletne vtičnice: dodajanje nove povezave ........................................30

Izvorna koda 6.3.3 Spletne vtičnice: pošiljanje podatkov ..................................................30

viii

Izvorna koda 6.3.4 Spletne vtičnice: pošiljanje prejetih sporočil odjemalca ......................31

Izvorna koda 6.3.5 Spletne vtičnice: odstranimo zaprto povezavo ...................................31

Izvorna koda 6.3.6 Spletne vtičnice: metode na strani odjemalca ....................................31

Izvorna koda 6.4.1 SignalR: definiranje razreda Hub .......................................................32

Izvorna koda 6.4.2 SignalR: pošiljanje sporočil ................................................................32

Izvorna koda 6.4.3 SignalR: deklaracija skript ..................................................................33

Izvorna koda 6.4.4 SignalR: prejemanje sporočil .............................................................33

KAZALO GRAFOV

Graf 7.1.1 Poraba procesorske moči: 50 povezav ............................................................35

Graf 7.1.2 Poraba procesorske moči: 250 povezav ..........................................................35

Graf 7.1.3 Poraba procesorske moči: 500 povezav ..........................................................36

Graf 7.1.4 Poraba procesorske moči: 1000 povezav ........................................................36

Graf 7.1.5 Poraba procesorske moči: 5000 povezav ........................................................37

Graf 7.2.1 Poraba pomnilnika: 50 povezav ......................................................................38

Graf 7.2.2 Poraba pomnilnika: 250 povezav ....................................................................39

Graf 7.2.3 Poraba pomnilnika: 500 povezav ....................................................................39

Graf 7.2.4 Poraba pomnilnika: 1000 povezav ..................................................................40

Graf 7.2.5 Poraba pomnilnika: 5000 povezav ..................................................................40


1

1 UVOD

V današnjem času postaja splet vseprisoten. Iz dneva v dan narašča število uporabnikov

interneta in storitev, ki jih ta ponuja. Posledično s številom uporabnikov storitev narašča

tudi število ponudnikov le-teh. Svetovni splet je prisoten ţe kar nekaj časa, vendar

inovacije in tehnologije, ki so povezane z njim, ne mirujejo, ampak se ves čas razvijajo in

teţijo k zagotavljanju čim boljše uporabnosti in učinkovitosti spleta.

Svetovni splet je star dobrih 20 let in je v vseh teh letih doţivel ogromen napredek in

razvoj. Na začetku so na spletu obstajale statične spletne strani, pri katerih so se podatki

le redko spreminjali. Tudi število uporabnikov je bilo manjše in tako se uporabnikovi

interakciji ni posvečalo veliko pozornosti. Danes ţivimo v času Spleta 2.0, ki v središče

postavlja uporabnika in ne spletne strani, kot je to veljalo v preteklosti. Uporabniki

soustvarjajo vsebino s svojimi prispevki in postajajo vedno pomembnejši sestavni del

spleta. Ker je bil splet načrtovan glede na takratne standarde in potrebe, se danes

razvijalci soočajo z različnimi problemi, kako zagotoviti najboljšo uporabniško izkušnjo.

Do svetovnega spleta ne dostopamo več samo z domačih računalnikov, ampak se je ta

razširil tudi na mobilne telefone in tablične računalnike, kar pomeni, da nismo več omejeni

s prostorom, ampak si ţelimo dostopati do sveţih podatkov kjerkoli se nahajamo.

Posledično večja dostopnost pomeni tudi večje količine podatkov, ki se dnevno pretakajo

od in do uporabnikov. S stalno povezanostjo si ţelimo prenos podatkov takoj, ko se ti

pojavijo, saj je lahko podatek star nekaj minut ţe zastarel in ni več uporaben.

Razvijalci spletnih storitev so bili postavljeni pred nov izziv, kako zagotoviti čim boljši in

čim hitrejši pretok podatkov do uporabnikov. Iznajdljivost razvijalcev ne pozna meja in

tako ţe dolgo obstajajo načini, kako ponuditi vsebino uporabnikom brez njihove ponovne

zahteve po osveţitvi strani. Vso to sodobno miselnost in tehnologije so pomenljivo zdruţili

pod imenom splet v realnem času. Poznamo več pristopov, ki več ali manj dobro rešujejo

takšne probleme. Glavna načina sta tehnika povpraševanja in tehnika potiskanja podatkov

spletnim odjemalcem. Pri tehniki povpraševanja se avtomatsko proţijo povpraševanja v

določenem časovnem intervalu. Potiskanje podatkov pa nam omogoča takojšnje

obveščanje odjemalcev ob pojavitvi novih podatkov. Seveda je potrebno takojšnje

obveščanje vzeti z rezervo, saj moramo upoštevati tudi zakasnitve pri prenosu, vendar se

ţelimo s temi tehnologijami čim bolj pribliţati obveščanju v realnem času. Takšen pristop


2

do svetovnega spleta se je izkazal za tako pomembnega in zaţelenega, da se je konzorcij

W3C odločil za poenotenje standarda in v najnovejši različici označevalnega jezika

HTML5 najdemo dve tehnologiji, in sicer dogodki poslani s streţnika in spletne vtičnice, ki

obe omogočata enostavno implementacijo takšnih storitev na spletno stran.

V diplomski nalogi bomo obravnavali obstoječe tehnike potiskanja podatkov spletnim

odjemalcem in jih na podlagi testiranj in analiz kritično ovrednotili s stališča razvijalca.

Osredotočili se bomo na tri tehnike in tehnologije, in sicer 1) dolga povpraševanja, 2)

dogodke poslane s streţnika in 3) spletne vtičnice. Kot posebnost bomo obravnavali tudi

knjiţnico SignalR, ki zajema vse tri tehnike potiskanja podatkov in omogoča enostavno

implementacijo rešitev. Ugotoviti ţelimo, katere tehnologije so najprimernejše za uporabo,

najbolj poenostavijo razvoj spletnih aplikacij, so najučinkovitejše, so podprte v največji

meri in katere najbolj izrabijo streţniške vire. Pri testiranju se bomo omejili na

najpopularnejše spletne brskalnike, kot so Google Chrome, Internet Explorer, Mozzila

Firefox, Opera in Apple Safari. Podprtost bomo preverili tudi na mobilnih platformah

Android in Windows Phone1.

Z diplomsko nalogo ţelimo prispevati k boljšemu poznavanju koncepta realno-časovne

komunikacije med streţnikom in odjemalci in dognati, katere trenutno obstoječe

tehnologije so dovolj zrele in najprimernejše za uporabo v produkcijskih rešitvah.

1 Našteti brskalniki nimajo vsi pripadajočih mobilnih različic, prav tako ne obstajajo različice za obe

navedeni mobilni platformi, zato bo temu primerno brskalnik izločen iz testiranja.


3

2 SPLET V REALNEM ČASU

Svetovni splet postaja v našem vsakdanu vedno bolj vseprisoten. Do spletnih strani ne

dostopamo več samo z namiznih računalnikov, ampak se dostop seli na vedno več

mobilnih naprav, ki nam omogočajo, da do informacij dostopamo kjerkoli se nahajamo.

Včasih, ko smo dostopali do spletnih virov le z domačih računalnikov, hiter pretok

podatkov ni bil tako pomemben, saj smo novico prebrali, ko smo priţgali računalnik.

Danes pa smo lahko povezani na vsakem koraku in si navadno ţelimo dostopati do

novosti takoj, ko se pojavijo. Ponudniki spletnih storitev so zato primorani zagotoviti čim

boljšo uporabniško izkušnjo in čim hitrejše obveščanje uporabnikov.

Izraz splet v realnem času se nanaša na pravočasno obveščanje o dogodku, ki se je

zgodil. Pri obveščanju si ne ţelimo zakasnitev, ampak ţelimo doseči čim hitrejši odzivni

čas[9].

Splet temelji na principu zahteva-odgovor, kjer uporabniki z navigacijo po spletni strani

dostopajo do vsebin. Ko se vsebina prikaţe, vidijo le tisto vsebino, ki je bila dostopna v

trenutku podane zahteve. Če ţelijo dostopati do novih vsebin, morajo ponovno osveţiti

spletno stran. Takšen pristop predstavlja slabo uporabniško izkušnjo in se mu ţelimo z

uporabo tehnik spleta v realnem času izogniti (slika 2.1).

Slika 2.1 Uporabniško orientiran pristop[14]

Splet v realnem času je paradigma, ki temelji na potiskanju podatkov uporabnikom takoj,

ko so ti na voljo, namesto da bi oni ali programska oprema periodično preverjala, ali


4

obstajajo novosti. Takšno delovanje je mogoče zagotoviti na različne načine in z različnimi

tehnologijami. S tem pristopom ţelimo zagotoviti večjo vključenost uporabnikov in

zmanjšati obremenjenost streţniške infrastrukture[8].

Paradigma spleta se je premaknila od modela, kjer je bila spletna stran v središču

interakcije, k modelu osredotočenosti na uporabnika. Tako se vse interakcije začnejo in

končajo pri uporabniku. V današnjem času se je način interakcije s spletno stranjo

spremenil. Spletna stran ne čaka več uporabnika, da bo ta dostopal do njenih vsebin,

ampak ţeli avtomatsko ponuditi vsebino uporabniku, ne glede na to kje se nahaja oz. na

kateri napravi je dosegljiv[14] (slika 2.2).

Slika 2.2 Streţniško orientiran pristop[14]

Splet v realnem času ne predstavlja rešitev za vse probleme. V določenih primerih je

uporaba smiselna, v nekaterih pa uporaba ni primerna. Najenostavneje določimo

primernost uporabe tako, da pogledamo, kakšno vrsto podatkov imamo. Če se podatki

pogosto spreminjajo, obstaja velika moţnost, da je uporaba primerna. V največji meri se

pokaţe prednost uporabe tehnologije, kadar se podatki nenehno spreminjajo v določenih,

nekonsistentnih časovnih intervalih. Zaradi same zasnove tehnologije časovna pojavitev

novih podatkov ne predstavlja ovire, saj bo uporabnik obveščen, ko pride do spremembe.

Danes ţe kar nekaj spletnih strani uporablja tehnologije, ki omogočajo splet v realnem

času. Primeri takšne uporabe so Googlov takojšnji iskalnik, Facebook-ovo in Twitter-jevo

posodabljanje novic in objav. Obstaja tudi mnogo rešitev za spletno klepetanje in druga

instantna obveščanja. Iz dneva v dan pa smo priča novim načinom uporabe na različnih


5

področjih. Najpogostejša uporaba realno-časovnih tehnologij se pojavlja na straneh, ki

ponujajo dnevne novice, »bloganje« in spremljanje športnih rezultatov.

2.1 Primerjava tehnik povpraševanja in potiskanja podatkov

Ţe dolgo obstajata dva načina, ki omogočata pošiljanje podatkov spletnim odjemalcem.

Ta načina sta povpraševanje in potiskanje podatkov odjemalcem. Do prihoda HTML5 ni

obstajal standardiziran način komunikacij, ampak je bilo vse prepuščeno iznajdljivosti

razvijalcev. Problem predstavlja komunikacija med streţnikom in brskalnikom, saj se ta

vedno začne na strani odjemalca, ki streţniku pošlje zahtevo za prenos podatkov. Vsaka

interakcija med njima je neodvisna od drugih in vseh nadaljnjih interakcij. Med njima

odprta povezava ne obstaja; ta se takoj zapre, prav tako streţnik ne hrani stanja o

odjemalcu. Takšna shema omogoča dobro razširljivost, vendar oteţuje delovanje spleta v

realnem času[3].

S prihodom Spleta 2.0 so razvijalci dobili moţnost laţje implementacije tehnik potiskanja

podatkov. S Spletom 2.0 se prične vedno večja uporaba tehnologije AJAX, ki med

streţnikom in odjemalcem omogoča asinhrono izmenjavo podatkov v ozadju. Tako so se

pojavile prve rešitve povpraševanj, ki so omogočale dodatna povpraševanja, ki niso več

temeljila na poizvedbah uporabnika, ampak so se izvajale preko JavaScripta. Poizvedbe

in odgovori se pošiljajo preko XMLHttpRequest objektov in za prikaz ne potrebujejo

osveţevanja strani.

Tehnika povpraševanja predvideva, da odjemalec v določenih časovnih intervalih na

streţnik pošlje zahtevo, ali obstajajo novi podatki. Ta mu nemudoma odgovori, četudi ni

sprememb. Nato se čez določen čas spet izvedeta povpraševanje in odgovor o

spremembah. Glavni prednosti uporabe tehnologije potiskanja podatkov sta njena

enostavna izvedba in univerzalna uporaba: deluje v vsakem primeru, z vsemi brskalniki in

z vsemi streţniki, saj uporablja standardne HTTP funkcije[1]. Vendar uporaba ni vedno

primerna, saj je cena takšnega delovanja včasih previsoka. Število poizvedb se močno

poveča, v določenih primerih so poizvedbe celo nepotrebne, kar posledično vpliva na

večjo obremenjenost streţnika in lahko privede do zakasnitev pri prenosu podatkov [14].

Prav tako neprekinjeno vzpostavljanje povezave predstavlja veliko breme v smislu

pasovne širine in procesiranja zahtev na obeh koncih komunikacije. Obstajajo pristopi, ki

omogočajo premostitev teh pomanjkljivosti. Ena od takšnih je uporaba različnih časovnih

intervalov med poizvedbami. Interval se prilagaja trenutnim obremenitvam sistema ali


6

verjetnosti novih posodobitev. Takšen način je zelo preprost za uporabo in lahko bistveno

izboljša porabo virov[1].

Kljub vsem slabostim ne smemo zanemariti uporabe tehnik povpraševanja. Prednost

uporabe je v primeru, kadar ţelimo preprosto rešitev, ki jo je moč uporabiti povsod in v

vseh primerih in kadar ni potrebna visoka frekvenca posodobitev. V nekaterih primerih

uporaba povpraševanja ni primerna – npr. spletne klepetalnice, masovne spletne igre,

orodja za hkratno delo in katerakoli storitev, kjer ţelimo, da uporabnik prejme podatek v

trenutku, ko se ta pojavi na streţniku. Za takšne aplikacije ţelimo, da prevzame pobudo

streţnik in obvesti odjemalca o spremembah v trenutku, ko se te pojavijo in ne čakajo na

odjemalca, da ta pošlje zahtevo. Prav to je ideja tehnologij potiskanja podatkov.

Ţelimo si, da bi lahko streţnik obveščal vse odjemalce v realnem času. Idealno bi bilo, da

bi se med njimi vzpostavila povezava od točke do točke, kar pa iz varnostnih razlogov ni

mogoče. Obstaja več vmesnih ravni, kot so poţarni zidovi, usmerjevalniki in posredovalni

streţniki, ki takšno delovanje onemogočajo. Da bi se izognili temu, so se pojavile nekatere

tehnike, ki temeljijo na elementih, vgrajenih v spletne strani (Java, Flash, Silverlight

aplikacije). Te komponente običajno uporabljajo spletne vtičnice, s pomočjo katerih

zagotavljajo stalno povezavo s streţnikom. Vendar se od prihoda HTML5 standarda te

tehnologije vedno manj uporabljajo zaradi večjih varnostnih pomanjkljivosti in potrebe po

nalaganju dodatnih vključkov in vtičnikov v brskalnik[1].

Tehnologije potiskanja podatkov delujejo drugače kot tehnike povpraševanja. Med

streţnikom in odjemalcem se vzpostavi povezava, ki ostane odprta, dokler se ne pojavijo

spremembe. Ob novih informacijah se ti nemudoma pošljejo uporabnikom in ni potrebe po

dodatnih vzpostavitvah povezav ali povpraševanjih, ampak se uporabi ista povezava.

Samo delovanje je odvisno od uporabljene tehnike. Nekatere tehnike omogočajo stalno

odprto povezavo, ki se zapre šele, ko uporabnik zapusti spletno stran. Spet druge delujejo

na podoben način kot tehnike potiskanja, vendar s to razliko, da se ob povpraševanju

streţnik ne odzove z odgovorom takoj, ampak ostane povezava odprta do trenutka, ko

streţnik prejme podatke in se ti pošljejo odjemalcu. Tukaj ni več potrebe po intervalnih

povpraševanjih, ampak se po prejetju odgovora povezava ponovno vzpostavi in

odjemalec čaka na odgovor. Večina danes obstoječih tehnologij potiskanja podatkov

omogoča samo enosmerno komunikacijo s strani streţnika. Če ţelimo poslati podatke od


7

odjemalca k streţniku, moramo uporabiti tehnologijo AJAX. Trenutno dvosmerno

komunikacijo omogoča le tehnologija spletnih vtičnic, ki pa je še v fazi razvoja.

Slika 2.1.1 Primerjava tehnik povpraševanja in potiskanja podatkov[14]

Tehnike potiskanja rešujejo mnogo problemov, ki so prisotni pri tehnikah povpraševanja.

Izognemo se obremenitvam streţnika, ki nastanejo s konstantnim vzpostavljanjem novih

povezav. Vendar tudi te niso prizanesljive s streţniškimi viri, saj so povezave stalno

odprte, za kar je potrebno kar nekaj virov.


8

3 TEHNOLOGIJE

Splet se čedalje hitreje razvija in prav tako z njim tehnologije, ki nam omogočajo

komunikacijo in izdelavo spletnih strani. Vendar splet v realnem času v veliki meri

uporablja preizkušene tehnologije in protokole, ki mu omogočajo ţeleno delovanje.

3.1 HTTP protokol

HTTP protokol je sestavni del interneta, ki omogoča pošiljanje podatkov na spletu.

Definiran je bil leta 1996, njegova preprosta in vsestranska zasnova pa je do neke mere

odgovorna za uspeh in širitev spleta in interneta kot celote[1]. Primarno je namenjen

pošiljanju HTML datotek, omogoča pa tudi druge podatkovne formate, kot so tekstovne

datoteke, slike, avdio in video formati. Protokol je nadzorovan s strani W3C konzorcija, kar

zagotavlja standardiziran način uporabe na vseh napravah in brskalnikih.

Njegovo delovanje temelji na shemi zahteva-odgovor, ki se vedno začne na strani

odjemalca. Ta postopek se pogosto omenja kot model povpraševanja: ko odjemalec

potrebuje dostop do virov, ki jih streţnik gosti, namenoma vzpostavi povezavo s

streţnikom in zahteva ţelene podatke s pomočjo protokola HTTP. Streţnik izvede

zahtevo, vrne vir, ki je bil zahtevan, in povezava se nato takoj zapre. Vrnjena vsebina je

lahko zahtevana datoteka, rezultat procesa, izvedenega na strani streţnika, ali statusna

koda. Ob vsaki zahtevi se s strani odjemalca poleg zahteve pošlje tudi glava sporočila, ki

vsebuje dodatne informacije o odjemalcu in navodila streţniku, kako naj obravnava

zahtevo in na kakšen način naj vrne podatke. Po izvršeni zahtevi streţnik vrne sporočilo in

statusno kodo, ki pove brskalniku, na kakšen način se je končala zahtevana akcija. Če

odjemalec ţeli dostopati do novih virov, se postopek ponovi[1].

Proces se izvaja sinhrono, kar pomeni, da kadar odjemalec poda zahtevo za prenos

informacij, se, dokler ne prejme odgovora s strani streţnika, prestavi v stanje

pripravljenosti. S pomočjo tehnike AJAX lahko spremenimo način delovanja spletne strani

in omogočimo asinhrono pošiljanje in prejemanje podatkov. Z uporabo tehnike AJAX

lahko izmenjujemo informacije med odjemalcem in streţnikom brez ponovne osveţitve

strani. V določenem trenutku lahko odjemalec vzpostavi povezavo s streţnikom z uporabo

JavaScript-a, zahteva nov vir in posodobi le del strani[1]. Kljub takšnemu načinu delovanja

streţnik še vedno ne more sam dostopati do odjemalca, ampak je vedno odjemalec tisti,

ki vzpostavi povezavo in prične s komunikacijo.


9

Eden od razlogov za takšno delovanje je, da HTTP protokol deluje brez stanja, kar

pomeni, da se takoj, ko se zahteva izvede, povezava prekine, ne ohranijo se nobeni

podatki o odjemalcu. Komunikacija običajno poteka prek TCP/IP protokola, vendar se

lahko uporablja tudi katerikoli drug primeren protokol. Privzeto deluje preko vrat številka

80, obstaja pa moţnost drugačnih nastavitev in uporabe drugih prostih vrat[11]. Protokol

ima tri različice, vendar sta v praksi v uporabi le zadnji dve. Večina streţnikov še vedno

uporablja verzijo HTTP/1.0, ki omogoča le zahteve z enim odgovorom na povezavo.

Zaradi te omejitve se večina ponudnikov seli na najnovejšo verzijo HTTP/1.1. Sedanja

različica dodaja nekaj dodatnih funkcij prejšnji različici 1.0. Najpomembnejše so vključitev

trajnih povezav, razdrobljeno kodiranje prenosa in napredno pomnjenje[11].

3.1.1 HTTP zahteve

GET: Najbolj pogosta metoda za pridobitev vsebine spletne strani.

HEAD: Identično kot GET, vendar streţnik ne pošlje vsebine, ampak odgovori le z

glavo datoteke.

POST: Metoda za pošiljanje podatkov s strani odjemalca k streţniku.

PUT: Uporablja se za pošiljanje datotek na ciljni spletni streţnik.

DELETE: Omogoča brisanje datotek na strani streţnika.

TRACE: Vrne pot zahtevka, po kateri potuje od odjemalca k streţniku.

OPTIONS: Vrne seznam HTTP zahtevkov, ki jih streţnik podpira.

CONNECT: Uporablja se za vzpostavitev SSL povezave[6].

3.2 TCP protokol

TCP protokol spada pod transportni sloj, ki je odgovoren za vzpostavljanje in vzdrţevanje

povezave med dvema končnima gostiteljema. Internetne aplikacije, kot so spletni

brskalniki, odjemalci FTP in pregledovalniki elektronske pošte, so vse odvisne od

protokola TCP, ki brez napak prenaša velike količine podatkov[16].

Protokol nadzora nad prenosom (ang. Transmission Control Protocol) se uporablja za

zanesljiv pretok podatkov med gostitelji in omreţji. TCP podatke razdeli na koščke, jim

doda informacije, ki so potrebne, da podatki najdejo pot do destinacije in nato koščke

ponovno sestavi na koncu povezave. Koščki se imenujejo datagrami[16]. TCP doda k

podatkom aplikacijskega sloja v datagram glavo, ki vsebuje številko vrat, začetno število

datagrama in kontrolno vsoto, ki sluţi za preverjanje pravilnosti prenosa. Protokol poskrbi

za pravilnost in popolnost prenosa podatkov preko interneta. Ob končanem prenosu se


10

preveri, ali so bili poslani vsi podatki in ali so prispeli na cilj nespremenjeni. V primeru

nepravilnega prenosa se pošlje ponovna zahteva za prenos izgubljenih podatkov. Pred

samim prenosom protokol poskrbi za razdrobitev večjih podatkov na manjše dele in ob

prejemu na strani prejemnika za ponovno zdruţitev podatkov v celoto.

TCP protokol omogoča vzpostavitev povezave med dvema strojema preko zanesljive

povezave, ki jo vzpostavi z uporabo metode trosmernega usklajevanja (ang. three-way

handshake). Najprej se vzpostavi povezava med odjemalcem in pošiljateljem. Pri

povezavi so določeni odjemalčev IP naslov in vrata ter pošiljateljev naslov in vrata, na

katerih posluša storitev streţnika. IP naslov povezan z določenimi vrati tvori vtičnico (ang.

socket) in par odjemalčeve in pošiljateljeve vtičnice tvori povezavo TCP, ki je edinstveno

določena. Glava paketa TCP vsebuje izvorni IP naslov in vrata, ciljni IP naslov in vrata,

zaporedno številko paketa, številko potrditve in kontrolne zastavice[16].

3.3 ASP.NET MVC 4

ASP.NET MVC je ogrodje, ki temelji na Microsoft .NET platformi (slika 3.3.1) in omogoča

razvijalcem izgradnjo dobro strukturiranih spletnih aplikacij. Ogrodje je bilo izdelano kot

alternativa ASP.NET Web Forms. Od leta 2007, ko je bilo ogrodje ASP.NET MVC prvič

predstavljeno, močno pridobiva na popularnosti. Microsoft ţe lep čas ponuja razvojna

orodja in ogrodja za razvoj spletnih strani, vendar ASP.NET MVC s poudarkom na čisti

kodi, ločitvi aplikacijskih nivojev in testiranju prinaša veliko novosti in predstavlja velik

premik naprej. Do sedaj so izšle 4 različice ogrodja.

Slika 3.3.1 Ogrodje ASP.NET MVC[10]


11

Ogrodje temelji na MVC (Model - View - Controller) načrtovalskem vzorcu, ki je sestavljen

iz treh delov, in sicer Model - Pogled - Krmilnik (slika 3.3.2). Model MVC je namenjen

predvsem ločitvi posameznih stopenj izdelave aplikacije. Omogoča nam, da ločimo pogled

(View) – predstavitev uporabniškega vmesnika – od podatkov in programske logike. S tem

pospešimo razvoj same aplikacije in izboljšamo prenosljivost kode. Ena bistvenih

prednosti MVC je izboljšava testiranja aplikacij s premikom programske logike iz Pogleda

v Krmilnik.

Slika 3.3.2 Načrtovalski vzorec MVC[10]

Vzorec sestavljajo trije deli:

Model: Model vsebuje samo podatke, ki so izolirani od vseh ostalih elementov in

programske logike v naši aplikaciji. Modelu ni potrebno vedeti, od kod so prišli

podatki. Lahko jih prenesemo z uporabo WCF servisov, WCF RIA servisov,

RESTful servisov ali neposredno iz SQL podatkovne baze. Model lahko vsebuje

tudi poslovno logiko za verifikacijo in preverjanje pravilnosti podatkov.

Pogled: Zajema vizualno predstavitev modela in vsebuje gradnike, ki sestavljajo

spletno stran. Običajno se uporablja označevalni jezik, kot na primer HTML in

CSS, ki ga brskalnik nato prikaţe.

Krmilnik: Predstavlja koordinatorja, ki zagotavlja povezavo med pogledom in

podatkovnim modelom. Odgovoren je za obdelavo vnesenih podatkov, akcije nad

modelom in odločanje o tem, katere akcije se morajo izvesti — npr. prikaz pogleda

ali preusmeritev na drugo stran.


12

Koncept prinaša mnogo novosti pri izdelavi novih spletnih aplikacij. Razvijalci morajo

prilagoditi način razmišljanja novemu konceptu, saj ne uporabljajo več standardnih ASPX

strani in elementov, ni več pošiljanja »povratnih klicev« in zapletenih stanj strani[10].

Namesto tega se osredotočimo na izdelavo krmilnikov, dejanj, ki jih izvajajo krmilniki in na

izgled spletne strani. ASP.NET MVC še vedno temelji na ASP.NET, zato lahko uporabimo

HTTP ročke in HTTP module, prav tako pa lahko v eni spletni aplikaciji zdruţimo Web

Forms in MVC aplikacijo, ki tečeta druga ob drugi[10].

Eden od ključnih elementov novega ogrodja ASP.NET MVC je prevajalnik Razor. Nudi

nam kratek in jedrnat način za pisanje kode in označevalnega jezika v isti datoteki.

Omogoča enostaven prehod med kodo in označevalnim jezikom, kar pripomore k laţjemu

sledenju in razumevanju kode.

3.4 Knjižnica jQuery

Knjiţnica jQuery je ogrodje zgrajeno s pomočjo JavaScript-a in ni samostojni programski

jezik. jQuery lahko uporabljamo tudi brez predhodnega poznavanja jezika JavaScript.

Namen knjiţnice jQuery je olajšati razvoj in uporabo JavaScript-a na spletni strani. jQuery

zajema pogosto uporabljene akcije, ki jih ţelimo izvesti na spletni strani in zahtevajo veliko

vrstic kode JavaScript za izvršitev, in jih ovije v metodah, ki jih lahko kličete z eno vrstico

jQuery kode.

Omogoča nam manipulacijo z:

HTML/DOM elementi,

CSS elementi,

HTML dogodki,

izdelavo animacij in posebnih učinkov,

poenostavlja uporabo AJAX-a[7].


13

4 TEHNIKE POTISKANJA PODATKOV SPLETNIM

ODJEMALCEM

Uporaba tehnik potiskanja podatkov spletnim odjemalcem postaja vedno bolj popularna

tako pri uporabnikih kot pri ponudnikih storitev. Uporabniki si ţelijo vedno večje

interaktivnosti na spletni strani, ponudniki pa si ţelijo zagotoviti čim hitrejšo objavo

podatkov. S pomočjo potiskanja podatkov lahko uspešno rešujemo nekatere scenarije,

upoštevati pa moramo, da tehnike premorejo kar nekaj omejitev, ki jih prinaša uporaba

storitev preko HTTP protokola.

Obstaja več metod, s katerimi lahko doseţemo ţelen učinek potiskanja podatkov. Danes

razvijalci uporabljajo tehnike, kot so Comet, HTTP Push, Reverse Ajax, Ajax Push itd.

Obstajajo pa tudi nekatere starejše tehnike, ki prav tako temeljijo na HTTP protokolu, kot

so Long polling, XHR streaming ali Forever Frame[1].

Osredotočili se bomo na eno izmed ţe uveljavljenih tehnologij in na dve novejši

tehnologiji, ki sta še v fazi nastajanja. Obravnavali bomo tri tehnike potiskanja podatkov, in

sicer dolgega povpraševanja (Long polling), dogodke poslane s streţnika (Server - sent

events) in spletne vtičnice (Websockets). Kot posebnost bomo obravnavali tudi knjiţnico

SignalR, ki omogoča realno-časovno komunikacijo, zajema vse zgoraj navedene tehnike

in predstavlja abstrakcijo niţje leţečih tehnik.

4.1 Tehnika dolgega povpraševanja (Long polling)

Tehnika dolgega povpraševanja je najstarejša tehnika med tremi obravnavanimi

tehnikami. Za svoje delovanje izkorišča prednosti HTTP protokola in tehnologije AJAX.

Zaradi tega jo je mogoče uporabiti v skoraj vseh brskalnikih in na vseh platformah, saj ne

potrebuje dodatnih vtičnikov ali posebnih tehnologij, ki so podprte le v novejših brskalnikih.

Uporaba te tehnike je pogosta, vendar jo zaradi nekaterih pomanjkljivosti v zadnjem času

izpodrivajo novejše tehnologije. Dolgo povpraševanje uporabimo kot nadomestno

tehnologijo v veliko primerih, kjer se najprej skuša uporabiti novejšo tehnologijo, kot npr.

spletne vtičnice, in če brskalnik ne podpira te tehnologije, delovanje preide na uporabo

dolgega povpraševanja.

Dolgo povpraševanje uporablja za delovanje tehnologijo Ajax, ki je tehnika programiranja,

ki omogoča spletnim streţnikom pošiljanje podatkov odjemalcem brez dodatne zahteve


14

po prenosu s strani odjemalca[5]. Dolgo povpraševanje deluje po principu zahteva-

odgovor. Vsako povpraševanje vedno začne odjemalec, ki vzpostavi povezavo s

streţnikom in nato čaka na odgovor. Streţnik nato počaka z odgovorom, dokler se ne

pojavijo novi podatki ali ne poteče čas poizvedbe. Streţnik pusti povezavo odprto toliko

časa, dokler se ne pojavijo spremembe in ne odgovori takoj, kot pri normalnih HTTP

poizvedbah. Ko odjemalec prejme odgovor, takoj pošlje novo poizvedbo in ta spet ostane

odprta, dokler se na streţniku ne pojavijo spremembe (slika 4.1.1).

Slika 4.1.1 Delovanje tehnike dolgega povpraševanja[15]

Uporabimo lahko trajno ali navadno HTTP povezavo. Uporaba trajne HTTP povezave

prepreči dodatno obremenitev streţnika, saj ni potrebno ob vsaki dodatni poizvedbi

vzpostaviti nove TCP/IP povezave[18]. Lahko pa predstavlja dodatno obremenitev v

smislu vzdrţevanja povezave in hitro lahko doseţemo maksimalno število dovoljenih

odprtih povezav na streţniku in tako onemogočimo vzpostavitev novih.

Glavna prednost uporabe odprte povezave dolgega povpraševanja je manjša zakasnitev

pri posodabljanju podatkov, saj streţnik podatke pošlje preko ţe vzpostavljene povezave,

tako da odjemalec prejme spremembe v realnem času. Prav tako je izraba streţniških

virov veliko boljša, ker je število odprtih in zaprtih povezav v primerjavi s tehnikami

povpraševanja manjše. Uporaba takšnega pristopa pa prinaša tudi nekaj slabosti. Vsaka

zahteva in odgovor predstavljata celotno HTTP sporočilo in tako vsebuje celotno glavo

sporočila. Za prenos kratkih sporočil lahko glava sporočila predstavlja skoraj celotno

sporočilo, kar prinese dodatno obremenitev na streţniku in povezavi. Ena izmed teţav je

tudi ta, da mehanizem odpre in zapre veliko število povezav med odjemalcem in

streţnikom. Za vsako vzpostavljeno povezavo se rezervirajo streţniški viri, ki prispevajo k

dodatni obremenitvi streţnika. Temu se lahko delno izognemo z uporabo trajne povezave,

ki omogoča ponovno uporabo ţe obstoječe povezave[18].


15

Večji problem nastane v primeru, kadar je streţnik bolj zaseden in mora obravnavati večje

število hkratnih povezav. Če dodatna obremenitev povzroči počasno delovanje streţnika

ali odjemalca, potem se začnejo nova sporočila nabirati in se pošljejo šele, ko se

obremenitev sprosti. Če se je nabralo večje število sporočil, se te pošljejo kot eno

sporočilo, kar kratkotrajno razbremeni streţnik, vendar se posodobitve niso izvedle v

realnem času[18].

Poraba virov je nekoliko višja kot pri drugih tehnikah. Razlog za to je večje število odprtih

in zaprtih povezav, če je stopnja posodobitve visoka. Tudi čas, ki je potreben za

vzpostavitev povezave pomeni, da lahko pride do nekaj zakasnitve med obvestili[1].

4.2 Tehnologija dogodkov poslanih s strežnika (Server - sent

events)

Dogodki poslani s streţnika (v nadaljevanju SSE), znani tudi kot Server – sent events ali

EventSource, je drugi standard za potiskanje podatkov spletnim odjemalcem, ki ga

najdemo v HTML5 in je koordiniran s strani W3C konzorcija. Trenutno je standard še v

nastajanju in zato ga še ne podpirajo vsi brskalniki.

Dogodki poslani s streţnika so bili zasnovani za učinkovito delovanje. Pri komuniciranju s

pomočjo SSE lahko streţnik pošlje podatke odjemalcu kadarkoli, brez potrebe po

interakciji uporabnika. Posodobitve se bodo poslale s streţnika do odjemalca, ko se te

zgodijo, saj je med streţnikom in odjemalcem vzpostavljen enosmerni kanal [2] (slika

4.2.1).

Slika 4.2.1 Delovanje tehnike dogodkov poslanih s streţnika

Za implementacijo je potreben JavaScript API in ne potrebuje nobenih sprememb na niţje

leţečih protokolih, saj uporablja HTTP protokol. Implementacija je enostavnejša kot v

primeru standarda spletnih vtičnic in ne potrebuje dodatnih streţniških nastavitev.


16

Spletne vtičnice na drugi strani zahtevajo polno dvosmerno povezavo in streţnik, ki

podpira takšen protokol. Poleg tega SSE omogočajo nekatere funkcije, ki jih spletne

vtičnice ne – vzpostavljanje avtomatske povezave, identifikatorje dogodka in moţnost

pošiljanja poljubnih dogodkov[2].

Vsa komunikacija poteka preko HTTP protokola. Edina razlika v primerjavi z normalno

HTTP povezavo je uporaba »Content-Type text/event-stream« direktive v glavi

sporočila, ki pove streţniku, da mora povezava ostati odprta, saj se bo uporabljala za

konstantno pošiljanje dogodkov ali sporočil s streţnika[1].

Ko kreiramo EventSource objekt, se s tem avtomatsko prijavimo na obvestila s strani

streţnika. Pred vzpostavitvijo povezave preverimo, ali brskalnik podpira SSE in temu

primerno ukrepamo.

Vgrajene so tudi tri pomembnejše metode, ki nam omogočijo enostavno preverjanje ali je

bila povezava vzpostavljena ali se je prekinila in metoda za prejemanje sporočil.

Do prejetih sporočil lahko nato dostopamo s funkcijo onmessage, kamor se s povratnim

klicem pošljejo podatki.

if (!!window.EventSource) { var source = new EventSource('api/EventSource'); } else { console.log("Brskalnik ne podpira Dogodke poslane s strežnika"); }

source.addEventListener('message', function (e) { console.log(e.data); }, false); source.addEventListener('open', function (e) { console.log("Povezava vzpostavljena"); }, false); source.addEventListener('error', function (e) { if (e.readyState == EventSource.CLOSED) { console.log("Povezava prekinjena"); } }, false);

Izvorna koda 4.2.2 Metode tehnologije dogodkov poslanih s streţnika

Izvorna koda 4.2.1 Vzpostavitev povezave dogodkov poslanih s streţnika


17

Trenutno skoraj vsi brskalniki podpirajo ta standard, razen Internet Explorer, kar omejuje

njegovo uporabo v produkcijskih aplikacijah. Če gledamo na to z razvojnega vidika,

ugotovimo, da ker tehnologija temelji na HTTP protokolu, to močno poenostavi

implementacijo in uporabo. Prav tako je pomembno izpostaviti omejitve, ki jih prinaša

enosmerna komunikacija. Tehnologija nam ne omogoča pošiljanja podatkov odjemalca

streţniku, ampak moramo za to uporabiti druge tehnike[1].

4.3 Tehnologija spletnih vtičnic (Websockets)

Standard spletnih vtičnic je del HTML5 API-ja, ki ga je določil W3C konzorcij in temelji na

komunikacijskem protokolu, za katerega skrbi IETF.

Standard omogoča vzpostavitev trajne povezave, ki jo začne odjemalec. Med njima se

vzpostavi dvosmerni kanal, preko katerega lahko izmenjujeta podatke. Tehnologija je še v

stanju nastajanja, kar pomeni, da se standard še razvija in spreminja skozi različice in

tako še ni najbolj primeren za uporabo v razvojnem okolju.

Slika 4.3.1 Delovanje tehnike spletnih vtičnic[15]

Podporo za Websockets najdemo le v najnovejših različicah brskalnikov, kot so Internet

Explorer 10, Google Chrome in Mozzila Firefox, nekateri pa ga podpirajo samo delno

(Opera, Apple Safari). Poleg problema različnih implementacij standarda s strani

proizvajalcev spletnih brskalnikov, standard uporablja tudi lasten neodvisni protokol za

komunikacijo (čeprav se sprva vzpostavi povezava preko HTTP), kar pomeni, da so

potrebne tudi spremembe na strani streţnika. Do izida zadnje Microsoftove različice

tehnologije ni bilo mogoče enostavno uporabiti, kar pa se je spremenilo z izidom Internet

Explorerja 10, ASP.NET 4.5, WCF in IIS8[17]. Trenutno je gostovanje spletnih vtičnic

omejeno le na spletni streţnik IIS 8 in operacijska sistema Windows 8 ali Windows Server

2012.


18

Z vidika razvijalca spletne vtičnice ponujajo JavaScripta API, ki je enostaven za uporabo.

Omogoča nam vzpostavitev povezave, pošiljanje sporočil in prekinitev povezave, kakor

tudi metode za prejemanje sporočil na strani odjemalca.

Povezavo vzpostavimo preko url naslova, ki ga definiramo z uporabo predpone ws:/ /, s

čimer obvestimo streţnik, naj se vzpostavi povezava preko spletnih vtičnic. Brez dvoma je

Websocket tehnologija prihodnosti za potiskanje podatkov v realnem času.

4.4 Knjižnica SignalR

ASP.NET SignalR je nova knjiţnica, namenjena ASP.NET razvijalcem, ki omogoča, da

enostavno dodamo funkcionalnost potiskanja podatkov v spletno aplikacijo. Ogrodje

SignalR nam omogoča gradnjo interaktivnih, večuporabniških in realno-časovnih spletnih

aplikacij, saj močno temelji na uporabi asinhronih tehnik, s čimer ţeli doseči visoko

učinkovitost uporabe.

Prvotno je bil osebni projekt Davida Fowlerja in Damiana Edwardsa, članov razvojne

ekipe ASP.NET pri Microsoftu, vendar je zaradi svoje popularnosti zdaj uradno vključen v

ogrodje ASP.NET[1] (slika 4.4.1). Projekt še vedno ostaja odprtokoden, kar pomeni, da

lahko enostavno dostopamo do izvorne kode in dodajamo lastne prispevke in popravke. V

času pisanja diplomske naloge je zadnja različica 1.1.3., vendar popularnost knjiţnice

močno narašča in s tem tudi njen razvoj.

var ws = new WebSocket("ws://localhost:9998/Test"); ws.onopen = function () { ws.send("Sporočilo iz strani odjemalca"); }; ws.onmessage = function (evt) { var sporocilo = evt.data; console.log("Prejeto sporočilo: " + sporocilo); }; ws.onclose = function () { console.log("Povezava prekinjena"); }

Izvorna koda 4.3.2 Metode tehnike spletnih vtičnic


19

Slika 4.4.1 Umeščenost tehnologije SignalR v ogrodje ASP.NET

SignalR predstavlja abstrakcijo niţje leţečih nivojev in nam s tem daje vtis, da delamo

samo s trajno odprto povezavo[1]. Pri implementaciji nam ni potrebno skrbeti za

posamezne tehnike in protokole kot pri ostalih implementacijah tehnologij potiskanja

podatkov, ampak nam omogoča, da se osredotočimo le na poslovno logiko, za vse ostalo

poskrbi knjiţnica. Za doseganje tega SignalR vključuje komponente, ki poskrbijo za obe

strani komunikacije tako na streţniški strani kot na strani odjemalca.

Kot smo ţe spoznali v diplomski nalogi, je velik problem uporabe posameznih tehnologij

ravno v nepodprtosti v brskalnikih in posameznih napravah. SignalR se ţeli temu izogniti

tako, da se ob vzpostavitvi povezave najprej preveri, katera tehnika je najprimernejša za

uporabo na strani odjemalca in na strani streţnika. Ko se določi tehnika potiskanja

podatkov, se vzpostavi povezava, ki je stalno odprta. Omogoča nam tudi samodejno

upravljanje prekinitve povezave in ponovno vzpostavitev, kadar je to potrebno.

Slika 4.4.2 Podprte tehnologije SignalR

SignalR zajema tehnike Neskončni okvir (Forever frame), Dolgo povpraševanje (Long

polling), Dogodke poslane s streţnika (Server - sent events) in Spletne vtičnice

(Websockets), s pomočjo katerih zagotavlja stalno povezanost. Uporaba tehnike se določi

na podlagi nekaterih dejavnikov, kot je podprtost tehnologije na obeh koncih povezave[1].

SignalR vedno poskuša uporabiti najbolj učinkovito tehnologijo in tako prične najprej z

Websockets in nato počasi prehaja na druge tehnologije, dokler ne najde tiste, ki jo je

mogoče uporabiti. Določitev tehnike se izvede samodejno v začetni fazi komunikacije med


20

odjemalcem in streţnikom, ki je znana kot »pogajanje«. Omogoča nam tudi, da sami

določimo, kateri protokol ţelimo uporabiti.

Za določitev uporabe tehnike je določen naslednji postopek:

1. Če je brskalnik Internet Explorer 8 ali starejša verzija ali če je omogočena uporaba

JSON, potem se uporabi Long polling.

2. Če ni omogočena uporaba JSON in tako odjemalec kot streţnik podpirata

Websockets, potem se bodo uporabili Websockets.

3. Če odjemalec ali streţnik ne podpirata Websockets in so podprti Server-sent

events, potem se bodo uporabili le-ti.

4. Če ni podprta uporaba Server-sent events, potem poskusi uporabiti Forever frame.

5. Če nič od zgoraj naštetega ni podprto, potem se uporabi Long polling.

Preko abstrakcije nam SignalR ponuja enoten programski model, ki je neodvisen od

uporabljene tehnike. Kot razvijalci izvajamo svoje storitve na navidezni povezavi, ki jo

vzpostavi ogrodje. Ni pomembno ali je uporabljeno dolgo povpraševanje ali spletne

vtičnice, vedno lahko uporabimo isti API. Poleg svoje enostavne uporabe prinaša tudi

druge prednosti, ki nam omogočajo, da se osredotočimo na načrtovanje naših storitev,

SignalR pa poskrbi za upravljanje povezav in specifike odjemalca ter streţniške

programske opreme.

SignalR ima preprost API za izvajanje RPC klicev iz .NET kode, s pomočjo katerih lahko

izvajamo JavaScript funkcije, ki se nahajajo v brskalniku[4]. Vključuje tudi sporočilno vrsto,

ki poskrbi za upravljanje prenosa podatkov in odprtih povezav, kar pomeni, da lahko

streţnik sledi, koliko povezav je odprtih, kar mu omogoča enostavno pošiljanje sporočil

vsem odjemalcem, ki so trenutno povezani. Sporočila lahko pošljemo tudi le delu

odjemalcev. Poleg tega vsebuje tudi dodelane knjiţnice na strani odjemalca, ki omogočajo

enostavno pošiljanje ali prejemanje podatkov. S pomočjo sporočile vrste, SQL streţnika

ali podatkovno orientiranega streţnika Redis, je SignalR zmoţen vzdrţevati tudi do več

tisoč hkratnih povezav[4].

Knjiţnica SignalR vsebuje dva modela, preko katerih poteka komunikacija: »Persistent

connection« in »Hub«.


21

Persistent connection:

Persistent connection predstavlja končno točko za neposredno pošiljanje podatkov in daje

razvijalcu neposreden dostop do komunikacijskega protokola[4].

Hub:

Hub leţi na višjem nivoju in temelji na Connection API, ki omogoča neposredno

komunikacijo med odjemalcem in streţnikom[4]. Odjemalcem omogoča enostavno

klicanje metod, ki se nahajajo na streţniku, kot tudi klicanje metod s streţnika na strani

odjemalca. Uporaba Hub-a nam omogoča uporabo tipiziranih parametrov.

Kadar metoda, ki se nahaja na strani streţnika, pokliče metodo na strani odjemalca, se

pošlje paket, ki vsebuje ime in parametre metode, ki se naj izvede. Parametri so privzeto

serializirani z uporabo standarda JSON. Odjemalec nato poišče pripadajočo metodo, ki se

nato izvede.

Slika 4.4.3 Arhitektura knjiţnice SignalR

S knjiţnico SignalR lahko enostavno razvijemo večuporabniške aplikacije, ki omogočajo

pošiljanje podatkov v realnem času.


22

5 PODPRTOST TEHNOLOGIJ V BRSKALNIKIH

Za posamezno tehnologijo smo ţeleli ugotoviti, kakšna je podprtost v brskalnikih, ki so v

največji meri v uporabi danes. V vzorec smo zajeli zadnjih 15 verzij posameznega

brskalnika, če pa brskalnik premore manjše število verzij, smo obravnavali vse.

Legenda barv:

Tabela 5.1 Podprtost tehnike dolgega povpraševanja v spletnih brskalnikih

6 16 9 9 3.1 9 28 22 10 3.2 2.1

7 17 10 9.5 3.2 10 11 4.0 2.2

8 18 11 10 4.0 11.1 4.2 2.3

9 19 12 10.5 5 11.5 5.0 3.0

10 20 13 10.6 5.1 12 6.0 4.0

11 21 14 11 6 12.1 7.0 4.1

22 15 11.1 7 14 4.2

23 16 11.5

24 17 11.6

25 18 12

26 19 12.1

27 20 15

28 21 16

29 22

30 23

Popolna podpora Delna podpora Ne podpira


23

V primeru podpore izvajanja Dolgega povpraševanja v mobilnih brskalnikih je potrebno

upoštevati način implementacije rešitve. Nekatere starejše različice mobilnih brskalnikov

različno izvajajo JavaScript kodo in v nekaterih primerih ne podpirajo XMLHttpRequest

objektov. Kadar ţelimo nuditi podporo za starejše različice brskalnikov, moramo temu

ustrezno prilagoditi programsko kodo. V najnovejših različicah mobilnih brskalnikov te

teţave ni, saj je njihovo delovanje primerljivo z namiznimi različicami.

Tabela 5.2 Podprtost tehnologije dogodkov poslanih s streţnika v brskalnikih[12]

6 16 9 9 3.1 9 28 22 10 3.2 2.1

7 17 10 9.5 3.2 10 11 4.0 2.2

8 18 11 10 4.0 11.1 4.2 2.3

9 19 12 10.5 5 11.5 5.0 3.0

10 20 13 10.6 5.1 12 6.0 4.0

11 21 14 11 6 12.1 7.0 4.1

22 15 11.1 7 14 4.2

23 16 11.5

24 17 11.6

25 18 12

26 19 12.1

27 20 15

28 21 16

29 22

30 23


24

Tabela 5.3 Podprtost tehnologije spletnih vtičnic[13]

6 16 9 9 3.1 9 28 22 10 3.2 2.1

7 17 10 9.5 3.2 10 11 4.0 2.2

8 18 11 10 4.0 11.1 4.2 2.3

9 19 12 10.5 5 11.5 5.0 3.0

10 20 13 10.6 5.1 12 6.0 4.0

11 21 14 11 6 12.1 7.0 4.1

22 15 11.1 7 14 4.2

23 16 11.5

24 17 11.6

25 18 12

26 19 12.1

27 20 15

28 21 16

29 22

30 23

Podprtost uporabe knjiţnice SignalR v današnjih spletnih brskalnikih moramo obravnavati

malo drugače. Ker knjiţnica sama poskrbi za izbiro tehnike, preko katere se bo izvajal

prenos podatkov, lahko pričakujemo, da se bo izbrala podprta tehnika in bomo knjiţnico

lahko uporabili z vsemi brskalniki. Potrebno je upoštevati tudi, da je za delovanje nujno

potrebna uporaba knjiţnice jQuery, kar je pogoj, da brskalnik podpira uporabo le-te. Pri

podprtosti je potrebno upoštevati, da lahko knjiţnica deluje v starejših različicah spletnih

brskalnikov, vendar ni zagotovila, da bo delovala pravilno, saj je uradno podprta le v

zadnjih dveh najnovejših različicah, v primeru kadar uporabljamo zadnjo uradno izdajo

knjiţnice.


25

Tabela 5.4 Podprtost knjiţnice SignalR v brskalnikih[19]

6 16 9 9 3.1 9 28 22 10 3.2 2.1

7 17 10 9.5 3.2 10 11 4.0 2.2

8 18 11 10 4.0 11.1 4.2 2.3

9 19 12 10.5 5 11.5 5.0 3.0

10 20 13 10.6 5.1 12 6.0 4.0

11 21 14 11 6 12.1 7.0 4.1

22 15 11.1 7 14 4.2

23 16 11.5

24 17 11.6

25 18 12

26 19 12.1

27 20 15

28 21 16

29 22

30 23


26

6 IMPLEMENTACIJA TEHNOLOGIJ V ASP.NET MVC

Kot primer testne spletne aplikacije smo implementirali simulacijo parkirišča, kjer so

prikazana trenutno prosta mesta. Podatki o prostih in zasedenih mestih se pošiljajo v

naključnih intervalih, ki se nato prikaţejo na spletni strani.

Slika 6.1 Spletna aplikacija simulacije parkirišča

Implementacije vseh tehnik in tehnologij so sestavljene iz dveh delov – na strani

odjemalca in na strani streţnika. V vseh primerih se za implementacijo na odjemalčevi

strani uporablja knjiţnica jQuery, ki poenostavi dostop do elementov strani in streţniških

metod. Implementacija na strani streţnika se razlikuje od primera do primera. Nekateri so

enostavnejši za implementacijo, za nekatere moramo v celoti poskrbeti sami, za druge

obstajajo namenske knjiţnice.

Za obveščanje o spremembah na strani streţnika smo implementirali razred z

načrtovalskim vzorcem Edinec, v katerem se nahaja upravitelj dogodkov (ang.

EventHandler), ki obvesti vse odjemalce o spremembah, ko se te pojavijo. Z izbiro

takšnega pristopa je bilo potrebno prilagoditi način implementacije posameznih tehnik, saj

smo morali upoštevati, da se lahko v toku izvajanja ustvari več primerkov posameznih

kontrolnikov in smo morali ločiti obveščanje o spremembah od obveščanja uporabnikov.


27

6.1 Dolgo povpraševanje (Long polling)

Za implementacijo dolgega povpraševanja smo uporabili asinhron kontrolnik (ang.

AsyncController), ki nam omogoča, da ob vzpostavitvi povezave vzdrţujemo odprto

povezavo, dokler se ne pojavijo spremembe. To storimo tako, da ob začetnem

povpraševanju povečamo število čakajočih povezav, s tem si zapomnimo, da smo prejeli

zahtevo, shranijo se vsi podatki o zahtevi in odjemalcu, nato pa se nit, ki je obravnavala

zahtevo, vrne nazaj v bazen niti in lahko obravnava drugo zahtevo (izvorna koda 4).

Ko pride do sprememb in ţelimo obvestiti uporabnike, pošljemo objekt upravljavcu

asinhronih operacij, ki jih nato posreduje odjemalcu. To operacijo lahko opravi ista nit, ki je

vzpostavila povezavo, ali katera koli druga nit iz bazena. Ob odgovoru zmanjšamo število

čakajočih povezav in pošljemo podatke odjemalcu (izvorna koda 5).

Pred pošiljanjem odgovora lahko pretvorimo podatkovni niz v format JSON, lahko pa

uporabimo tudi katerikoli drug format – od XML do navadnega podatkovnega niza.

Na strani odjemalca smo za implementacijo funkcionalnosti uporabili knjiţnico jQuery,

preko katere proţimo AJAX zahtevke in prejemamo odgovore (izvorna koda 6).

public void IndexAsync() { AsyncManager.OutstandingOperations.Increment(); }

private void upravitelj_Obvesti(object sender, UpraviteljParkirisca.Arg e) { AsyncManager.Parameters["lokacija"] = e.Lokacija; AsyncManager.OutstandingOperations.Decrement(); }

Izvorna koda 6.1.1 Dolgo povpraševanje: vzpostavitev povezave

Izvorna koda 6.1.2 Dolgo povpraševanje: obvestimo nit o zaključku operacije

public JsonResult IndexCompleted(ParkirniProstor lokacija) { return this.Json(lokacija); }

Izvorna koda 6.1.3 Dolgo povpraševanje: pošiljanje odgovora


28

6.2 Dogodki poslani s strežnika (Server – sent events)

Pri implementaciji dogodkov poslanih s streţnika je potrebno dodati kontrolnik, ki poskrbi

za vzpostavitev novih povezav. Za obravnavanje vzpostavitev smo definirali API kontrolnik

(ang. ApiController), ki je podoben navadnemu ASP.NET MVC kontrolniku, vendar deluje

s to razliko, da ne servira pogledov, ampak poskrbi za serializacijo podatkov in vrača

samo podatkovne nize.

Pošiljanje dogodkov s streţnika vsebuje dve pomembni metodi. Prva je metoda Get, ki

poskrbi za pravilno vzpostavitev povezave med odjemalcem in streţnikom (izvorna koda

7). Ko prejme zahtevo za povezavo, kreira odgovor s ključnim nizom "text/event-stream"

v glavi odgovora, ki pove, da naj povezava ostane odprta. V naslednjem koraku se izvede

metoda OnStreamAvailable, kjer dodamo odjemalca v seznam vseh odprtih povezav

(izvorna koda 8).

function vrniSprememboParkirisca() { $.ajax({ url: '/LongPollingAysinc', type: 'post', dateType: 'json', success: function (data) { //Implementacija prikaza podatkov vrniSprememboParkirisca(); }, error: function () { vrniSprememboParkirisca(); } }); }

Izvorna koda 6.1.4 Dolgo povpraševanje: pošiljanje zahtevkov odjemalca

public HttpResponseMessage Get() { HttpResponseMessage response = Request.CreateResponse(); response.Content = new PushStreamContent(OnStreamAvailable, "text/event- stream"); return response; }

Izvorna koda 6.2.1 Dogodki poslani s streţnika: vzpostavitev povezave


29

Za pošiljanje podatkov smo uporabili StreamWriter, ki poskrbi za potiskanje podatkov

odjemalcem. Preden pošljemo podatke, moramo poskrbeti za pravilni format, saj ima

tehnologija jasno definiran format sporočila. Poslani podatki se morajo pričeti s predpono

data:, ki ji nato sledijo podatki in se mora obvezno zaključiti z dvojnim znakom za konec

vrstice \n\n, kar pove, da se je trenutni prenos zaključil (izvorna koda 9). Podatke lahko s

pomočjo enojnega znaka za konec vrstice ločimo tudi v več vrstic.

Na strani odjemalca imamo tri metode, s pomočjo katerih upravljamo povezavo. Pred

pričetkom preverimo, ali naš brskalnik omogoča dogodke poslane s streţnika in če jih,

skušamo vzpostaviti povezavo. Ko je povezava vzpostavljena, lahko uporabimo funkcijo

open, ki nam pove, ali se je povezava uspešno vzpostavila. Lovimo lahko tudi napake in

prekinitev povezave, kar storimo z uporabo funkcije error. Najpomembnejša izmed treh

omenjenih funkcij pa je funkcija message, preko katere dostopamo do poslanih podatkov

(izvorna koda 10).

static var PovezaniUporabniki = new ConcurrentQueue<StreamWriter>(); public static void OnStreamAvailable(Stream stream, HttpContent headers, TransportContext context) { var clientStream = new StreamWriter(stream); ConnectedClients.Enqueue(clientStream); }

Izvorna koda 6.2.2 Dogodki poslani s streţnika: kreiranje novega odjemalca

foreach (var uporabnik in PovezaniUporabniki) { uporabnik.WriteLine("data:" + JsonConvert.SerializeObject(e.Lokacija) + "\n\n"); uporabnik.Flush(); }

Izvorna koda 6.2.3 Dogodki poslani s streţnika: obveščanje odjemalcev

if (!!window.EventSource) { var serverSentEvents = new window.EventSource('/api/EventSource'); serverSentEvents.addEventListener('message', function (e) { //Implementacija prikaza podatkov }, false); } else { console.log("Brskalnik ne podpira Server - sent events"); }

Izvorna koda 6.2.4 Dogodki poslani s streţnika: prejemanje odgovorov


30

6.3 Spletne vtičnice (Websockets)

Za delovanje spletnih vtičnic potrebujemo dva kontrolnika. Najprej definiramo Api

kontrolnik, ki poskrbi za vzpostavljanje povezave z odjemalcem. Ko prejme zahtevo za

povezavo, najprej potrdi, da razume zahtevo in preide na komunikacijo preko TCP

povezave (izvorna koda 11).

Ko se vzpostavi povezava, se odjemalec doda med odprte povezave, ki nato sluţijo za

pošiljanje podatkov. To storimo z metodo OnOpen, kjer prejmemo zahtevo in nato

povezavo dodamo v seznam klientov (izvorna koda 12). Obratno storimo z metodo

OnClose, kjer ob prekinitvi povezave odstranimo klienta (izvorna koda 15). Če ţelimo

poslati sporočilo, lahko to storimo z uporabo metode Broadcast, ki jo najdemo na

seznamu povezav WebSocketCollection (izvorna koda 13). Podatki so lahko

serializirani, protokol pa nam omogoča tudi pošiljanje binarnih podatkov. Websockets so

edina tehnologija, ki nam omogoča pošiljanje podatkov v obe smeri; tako imamo na voljo

tudi metodo OnMessage, kamor lahko odjemalec pošlje podatke na streţnik, ta pa lahko

nato te podatke obdela ali jih pošlje ostalim odjemalcem (izvorna koda 14).

public HttpResponseMessage Get()

{

HttpContext.Current.AcceptWebSocketRequest(new WebSokcetsParking());

return Request.CreateResponse(HttpStatusCode.SwitchingProtocols); }

Izvorna koda 6.3.1 Spletne vtičnice: kreiranje nove povezave

private static WebSocketCollection clients = new WebSocketCollection(); public override void OnOpen() { clients.Add(this); }

Izvorna koda 6.3.2 Spletne vtičnice: dodajanje nove povezave

if (clients.Count > 0) { clients.Broadcast(serializer.Serialize(e.Spot)); }

Izvorna koda 6.3.3 Spletne vtičnice: pošiljanje podatkov


31

Podobno kot pri dogodkih poslanih s streţnika imamo tudi pri spletnih vtičnicah na strani

odjemalca štiri metode. Ob vzpostavitvi povezave se izvede metoda onopen, njeno

prekinitev lahko zaznamo z metodo onclose. Napake lahko ulovimo s pomočjo namenske

metode onerror. Sporočila na strani odjemalca prejemamo preko metode onmessage. V

implementaciji spletnih vtičnic pa imamo tudi metodo send, s pomočjo katere lahko

pošiljamo sporočila s strani odjemalca na streţnik.

6.4 Knjižnica SignalR

Uporaba SignalR knjiţnice zahteva nekaj več nastavitev, vendar nam kasneje močno

olajša delo. Najprej je potrebno prenesti knjiţnico v naš projekt, kar lahko storimo s

public override void OnMessage(string s) { if (clients.Count > 0) { clients.Broadcast(s); } }

Izvorna koda 6.3.4 Spletne vtičnice: pošiljanje prejetih sporočil odjemalca

public override void OnClose() { clients.Remove(this); }

Izvorna koda 6.3.5 Spletne vtičnice: odstranimo zaprto povezavo

var uri = 'ws://localhost/api/WebSocketsApi'; websocket = new WebSocket(uri); websocket.onopen = function () { console.log('Povezava vzpostavljena'); websocket.send(true); }; websocket.onerror = function (dogodek) { console.log('Napaka'); }; websocket.onmessage = function (dogodek) { //Implementacija prikaza podatkov };

Izvorna koda 6.3.6 Spletne vtičnice: metode na strani odjemalca


32

pomočjo upravljavca paketov Nuget2, tako da v konzolo vpišemo PM> Install-Package

Microsoft.AspNet.SignalR -Version 1.1.3 in se ta nato skupaj z vsemi pripadajočimi in

odvisnimi knjiţnicami avtomatsko prenese v naš projekt. V naslednjem koraku moramo

ustvariti razred Hub (izvorna koda 17), ki poskrbi za komunikacijo med odjemalcem in

streţnikom. Potrebno je opozoriti, da ni priporočljiva uporaba besede SignalR v imenu

Hub-a, saj lahko pride do konfliktov, ki lahko povzročijo nepravilnosti v delovanju. V

razredu Hub definiramo metode, do katerih dostopamo s strani odjemalca. Če ţelimo,

lahko s pomočjo HubName direktive spremenimo ime, s katerim nato dostopamo z

uporabniške strani.

Za obveščanje odjemalcev uporabimo razred Clients in z oznako All povemo, da ţelimo

obvestiti vse povezane uporabnike. Obveščamo lahko tudi skupine uporabnikov (Group)

ali samo posameznike (Caller). V naslednjem koraku definiramo metodo, preko katere

obvestimo odjemalce o spremembah. Metoda posodobiLokacijo se ne nahaja na strani

streţnika, ampak je dinamična metoda, ki je na strani odjemalca.

SignalR nam omogoča, da izvedemo pošiljanje v kateremkoli razredu, ki se nahaja v

našem projektu. Pridobiti moramo samo seznam vseh povezanih uporabnikov in

izvedemo enak postopek za pošiljanje kot v razredu Hub.

Za pravilno delovanje moramo prenesti dve knjiţnici. Datoteka signalR/hubs je posebna

datoteka, ki ne obstaja pred začetkom izvajanja. S to direktivo povemo streţniku, da

ţelimo, da se datoteko prenese, ko se ta generira. V tej datoteki se nahajajo vse

2 NuGet je upravljavec paketov za razvojno platformo Microsoft, vključno z .NET. S paketi so

predstavljene različne plačljive ali odprtokodne rešitve, knjiţnice, itd. Orodje NuGet nam omogoča enostavno vključitev obstoječih rešitev vključno z vsemi odvisnostmi v naš projekt.

[HubName("upraviteljParkirisca")] public class ParkirisceHub : Hub { private void upravitelj_Obvesti(object sender, UpraviteljParkirisca.Arg e) { Clients.All.posodobiLokacijo(e.Lokacija); } }

Izvorna koda 6.4.1 SignalR: definiranje razreda Hub

var povezave = GlobalHost.ConnectionManager.GetHubContext<ParkirisceHub>(); povezave.Clients.All.posodobiLokacijo(e.Lokacija);

Izvorna koda 6.4.2 SignalR: pošiljanje sporočil


33

podrobnosti za pravilno izvajanje metod in komunikacijo med streţnikom in odjemalcem.

Generira se dinamično in zajema vse dinamične metode, ki smo jih definirali na strani

streţnika. S tem nam omogoči enostavno izvajanje teh metod na obeh straneh

komunikacije.

Najprej moramo vzpostaviti povezavo s streţnikom, kar storimo z

$.connection.upraviteljParkirisca, kjer navedemo ime Hub-a, ki je definiran na

streţniku. S tem ustvarimo samo objekt za komunikacijo, začetek komunikacije pa

označimo s klicem medote $.connection.hub.start, kjer imamo dostop do vgrajenih

metod, s pomočjo katerih ugotovimo ali je bila povezava uspešno vzpostavljena in lahko

lovimo napake. Definirati moramo tudi metodo, preko katere streţnik pošilja podatke

odjemalcu. To storimo z razširitvijo jQuery metod, ki jim dodamo funkcijo

posodobiLokacijo, ki vsebuje logiko za spreminjanje podatkov (izvorna koda 20).

SignalR sam poskrbi za določitev najprimernejšega komunikacijskega protokola, lahko pa

ga definiramo tudi sami. Ob vzpostavitvi povezave določimo ţeljen protokol s pomočjo

atributa »transport«, ki podpira štiri vrednosti:

webSockets,

foreverFrame,

serverSentEvents,

longPolling.

Določimo lahko tudi enega ali več protokolov, ki se naj uporabijo in knjiţnica sama poskrbi

za uporabo najprimernejšega.

<script src="~/Scripts/jquery.signalR-1.1.3.js"></script> <script src="../signalr/hubs"></script>

Izvorna koda 6.4.3 SignalR: deklaracija skript

$.extend(upravitelj.client, { posodobiLokacijo: function (data) { //Implementacija prikaza podatkov } });

Izvorna koda 6.4.4 SignalR: prejemanje sporočil


34

7 TESTIRANJE TEHNIK IN TEHNOLOGIJ

S testiranjem smo ţeleli ugotoviti, katere tehnike ali tehnologije najučinkoviteje izrabljajo

streţniške vire. S pomočjo meritev smo izmerili porabo procesorske moči in pomnilnika pri

različnem številu povezanih uporabnikov. Za pravilnejše izvajanje meritev smo poenotili

intervalni čas pošiljanja sporočil, ki se izvede vsake 3 sekunde in velikost podatka, ki

znaša 32 bajtov.

Spletna aplikacija se je nahajala na operacijskem sistemu Windows Server 2012 in na

polni različici spletnega streţnika IIS 8, ki je potreben zaradi podpore tehnologije spletnih

vtičnic. Streţniška konfiguracija je bila 4 jedrni procesor, ki teče s 3,20 GHz in 4 Gb

pomnilnika.

Ker so tehnologije spleta v realnem času dokaj nove, ni na razpolago orodij, s pomočjo

katerih bi lahko enostavno testirali njihovo delovanje. Ker smo ţeleli zagotoviti

obremenitev samo tistega dela spletne aplikacije, ki skrbi za potiskanje podatkov, smo

izdelali lastno testirno orodje. Za testiranje dolgega povpraševanja smo uporabili razred

HttpWebRequest, s pomočjo katerega smo pošiljali zahtevke asinhronemu kontrolniku.

Dogodke poslane s streţnika smo testirali s pomočjo odprtokodne knjiţnice

EventSource4Net3, ki omogoča dolgotrajno odprto povezavo s streţnikom. Za spletne

vtičnice smo implementirali rešitev s pomočjo knjiţnice Websockets4Net4, ki omogoča

namiznim aplikacijam dostop do streţnika preko spletnih vtičnic. SignalR ţe v osnovi

ponuja namiznega odjemalca za povezavo z rešitvijo, ki je na strani streţnika.

Testiranje smo izvajali lokalno, kar ima slabosti, saj testno orodje porablja vire, ki bi jih

lahko drugače izkoristil streţnik. Tako smo bili omejeni tudi v številu hkratnih povezav, ki

smo jih lahko naenkrat simulirali, saj smo pri nekaterih tehnologijah dosegli zgornjo mejo

testirnega orodja pri 1000 hkratnih odjemalcih. V nasprotnem primeru, če bi ţeleli testirati

na dveh računalnikih, bi hitro naleteli na omejitev v internetni povezavi in smo se tako raje

odločili, da bomo izvedli testiranje lokalno. Trajanje posameznega testa smo omejili na 5

minut, saj smo predpostavljali, da uporabniki spletne aplikacije na eni lokaciji iščejo

parkirno mesto povprečno 5 minut. Podatke smo pridobili s pomočjo orodja Performance

monitor, ki je del operacijskega sistema Windows.

3 http://www.nuget.org/packages/EventSource4Net

4 http://www.nuget.org/packages/WebSocket4Net


35

7.1 Poraba procesorskih virov

Porabo procesorske moči smo merili preko števca % Managed processor time, ki ga

najdemo v kategoriji ASP.NET Applications. Števec predstavlja ocenjeni odstotek porabe

časa, ki ga procesor uporabi za izvršitev upravljane aplikacijske kode.

Graf 7.1.1 Poraba procesorske moči: 50 povezav


1,72% 0,81% 0,59% 4,65%

0,74% 1,44%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

50 povezav

Po

rab

a p

roce

sors

ke m

oči

50 povezav

Dolgo povpraševanje

Dogodki poslani s strežnika

Spletne vtičnice

SignalR dolgo povpraševanje

SignalR dogodki poslani sstrežnika

SignalR spletne vtičnice

9,25%

0,98% 0,76%

16,82%

1,60% 4,15%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

250 povezav

Po

rab

a p

roce

sors

ke m

oči

250 povezav



Spletne vtičnice





36



17,03%

1,60% 1,38%

30,26%

2,75% 7,02%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

500 povezav

Po

rab

a p

roce

sors

ke m

oči

500 povezav



Spletne vtičnice




26,76%

2,54% 2,58%

46,40%

4,89% 11,62%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

1000 povezav

Po

rab

a p

roce

sors

ke m

oči

1000 povezav



Spletne vtičnice





37

Graf 7.1.5 Poraba procesorske moči: 5000 povezav5

Pri analizi grafov porabe procesorske moči lahko vidimo, da nobena izmed tehnik ne

predstavlja večje obremenitve streţnika. Najslabše izmed vseh se odreţe dolgo

povpraševanje, ki mu sledijo spletne vtičnice, najboljše pa so se odrezali dogodki poslani

s streţnika.

Dolgo povpraševanje pričakovano porabi največ procesorske moči, saj deluje na način

konstantnega pošiljanja novih povpraševanj in s tem z vsako novo poizvedbo dodatno

obremeni streţnik, ki mora obravnavati vsako poizvedbo posebej in nato pošlje še

odgovor. Pri ostalih tehnikah se povezava vzpostavi le enkrat in je večja le začetna

obremenitev, nato pa streţnik obremenjuje samo še pošiljanje podatkov.

Spletne vtičnice so drugi največji porabnik procesorske moči, vendar veliko manj

obremenijo streţnik kot dolgo povpraševanje. Če jih primerjamo z dogodki poslanimi s

streţnika, ki v osnovi delujejo na podoben način, lahko vidimo, da so obremenitve

pribliţno enake. Nekaj več procesorskega časa odpade pri spletnih vtičnicah na

vzpostavitev povezave, saj mora streţnik izpeljati rokovanje med odjemalcem in

streţnikom. Ta najprej prejme zahtevo za vzpostavitev povezave, jo obravnava in pošlje

5 Iz testiranja smo izključili dolgo povpraševanje, saj nam s testirnim orodjem ni uspelo vzpostaviti

več kot 1000 povezav. Omejitev je bila na strani orodja, s katerim smo testirali in ne na strani streţnika.

13,42% 11,72%

56,58%

20,45%

34,04%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

5000 povezav

Po

rab

a p

roce

sors

ke m

oči

5000 povezav



Spletne vtičnice





38

odgovor ter preklopi na delovanje preko TCP protokola. Proces se zaključi z odgovorom

odjemalca, da je povezava vzpostavljena. Pri dogodkih poslanih s streţnika streţnik samo

prejme zahtevo in nanjo odgovori s sporočilom, ki zagotavlja odprto povezavo in kreira

nov podatkovni tok, preko katerega se lahko pošiljajo podatki.

Če primerjamo naše implementacije s knjiţnico SignalR, lahko vidimo, da je tam

delovanje enako. Največji porabnik je dolgo povpraševanje, ki mu sledijo spletne vtičnice

in na koncu še dogodki poslani s streţnika. Opazimo lahko, da so pri uporabi knjiţnice

obremenitve nekoliko večje kot pri naših rešitvah. To lahko pripišemo dejstvu, da smo mi

zagotovili le pošiljanje podatkov, knjiţnica pa nam omogoča tudi ponovno vzpostavitev

povezave ob prekinitvi in sporočilno vrsto, ki poskrbi, da ne pride do izgube sporočil, kar

povzroči dodatna preverjanja pred pošiljanjem sporočil. Preveri se, katero je bilo zadnje

prejeto sporočilo in se temu primerno sestavi novo sporočilo z neprejetimi podatki.

7.2 Poraba pomnilnika

Porabo pomnilnika smo pridobili s pomočjo števca Managed memory used, ki se prav

tako nahaja v kategoriji ASP.NET Applications. Predstavlja ocenjeno porabo upravljane

kopice v pomnilniku (v KB), ki ga zavzame aplikacija.

Graf 7.2.1 Poraba pomnilnika: 50 povezav

9,55 Mb

5,15 Mb

1,70 Mb

3,22 Mb

4,74 Mb 4,15 Mb

Mb

2 Mb

4 Mb

6 Mb

8 Mb

10 Mb

12 Mb

50 povezav

Po

rab

a p

om

niln

ika

50 povezav



Spletne vtičnice





39



31,19 Mb

9,72 Mb

3,31 Mb 4,48 Mb

7,15 Mb 6,98 Mb

Mb

5 Mb

10 Mb

15 Mb

20 Mb

25 Mb

30 Mb

35 Mb

250 povezav

Po

rab

a p

om

niln

ika

250 povezav



Spletne vtičnice




54,60 Mb

15,62 Mb

6,94 Mb 9,10 Mb

17,77 Mb 13,79 Mb

Mb

10 Mb

20 Mb

30 Mb

40 Mb

50 Mb

60 Mb

500 povezav

Po

rab

a p

om

niln

ika

500 povezav



Spletne vtičnice





40


Graf 7.2.5 Poraba pomnilnika: 5000 povezav6

6 Iz testiranja smo izključili dolgo povpraševanje, saj nam s testirnim orodjem ni uspelo vzpostaviti

več kot 1000 povezav. Omejitev je bila na strani orodja, s katerim smo testirali in ne na strani streţnika.

71,12 Mb

33,55 Mb

8,27 Mb 15,25 Mb

37,20 Mb

20,25 Mb

Mb

10 Mb

20 Mb

30 Mb

40 Mb

50 Mb

60 Mb

70 Mb

80 Mb

1000 povezav

Po

rab

a p

om

niln

ika

1000 povezav



Spletne vtičnice




59,03 Mb 54,79 Mb

24,09 Mb

58,27 Mb

29,00 Mb

Mb

10 Mb

20 Mb

30 Mb

40 Mb

50 Mb

60 Mb

70 Mb

5000 povezav

Po

rab

a p

om

niln

ika

5000 povezav



Spletne vtičnice





41

Kot pri porabi procesorske moči tudi tu zasledimo, da je največja poraba pomnilnika pri

dolgem povpraševanju. To lahko pripišemo vsakokratnemu vzpostavljanju povezave in

delovanju asinhronega kontrolnika, ki si mora ob vsakem povpraševanju shraniti stanje

povezave, da lahko vrne odgovor. Posledica večje porabe pomnilnika je lahko tudi način

implementacije, saj nismo uporabili direktive »keep-alive«, s katero bi ponovno uporabili

obstoječo povezavo. Takšna implementacija je bila namenska, saj IIS streţnik podpira le

določeno število istočasnih povezav in bi z odprtimi povezavami lahko presegli to

omejitev.

V primeru dogodkov poslanih s streţnika vidimo, da je poraba pomnilnika večja od

spletnih vtičnic. Tukaj gre predvsem za implementacijo tehnologije, ki uporablja

podatkovni tok za pošiljanje podatkov, ki je odprt ves ţivljenjski krog povezave, pred

pošiljanjem pa se podatki pretvorijo in zapišejo v pomnilnik. Spletne vtičnice imajo

najmanjšo porabo pomnilnika.

Primerjalno gledano knjiţnica SignalR zavzame večji del pomnilnika, kar je posledica

uporabe sporočilne vrste, kjer so shranjena predhodna sporočila. V primerjavi z našimi

implementacijami je poraba pomnilnika nekoliko manjša, kar je posledica večje

optimiziranosti programske kode.


42

8 SKLEP

Tehnike potiskanja podatkov postajajo realnost in so iz dneva v dan vse bolj prisotne. Z

razvojem in standardizacijo se njihova uporaba povečuje in počasi izpodriva tehnike

povpraševanja. S primerjavo obeh pristopov smo ugotovili, da ima vsak svoje prednosti in

slabosti. Vendar pristop potiskanja podatkov prinaša številne prednosti pred

povpraševanjem, še posebej, če upoštevamo razvoj novih tehnologij, kot sta dogodki

poslani s streţnika in spletne vtičnice, ki sta uradno podprti tehniki v spletnih brskalnikih.

Odločitev glede uporabe posameznega pristopa pa je v končni fazi vedno odvisna od več

dejavnikov, kot so npr. vrsta podatkov, intervali sprememb in problem, ki ga ţeli rešiti

razvijalec.

S primerjavo vseh treh tehnik smo ugotovili, da ima v brskalnikih najboljšo podporo dolgo

povpraševanje, ki je tudi najstarejša tehnika izmed vseh in potrebuje za svoje delovanje le

JavaScript. Ostali dve tehniki sta še v fazi razvoja in tako še ni uradne standardizirane

implementacije v brskalnikih. Trenutno po nekaterih ocenah podpira dogodke poslane s

streţnika 65 % brskalnikov, spletne vtičnice pa le 50 %. S časom lahko v vseh novejših

brskalnikih pričakujemo vedno večjo podporo tehnik, vendar ob tem ostaja nerazrešen

problem uporabe starejših različic brskalnikov pri nekaterih uporabnikih. To pomeni, da je

izbira tehnike močno pogojena s poznavanjem uporabnikov in odločitvijo, katere

uporabniške skupine ţelimo zajeti z našo spletno aplikacijo.

S testi porabe streţniških virov smo ugotovili, da je največji porabnik dolgo povpraševanje.

Pri ostalih dveh tehnikah so razlike zanemarljive in tako obe predstavljata dobro izbiro.

Končna odločitev o uporabi posamezne tehnike je odvisna od več parametrov. Upoštevati

je potrebno ciljno skupino uporabnikov in platforme, na katerih ţelimo ponuditi dostop do

naših storitev. Izbira je odvisna tudi od samega načina delovanja aplikacije. Kadar

potrebujemo dvosmerno komunikacijo, so prava izbira spletne vtičnice, ki nam to

omogočajo. Če potrebujemo samo pošiljanje sporočil s strani streţnika, potem prideta v

poštev tehnika dogodkov poslanih s streţnika in spletne vtičnice.

Glede na trenutno stanje podprtosti tehnik v spletnih brskalnikih in moţnost enostavne

implementacije je priporočljiva uporaba tehnike spletnih vtičnic ali dogodkov poslanih s

streţnika v navezi s tehniko dolgega povpraševanja. S tem se izognemo omejitvam in


43

ponudimo našo storitev vsem odjemalcem. Implementirati je potrebno mehanizem

milostne alternative, ki poskuša najprej vzpostaviti povezavo s pomočjo ene izmed

novejših tehnik in če ta ne uspe, preide na delovanje preko dolgega povpraševanja.

Kadar ţelimo ţe obstoječo rešitev, je primerna uporaba knjiţnice SignalR. Sama knjiţnica

je podprta v skoraj vseh novejših brskalnikih in na vrsti naprav in platform. Deluje s

pomočjo štirih tehnik potiskanja podatkov in sama poskrbi za prehod na tehniko, ki jo

brskalnik podpira in je najprimernejša. Prinaša tudi obilo prednosti pri sami implementaciji,

saj nam omogoča, da se osredotočimo na izdelavo poslovne logike, za ostalo pa poskrbi

knjiţnica. S tem močno pospešimo izdelavo novih spletnih aplikacij. Knjiţnica ima

implementirane tudi mehanizme za ponovno vzpostavitev povezave ob prekinitvi in

sporočilno vrsto, ki zagotavlja prenos vseh sporočil brez izgube.

Izbira knjiţnice SignalR se zdi smiselna, saj nam nudi rešitev, ki jo enostavno uporabimo.

Kadar ţelimo več nadzora nad samo implementacijo rešitve in ţelimo dodati

funkcionalnost potiskanja podatkov, sta pravi izbiri tako tehnika dolgega povpraševanja

kot spletne vtičnice. Spletne vtičnice so najboljša tehnika za uporabo, saj omogočajo

dvosmerno komunikacijo in enostavnost implementacije, vendar imajo slabo podporo v

spletnih brskalnikih in trenutno jih je mogoče gostiti samo na spletnem streţniku IIS 8.

Dogodki poslani s streţnika nimajo te omejitve, vendar je njihova podpora le malenkost

boljša od spletnih vtičnic in omogočajo le enosmerno komunikacijo. Upoštevajoč

navedeno lahko zaključimo, da je še vedno najboljši pristop uporabe dveh ali več tehnik

hkrati.


44

9 VIRI IN LITERATURA

[1] Aguilar J., ASP.NET SignalR: Incredibly simple real-time features for your web apps.

Camus MVP.NET, 2013. Dostopno na: http://www.campusmvp.net/signalr-ebook-done

[2. 9. 2013]

[2] Bidelman E., Server - sent events, Dostopno na:

http://www.html5rocks.com/en/tutorials/eventsource/basics/ [2.9.2013]

[3] Bozdag E., Mesbah A., van Deursen A., Primerjava tehnik povpraševanja in

potiskanja podatkov, Dostopno na: http://arxiv.org/ftp/arxiv/papers/0706/0706.3984.pdf

[2. 8. 2013]

[4] Fletcher P., Predstavitev knjižnice SignalR, Dostopno na:

http://www.asp.net/signalr/overview/getting-started/introduction-to-signalr [2.9.2013]

[5] Haritesh J., Potiskanje podatkov s pomočjo AJAX tehnologije, Dostopno na:

http://jharitesh.blogspot.com/2012/07/comet-use-of-reverse-ajaxpush.html [2.9.2013]

[6] HTTP protokol, Dostopno na: http://sl.wikipedia.org/wiki/HTTP [2.9.2013]

[7] jQuery, Dostopno na: http://www.w3schools.com/jquery/jquery_intro.asp [2.9.2013]

[8] Kirkpatrick, M., Splet v realnem času v 100 besedah, Dostopno na:

http://readwrite.com/2009/09/22/explaining_the_real-

time_web_in_100_words_or_less#awesm=~odlFKQaULIOXY0

[2.9. 2013]

[9] Lengstorf J., Leggetter P., Realtime Web Apps: With HTML5 WebSocket, PHP, and

jQuery. New York: Apress, 2013.

[10] Palermo J., Bogard J., Hexter E., Hinze M., Skinner J., ASP.NET MVC 4 in Action,

Shelter Island: Manning, 2012.


45

[11] Podila P., Razlaga HTTP protokola, Dostopno na:

http://net.tutsplus.com/tutorials/tools-and-tips/http-the-protocol-every-web-developer-must-

know-part-1/ [2. 9. 2013]

[12] Podprtost Server - sent events v brskalnikih, Dostopno na:

http://caniuse.com/#feat=websockets [2.9.2013]

[13] Podprtost Websockets-ov v brskalnikih, Dostopno na:

http://caniuse.com/#feat=websockets [2.9.2013]

[14] Roden T., Building Realtime User Experience. Sebastopol: O’Reilly Media, 2010.

[15] Senthilvel G., Programiranje Websockets-ov, Dostopno na:

http://www.codeproject.com/Articles/437342/DotNet-WebSocket-Programming [2.9.2013]

[16] TCP protokol, Dostopno na:

http://www.egradiva.net/moduli/upravljanje_ik/66_tcp/01_datoteka.html [2. 9. 2013]

[17] Ubl M., Kitamura E., Predstavitev tehnologije Websockets, Dostopno na:

http://www.html5rocks.com/en/tutorials/websockets/basics/ [2.9.2013]

[18] Uporaba dolgega povpraševanja, Dostopno na: http://tools.ietf.org/html/draft-loreto-

http-bidirectional-07 [2.8.2013]

[19] Podprtost knjiţnice SignalR v brskalnikih, Dostopno na:

http://www.asp.net/signalr/overview/getting-started/supported-platforms [2.9.2013]


46

10 PRILOGE

Priloga A

Izvorna koda programa za testiranje tehnik


47

private static volatile bool longPollingrunning = true; private void LongPollingTest() { ServicePointManager.DefaultConnectionLimit = Int32.MaxValue; ThreadPool.SetMinThreads(TestSettings.Connections, 2); var options = new ParallelOptions { MaxDegreeOfParallelism = TestSettings.Connections }; BackgroundWorker worker = new BackgroundWorker(); worker.DoWork += (s, e) => { Parallel.For(0, connections, options, async i => { await AjaxRequest(); }); }; worker.RunWorkerAsync(); } private Task AjaxRequest() { var batchTcs = new TaskCompletionSource<object>(); HttpWebRequest req = (HttpWebRequest)HttpWebRequest.Create(url); req.Timeout = 40000; req.ReadWriteTimeout = 50000; req.KeepAlive = false; req.Method = WebRequestMethods.Http.Post; req.ContentLength = 0; req.Proxy = null; try { HttpWebResponse response = (HttpWebResponse)req.GetResponse(); response.Close(); response = null; if (req.HaveResponse) if (longPollingrunning){ req = null; AjaxRequest(); } } catch (WebException) { req.Abort(); if (longPollingrunning) AjaxRequest(); } return batchTcs.Task; }


48

ConcurrentBag<EventSource> sseClients = null; private void ServerSentEventsTest() { sseClients = new ConcurrentBag<EventSource>(); ServicePointManager.DefaultConnectionLimit = Int32.MaxValue; ThreadPool.SetMinThreads(TestSettings.Connections, 2); var options = new ParallelOptions { MaxDegreeOfParallelism = TestSettings.Connections }; BackgroundWorker worker = new BackgroundWorker(); worker.DoWork += (s, e) => { Parallel.For(0, connections, options, async i => { await Sse(); }); }; worker.RunWorkerAsync(); } private Task Sse() { var batchTcs = new TaskCompletionSource<object>(); EventSource es = new EventSource(new Uri(url)); sseClients.Add(es); es.StateChanged += new EventHandler<StateChangedEventArgs>(StateChanged); es.EventReceived += new EventHandler<ServerSentEventReceivedEventArgs>(SseEventRecived); es.Start(); return batchTcs.Task; } private void StateChanged(object sender, StateChangedEventArgs e) { if (e.State == EventSourceState.OPEN){ } else if (e.State == EventSourceState.CLOSED) {} } private void SseEventRecived(object sender, ServerSentEventReceivedEventArgs e){ }


49

private static volatile bool webSocketsRunning = true; ConcurrentBag<WebSocket> websockets = null; private void WebSocketsTest() { websockets = new ConcurrentBag<WebSocket>(); ServicePointManager.DefaultConnectionLimit = Int32.MaxValue; ThreadPool.SetMinThreads(TestSettings.Connections, 2); var options = new ParallelOptions { MaxDegreeOfParallelism = TestSettings.Connections }; BackgroundWorker worker = new BackgroundWorker(); worker.DoWork += (s, e) => { Parallel.For(0, TestSettings.Connections, options, async i => { await WebSocketsConnection(); }); }; worker.RunWorkerAsync(); } private Task WebSocketsConnection() { var batchTcs = new TaskCompletionSource<object>(); WebSocket websocket = new WebSocket(url); websockets.Add(websocket); websocket.Opened += new EventHandler(WebsocketOpened); websocket.Error += new EventHandler<SuperSocket.ClientEngine.ErrorEventArgs>(WebsocketError); websocket.Closed += new EventHandler(WebsocketClosed); websocket.Message += new EventHandler<MessageReceivedEventArgs>(WebsocketMessageReceived); websocket.Open(); return batchTcs.Task; } private void WebsocketError(object sender, ErrorEventArgs e) { if (webSocketsRunning) WebSocketsConnection(); } private void WebsocketMessage (object sender, MessageReceivedEventArgs e) { } private void WebsocketClosed(object sender, EventArgs e) { } private void WebsocketOpened(object sender, EventArgs e) { }


50

ConcurrentBag<HubConnection> connections = null; private Task SignalRTest() { connections = new ConcurrentBag<HubConnection>(); ServicePointManager.DefaultConnectionLimit = Int32.MaxValue; ThreadPool.SetMinThreads(TestSettings.Connections, 2); var options = new ParallelOptions { MaxDegreeOfParallelism = TestSettings.Connections }; var batchTcs = new TaskCompletionSource<object>(); Parallel.For(0, connections, options, async i => { var hubConnection = new HubConnection(TestSettings.Url); connections.Add(hubConnection); IHubProxy signalrHubProxy = hubConnection.CreateHubProxy(hubName); switch (techniqueType) { case Technique.SignalRLongPolling: await hubConnection.Start(new LongPollingTransport()); break; case Technique.SignalRServerSentEvents: await hubConnection.Start(new ServerSentEventsTransport()); break; case Technique.SignalRWebSockets: await hubConnection.Start(new WebSocketTransport()); break; default: await hubConnection.Start(); break; } hubConnection.Closed += HubConnectionClosed; hubConnection.Error += HubConnectionError; signalrHubProxy.On<string>(TestSettings.HubMethod, s => { }); }); return batchTcs.Task; } private void HubConnectionError(Exception obj) { } private void HubConnectionClosed() { }

tehnike potiskanja podatkov spletnim odjemalcem · iv web client data push techniques key words:...

Documents