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.
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
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.
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´ı
• 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