• No results found

technick´a univerzita v liberci Fakulta mechatroniky, informatiky a mezioborov´ych studi´ı

N/A
N/A
Protected

Academic year: 2022

Share "technick´a univerzita v liberci Fakulta mechatroniky, informatiky a mezioborov´ych studi´ı"

Copied!
171
0
0

Loading.... (view fulltext now)

Full text

(1)

technick´ a univerzita v liberci

Fakulta mechatroniky, informatiky a mezioborov´ych studi´ı

Disertaˇ cn´ı pr´ ace

Liberec 2010 Ing. Jiˇr´ı Hn´ıdek

(2)

technick´ a univerzita v liberci

Fakulta mechatroniky, informatiky a mezioborov´ych studi´ı

Studijn´ı program: P2612 Elektrotechnika a informatika Studijn´ı obor: 2612V045 Technick´a kybernetika

S´ıt’ov´y protokol pro grafick´e aplikace Network protocol for graphics application

Ing. Jiˇr´ı Hn´ıdek

Skolitel:ˇ doc. RNDr. Pavel Satrapa PhD.

Pracoviˇstˇe: ´Ustav nov´ych technologi´ı a aplikovan´e informatiky

Rozsah pr´ace:

Poˇcet stran: 171 Poˇcet obr´azk˚u: 82 Poˇcet tabulek: 4

30.12.2010

(3)

Anotace

Tato disertaˇcn´ı pr´ace se zab´yv´a n´avrhem s´ıt’ov´eho protokolu pro real- timovou v´ymˇenu 3D dat mezi aplikacemi sd´ılen´e virtu´aln´ı reality, kdy jsou na navrhovan´y protokol kladeny dva protich˚udn´e poˇzadavky. Protokol mus´ı zaruˇcovat ´uplnou nebo ˇc´asteˇcnou spolehlivost pˇren´aˇsen´ych dat. Z´aroveˇn mus´ı protokol pˇren´aˇset data s n´ızk´ymi latencemi. Pˇri n´avrhu protokolu se ˇc´asteˇcnˇe vych´azelo z konceptu jiˇz existuj´ıc´ıho protokolu Verse, jehoˇz p˚uvodn´ı n´avrh byl zcela pˇrepracov´an s ohledem na vyˇsˇs´ı bezpeˇcnost, spolehlivost a efektiv- nost.

Pr´ace se zab´yv´am pˇredevˇs´ım n´avrhem nov´eho resend mechanismu, kter´y d´ıky pˇrepos´ıl´an´ı aktu´aln´ıch dat dosahuje n´ızk´ych latenc´ı. Korektnost d˚uleˇzi- t´ych ˇc´ast´ı n´avrhu protokolu - autentizace, handshake a samotn´y resend me- chanismus - byla ovˇeˇrena programem Spin pomoc´ı verifikaˇcn´ıch model˚u vy- tvoˇren´ych v programovac´ım jazyku PROMELA.

Efektivita a spolehlivost implementace navrˇzen´eho protokolu byla ovˇeˇrena v experiment´aln´ım prostˇred´ı. V tomto prostˇred´ı z´aroveˇn doˇslo k testov´an´ı vy- bran´ych transportn´ıch protokol˚u vˇcetnˇe p˚uvodn´ıho protokolu Verse. V´ysledky jednotliv´ych experiment˚u prok´azaly, ˇze navrˇzen´y protokol m˚uˇze b´yt efektivnˇe pouˇzit pro sd´ılen´ı rozs´ahl´ych sc´en virtu´aln´ı reality.

Kl´ıˇcov´a slova: s´ıt’ov´y protokol, grafick´a aplikace, 3D, virtu´aln´ı realita

(4)

Annotation

This disertation thesis deals with the design of network protocol for ex- change of 3D data between application of distributed virtual environment.

Two antithetical requirements are claimed for such protocol. Protocol has to be partially or completely reliable. Neither delay jitter nor too high delay are acceptable. The draft of the protocol si partially based on the concept of existing protocol called Verse. Original draft was completly rewritten with a respect to greater security, realibility and efficiency.

The paper deals with the design of a new resend mechanism. This resend mechanism resends only actual data, thus low latency is achieved. Correctness of the important parts of the draft protocol - authentication, handshake and resend mechanism - was verified using Spin protocol. Verification models were created in the PROMELA programming language.

Efficiency and reliability of the proposed implementation of the protocol was tested in an experimental environment. Several transport protocols and the original Verse protocol were also tested in this environment. Results of experiments showed that the proposed protocol can be effectively used to share large scenes of virtual reality.

Keywords: network protocol, graphics application, 3D, virtual reality

(5)

Prohl´ aˇ sen´ı

Byl jsem sezn´amen s t´ım, ˇze na mou disertaˇcn´ı pr´aci se plnˇe vztahuje z´akon ˇc. 121/2000 o pr´avu autorsk´em, zejm´ena § 60 (ˇskoln´ı d´ılo).

Beru na vˇedom´ı, ˇze TUL m´a pr´avo na uzavˇren´ı licenˇcn´ı smlouvy o uˇzit´ı m´e disertaˇcn´ı pr´ace a prohlaˇsuji, ˇze souhlas´ım s pˇr´ıpadn´ym uˇzit´ım m´e disertaˇcn´ı pr´ace (prodej, zap˚ujˇcen´ı apod.).

Jsem si vˇedom(a) toho, ˇze uˇz´ıt sv´e disertaˇcn´ı pr´ace ˇci poskytnout li- cenci k jej´ımu vyuˇzit´ı mohu jen se souhlasem TUL, kter´a m´a pr´avo ode mne poˇzadovat pˇrimˇeˇren´y pˇr´ıspˇevek na ´uhradu n´aklad˚u, vynaloˇzen´ych univerzitou na vytvoˇren´ı d´ıla (aˇz do jejich skuteˇcn´e v´yˇse).

Disertaˇcn´ı pr´aci jsem vypracoval samostatnˇe s pouˇzit´ım uveden´e litera- tury a na z´akladˇe konzultac´ı se ˇskolitelem.

V Liberci 30. prosince 2010

(6)

R´ad bych zde podˇekoval sv´e rodinˇe, pˇredevˇs´ım Janˇe a Viktorce, bez jejichˇz podpory a trpˇelivosti bych tuto pr´aci pravdˇepodobnˇe nedokonˇcil.

D´ale bych zde chtˇel podˇekovat sv´emu vedouc´ımu doc. RNDr. Pavlu Sa- trapovi Ph.D. za svˇedomit´e veden´ı m´e disertaˇcn´ı pr´ace, Mgr. Davidovi Kmo- chovi za peˇcliv´e ˇcten´ı m´ych ˇcl´ank˚u, Ing. Jirkovi Jen´ıˇckovi Ph.D za cenn´e rady a Ing. Jirkovi Vran´emu Ph.D. za motivaci.

(7)

Obsah

1 Uvod´ 17

2 Uvod do teorie n´´ avrhu s´ıt’ov´ych protokol˚u 19

3 P˚uvodn´ı protokol Verse 22

3.1 Struktura paketu . . . 22

3.2 Handshake . . . 23

3.3 Resend mechanismus . . . 24

3.4 Datov´y model . . . 26

4 Nov´y protokol Verse 28 4.1 Poˇzadavky na nov´y protokol . . . 28

4.2 K´odov´an´ı dat . . . 29

4.3 Transportn´ı protokol . . . 29

4.4 Struktura zpr´av a pˇr´ıkaz˚u . . . 30

4.5 Nav´az´an´ı spojen´ı . . . 31

4.5.1 TLS handshake . . . 32

4.5.2 Autentizace . . . 33

4.5.3 Dohadov´an´ı vlastnost´ı spojen´ı . . . 38

4.6 Datagramov´e spojen´ı . . . 48

4.7 Handshake datagramov´eho spojen´ı . . . 50

4.7.1 Prvn´ı ˇc´ast handshaku . . . 50

4.7.2 Druh´a ˇc´ast handshaku . . . 53

4.7.3 Dohadov´an´ı na datagramov´em spojen´ı . . . 54

4.7.4 Dohadov´an´ı o Flow Control . . . 55

4.7.5 Dohadov´an´ı o Congestion Control . . . 56

4.7.6 Bezpeˇcnostn´ı rizika handshaku . . . 57

4.8 Resend mechanismus . . . 57

4.8.1 Pozitivn´ı potvrzov´an´ı . . . 58

4.8.2 Negativn´ı potvrzov´an´ı . . . 60

4.8.3 Keep-alive pakety . . . 63

(8)

4.8.4 Komprese potvrzovac´ıch pˇr´ıkaz˚u . . . 64

4.8.5 Zmˇena poˇrad´ı paket˚u . . . 65

4.9 Ukonˇcen´ı spojen´ı . . . 67

4.10 Verifikace datagramov´eho spojen´ı . . . 69

4.11 Flow Control . . . 71

4.12 Congestion Control . . . 71

5 Datov´y model 72 5.1 Uˇzivatel´e a uˇzivatelsk´e ´uˇcty . . . 72

5.2 Uzly . . . 73

5.2.1 Pˇr´ıstupov´a pr´ava . . . 73

5.2.2 Stromov´a struktura . . . 74

5.2.3 Avatar . . . 75

5.2.4 Z´akladn´ı operace s uzly . . . 76

5.2.5 Pˇrihlaˇsov´an´ı k uzl˚um . . . 78

5.2.6 Potvrzov´an´ı uzlov´ych pˇr´ıkaz˚u . . . 80

5.2.7 Nastaven´ı vazeb mezi uzly . . . 81

5.2.8 Zmˇena pˇr´ıstupov´ych pr´av . . . 82

5.2.9 Zmˇena vlastn´ıka . . . 83

5.2.10 Doˇcasn´e z´amky . . . 83

5.2.11 Priority uzl˚u . . . 84

5.2.12 Tagy a skupiny tag˚u . . . 86

5.2.13 Vrstvy . . . 90

5.3 Casov´ˇ e znaˇcky . . . 92

6 Implementace 94 6.1 Server . . . 94

6.2 Klient . . . 96

6.3 Fronta pˇr´ıkaz˚u . . . 97

6.4 Historie pˇr´ıkaz˚u . . . 99

7 V´ysledky mˇeˇren´ı 101 7.1 Podm´ınky experiment˚u . . . 101

7.2 Metody experiment˚u . . . 102

7.3 Transportn´ı protokoly . . . 103

7.3.1 UDP . . . 103

7.3.2 TCP . . . 106

7.3.3 SCTP . . . 108

7.3.4 DCCP . . . 111

7.3.5 Dalˇs´ı transportn´ı protokoly . . . 111

7.4 Aplikaˇcn´ı protokoly . . . 111

(9)

7.4.1 P˚uvodn´ı protokol Verse . . . 112 7.4.2 Nov´y protokol Verse . . . 114

8 Z´avˇer 118

9 Pˇr´ılohy verifikaˇcn´ıch model˚u 124

10 Struktury pˇr´ıkaz˚u 147

11 Verse API 165

(10)

Seznam obr´ azk˚ u

3.1 Struktura paketu p˚uvodn´ıho protokolu Verse . . . 23

3.2 Pˇr´ıklad v´ymˇeny paket˚u bˇehem handshaku . . . 23

3.3 Zjednoduˇsen´y pˇr´ıklad v´ymˇeny paket˚u . . . 25

4.1 Struktury string8 (a) a string16 (b) pro pˇrenos ˇretˇezc˚u . . . . 29

4.2 Struktura zpr´avy pos´ılan´a pˇres zabezpeˇcen´e TCP spojen´ı . . . 30

4.3 Struktura kr´atk´e varianty pˇr´ıkazu . . . 31

4.4 Struktura dlouh´e varianty pˇr´ıkazu . . . 31

4.5 Zjednoduˇsen´y pr˚ubˇeh TLS handshaku . . . 32

4.6 Struktura pˇr´ıkazu UserAauthRequest . . . 33

4.7 Struktura pˇr´ıkazu UserAauthFailure se seznamem podporo- van´ych metod . . . 34

4.8 Struktura pˇr´ıkazu UserAauthFailure ukonˇcuj´ıc´ı spojen´ı . . . . 34

4.9 Struktura pˇr´ıkazu UserAauthRequest obsahuj´ıc´ı heslo . . . 35

4.10 Struktura pˇr´ıkazu UserAauthSuccess . . . 35

4.11 Pˇr´ıklad ´uspˇeˇsn´e autentizace . . . 36

4.12 Pˇr´ıklad ne´uspˇeˇsn´e autentizace . . . 36

4.13 Stavov´y model autentizace na stranˇe klienta . . . 37

4.14 Stavov´y model autentizace na serveru . . . 38

4.15 Struktura pˇr´ıkaz˚u pro dohadov´an´ı vlastnost´ı spojen´ı . . . 38

4.16 Dva Verse klienti s r˚uzn´ym FPS . . . 41

4.17 Pˇr´ıklad odpovˇedi klienta na nepodporovan´e DED . . . 43

4.18 Pˇr´ıklad odpovˇedi klienta na podporovan´e DED . . . 43

4.19 Stavov´y model dohadov´an´ı datagramov´eho spojen´ı na stranˇe klienta . . . 45

4.20 Stavov´y model dohadov´an´ı datagramov´eho spojen´ı na serveru 45 4.21 Pˇr´ıklad kompletn´ıho handshaku . . . 47

4.22 Struktura Verse paketu . . . 48

4.23 Struktura pˇr´ıkazu ACK (a) a NAK (b) . . . 49

4.24 Pˇr´ıklad handshaku na datagramov´em spojen´ı . . . 51

4.25 Pˇr´ıklad 4 moˇzn´ych sc´en´aˇr˚u bˇehem prvn´ı ˇc´asti handshaku . . . 52

4.26 Pˇr´ıklad 4 moˇzn´ych sc´en´aˇr˚u bˇehem druh´e ˇc´asti handshaku . . . 54

(11)

4.27 Pˇr´ıklad dohadov´an´ı o Flow Control . . . 56

4.28 Pˇr´ıklad nedohodnut´ı algoritmu Flow Control . . . 57

4.29 Pˇr´ıklad dohadov´an´ı o Congestion Control . . . 58

4.30 Pˇr´ıklad pozitivn´ıho potvrzen´ı . . . 59

4.31 Pˇr´ıklad ztr´aty paketu s pozitivn´ım potvrzen´ım . . . 60

4.32 Pˇr´ıklad negativn´ıho potvrzen´ı . . . 61

4.33 Porovn´an´ı metod detekce ztr´aty paketu pro velk´e RTT . . . . 62

4.34 Porovn´an´ı metod detekce ztr´aty paketu pro mal´e RTT . . . . 63

4.35 Pˇr´ıklad zmˇeny poˇrad´ı paket˚u . . . 66

4.36 Pˇr´ıklad ukonˇcen´ı datagramov´eho spojen´ı . . . 68

4.37 Pˇr´ıklad ukonˇcen´ı datagramov´eho spojen´ı . . . 69

4.38 Stavov´y model datagramov´eho spojen´ı klienta . . . 69

4.39 Stavov´y model datagramov´eho spojen´ı serveru . . . 70

5.1 Pˇr´ıklad stromov´e struktury . . . 75

5.2 Struktura pˇr´ıkazu pro vytvoˇren´ı nov´eho uzlu . . . 77

5.3 Struktura pˇr´ıkazu pro zruˇsen´ı uzlu . . . 78

5.4 Struktura pˇr´ıkazu pro pˇrihl´aˇsen´ı se k uzlu . . . 78

5.5 Zjednoduˇsen´y pˇr´ıklad pˇrihl´aˇsen´ı se k dat˚um jednoho uzlu . . . 79

5.6 Struktura pˇr´ıkazu pro odhl´aˇsen´ı se od uzlu . . . 80

5.7 Struktura pˇr´ıkazu pro ohl´aˇsen´ı chybn´eho pˇr´ıkazu . . . 81

5.8 Struktura pˇr´ıkazu pro zmˇenu vazeb mezi uzly . . . 81

5.9 Struktura pˇr´ıkazu pro zmˇenu pˇr´ıstupov´ych pr´av . . . 82

5.10 Bitov´e pˇr´ıznaky pro nastaven´ı pˇr´ıstupov´ych pr´av . . . 82

5.11 Struktura pˇr´ıkazu pro nastaven´ı v´ychoz´ıch pˇr´ıstupov´ych pr´av u ostatn´ıch uˇzivatel˚u . . . 83

5.12 Struktura pˇr´ıkazu pro zmˇenu vlastn´ıka uzlu . . . 83

5.13 Struktura pˇr´ıkazu zamknut´ı uzlu . . . 84

5.14 Struktura pˇr´ıkazu odemˇcen´ı uzlu . . . 84

5.15 Struktura pˇr´ıkazu pro nastaven´ı priority uzlu . . . 85

5.16 Sch´ema moˇzn´eho uspoˇr´ad´an´ı objekt˚u do oktanov´eho stromu . 85 5.17 Struktura pˇr´ıkazu pro vytvoˇren´ı nov´eho tagu . . . 88

5.18 Struktura pˇr´ıkazu pro nastaven´ı hodnoty tagu real32 . . . 89

5.19 Jednotliv´e varianty opakov´an´ı adresy pˇr´ıkazu Tag Set (real32) 89 5.20 Pˇr´ıklad komprese pˇr´ıkazu Tag Set, jeˇz byl pouˇzit´y pro pˇrenos pozice . . . 90

5.21 Porovn´an´ı efektivity vyuˇzit´ı m´ısta v p˚uvodn´ım (a) a nov´em protokolu (b) . . . 91

5.22 Struktura pˇr´ıkazu pro nastaven´ı ˇcasov´e znaˇcky . . . 92

6.1 Vl´akna Verse serveru . . . 95

(12)

6.2 Stavy uzlu . . . 96

6.3 Vl´akna verse klienta . . . 97

6.4 Pˇrid´an´ı pˇr´ıkazu do fronty pˇr´ıkaz˚u . . . 98

6.5 Sch´ema historie odeslan´ych paketu . . . 100

7.1 Sch´ema omezen´ı datov´eho okruhu . . . 101

7.2 Casov´ˇ y pr˚ubˇeh poˇctu pos´ılan´ych ˇc´astic . . . 102

7.3 Struktura zpr´avy pro pos´ıl´an´ı ˇc´astic . . . 103

7.4 V´ysledky mˇeˇren´ı za pouˇzit´ı protokolu UDP . . . 105

7.5 Screenshot klientsk´e aplikace vizualizuj´ıc´ı zpoˇzdˇen´ıˇc´astic (pro- tokol TCP) . . . 106

7.6 V´ysledky mˇeˇren´ı za pouˇzit´ı protokolu TCP . . . 107

7.7 V´ysledky mˇeˇren´ı za pouˇzit´ı spolehliv´e varianty protokolu SCTP109 7.8 V´ysledky mˇeˇren´ı za pouˇzit´ı ˇc´asteˇcnˇe spolehliv´e varianty pro- tokolu SCTP . . . 110

7.9 V´ysledky mˇeˇren´ı za pouˇzit´ı p˚uvodn´ıho protokolu Verse . . . . 113

7.10 V´ysledky mˇeˇren´ı za pouˇzit´ı nov´eho protokolu Verse (bez kom- prese pˇr´ıkaz˚u) . . . 115

7.11 V´ysledky mˇeˇren´ı za pouˇzit´ı nov´eho protokolu Verse (s kom- pres´ı pˇr´ıkaz˚u) . . . 116

7.12 Porovn´an´ı v´ysledk˚u experiment´aln´ıho mˇeˇren´ı v re´aln´e s´ıt’ov´em provozu . . . 117

10.1 Struktura pˇr´ıkazu pro vytvoˇren´ı nov´eho uzlu . . . 147

10.2 Struktura pˇr´ıkazu pro zruˇsen´ı uzlu . . . 147

10.3 Struktura pˇr´ıkazu pro pˇrihl´aˇsen´ı se k uzlu . . . 148

10.4 Struktura pˇr´ıkazu pro odhl´aˇsen´ı se od uzlu . . . 148

10.5 Struktura pˇr´ıkazu pro ohl´aˇsen´ı chyby . . . 148

10.6 Struktura pˇr´ıkazu pro zmˇenu vazeb mezi uzly . . . 149

10.7 Struktura pˇr´ıkazu pro zmˇenu pˇr´ıstupov´ych pr´av . . . 149

10.8 Struktura pˇr´ıkazu pro nastaven´ı v´ychoz´ıch pˇr´ıstupov´ych pr´av u ostatn´ıch uˇzivatel˚u . . . 150

10.9 Struktura pˇr´ıkazu pro zmˇenu vlastn´ıka uzlu . . . 150

10.10Struktura pˇr´ıkazu zamknut´ı uzlu . . . 151

10.11Struktura pˇr´ıkazu odemˇcen´ı uzlu . . . 151

10.12Struktura pˇr´ıkazu pro nastaven´ı priority uzlu . . . 151

10.13Struktura pˇr´ıkazu pro vytvoˇren´ı skupiny tag˚u . . . 153

10.14Struktura pˇr´ıkazu pro zruˇsen´ı skupiny tag˚u . . . 153

10.15Struktura pˇr´ıkazu pro pˇrihl´aˇsen´ı se ke skupiny tag˚u . . . 153

10.16Struktura pˇr´ıkazu pro odhl´aˇsen´ı se od skupiny tag˚u . . . 154

10.17Struktura pˇr´ıkazu pro vytvoˇren´ı nov´eho tagu . . . 155

(13)

10.18Struktura pˇr´ıkazu pro zruˇsen´ı tagu . . . 155

10.19Struktura pˇr´ıkazu pro nastaven´ı hodnoty tagu int8 . . . 156

10.20Struktura pˇr´ıkazu pro nastaven´ı hodnoty tagu uint8 . . . 156

10.21Struktura pˇr´ıkazu pro nastaven´ı hodnoty tagu int16 . . . 157

10.22Struktura pˇr´ıkazu pro nastaven´ı hodnoty tagu uint16 . . . 157

10.23Struktura pˇr´ıkazu pro nastaven´ı hodnoty tagu int32 . . . 157

10.24Struktura pˇr´ıkazu pro nastaven´ı hodnoty tagu uint32 . . . 157

10.25Struktura pˇr´ıkazu pro nastaven´ı hodnoty tagu real32 . . . 158

10.26Struktura pˇr´ıkazu pro nastaven´ı hodnoty tagu real64 . . . 158

10.27Struktura pˇr´ıkazu pro vytvoˇren´ı vrstvy . . . 159

10.28Struktura pˇr´ıkazu pro zruˇsen´ı vrstvy . . . 159

10.29Struktura pˇr´ıkazu pro pˇrihl´aˇsen´ı se k vrstvˇe . . . 159

10.30Struktura pˇr´ıkazu pro odhl´aˇsen´ı se od vrstvy . . . 160

10.31Struktura pˇr´ıkazu pro vytvoˇren´ı/nastaven´ı poloˇzky vrstvy, jej´ıˇz typ je int8 . . . 160

10.32Struktura pˇr´ıkazu pro vytvoˇren´ı/nastaven´ı poloˇzky vrstvy, jej´ıˇz typ je uint8 . . . 161

10.33Struktura pˇr´ıkazu pro vytvoˇren´ı/nastaven´ı poloˇzky vrstvy, jej´ıˇz typ je int16 . . . 161

10.34Struktura pˇr´ıkazu pro vytvoˇren´ı/nastaven´ı poloˇzky vrstvy, jej´ıˇz typ je uint16 . . . 162

10.35Struktura pˇr´ıkazu pro vytvoˇren´ı/nastaven´ı poloˇzky vrstvy, jej´ıˇz typ je int32 . . . 162

10.36Struktura pˇr´ıkazu pro vytvoˇren´ı/nastaven´ı poloˇzky vrstvy, jej´ıˇz typ je uint32 . . . 162

10.37Struktura pˇr´ıkazu pro vytvoˇren´ı/nastaven´ı poloˇzky vrstvy, jej´ıˇz typ je real32 . . . 163

10.38Struktura pˇr´ıkazu pro vytvoˇren´ı/nastaven´ı poloˇzky vrstvy, jej´ıˇz typ je real64 . . . 163

10.39Struktura pˇr´ıkazu pro nastaven´ı hodnoty tagu real32 . . . 163

(14)

Seznam tabulek

4.1 Metody autentizace . . . 34

4.2 Seznam pˇr´ıkaz˚u pro dohadov´an´ı vlastnost´ı spojen´ı . . . 39

4.3 Seznam vlastnost´ı spojen´ı . . . 39

7.1 Testovan´a zpoˇzdˇen´ı a jejich rozptyl . . . 103

(15)

Seznam symbol˚ u a zkratek

ASVR Application of Shared Virtual Reality CC Congestion Control

DCCP Datagram Congestion Control Protocol DED Data Exchange Definition

DoS Denial of Service

DDoS Distributed Denial of Service

DTLS Datagram Transport Layer Security ECN Explicit Congestion Notification FC Flow Control

FPS Frames per Second

MAC Message Authentication Code

MMORPG Massively Multiplayer Online Role Playing Game MTU Maximum Transmission Unit

NTP Network Time Protocol

PMTU Path Maximum Transmission Unit RTT Round Trip Time

TCP Transmision Control Protocol TLS Transport Layer Security VR Virtual Reality

(16)

SCTP Stream Control Transport Protocol SRTT Smoothed Round Trip Time

SVR Shared Virtual Reality UDP User Datagram Protocol URL Uniform Resource Locator WFQ Weighted Fair Queuing

(17)

Kapitola 1 Uvod ´

V oblasti poˇc´ıtaˇcov´e grafiky se ˇc´ım d´al ˇcastˇeji setk´av´ame s poˇzadavkem na pˇrenos dat mezi grafick´ymi aplikacemi. V grafick´ych studi´ıch je to d´ano t´ım, ˇze se pouˇz´ıvaj´ı aplikace se specifick´ym zamˇeˇren´ım na dan´y ´ukol (fy- zik´aln´ı simulace, vizualizace, animace postav, apod.). Z´aroveˇn doch´az´ı k ´uzk´e profesn´ı specializaci grafik˚u pracuj´ıc´ıch s tˇemito aplikacemi. V situaci, kdy spolupracuje nˇekolik lid´ı v jednom t´ymu nebo uˇzivatel pouˇz´ıv´a v´ıce r˚uzn´ych aplikac´ı pro svoji pr´aci, tak nar´aˇz´ıme na probl´em s konverz´ı a pˇrenosem dat.

Obecnˇe plat´ı, ˇze v´ystupn´ı soubor jedn´e aplikace je vstupem pro jinou apli- kaci. Vˇetˇsinou se data v tomto pˇr´ıpadˇe ukl´adaj´ı do textov´ych soubor˚u, kdy pˇri velk´em objemu dat ne´umˇernˇe nar˚ust´a velikost v´ysledn´ych soubor˚u i doba pro jejich ukl´ad´an´ı a naˇc´ıt´an´ı. V pracovn´ıch postupech uˇzivatel˚u se st´ale setk´av´ame s form´atem OBJ Wavefront nebo novˇeji s form´atem COLLADA [3] postaven´em na technologii XML, kter´y m´a ambice st´at se pr˚umyslov´ym standardem v dan´e oblasti. Obˇe technologie ovˇsem neˇreˇs´ı probl´em nezbyt- nosti ukl´ad´an´ı dat do souboru a jeho opˇetovn´e naˇc´ıt´an´ı v jin´e aplikaci i pˇri sebemenˇs´ı zmˇenˇe dat.

Dalˇs´ı oblast poˇc´ıtaˇcov´e grafiky, kdy se pˇren´aˇsej´ı data mezi aplikacemi, jsou aplikace sd´ılen´e virtu´aln´ı reality (SVR). Data jsou v tomto pˇr´ıpadˇe pˇren´aˇsena pomoc´ı s´ıt’ov´eho protokolu. Nejrozˇs´ıˇrenˇejˇs´ımi aplikacemi SVR jsou bezpochyby hern´ı aplikace typu first-person shooter (FPS), kter´e vˇetˇsinou nevyˇzaduj´ı sd´ılen´ı geometrie a topologie 3D objekt˚u. Vystaˇc´ı si se sd´ılen´ım polohy jednotliv´ych avatar˚u a jejich stav˚u. Pokud se uˇzivatel´e ASVR maj´ı setk´avat a spoleˇcnˇe mˇenit prostˇred´ı virtu´aln´ı reality, tak se protokoly hern´ıch aplikac´ı jev´ı jako nedostateˇcn´e. V takov´em pˇr´ıpadˇe je potˇreba odliˇsn´y pˇr´ıstup n´avrhu s´ıt’ov´eho protokolu. N´aroky na nˇej jsou ovˇsem velmi protich˚udn´e.

Jednak jsou vyˇzadov´any n´ızk´e latence pˇren´aˇsen´ych dat, jak to poskytuje napˇr´ıklad transportn´ı protokol UDP. Z´aroveˇn je potˇreba zaruˇcit spolehlivost pˇren´aˇsen´ych dat, ale nikoliv ´uplnou spolehlivost pˇren´aˇsen´ych dat doruˇcen´ych

(18)

ve spr´avn´em poˇrad´ı, tak jak to zaruˇcuje napˇr´ıklad transportn´ı protokol TCP.

S´ıt’ov´y protokol, kter´y mˇel ambice b´yt univerz´aln´ım s´ıt’ov´ym protokolem pro komunikaci mezi grafick´ymi aplikacemi, je protokol Verse. Verse byl od poˇc´atku navrhov´an speci´alnˇe pro efektivn´ı real-timov´e sd´ılen´ı dat. Na jeho v´yvoji se pod´ılelo Uni-Verse konsorcium v r´amci 6. r´amcov´eho program Ev- ropsk´e unie. ˇCleny konsorcia bylo nˇekolik v´yznamn´ych evropsk´ych univerzit a v´yzkumn´ych instituc´ı (KTH, Fraunhoufer Institut, Helsinky University of Technology, Interactive Institute, Blender Foundation, a dalˇs´ı). Tento projekt mˇel za c´ıl i v´yvoj podp˚urn´eho aplikaˇcn´ıho vybaven´ı nebo integraci protokolu do vybran´ych grafick´ych aplikac´ı. Bohuˇzel se moˇzn´a aˇz pˇr´ıliˇs zamˇeˇril sp´ıˇse na v´yvoj aplikac´ı pouˇz´ıvaj´ıc´ı protokol Verse neˇz na v´yvoj samotn´eho proto- kolu. Po ukonˇcen´ı financov´an´ı z Evropsk´e unie v´yvoj protokolu Verse bohuˇzel v´ıcem´enˇe ustal a protokol Verse se nakonec z mnoha d˚uvod˚u pˇr´ıliˇs nerozˇs´ıˇril.

C´ılem t´eto disertace bylo navrhnout lepˇs´ı n´ahradu p˚uvodn´ıho protokolu.

Pr´ace je organizov´ana t´ımto zp˚usobem: teoretick´y ´uvod do n´avrhu s´ıt’o- v´ych protokol˚u. Dalˇs´ı kapitola je vˇenov´ana popisu p˚uvodn´ıho protokolu Verse, na kterou navazuje kapitola vˇenovan´a n´avrhu nov´eho protokolu Verse. N´asle- duj´ıc´ı kapitola se vˇenuje doporuˇcen´ım, jak prov´adˇet implementaci nov´eho protokolu. Posledn´ı kapitola obsahuje v´ysledky v´ykonnostn´ıch test˚u.

(19)

Kapitola 2

Uvod do teorie n´ ´ avrhu s´ıt’ov´ ych protokol˚ u

N´avrh s´ıt’ov´eho protokolu je netrivi´aln´ı ˇcinnost pˇri kter´e nen´ı vhodn´e se spol´ehat pouze na vlastn´ı ´usudek jako je to moˇzn´e pˇri n´avrhu sekvenˇcn´ıho algoritmu. Pˇri n´avrhu s´ıt’ov´eho protokolu je nutn´e uvaˇzovat, ˇze spolu komu- nikuj´ı dva a v´ıce poˇc´ıtaˇc˚u. Pokud autor navrhuje sloˇzitˇejˇs´ı s´ıt’ov´y protokol, tak nen´ı v jeho sil´ach uvaˇzovat vˇsechny moˇzn´e sc´en´aˇre komunikace. Uˇz pˇri sa- motn´e tvorbˇe n´avrhu se m˚uˇze dopustit mnoha chyb, kter´e ve v´ysledku vedou k nepˇredv´ıdateln´emu chov´an´ı protokolu.

Pˇri n´avrhu s´ıt’ov´eho protokolu je vhodn´e nejprve vytvoˇrit detailn´ı spe- cifikaci s´ıt’ov´eho protokolu. Z´aroveˇn je vhodn´e, aby tv˚urci n´avrh protokolu formalizoval do zjednoduˇsen´eho modelu a provedli verifikaci tohoto modelu.

Pˇri ovˇeˇrov´an´ı n´avrhu protokolu je moˇzn´e pouˇz´ıt celou ˇradu programov´ych n´astroj˚u, kter´e umoˇzˇnuj´ı odhalit jeho chyby. Jedn´ım z takov´ych n´astroj˚u je program Spin [21], kter´y slouˇz´ı k verifikaci syst´em˚u popsan´ych pomoc´ı programovac´ıho jazyka PROMELA. Program Spin umoˇzˇnuje prov´adˇet simu- laci vytvoˇren´eho modelu, nebo umoˇzˇnuje vygenerovat program v jazyce C, kter´y m˚uˇze prov´est ´uplnou prohl´ıdku stavov´eho prostoru dan´eho syst´emu.

Spin m˚uˇze bˇehem prohl´ıdky stavov´eho prostoru prov´adˇet kontrolu existence uv´aznut´ı, nevyv´ıjej´ıc´ıch se cykl˚u, nekorektn´ıch koncov´ych stav˚u, apod. Dalˇs´ı nem´enˇe d˚uleˇzitou vlastnost´ı je moˇznost ovˇeˇrovat vlastnost syst´emu pomoc´ı line´arn´ı tempor´aln´ı logiky (LTL).

Po verifikaci n´avrhu protokolu n´asleduje jeho implementace ve vhodn´em programovac´ım jazyku. Vlastn´ı implementaci je vhodn´e otestovat a n´aslednˇe nasadit do re´aln´eho provozu. V ide´aln´ım pˇr´ıpadˇe uˇz nen´ı nikdy potˇreba proto- kol mˇenit, protoˇze velmi dobˇre ˇsk´aluje a je moˇzn´y vymˇenit kter´ykoliv protokol na niˇzˇs´ı vrstvˇe. V praxi se pˇri testov´an´ı nebo jeho nasazen´ı mohou objevit pot´ıˇze, kter´e autoˇri ve sv´em p˚uvodn´ım n´avrhu neoˇcek´avali ˇci nepˇredv´ıdali,

(20)

coˇz ˇcasto vede k nutnosti zmˇenit p˚uvodn´ı specifikaci. Zmˇena ve specifikaci by v ide´aln´ım pˇr´ıpadˇe mˇela b´yt opˇet n´asledov´ana verifikac´ım zmˇenˇen´eho mo- delu a n´aslednˇe implementac´ı a testov´an´ım. N´avrh s´ıt’ov´eho protokolu je ˇziv´y proces, kter´y nemus´ı nikdy ustat. Pˇr´ıkladem protokolu, kter´y se st´ale vyv´ıj´ı a snaˇz´ı se reflektovat v´yvoj s´ıt’ov´ych technologi´ı, je napˇr´ıklad protokol TCP.

Proti snah´am o zmˇenu specifikace p˚uvodn´ıho protokolu jde naopak potˇreba o zachov´an´ı zpˇetn´e kompatibility s p˚uvodn´ı specifikac´ı. S´ıt’ov´e prvky, koncov´a zaˇr´ızen´ı a aplikace oˇcek´avaj´ı nebo vyˇzaduj´ı urˇcit´e chov´an´ı protokolu a jeho ˇ

cast´e a z´asadn´ı zmˇeny m˚uˇze m´ıt negativn´ı dopad na fungov´an´ı aplikac´ı nebo cel´e s´ıtˇe.

Prvn´ı, nejd˚uleˇzitˇejˇs´ı ˇc´ast´ı n´avrhu protokolu je tedy vytvoˇren´ı jeho speci- fikace. Kaˇzd´a specifikace protokolu by mˇela obsahovat pˇet ˇc´ast´ı.

1. Definice a popis sluˇzby, kterou bude protokol poskytovat 2. Pˇredpoklady o prostˇred´ı, ve kter´em bude protokol provozov´an 3. Definice zpr´av, kter´e se budou pouˇz´ıvat k implementaci protokolu 4. Form´at a zp˚usob k´odov´an´ı zpr´av

5. Seznam pravidel, kter´e budou zajiˇst’ovat spr´avn´e doruˇcen´ı dat

Pˇri popisu prostˇred´ı, ve kter´em bude protokol provozov´an, se ˇcasto vyuˇz´ıv´a tzv. v´ıcevrstv´y model, kter´y velmi zjednoduˇsuje n´avrh vˇetˇsiny protokol˚u. Ve specifikaci je ˇcasto uvedeno, na jak´e vrstvˇe je dan´y protokol zam´yˇslen a jak´e poˇzadavky jsou kladeny na niˇzˇs´ı vrstvu. V mnoha pˇr´ıpadech je v n´avrhu protokolu uvedeno, ˇze na niˇzˇs´ı vrstvˇe je vyˇzadov´an nˇejak´y konkr´etn´ı proto- kol. Pˇri definici zpr´av je m´alokdy moˇzn´e pouˇz´ıt v´yˇcet vˇsech moˇzn´ych zpr´av.

Vˇetˇsina protokol˚u m´a tud´ıˇz nˇejakou hierarchickou strukturu zpr´avy jako je napˇr´ıklad hlaviˇcka, tˇelo zpr´avy, apod. Specifikace pak obsahuje popis struk- tury zpr´av a jej´ı moˇzn´e hodnoty. Nejtˇeˇzˇs´ı ˇc´ast´ı n´avrhu protokolu je vytvoˇren´ı seznamu pravidel, kter´a zajist´ı jeho spr´avn´e fungov´an´ı.

Pˇri vlastn´ım n´avrhu specifikace protokolu a n´asledn´e implementaci je vhodn´e dodrˇzovat urˇcit´e z´asady. G. J. Holzman [21] navrhuje pˇri n´avrhu protokolu dodrˇzovat n´asleduj´ıc´ıch 10 krok˚u.

1. Nejprve je vhodn´e ujistit se, ˇze probl´em je dobˇre definovan´y. Pˇred vlastn´ım n´avrhem mus´ı b´yt jasn´a a zˇrejm´a vˇsechna krit´eria, poˇzadavky a omezen´ı, kter´a budou na navrhovan´y protokol kladena.

2. D´ale je vhodn´e definovat sluˇzbu, kterou bude dan´y protokol poskytovat.

(21)

3. Pˇred n´avrhem vnitˇrn´ı funkcionality programu je v´yhodn´e navrhnout jeho vnˇejˇs´ı funkcionalitu, neboli jak bude protokol komunikovat s nadˇra- zenou vrstvou. V tomto kroku n´avrhu je vhodn´e o protokolu uvaˇzovat jako o ˇcern´e skˇr´ıˇnce, kter´a splˇnuje poˇzadavky z pˇredchoz´ıch krok˚u.

4. N´avrh protokolu by mˇel b´yt co moˇzn´a nejjednoduˇsˇs´ı, protoˇze kompliko- van´e protokoly jsou n´achylnˇejˇs´ı na chyby, sloˇzitˇe se implementuj´ı, veri- fikuj´ı a ˇcasto nejsou tak efektivn´ı jako jednoduch´e protokoly. Probl´em, kter´y se jev´ı jako komplikovan´y, lze ˇcasto rozloˇzit na nˇekolik jedno- duch´ych podprobl´em˚u a ˇreˇsit je samostatnˇe.

5. Nen´ı dobr´e spojovat, co je nez´avisl´e.

6. Dobˇre navrˇzen´y protokol nezakazuje irelevantn´ı a ned˚uleˇzit´e vˇeci. Dobˇre navrˇzen´y protokol by mˇel m´ıt moˇznost se d´ale vyv´ıjet.

7. Pˇred vlastn´ı implementac´ı protokolu je vhodn´e vytvoˇrit model proto- kolu a ovˇeˇrit, ˇze jsou splnˇena vˇsechna krit´eria n´avrhu protokolu.

8. Teprve v tomto kroku dojde k vlastn´ı implementaci protokolu, v´ykon- nostn´ım test˚um a pˇr´ıpadn´e optimalizaci k´odu.

9. Po implementaci by mˇelo b´yt ovˇeˇreno, ˇze se implementace chov´a stejnˇe jako model vytvoˇren´y v 7. kroku.

10. Nen´ı vhodn´e vynechat 1. aˇz 7. krok.

V´yˇse uveden´a pravidla nejsou naˇr´ızen´ım, jak postupovat pˇri n´avrhu pro- tokolu, ale maj´ı slouˇzit pouze jako doporuˇcen´ı pro autory protokolu. Nutno podotknout, ˇze se pˇri n´avrhu s´ıt’ov´ych protokol˚u nejˇcastˇeji poruˇsuje 10. pra- vidlo

(22)

Kapitola 3

P˚ uvodn´ı protokol Verse

V´yvoj p˚uvodn´ıho protokolu Verse zapoˇcal Eskil Steenberg a Emil Brink v roce 1999 na KTH. Tento protokol byl navrhov´an pomˇernˇe ˇzivelnˇe a jeho n´avrh se rozhodnˇe neprov´adˇel podle z´asad popsan´ych v druh´e kapitole. V ko- neˇcn´em d˚usledku m´a specifikace [32] i implementace p˚uvodn´ıho protokolu Verse mnoho nedostatk˚u. Na druhou stranu v jeho specifikaci lze nal´ezt nˇekolik zaj´ımav´ych myˇslenek, kter´e byly inspirac´ı pro nov´y n´avrh specifikace protokolu Verse. Aby bylo moˇzn´e porovnat p˚uvodn´ı a nov´y n´avrh, tak v t´eto kapitole budou pops´any z´akladn´ı vlastnosti p˚uvodn´ıho protokolu Verse.

Protokol Verse pouˇz´ıv´a architekturu klient-server. Na transportn´ı vrstvˇe vyˇzaduje protokol UDP, protoˇze umoˇzˇnuje zaruˇcit n´ızkou latenci doruˇcen´ych dat a je ˇsiroce podporovan´y. Protokol poskytuje ˇc´asteˇcnˇe spolehliv´y pˇrenosov´y kan´al, kter´y pˇrepos´ıl´a pouze aktu´aln´ı data. Protokol byl od poˇc´atku navrˇzen speci´alnˇe pro real-timov´e sd´ılen´ı 3D dat na serveru. Pokud klient provede zmˇenu ve sd´ılen´ych datech (poloha objektu, topologie objektu, apod.), tak by mˇel o t´eto zmˇenˇe odeslat pˇr´ısluˇsnou zpr´avu serveru. Server se n´aslednˇe mus´ı postarat o pˇreposl´an´ı zpr´avy vˇsem klient˚um, kteˇr´ı se o tato sd´ılen´a data zaj´ımaj´ı.

3.1 Struktura paketu

Kaˇzd´y paket p˚uvodn´ıho protokolu m´a velice jednoduchou strukturu:

Hlaviˇcka obsahuje pouze Packet ID, kter´y slouˇz´ı jako je jedineˇcn´y iden- tifik´ator paketu, kter´y odes´ılaj´ıc´ı strana inkrementuje s kaˇzd´ym odeslan´ym paketem. Za hlaviˇckou n´asleduj´ı pˇr´ıkazy, jejichˇz typ, d´elka a struktura je pevnˇe dan´a prvn´ım bytem kaˇzd´eho pˇr´ıkazu. Takov´a jednoduch´a struktura paketu m´a v´yhodu v tom, ˇze se ˇsetˇr´ı m´ıstem na d˚uleˇzit´a data, ale na druhou stranu nen´ı pˇr´ıliˇs flexibiln´ı.

(23)

0 0 0 1 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---+---+---+---+

0 | Packet_ID |

+---+---+---+---+

1 | Commands |

. .

| |

+---+---+---+---+

Obr´azek 3.1: Struktura paketu p˚uvodn´ıho protokolu Verse

3.2 Handshake

Handshake mezi klientem a serverem m´a n´asleduj´ıc´ı podobu:

client server

o o

| |

| Packet_ID=0 Cmd_ID=0 State=0 Public_Key | +--->+----+

| | |

| | |

| Packet_ID=0 Cmd_ID=0 State=0 | |

+----+<---+<---+

| | Sec=123 Nsec=345 Public_Key |

| | |

| | Packet_ID=1 Cmd_ID=0 State=2 |

+--->+--->+----+

| Encrypted_Name Encrypted_Password | |

| | |

| Packet_ID=1 Cmd_ID=0 Avatar_ID | |

+----+<---+<---+

| | Encrypted_Secret_Key |

| | |

| | Packet_ID=2 XOR_Encrypted_Command | +--->+--->+

| |

. .

. .

Obr´azek 3.2: Pˇr´ıklad v´ymˇeny paket˚u bˇehem handshaku

Klient zahajuje spojen´ı se serverem zasl´an´ım paketu, kde se server dozv´ı RSA veˇrejn´y kl´ıˇc klienta. Server odpov´ıd´a zasl´an´ım paketu, kter´y obsahuje kromˇe RSA veˇrejn´eho kl´ıˇce serveru tak´e ˇcasovou znaˇcku, kter´a slouˇz´ı k syn- chronizaci ˇcasu na stranˇe klienta a serveru. Kdyˇz klient zn´a veˇrejn´y kl´ıˇc serveru, tak pomoc´ı nˇeho zaˇsifruje jm´eno a heslo a poˇsle ho serveru. Ser- ver zaˇsifrovan´e jm´eno a heslo rozˇsifruje pomoc´ı tajn´eho kl´ıˇce a pokud se shoduje s jeho z´aznamy, tak na tento paket odpov´ı paketem obsahuj´ıc´ım pˇr´ıkaz potvrzuj´ıc´ı pˇripojen´ı. Tento pˇr´ıkaz z´aroveˇn obsahuje jedineˇcn´y identi- fik´ator avatara a tajn´y kl´ıˇc pro symetrickou ˇsifru, kter´y je zaˇsifrovan´y pomoc´ı

(24)

veˇrejn´eho kl´ıˇce klienta. Klient m˚uˇze po obdrˇzen´ı tohoto paketu zaˇc´ıt pos´ılat serveru pakety zaˇsifrovan´e pomoc´ı symetrick´e ˇsifry. V kaˇzd´em kroku hand- shaku pos´ıl´a klient sv˚uj poˇzadavek opakovanˇe, dokud nedostane od serveru odpovˇed’ nebo dokud nevyprˇs´ı timout pro dan´e spojen´ı, kter´y je pro kaˇzd´e spojen´ı 30 sekund.

Pouˇz´ıvan´y handshake je zraniteln´y proti Man-in-the-middle ´utoku, protoˇze navrˇzen´y handshake neobsahuje ˇz´adn´y mechanismus, kter´y by mohl ovˇeˇrit identitu serveru. Jedin´ym moˇzn´ym zp˚usobem jak se br´anit proti man-in- the-middle ´utoku je pˇrenesen´ı veˇrejn´eho kl´ıˇce serveru nˇejak´ym jin´ym za- bezpeˇcen´ym kan´alem a pˇri handshaku kontrolovat shodu tˇechto kl´ıˇc˚u. Dalˇs´ı nedostatek spoˇc´ıv´a v zasl´an´ı pouze jedn´e ˇcasov´e znaˇcky jako odpovˇed’ na prvn´ı paket. Ke zjiˇstˇen´ı pˇresn´eho ˇcasu na serveru je toto naprosto nedo- stateˇcn´y mechanismus. Bylo by vhodnˇejˇs´ı zav´est mechanismus pouˇz´ıvan´y v protokolu NTP.

Dalˇs´ım v´aˇzn´ym nedostatkem je pouˇzit´a symetrick´a ˇsifra. ˇSifrov´an´ı i de- ˇsifrov´an´ı se prov´ad´ı pomoc´ı velmi jednoduch´eho algoritmu, kter´y je pops´an pomoc´ı n´asleduj´ıc´ıho pseudo-k´odu:

begin

pos := packet id;

pos := key[pos mod key size];

for i := 0 to data size step 1 do

data[i] := data[i] xor key[(i + pos) mod key size];

od end

Kdyˇz vezmeme v ´uvahu, ˇze velikost tajn´eho kl´ıˇce je pevnˇe nastavena na 64 byt˚u a ˇze k ˇsifrov´an´ı se pouˇz´ıv´a de-facto pouze funkce XOR, tak jde o velmi chatrn´e zabezpeˇcen´ı. Situaci nav´ıc zhorˇsuje fakt, ˇze se nepouˇz´ıv´a ˇ

z´adn´e vyplˇnov´an´ı n´ahodn´ymi ˇc´ısly a ˇze vˇetˇsina klient˚u pos´ıl´a na zaˇc´atku spojen´ı podobnou sekvenci pˇr´ıkaz˚u.

3.3 Resend mechanismus

P˚uvodn´ı protokol Verse pouˇz´ıv´a velmi zaj´ımav´y koncept resend mecha- nismu, kter´y se snaˇz´ı pˇreposlat pouze ta data, kter´a jsou aktu´aln´ı. Nav´ıc je detekce ztr´aty paketu navrˇzena tak, aby doch´azelo k co moˇzn´a nejmenˇs´ımu zpoˇzdˇen´ım pˇri pˇrepos´ıl´an´ı paketu. Kdyˇz bude uvaˇzov´an pˇr´ıklad z obr´azku 3.3, tak ztr´ata paketu 32 nen´ı detekov´ana odes´ılaj´ıc´ı stranou na z´akladˇe vyprˇsen´ı

(25)

ˇ

casovaˇce dan´eho paketu, protoˇze takov´y pˇr´ıstup by vedl ke zbyteˇcnˇe velk´ym zpoˇzdˇen´ım.

Pouˇzit´y pˇr´ıstup bude pops´an na n´asleduj´ıc´ım zjednoduˇsen´em pˇr´ıkladu, kdy odes´ılatel pos´ıl´a v pravideln´ych intervalech polohu objektu. Kdyˇz pˇr´ıjemce

´

uspˇeˇsnˇe pˇrijme paket 31, tak pˇrijet´ı tohoto paketu potvrd´ı odesl´an´ım paketu obsahuj´ıc´ıho pˇr´ıkaz ACK = 31 a z´aroveˇn oˇcek´av´a pˇrijet´ı paketu 32. Ten je ovˇsem ztracen. Pˇr´ıjemce detekuje ztr´atu paketu 32 tehdy, kdyˇz pˇrijme paket 33. Paket 32 je povaˇzov´an za definitivnˇe ztracen´y, protoˇze autoˇri p˚uvodn´ıho protokolu uvaˇzovali, ˇze na s´ıti doch´az´ı zmˇenˇe poˇrad´ı paket˚u pouze ve speci´aln´ıch pˇr´ıpadech, kdy s´ıt’ nefunguje korektnˇe. Samozˇrejmˇe i v tomto existuj´ı vyj´ımky.

Obr´azek 3.3: Zjednoduˇsen´y pˇr´ıklad v´ymˇeny paket˚u

Pˇr´ıjemce potvrd´ı pˇrijet´ı paketu 33 a ztr´atu paketu 32 odesl´an´ım paketu obsahuj´ıc´ıho pˇr´ıkazy N AK = 32 a ACK = 33. Kdyˇz odes´ılatel obdrˇz´ı tento paket, tak nedojde k prost´emu pˇreposl´an´ı paketu 32, protoˇze by se pˇreposlala neaktu´aln´ı pozice objektu. Odes´ılatel mus´ı z paketu 32 pˇreposlat pouze ta data, kter´a jiˇz nebyla odesl´ana v nˇejak´em paketu, jehoˇz P acket ID bylo vˇetˇs´ı jak 32.

V´yˇse popsan´y resend mechanismus m´a v´yhodu v tom, ˇze nen´ı nutn´e pˇrepos´ılat neaktu´aln´ı data a detekce ztr´aty paketu je pomˇernˇe efektivn´ı, protoˇze ke ztr´atˇe paketu doch´az´ı vˇetˇsinou tehdy, kdyˇz se odes´ıl´a velk´e mnoˇz- stv´ı paket˚u a dojde k zahlcen´ı pˇrenosov´ych cest. Na druhou stranu v´yˇse uve- den´y koncept m´a nˇekolik nedostatk˚u. K potvrzen´ı pˇrijet´ı paketu m˚uˇze doj´ıt pouze tehdy, kdyˇz pˇr´ıjemce pos´ıl´a paket. K tomu m˚uˇze doj´ıt ze tˇrech d˚uvod˚u.

Pˇr´ıjemce m´a nˇejak´a data, kter´a chce pˇreposlat protistranˇe. Pˇr´ıjemce mus´ı poslat tzv. keep-alive packet, kter´y se pos´ıl´a kaˇzd´e dvˇe vteˇriny. Posledn´ım d˚uvodem je nutnost urgentnˇe doruˇcit informaci o ztr´atˇe paketu.

(26)

Dalˇs´ım nedostatkem resend mechanismu je fakt, ˇze se s potvrzovac´ımi pˇr´ıkazy ACK a N AK zach´az´ı jako s jak´ymkoliv jin´ymi pˇr´ıkazy. Jin´ymi slovy ACK a N AK pˇr´ıkazy jsou zasl´any odes´ılateli jenom jednou a jejich pˇr´ıpadn´a ztr´ata se detekuje opˇet na stranˇe odes´ılatele.

Posledn´ım nedostatkem je absence jak´akoliv komprese ACK a N AK pˇr´ıkazu, takˇze pˇri velk´em zpoˇzdˇen´ı mezi odes´ılatelem a pˇr´ıjemce doch´az´ı k vyplnˇen´ı velk´e ˇc´asti paketu pouze ACK a N AK pˇr´ıkazy.

3.4 Datov´ y model

Jedn´ım z c´ıl˚u protokolu Verse bylo vytvoˇrit s´ıt’ov´y protokol kter´y by umoˇzˇnoval komunikaci rozd´ıln´ych aplikac´ı. Aby bylo moˇzn´e sd´ılet mezi apli- kacemi data, byl vytvoˇren datov´y model a odpov´ıdaj´ıc´ı sada zpr´av pro v´ymˇenu tˇechto dat. Datov´y model byl na jednu stranu navrˇzen pomˇernˇe obecnˇe, ale nˇekter´e ˇc´asti obsahuj´ı zcela nelogick´a a zbyteˇcn´a omezen´ı.

Vˇsechna data jsou uloˇzena v tzv. uzlech. Kaˇzd´y uzel m´a sv˚uj jedineˇcn´y identifik´ator a typ, kter´y urˇcuje jeho dalˇs´ı moˇznou strukturu. Rozliˇsuje se 7 typ˚u uzl˚u:

1. Objektov´y uzel 2. Geometrick´y uzel 3. Materi´alov´y uzel 4. Bitmapov´y uzel 5. Textov´y uzel 6. Kˇrivkov´y uzel 7. Audio uzel

Objektov´y uzel umoˇzˇnuje sd´ılet informaci o poloze, rotaci a velikosti ob- jektu. Z´aroveˇn m˚uˇze tento uzel slouˇzit jako zdroj svˇetla a m˚uˇze b´yt propojen s jin´ym uzlem. Kaˇzd´y uzel umoˇzˇnuje sd´ılet informace v tzv. tagech a sku- pin´ach tag˚u. Tag m´a v r´amci sv´e skupiny jedineˇcn´y identifik´ator a jm´eno, kter´e umoˇzˇnuj´ı jeho adresov´an´ı v pˇr´ıkazech. Tag m˚uˇze n´est ˇc´ıselnou infor- maci, logickou hodnotu nebo ˇretˇezec. Dalˇs´ı typu uzl˚u jsou pops´any ve speci- fikaci [32] nebo v ˇcl´anku [9].

Aby se Verse klient dozvˇedˇel o uzlech sd´ılen´ych na serveru, tak mus´ı po- moc´ı speci´aln´ıho pˇr´ıkazu node index subscribe zaˇz´adat o pˇrihl´aˇsen´ı k dan´emu

(27)

typu uzl˚u. Verse server na tento poˇzadavek odpov´ıd´a zasl´an´ım sady pˇr´ıkaz˚u node create. Klient se n´aslednˇe m˚uˇze pˇrihl´asit k vlastn´ım dat˚um dan´eho uzlu.

Datov´y model na jednu stranu tlaˇc´ı v´yvoj´aˇre, aby napˇr´ıklad sd´ıleli trans- formaci objekt˚u v objektov´em uzlu, geometrii a topologii s´ıtˇe v geomet- rick´em uzlu, ale na druhou stranu neumoˇzˇnuje sd´ılet informace o hran´ach.

Neumoˇzˇnuje sd´ılet informace o ploˇsk´ach, kter´e obsahuj´ı v´ıce jak 4 hrany, atd.

V´ysledn´y datov´y model i cel´y s´ıt’ov´y protokol je dosti tˇeˇzkop´adn´y, neflexi- biln´ı. Nehledˇe na to, ˇze jeho implementace v dalˇs´ım programovac´ım jazyku by byla dosti pracn´a.

(28)

Kapitola 4

Nov´ y protokol Verse

Rozhodnut´ı vytvoˇrit zcela nov´y protokol mˇelo mnoho d˚uvod˚u. Jeho p˚u- vodn´ı ad-hoc n´avrh, zp˚usob implementace a nekompletn´ı specifikace ne- umoˇzˇnovaly n´avrh zmˇenit, aby v´ysledn´y protokol byl robustn´ı, spolehliv´y a z´aroveˇn zpˇetnˇe kompatibiln´ı. Dalˇs´ım d˚uvodem pro n´avrh nov´eho protokolu byla zkuˇsenost s implementac´ı star´eho protokolu do programu 3D mode- lovac´ıho a animaˇcn´ıho programu Blender, kter´a byla velmi komplikovan´a a v koneˇcn´em d˚usledku nekompletn´ı, pomal´a a nestabiln´ı. V´ysledn´a implemen- tace byla prezentov´ana na konferenci BCONF 2005 [17].

Nov´y protokol Verse byl zcela pˇrepracov´an a pˇri jeho tvorbˇe se postupo- valo podle z´asad popsan´ych v druh´e kapitole. Z´aroveˇn byl br´an zˇretel na to, aby jeho budouc´ı implementace a integrace do existuj´ıc´ıch i nov´ych aplikac´ı byla co moˇzn´a nejjednoduˇsˇs´ı.

4.1 Poˇ zadavky na nov´ y protokol

Vˇsechny podm´ınky na navrhovan´y protokol vych´azej´ı z myˇslenky, ˇze pro- tokol by mˇel umoˇzˇnovat v re´aln´em ˇcase sd´ılet data mezi grafick´ymi aplikacemi pomoc´ı s´ıtˇe Internet. Z tohoto lze odvodit spoustu d´ılˇc´ıch poˇzadavk˚u:

• Data mus´ı b´yt pˇren´aˇsena s minim´aln´ımi latencemi

• Pro pˇrenos dat je vyˇzadov´ana ˇc´asteˇcn´a spolehlivost

• Protokol mus´ı m´ıt mechanismus pro nav´az´an´ı spojen´ı a pˇr´atelsk´e ukon- ˇ

cen´ı spojen´ı

• Bude kladen velk´y d˚uraz na zabezpeˇcen´ı cel´eho protokolu

• Bude moˇzn´e dohadovat vlastnosti spojen´ı

(29)

• Protokol bude implementovat vlastn´ı sadu Congestion Control mecha- nism˚u

• Protokol bude podporovat obecn´y datov´y model

• Pˇr´ıstup k sd´ılen´ym dat˚um bude moˇzn´e omezit pomoc´ı pˇr´ıstupov´ych pr´av

4.2 K´ odov´ an´ı dat

Vˇsechny v´ıcebytov´e celoˇc´ıseln´e hodnoty jsou pˇren´aˇseny jako big-endian (nejv´ıce v´yznamn´y byte je prvn´ı). Protokol umoˇzˇnuje pˇren´aˇset i ˇc´ıseln´e hod- noty v plovouc´ı desetinn´e ˇc´arce. Konkr´etnˇe jsou podporov´any form´aty s jed- noduchou (real32) a dvojitou pˇresnost´ı (real64) jak je definuje standard IEEE 745. Pro pˇrenos ˇretˇezc˚u jsou definov´any dvˇe struktury strin8 a string16 jeˇz jsou uvedeny na obr´azku 4.1.

0 1 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---+---+---+---+

0 | Length | ... | (a)

+---+---+---+---+

0 1 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---+---+---+---+

0 | Length | ... | (b)

+---+---+---+---+

Obr´azek 4.1: Struktury string8 (a) a string16 (b) pro pˇrenos ˇretˇezc˚u Prvn´ı poloˇzka obsahuje vˇzdy d´elku ˇretˇezce v bytech. Poloˇzka Length se nepoˇc´ıt´a do d´elky ˇretˇezce. ˇRetˇezec by nemˇel b´yt ukonˇcen znakem 0x00, jak to vyˇzaduje napˇr´ıklad programovac´ı jazyk C/C++. Takov´y znak by mˇel b´yt z ˇretˇezce odstranˇen. Pokud nen´ı ˇreˇceno jinak, tak ˇretˇezec by mˇel b´yt k´odov´an pomoc´ı UTF-8 [37].

4.3 Transportn´ı protokol

Pˇred rozhodnut´ım jak´y pouˇz´ıt transportn´ı protokol byla provedena sada test˚u s c´ılem porovnat vhodnost jednotliv´ych transportn´ıch protokol˚u pro aplikace sd´ılen´e virtu´aln´ı reality (ASVR). V´ysledky experiment˚u jsou uve- deny na stranˇe 101.

(30)

V´ysledky mˇeˇren´ı uk´azaly, ˇze na transportn´ı vrstvˇe by nebylo vhodn´e nasazovat TCP ani spolehlivou variantu SCTP, protoˇze tyto protokoly ve- dou pˇri real-timov´emu sd´ılen´ı dat k pˇr´ıliˇs vysok´ym latenc´ım. Pˇri pouˇzit´ı ˇ

c´asteˇcn´e spolehliv´e varianty protokolu SCTP by se sice pˇredeˇslo velk´ym la- tenc´ım, ale timout omezuj´ıc´ı pˇrepos´ıl´an´ı by komplikoval n´avrh vlastn´ıho re- send mechanismu, kter´y m´a zajiˇst’ovat specifick´e vlastnosti protokolu Verse.

DCCP se m˚uˇze zd´at jako vhodn´y kandid´at, ale m´a nˇekolik vlastnost´ı, kter´e by vedly k neefektivn´ımu vyuˇz´ıv´an´ı pˇrenosov´ych cest. V jeho neprospˇech hraje i fakt, ˇze nen´ı ˇsiroce podporov´an na koncov´ych zaˇr´ızen´ıch ani s´ıt’ov´ych prvc´ıch. Jeho moˇzn´e budouc´ı nasazen´ı na transportn´ı vrstvˇe se ovˇsem ´uplnˇe nevyluˇcuje. Jako nejvhodnˇejˇs´ım kandid´atem se nakonec uk´azal opˇet proto- kol UDP, protoˇze umoˇzˇnuje pˇrenos s n´ızk´ymi latencemi a z´aroveˇn je ˇsiroce rozˇs´ıˇren´y. Pˇri dalˇs´ım n´avrhu se ovˇsem uvaˇzovalo i s alternativou, ˇze na trans- portn´ı vrstvˇe m˚uˇze b´yt v budoucnu pouˇzit i jin´y vhodn´y datagramov´y trans- portn´ı protokol neˇz je UDP.

Pˇrestoˇze se protokol TCP uk´azal jako nevhodn´y pro real-timov´y pˇrenos dat, v n´avrhu protokolu se s n´ım poˇc´ıt´a pro zah´ajen´ı spojen´ı. Na zabezpeˇcen´em TCP spojen´ı nejprve probˇehne autentizace uˇzivatele a n´aslednˇe si klient se serverem dohodnout typ datagramov´eho transportn´ıho protokolu a dalˇs´ı vlastnosti spojen´ı pro real-timov´e sd´ılen´ı dat. Pouˇzit´ı TCP protokolu pro nav´az´an´ı spojen´ı m˚uˇze m´ıt i tu v´yhodu, ˇze pokud nen´ı moˇzn´e dohodnout pouˇzit´ı UDP, protoˇze to napˇr´ıklad nedovoluje mobiln´ı oper´ator, tak spo- jen´ı pro real-timovou v´ymˇenu dat m˚uˇze b´yt degradov´ano na p˚uvodn´ı TCP spojen´ı. D´ale m˚uˇze b´yt teoreticky dvojice TCP a UDP spojen´ı pouˇzita pro efektivn´ı streamov´an´ı velk´eho 3D datov´eho souboru, jak to uk´azali Al-Regib a Altunbasak ve sv´em ˇcl´anku [1].

4.4 Struktura zpr´ av a pˇ r´ıkaz˚ u

Na TCP spojen´ı jsou data pˇren´aˇsena pomoc´ı zpr´av, jeˇz maj´ı strukturu popsanou na obr´azku 4.2.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---+---+---+---+---+

0 |Version| Reservation | Message Size |

+---+---+---+---+---+

1 | Commands |

. .

| |

+---+

Obr´azek 4.2: Struktura zpr´avy pos´ılan´a pˇres zabezpeˇcen´e TCP spojen´ı

(31)

Kaˇzd´a zpr´ava m´a jednoduchou hlaviˇcku, kter´a obsahuje Version: verzi protokolu, Reservation: rezervaci pro dalˇs´ı poloˇzky a Message Size: velikost zpr´avy vˇcetnˇe hlaviˇcky v bytech. Za hlaviˇckou n´asleduj´ı pˇr´ıkazy, kter´e maj´ı strukturu popsanou na obr´azku 4.3.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 8 0 1 +---+---+---+---+

| Op Code | Length<255 | Data... |

+---+---+ |

| |

. .

| |

+---+---+---+---+

Obr´azek 4.3: Struktura kr´atk´e varianty pˇr´ıkazu

Kaˇzd´y typ pˇr´ıkazu m´a sv˚uj jedineˇcn´y Op Code, kter´y specifikuje dalˇs´ı strukturu pˇr´ıkazu. Za poloˇzkou Op Code n´asleduje Length: d´elka pˇr´ıkazu (zahrnuj´ıc´ı i poloˇzky Op Code a Length), kter´a je ud´av´ana v bytech a m˚uˇze nab´yvat hodnot v rozsahu h2, 254i. Pokud je nutn´e poslat pˇr´ıkaz delˇs´ı jak 254 byt˚u, m´a strukturu popsanou na obr´azku 4.4

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 8 0 1 +---+-+-+-+-+-+-+-+-+---+---+

| Op Code |1|1|1|1|1|1|1|1| Length |

+---+-+-+-+-+-+-+-+-+---+---+

| Data... |

. .

. .

| |

+---+---+---+---+

Obr´azek 4.4: Struktura dlouh´e varianty pˇr´ıkazu

V tomto pˇr´ıkazu m˚uˇze b´yt pˇreneseno aˇz 65531 byt˚u dat. Poloˇzka s d´elkou pˇr´ıkazu nen´ı z´amˇernˇe volena vˇetˇs´ı. Hlavn´ım d˚uvodem je maxim´aln´ı velikost zpr´avy, kter´a je 65535 byt˚u. Nav´ıc stejn´a struktura pˇr´ıkazu se pouˇz´ıv´a i pro real-timov´y pˇrenos dat a UDP ani DCCP neumoˇzˇnuj´ı pˇren´est v jednom da- tagramu v´ıce jak 65535 byt˚u.

4.5 Nav´ az´ an´ı spojen´ı

Komunikaci zahajuje klient na TCP spojen´ı, kter´e mus´ı b´yt ˇsifrovan´e po- moc´ı protokolu Transport Layer Security (TLS) [11], protoˇze bˇehem t´eto ˇc´asti jsou pˇren´aˇseny citliv´e informace jako je napˇr´ıklad uˇzivatelsk´e jm´eno a heslo,

(32)

kter´e nesm´ı b´yt odposlechnuty ´utoˇcn´ıkem. Pˇr´ıklad kompletn´ıho handshaku je uveden na obr´azku 4.21, kter´y je pomˇernˇe komplikovan´y. D´a se ovˇsem rozdˇelit na nˇekolika ˇc´ast´ı.

4.5.1 TLS handshake

Prvn´ı ˇc´ast´ı nav´az´an´ı spojen´ı je TLS handshake, kter´y je detailnˇe popsan´y v pˇr´ısluˇsn´em RFC dokumentu [11]. Zjednoduˇsen´y pr˚ubˇeh TLS handshaku je vidˇet na obr´azku 4.5. V t´eto ˇc´asti budou zm´ınˇeny z´akladn´ı mechanismy a vlastnosti protokolu TLS.

client server

o o

| |

| ClientHello |

+-Version,RandomNumber,CypherList,CompressionList->+----+

| | |

| ServerHello | |

+----+<-Version,RandomNumber,CypherMeth,CompressionMeth-+<---+

| | Certificate,ServerHelloDone |

| | |

| | ClientKeyExchange |

+--->+---PreMasterSecret/PublicKey/None--->+----+

| ChangeCipherSpec,Finished | |

| | |

| ChangeCipherSpec | |

+<---Finished---+<---+

| |

. .

Obr´azek 4.5: Zjednoduˇsen´y pr˚ubˇeh TLS handshaku

TLS je aplikaˇcn´ı protokol vyuˇz´ıvaj´ıc´ı na niˇzˇs´ı vrstvˇe spolehliv´y trans- portn´ı protokol (napˇr. TCP). Spojen´ı se serverem zahajuje klient zasl´an´ım zpr´avy ClientHello, kter´a obsahuje verzi protokolu, n´ahodnˇe vygenerovan´e ˇ

c´ıslo, seznam navrhovan´ych ˇsifer a seznam kompresn´ıch metod. Server na tuto zpr´avu odpov´ı zpr´avou ServerHello, kter´a obsahuje stejnou verzi pro- tokolu, jakou se rozhodl pouˇz´ıt klient. D´ale tato zpr´ava obsahuje n´ahodnˇe vygenerovan´e ˇc´ıslo, vybranou sadu ˇsifer a kompresn´ı metodu. Server z´aroveˇn zaˇsle klientovi sv˚uj certifik´at. Server m˚uˇze zaslat klientovi i zpr´avu Certifi- cateRequest, kterou vyˇzaduje po klientovi zasl´an´ı jeho vlastn´ıho certifik´atu.

Toto ovˇsem v pˇr´ıpadˇe protokolu Verse nen´ı vyˇzadov´ano. Server prvn´ı ˇc´ast komunikace ukonˇcuje zpr´avou ServerHelloDone.

Klient z obdrˇzen´eho certifik´atu z´ısk´a veˇrejn´y kl´ıˇc serveru a digit´aln´ı pod- pis certifik´atu. Klient by mˇel ovˇeˇrit platnost veˇrejn´eho kl´ıˇce z certifik´atu vydavatele, kter´y mus´ı b´yt pˇredem nahran´y na stranˇe klienta. Po ovˇeˇren´ı platnosti veˇrejn´eho kl´ıˇce, ovˇeˇr´ı klient digit´aln´ı podpis v obdrˇzen´em certi-

(33)

fik´atu. Certifik´at by mˇel b´yt samozˇrejmˇe platn´y a mˇela by se shodovat adresa serveru uveden´a v certifik´atu s adresou serveru, kter´y certifik´at odeslal.

Kdyˇz klient ovˇeˇr´ı identitu serveru, tak odeˇsle serveru zpr´avu Client- KeyExchange, kter´a m˚uˇze obsahovat v z´avislosti na zvolen´e symetrick´e ˇsifˇre PreMasterSecret, veˇrejn´y kl´ıˇc anebo nic. Klient i server si z obsahu Client- KeyExchange a n´ahodn´ych ˇc´ısel spoˇc´ıtaj´ı tzv. master secret z kter´eho jsou odvozeny vˇsechny ostatn´ı kl´ıˇce. N´aslednˇe klient odeˇsle zpr´avu ChangeCipher- Spec, kterou ˇr´ık´a, ˇze n´asleduj´ıc´ı data jsou ˇsifrovan´a. Tuto ˇc´ast handshaku kli- ent zakonˇc´ı zaˇsifrovanou zpr´avou Finished, jeˇz obsahuje hash a MAC vˇsech pˇredchoz´ıch zpr´av. Server se tuto zpr´avu pokus´ı deˇsifrovat a ovˇeˇrit hash a MAC. Pokud deˇsifrov´an´ı a ovˇeˇren´ı neselˇze, tak server odpov´ı obdobn´ymi zpr´avami ChangeCipherSpec a Finished. V pˇr´ıpadˇe, ˇze i klient je schopn´y deˇsifrovat zpr´avu Finished a ovˇeˇrit hash a MAC, tak je TLS handshake ukonˇcen a obˇe strany mohou zah´ajit komunikaci po zabezpeˇcen´em spojen´ı.

4.5.2 Autentizace

Po ukonˇcen´ı TLS handshaku zaˇc´ın´a vlastn´ı komunikace pomoc´ı protokolu Verse a klient 30 sekund na to, aby poslal zpr´avu obsahuj´ıc´ı pˇr´ıkaz UserAu- thRequest. Jeho struktura je pops´ana na obr´azku 4.6. Pokud server tento pˇr´ıkaz do 30 sekund neobdrˇz´ı, server by mˇel spojen´ı s klientem automaticky ukonˇcit.

0 1 2

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3

+---+---+---+---...---+---+---

| Op Code=7 | Length | String_Length | User_Name | Auth_Method | ...

+---+---+---+---...---+---+---

Obr´azek 4.6: Struktura pˇr´ıkazu UserAauthRequest

Op Code tohoto pˇr´ıkazu je 7. Za d´elkou pˇr´ıkazu n´asleduje d´elka ˇretˇezce v nˇemˇz je uloˇzeno uˇzivatelsk´e jm´eno. Za uˇzivatelsk´ym jm´enem n´asleduje identifik´ator autentizaˇcn´ı metody. Cel´y pˇr´ıkaz je ukonˇcen vlastn´ımi auten- tizaˇcn´ımi daty. Seznam aktu´alnˇe navrhovan´ych autentizaˇcn´ıch metod je uve- den v tabulce 4.1. Cel´y autentizaˇcn´ı mechanismus byl navrˇzen flexibilnˇe, aby bylo moˇzn´e v budoucnu pˇridat dalˇs´ı autentizaˇcn´ı metody.

Pˇrestoˇze nen´ı doporuˇceno, aby server podporoval ovˇeˇrov´an´ı uˇzivatel˚u po- moc´ı metody NONE, klient by mˇel poslat prvn´ı pˇr´ıkaz UserAuthRequest pr´avˇe s touto metodou. Server mus´ı odpovˇedˇet na prvn´ı pˇr´ıkaz UserAu- thRequest obsahuj´ıc´ı nepodporovanou metodu pˇr´ıkazem UserAuthFailure se seznamem autentizaˇcn´ıch metod, kter´e server podporuje. Tento seznam mus´ı

(34)

RESERVED=0 Tato metoda by nemˇela b´yt nikdy pouˇzita NONE=1 Nen´ı doporuˇceno podporovat tuto metodu PASSWORD=3 Tato metoda je vyˇzadov´ana

HOSTBASED=4 Tato metoda je voliteln´a Tabulka 4.1: Metody autentizace

vˇzdy obsahovat metodu PASSWORD a jak server tak klient mus´ı tuto me- todu podporovat. Klient by si mˇel ze seznamu obdrˇzen´ych metod jednu vy- brat a pouˇz´ıt ji k odesl´an´ı platn´e kombinace uˇzivatelsk´eho jm´ena a auten- tizaˇcn´ıch dat. Pˇr´ıkaz UserAuthFailure je uveden na obr´azku 4.7.

0 1 1 2 2

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 ...

+---+---+---+---+---+

| Op Code=8 | Length | Auth_Method_1 | ... | Auth_Method_N | +---+---+---+---+---+

Obr´azek 4.7: Struktura pˇr´ıkazu UserAauthFailure se seznamem podporo- van´ych metod

Kdyˇz klient poˇsle neplatnou kombinaci uˇzivatelsk´eho jm´ena a auten- tizaˇcn´ıch dat, tak z´aleˇz´ı na tom, kolik ne´uspˇeˇsn´ych pˇr´ıkaz˚u UserAuthRequest jiˇz klient poslal. Pokud tento poˇcet pˇrekroˇcil stanoven´y limit, tak by mˇel ser- ver odpovˇedˇet pˇr´ıkazem UserAuthFailure uveden´ym na obr´azku 4.8. V opaˇc- n´em pˇr´ıpadˇe by mˇel server odpovˇedˇet pˇr´ıkazem z obr´azku 4.7 a umoˇznit klientovi dalˇs´ı pˇrihlaˇsovac´ı pokus. Zpr´avu s t´ımto pˇr´ıkazem by server nemˇel pos´ılat ihned, ale odpovˇed’ by mˇel pozdrˇzet. ˇCasov´y rozestup by mˇel s kaˇzd´ym neplatn´ym pokusem nar˚ustat, aby se co nejv´ıce zkomplikovalo h´ad´an´ı kombi- nac´ı uˇzivatelsk´ych jmen a autentizaˇcn´ıch dat hrubou silou. D´ale server nesm´ı bˇehem jednoho spojen´ı mˇenit seznam navrhovan´ych autentizaˇcn´ıch metod ani jejich poˇrad´ı.

Server by mˇel po odesl´an´ı ukonˇcuj´ıc´ıho pˇr´ıkazu UserAuthFailure ukonˇcit i TLS a TCP spojen´ı. Server by mˇel spojen´ı automaticky ukonˇcit i v tom pˇr´ıpadˇe, ˇze neobdrˇz´ı dalˇs´ı pˇr´ıkaz UserAuthRequest do 30 sekund po odesl´an´ı pˇr´ıkazu UserAuthFailure s navrhovan´ymi metodami.

0 1 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+

| Op Code=8 | Length=2 | +---+---+

Obr´azek 4.8: Struktura pˇr´ıkazu UserAauthFailure ukonˇcuj´ıc´ı spojen´ı

(35)

Pokud server obdrˇz´ı od klienta prvn´ı pˇr´ıkaz UserAuthRequest obsahuj´ıc´ı uˇzivatelsk´e jm´eno, jeˇz nen´ı obsaˇzeno v jeho datab´azi uˇzivatel˚u, tak by server nemˇel odpov´ıdat pˇr´ıkazem z obr´azku 4.8, protoˇze ´utoˇcn´ık zjiˇst’uj´ıc´ı platn´e kombinace uˇzivatelsk´ych jmen a autentizaˇcn´ıch dat by mˇel ulehˇcenou pr´aci.

Takov´y pˇr´ıstup by umoˇzˇnoval pˇr´ıpadn´emu ´utoˇcn´ıkovi nejprve zjistit platn´a uˇzivatelsk´a jm´ena a t´ım v´yraznˇe ulehˇcil zjiˇstˇen´ı platn´e kombinace uˇzivatelsk´e- ho jm´ena a autentizaˇcn´ıch dat.

Zat´ım jedinou navrhovanou autentizaˇcn´ı metodou, kter´a umoˇzˇnuje ovˇeˇrit uˇzivatele, je metoda PASSWORD. V t´eto metodˇe se uˇzivatel prokazuje hes- lem, kter´e by mˇel zn´at pouze on s´am. Na serveru by toto heslo mˇelo b´yt uloˇzeno v nˇejak´e zaˇsifrovan´e podobˇe. Struktura pˇr´ıkazu UserAuthRequest ob- sahuj´ıc´ı uˇzivatelsk´e jm´eno a heslo je uvedena na obr´azku 4.9.

0 1 1 2 2

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 ...

+---+---+---+---...---+

| Op Code=7 | Length | String_Length | User_Name |

+---+---+---+---...---+

...

+---+---+---...---+

| Meth=PASSWORD | String_Length | Password |

+---+---+---...---+

Obr´azek 4.9: Struktura pˇr´ıkazu UserAauthRequest obsahuj´ıc´ı heslo Kdyˇz se uˇzivatelsk´e jm´eno a autentizaˇcn´ı data (heslo) shoduj´ı s datab´az´ı na stranˇe serveru, server odeˇsle klientu zpr´avu s pˇr´ıkazem UserAuthSuccess jehoˇz struktura je uvedena na obr´azku 4.10.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---+---+---+---+

| Op Code=9 | Length=16 | User_ID |

+---+---+---+---+

| Avatar_ID |

+---+---+---+---+

Obr´azek 4.10: Struktura pˇr´ıkazu UserAauthSuccess

Tento pˇr´ıkaz obsahuje jedineˇcn´y identifik´ator uˇzivatele: User ID a ava- tara Avatar ID. User ID se pouˇz´ıv´a napˇr´ıklad pro nastaven´ı vlastnictv´ı a pˇr´ıstupov´ych pr´av ke sd´ılen´ym dat˚um. Po ´uspˇeˇsn´em ovˇeˇren´ı uˇzivatele server vytvoˇr´ı speci´aln´ı uzel, kter´y reprezentuje avatara dan´eho Verse klienta. Iden- tifik´ator tohoto uzlu je roven Avatar ID z pˇr´ıkazu UserAuthSuccess. Uzly reprezentuj´ıc´ı avatary budou detailnˇe pops´any v kapitole 5.

Pˇr´ıklad v´ymˇeny zpr´av a pˇr´ıkaz˚u bˇehem ´uspˇeˇsn´e a ne´uspˇeˇsn´e autentizace je uveden na obr´azc´ıch 4.11 a 4.12.

(36)

[client]:A [server]:B

o o

| |

| |

| USER_AUTH_REQUEST user_name=joe auth_method=NONE | +--->+----+

| | |

| USER_AUTH_FAILURE count=1 auth_method=PASSWORD | | +----+<---+<---+

| | |

| | USER_AUTH_REQUEST user_name=joe |

+--->+---auth_method=PASSWORD password=QX9#amD1--->+----+

| | |

| USER_AUTH_SUCCESS user_id=3 avatar_id=10 | | +<---+<---+

| |

. .

Obr´azek 4.11: Pˇr´ıklad ´uspˇeˇsn´e autentizace

[client]:A [server]:B

o o

| |

| |

| USER_AUTH_REQUEST user_name=sue auth_method=NONE | +--->+----+

| | |

| USER_AUTH_FAILURE count=1 auth_method=PASSWORD | | +----+<---+<---+

| | |

| | USER_AUTH_REQUEST user_name=sue |

+--->+---auth_method=PASSWORD password=password--->+----+

| | |

| USER_AUTH_FAILURE count=0 | |

+<---+<---+

| |

. .

Obr´azek 4.12: Pˇr´ıklad ne´uspˇeˇsn´e autentizace Verifikace autentizace

Autentizaˇcn´ı ˇc´ast handshaku bylo nutn´e verifikovat, protoˇze je relativnˇe komplikovan´a a nezbytn´a pro n´aslednou komunikaci mezi klientem a serve- rem. Nejprve byly vytvoˇreny stavov´e modely autentizace pro klienta a server, kter´e jsou uvedeny na obr´azc´ıch 4.13, 4.14.

Z tˇechto dvou stavov´ych model˚u byl vytvoˇren verifikaˇcn´ı program v pro- gramovac´ım jazyku Promela, kter´y je uveden v pˇr´ıloze na stranˇe 124. Pˇri tvorbˇe stavov´ych model˚u byl p˚uvodn´ı form´at pˇred´avan´ych zpr´av a pˇr´ıkaz˚u velmi zjednoduˇsen. Proces reprezentuj´ıc´ı klienta m˚uˇze pos´ılat skrz synchronn´ı kan´al pouze zjednoduˇsen´y pˇr´ıkaz UserAuthRequest. Poloˇzky username a data mohou nab´yvat pouze hodnoty platn´a nebo neplatn´a data. Toto m˚uˇze p˚usobit

(37)

Obr´azek 4.13: Stavov´y model autentizace na stranˇe klienta

jako pˇr´ıliˇs velk´e zjednoduˇsen´ı, ale je potˇreba si uvˇedomit, ˇze ´ukolem tohoto programu je verifikovat pr˚ubˇeh jednoho konkr´etn´ıho spojen´ı, kdy autentizace uˇzivatele na jednom spojen´ı neovlivn´ı autentizaci na kter´emkoliv dalˇs´ım spo- jen´ı. D´ıky tomu m˚uˇze b´yt zavedeno zjednoduˇsen´ı, kdy uˇzivatel m˚uˇze zadat bud’ platn´e nebo neplatn´e uˇzivatelsk´e jm´eno a platn´a nebo neplatn´a auten- tizaˇcn´ı data.

Server m˚uˇze skrz druh´y synchronn´ı kan´al pos´ılat zjednoduˇsen´e pˇr´ıkazy UserAuthFailure a UserAuthSuccess:

chan q1 = [ 0 ] o f { bit , byte , b i t } ; /∗ user name , a u t h t y p e , a u t h d a t a ∗/

chan q2 = [ 0 ] o f { bit , byte } ; /∗ cmd type , a u t h m e t h ∗/

C´ılem verifikace t´eto ˇc´asti protokolu bylo ovˇeˇrit, ˇze n´avrh neobsahuje ˇ

z´adn´e deadlocky, nevyv´ıjej´ıc´ı se cykly a ˇze oba procesy neskonˇc´ı v neko- rektn´ıch stavech. Na autentizaci nebyla kladena ˇz´adn´a dalˇs´ı krit´eria, kter´a by ˇslo vyj´adˇrit pomoc´ı LTL logiky. Verifikace, jej´ıˇz v´ysledky lze nal´ezt v pˇr´ıloze na stranˇe 129 prok´azala, ˇze tato ˇc´ast protokolu byla navrˇzena korektnˇe a neobsahuje ˇz´adn´e chyby.

Bezpeˇcnostn´ı rizika autentizace

Navrˇzen´y autentizaˇcn´ı mechanismus m˚uˇze b´yt zraniteln´y v˚uˇci DoS a DDoS ´utoku, protoˇze server ˇcek´a 30 sekund od ukonˇcen´ı TLS handshaku na prvn´ı pˇr´ıkaz UserAuthRequest a stejnou dobu ˇcek´a od odesl´an´ı pˇr´ıkazu UserAuthFailure obsahuj´ıc´ı seznam podporovan´ych metod na dalˇs´ı pˇr´ıkaz UserAuthRequest. Pˇr´ıpadn´y ´utoˇcn´ık se m˚uˇze pokusit otevˇr´ıt velk´e mnoˇzstv´ı spojen´ı a snaˇzit se vyˇcerpat syst´emov´e prostˇredky serveru ˇci dos´ahnout ma- xim´aln´ı povolen´e mnoˇzstv´ı spojen´ı na serveru.

Pˇri n´avrhu protokolu se poˇc´ıtalo, ˇze tento probl´em bude pˇrenech´an r˚uzn´ym

(38)

LISTEN

RESPOND user_auth

END failure

END authenticated timeout

auth_req:user,none

attempt++;

attemtp<MAX

auth_req,user=valid,data!=valid auth_req:user!=valid

auth_req:user=valid,data=valid

attempt>=MAX /timeout

Obr´azek 4.14: Stavov´y model autentizace na serveru

packet filtr˚um jako je napˇr´ıklad iptables [4], kter´e umoˇzˇnuj´ı efektivnˇe filtro- vat poˇcet pokus˚u o nov´e spojen´ı podle r˚uzn´ych krit´eri´ı. Nˇekter´e packet filtry (vˇcetnˇe iptables) nav´ıc umoˇzˇnuj´ı spolupracovat se serverov´ymi aplikacemi a prov´adˇet dalˇs´ı penalizaci nov´ych spojen´ı poch´azej´ıc´ıch z IP adresy ´utoˇcn´ıka.

4.5.3 Dohadov´ an´ı vlastnost´ı spojen´ı

Po ukonˇcen´ı autentizace m˚uˇze zaˇc´ıt dohadov´an´ı o nov´em datagramov´em spojen´ı. Pro dohadov´an´ı nov´eho spojen´ı jsou pouˇzity syst´emov´e pˇr´ıkazy pro dohadov´an´ı vlastnost´ı spojen´ı, kter´e jsou celkem ˇctyˇri: Change L, Confirm L, Change R a Confirm R, jejichˇz struktura je uvedena na obr´azku 4.15. Inspi- rac´ı pro tyto pˇr´ıkazy bylo dohadov´an´ı vlastnost´ı spojen´ı protokolu DCCP [25].

0 1 1 2 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +---+---+---+---+---

| Op Code | Length | Feature | Value(s) ...

+---+---+---+---+---

Obr´azek 4.15: Struktura pˇr´ıkaz˚u pro dohadov´an´ı vlastnost´ı spojen´ı Za d´elkou pˇr´ıkazu, kter´a nepˇr´ımo specifikuje kolik hodnot je v pˇr´ıkazu uvedeno, n´asleduje identifik´ator dohadovan´e vlastnosti. Identifik´ator vlast- nosti je n´asledov´an seznamem navrhovan´ych hodnot. Poˇrad´ı hodnot v pˇr´ıkazu

References

Related documents

Na z´ akladˇ e minim a maxim porovn´ avan´ ych element˚ u se vyhodnot´ı, zda elementy mohou nebo nemohou m´ıt spoleˇ cn´ y pr˚ unik, pokud elementy nemohou m´ıt spoleˇ cn´

Prostˇred´ı robotu je zn´amo a je reprezentov´ano pomoc´ı geometrick´e mapy. Dan´a mapa m˚ uˇze b´ yt zachycena pr˚ ujezdem robotu v prostˇred´ı na z´akladˇe pokyn˚

Důvod, proč jsou zapotřebí dva, je následující: Pokud by při konstantním tlaku tedy i indexu lomu uvnitř trubice interferometru, byla fáze výstupního paprsku π/2, nebylo

Indukovan´e v´ıˇriv´e proudy ve vodiˇci bud´ı vnitˇrn´ı magnetick´e pole. Podle Lencova pravidla je toto pole orientov´ano tak, ˇze p˚ usob´ı proti vnˇejˇs´ımu poli

Na obr´ azku 4.35 je zobrazeno porovn´ an´ı akustick´ eho tlaku nad nosn´ıkem uni- morf (bez elektrod i s elektrodami vych´ az´ı nad nosn´ıkem velice podobn´ y akustick´ y

Z´ akladn´ım pˇredpokladem pro dosaˇ zen´ı hmatateln´ eho v´ ystupu t´ eto bakal´ aˇrsk´ e pr´ ace bylo namˇ eˇren´ı impulsn´ıch odezev v urˇ cit´ em prostoru.

Pˇri v´ ypoˇ ctu vlastn´ı hodnoty implicitn´ı funkce (3) pro bod P nen´ı moˇ zn´ e testovat, kter´ e ˇr´ıd´ıc´ı struktury jsou dostateˇ cnˇ e daleko a u kter´ ych se

Při doběžné hraně T1 stavu jsou nastaveny signály MREQ a RD, které jsou pamětí chápány jako příkaz ke zkopírování obsahu paměti na adrese uvedené v address busu na