liˇs´ı podle typu tagu a zp˚usobu opakov´an´ı adresy pˇr´ıkazu. Pˇr´ıkaz pro nastaven´ı tagu real32 je uveden na obr´azku 5.18.
Kdyˇz se v jednom paketu vyskytuje mnoho pˇr´ıkaz˚u Tag Set, kter´e maj´ı totoˇznou znaˇcnou ˇc´ast adresy, tak by bylo neefektivn´ı tuto adresu opakovat.
Z tohoto d˚uvodu existuj´ı pro kaˇzd´y typ tagu 4 r˚uzn´e varianty pˇr´ıkazu Tag Set, jeˇz se liˇs´ı ve zp˚usobu opakov´an´ı jednotliv´ych poloˇzek adresy. Celkem je specifikov´ano 36 variant pˇr´ıkaz˚u Tag Set. Zp˚usoby opakov´an´ı pro typ real32 jsou uvedeny na obr´azku 5.19.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Obr´azek 5.19: Jednotliv´e varianty opakov´an´ı adresy pˇr´ıkazu Tag Set (real32) Prvn´ı varianta (a) opakov´an´ı je totoˇzn´a se zp˚usobem opakov´an´ım u pˇred-choz´ıch pˇr´ıkaz˚u. To znamen´a, ˇze za poloˇzkami OpCode a Length se
opa-kuje vˇzdy cel´a adresa pˇr´ıkazu (Node ID, TagGroup ID a Tag ID ), kter´a je n´asledov´ana vlastn´ı hodnotou Value. Druh´a varianta (b) umoˇzˇnuje uv´est poloˇzku Node ID pouze jednou a u zbyl´ych adres uv´adˇet pouze TagGroup ID a Tag ID. Tˇret´ı varianta (c) umoˇzˇnuje sd´ılet i poloˇzku TagGroup ID.
Posledn´ı variantu (d) je moˇzn´e pouˇz´ıt v pˇr´ıpadˇe, ˇze odes´ılatel chce odeslat nˇekolik pˇr´ıkaz˚u Tag Set, jeˇz maj´ı stejn´y typ, stejn´e Node ID, TagGroup ID a Tag ID je u kaˇzd´eho n´asleduj´ıc´ıho pˇr´ıkazu inkrementov´ano o jedna.
Kaˇzd´a varianta je vhodn´a pro jin´e kombinace pˇr´ıkaz˚u a odes´ılatel by mˇel vˇzdy vybrat vhodnou metodu opakov´an´ı podle toho, jak´e m´a pˇr´ıkazy v odes´ılac´ı frontˇe. Kdyˇz budeme uvaˇzovat pˇr´ıklad ze strany 87, tak pˇri zmˇenˇe polohy, rotace ˇci velikosti objektu se nejl´epe hod´ı posledn´ı varianta (d) z obr´ a-zku 5.19. Zmˇena pozice z pˇr´ıkladu na stranˇe 87 lze pak efektivnˇe pˇren´est pomoc´ı pˇr´ıkazu, jenˇz je uveden´y na obr´azku 5.20.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|73| *| ** | *** |**** | 10.23 | 7.68 | -0.03 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
* - Length=22, ** - Node ID=65560, *** - TagGroup ID=1, **** - Tag ID=0
Obr´azek 5.20: Pˇr´ıklad komprese pˇr´ıkazu Tag Set, jeˇz byl pouˇzit´y pro pˇrenos pozice
5.2.13 Vrstvy
Vrstvy v nov´em protokolu umoˇzˇnuj´ı sd´ılet libovoln´a nestrukturovan´a data.
Jejich pˇr´ıkazy jsou navrˇzeny pro sd´ılen´ı objemn´ych dat, jako jsou napˇr´ıklad souˇradnice vertex˚u, vrcholy ploˇsek, v´ahy vertex˚u, apod. Struktura z´akladn´ıch pˇr´ıkaz˚u pro vytvoˇren´ı, zruˇsen´ı, pˇrihl´aˇsen´ı a odhl´aˇsen´ı se od vrstvy je uvedena v pˇr´ıloze na stranˇe 159. Kdyˇz se klient pˇrihl´as´ı k uzlu a ten obsahuje nˇejak´e vrstvy, tak obdrˇz´ı od serveru sadu pˇr´ıkaz˚u Layer Create obsahuj´ıc´ı identi-fik´atory a typy jednotliv´ych vrstev. V´yznam jednotliv´ych vrstev m˚uˇze b´yt d´an napˇr´ıklad ve skupinˇe tag˚u jak je uvedeno na n´asleduj´ıc´ım pˇr´ıkladu:
• TagGroup(name: Vertexes, ID: 0)
– Tag(name: LayerID, ID: 0, type: uint16, value: 0) – Tag(name: Components, ID: 1, type: uint8, value: 3)
Skupina tag˚u se jmenuje v tomto pˇr´ıkladu ”Vertexes”, coˇz znaˇc´ı, ˇze tato skupina bude obsahovat informace o vertexech. Tag s Tag ID=0 se jm´enem
”LayerID” m´a hodnotu 0, takˇze vertexy by mˇely b´yt obsaˇzeny v nult´e vrstvˇe.
Tag s Tag ID=1 je pojmenovan´y ”Components” a jeho hodnota je 3, tud´ıˇz kaˇzd´y vertex m´a vˇzdy tˇri sloˇzky.
Vrstvy mohou obsahovat vˇzdy pouze hodnoty jednoho typu. Podporovan´e typy jsou uvedeny na n´asleduj´ıc´ım seznamu:
• int8 (signed char)
• uint8 (unsigned char)
• int16 (signed short)
• uint16 (unsigned short)
• int32 (signed int)
• uint32 (unsigned int)
• real32 (float)
• real64 (double)
Kdyˇz se klient pˇrihl´as´ı k vybran´e vrstvˇe, tak mu server zaˇcne pos´ılat pˇr´ısluˇsn´e pˇr´ıkazy Item Create, kter´ych je definov´ano celkem 32. Opˇet se liˇs´ı podle typu pˇren´aˇsen´ych dat a zp˚usobu opakov´an´ı jednotliv´ych poloˇzek po-dobnˇe jak to bylo uvedeno na obr´azku 5.19.
Obr´azek 5.21: Porovn´an´ı efektivity vyuˇzit´ı m´ısta v p˚uvodn´ım (a) a nov´em protokolu (b)
Vrstvy mohou b´yt pouˇzity napˇr´ıklad pro sd´ılen´ı v´ahy vertex˚u. V´ahu ver-tex˚u m˚uˇze uˇzivatel v grafick´ych aplikac´ıch ovlivˇnovat pomoc´ı interaktivn´ıch n´astroj˚u jako je napˇr´ıklad ˇstˇetec. Pˇri kreslen´ı na v´ahu vertex˚u Verse klient generuje velk´e mnoˇzstv´ı pˇr´ıkaz˚u mˇen´ıc´ı v´ahu vertex˚u. Na obr´azku 5.21 je po-tom vidˇet porovn´an´ı vyuˇzit´ı m´ısta v paketu pˇr´ı pouˇzit´ı p˚uvodn´ıho a nov´eho protokolu. V tomto pˇr´ıkladu pˇr´ıkazy p˚uvodn´ıho protokolu zab´ıraj´ı 75 B a nov´eho protokolu pouze 48 B.
5.3 Casov´ ˇ e znaˇ cky
V pˇredchoz´ıch dvou ˇc´astech byly uvedeny metody pro sd´ılen´ı dat. Klient m˚uˇze napˇr´ıklad pomoc´ı vrstvy sd´ılet na serveru nejen polohu objektu s = (x, y, z), ale m˚uˇze to b´yt i tˇreba jeho rychlost ~v = (vx, vy, vz) a zrychlen´ı
~a = (ax, ay, az). D˚uvodem pro sd´ılen´ı rychlosti a zrychlen´ı m˚uˇze b´yt snaha dos´ahnout spojit´eho pohybu objekt˚u i pˇri ztr´atˇe nˇekter´ych paket˚u. Klient pˇrij´ımaj´ıc´ı tyto informace ovˇsem potˇrebuje ke spr´avn´emu dopoˇc´ıt´an´ı aktu´aln´ı polohy objektu pomoc´ı vztahu 5.3 i informaci o ˇcasu t0, kdy byla poloha, rychlost a zrychlen´ı u dan´eho objektu stanoveny.
x(t1) = x(t0) + vx(t0)(t1 − t0) + 12ax(t0)(t1− t0)2 y(t1) = y(t0) + vy(t0)(t1 − t0) + 12ay(t0)(t1− t0)2 z(t1) = z(t0) + vz(t0)(t1− t0) + 12az(t0)(t1− t0)2
(5.1)
Klient pos´ılaj´ıc´ı informaci o rychlosti a zrychlen´ı mus´ı tedy pos´ılat i infor-maci o ˇcasu t0. Jelikoˇz se simulace pohybu v´ıce objekt˚u vˇetˇsinou vypoˇc´ıt´av´a pro jeden ˇcasov´y okamˇzik, tak je efektivn´ı hodnotu t0 sd´ılet pro v´ıce pˇr´ıkaz˚u pomoc´ı jednoho pˇr´ıkazu Time Stamp jeˇz je uveden na obr´azku. Tento ˇcas je potom platn´y pro vˇsechny n´asleduj´ıc´ı pˇr´ıkazy v dan´em paketu.
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 +---+---+---+---+
| OpCode=117 | Length=14 | |
+---+---+ +
| Time (Seconds) |
+ +---+---+
| | Time (Microseconds) (high) |
+---+---+---+---+
| Time (microseconds) (low) | +---+---+
Obr´azek 5.22: Struktura pˇr´ıkazu pro nastaven´ı ˇcasov´e znaˇcky
Chceme-li vyj´adˇrit, ˇze v dan´em paketu jsou n´asleduj´ıc´ı pakety bez ˇcasov´e
znaˇcky, tak je potˇreba vloˇzit do paketu pˇr´ıkaz Time Stamp, kdy poloˇzka Time (seconds) m´a hodnotu 264 a poloˇzka Time (Microseconds) m´a hodnotu 232.
Cas je vyj´ˇ adˇren pomoc´ı dvou hodnot podobnˇe jako UNIXov´y ˇcas. Hod-nota (64-bitov´y integer) v sekund´ach vyjadˇruje UTC ˇcas od p˚ulnoci 1. ledna 1970. Druh´a hodnota vyjadˇruje ˇcas v mikrosekund´ach od posledn´ı ukonˇcen´e sekundy.
Dalˇs´ı podm´ınkou pro korektn´ı fungov´an´ıˇcasov´ych znaˇcek je synchronizace ˇ
casu na jednotliv´ych klientech. Protokol Verse ˇz´adn´y takov´y mechanismus neposkytuje, takˇze klienti pouˇz´ıvaj´ıc´ı pˇr´ıkaz Time Stamp si mus´ı synchro-nizovat ˇcas napˇr´ıklad pomoc´ı protokolu NTP [27]. NTP protokol umoˇzˇnuje v z´avislosti na kvalitˇe spojen´ı nastavit ˇcas s pˇresnost´ı aˇz 0,2 ms.
Pokud nastane situace, ˇze by klient nemˇel ˇcas synchronizovan´y korektnˇe a hodiny by se mi zpoˇzd’ovaly, tak se m˚uˇze st´at, ˇze ˇcas t0pˇrijat´y pomoc´ı pˇr´ıkazu Time Stamp bude napˇred pˇred jeho aktu´aln´ım ˇcasem t1. V´ypoˇcet polohy pomoc´ı vztahu 5.3 by potom vedl k nekorektn´ım v´ysledk˚um. V pˇr´ıpadˇe, ˇze je t0 > t1 nen´ı moˇzn´e prov´adˇet estimaci aktu´aln´ı polohy objektu, ale je nutn´e pouˇz´ıt pouze pˇrijatou informaci o poloze a rychlost i zrychlen´ı ignorovat.
Kapitola 6
Implementace
Tato kapitola neobsahuje pouze popis implementace, ale mˇela by d´at n´avrh a doporuˇcen´ı, jak efektivnˇe prov´adˇet implementaci Verse serveru i kli-enta. Jedn´a se pˇredevˇs´ım o implementaci resend mechanismu, kde je vyˇ zado-v´ano, aby byla pos´ıl´ana pouze aktu´aln´ı data.
V´ysledn´a implementace protokolu Verse je naprogramov´ana v jazyku C a vyuˇz´ıv´a z knihovny OpenSSL implementaci protokolu TLS a DTLS. D´ale je vyuˇz´ıv´ana knihovna pthread pro pr´aci s vl´akny. Pouˇzit´e technologie umoˇzˇnuj´ı snadn´e portov´an´ı na r˚uzn´e platformy.
6.1 Server
Pˇri implementaci Verse serveru byl kladen d˚uraz na dosaˇzen´ı maxim´aln´ıho v´ykonu a propustnosti. Proto byl implementov´an jako v´ıcevl´aknov´a apli-kace. Server poslouch´a na poˇzadavky klient˚u v samostatn´em vl´aknˇe pomoc´ı TCP soketu, kter´y je vytvoˇren pomoc´ı syst´emov´eho vol´an´ı listen(). Kli-ent˚uv poˇzadavek na nov´e spojen´ı je detekov´an pomoc´ı syst´emov´eho vol´an´ı select(). Server n´aslednˇe vytvoˇr´ı pro nov´e spojen´ı samostatn´e vl´akno. Teprve v nov´em vl´aknˇe se provede TCP a TLS handshake. Po autentizaci uˇzivatele a dohodnut´ı nov´eho UDP spojen´ı je pro UDP spojen´ı vytvoˇreno dalˇs´ı tzv.
datagramov´e vl´akno. Zde m˚uˇze probˇehnout DTLS handshake a n´aslednˇe handshake datagramov´eho spojen´ı. Vlastn´ı komunikace s klientem prob´ıh´a v tomto vl´aknˇe.
Kdyˇz se nˇekter´y z handshak˚u nepovede nebo je dan´e spojen´ı zruˇseno, tak jsou obˇe vl´akna ukonˇcena a pˇr´ısluˇsn´e syst´emov´e prostˇredky jsou uvolnˇeny pro dalˇs´ı spojen´ı. Kromˇe v´yˇse zm´ınˇen´ych vl´aken je pˇri startu syst´emu vytvoˇreno jedno datov´e vl´akno, kter´e spravuje sd´ılen´a data. Komunikace mezi datov´ym vl´aknem a datagramov´ym vl´aknem se prov´ad´ı pomoc´ı speci´aln´ıch front, kter´e
Obr´azek 6.1: Vl´akna Verse serveru
budou pops´any v ˇc´asti 6.3 na stranˇe 97. Datov´e vl´akno pˇri pˇrijet´ı zpr´avy z fronty zpr´av nejprve zkontroluje korektnost pˇrijat´e zpr´avy (platnost ID, pˇr´ıstupov´a pr´ava, atd.). Kdyˇz pˇrijat´a zpr´ava neobsahuje ˇz´adnou chybu, tak pomoc´ı n´ı nastav´ı vlastn´ı kopii sd´ılen´ych dat a n´aslednˇe tuto zpr´avu zaˇrad´ı do fronty zpr´av klient˚u, kteˇr´ı byli pˇrihl´aˇseni k uzl˚um, skupin´am tag˚u nebo vrstv´am. Datov´e vl´akno by z´aroveˇn mˇelo zajistit, aby klient neobdrˇzel pˇr´ıkaz ruˇs´ıc´ı nˇejakou entitu (uzel, skupinu tag˚u, atd.), aniˇz by pˇred t´ım obdrˇzel odpov´ıdaj´ıc´ı pˇr´ıkaz pro vytvoˇren´ı dan´e entity. Kaˇzd´a v´yˇse zm´ınˇen´a entita by si mˇela uchov´avat pro kaˇzd´eho pˇrihl´aˇsen´eho klienta z´aznam o tom, v jak´em stavu se z jeho pohledu nach´az´ı. Pˇr´ısluˇsn´y stavov´y diagram je uveden na obr´azku 6.2.
Obecnˇe plat´ı doporuˇcen´ı, aby kaˇzd´e spojen´ı mˇelo minim´alnˇe jedno vl´akno a jeden samostatn´y TCP soket a UDP soket. Implementace vlastn´ıho vl´akna pro kaˇzd´e spojen´ı umoˇzˇnuje garantovat jednotliv´ym spojen´ım f´erov´e zach´azen´ı.
Poˇzadavek na vlastn´ı UDP soket pro kaˇzd´e spojen´ı vych´az´ı ze skuteˇcnosti, ˇze vˇetˇsina operaˇcn´ıch syst´em˚u alokuje pro vstupn´ı buffer UDP soketu pˇribliˇznˇe 100 KB. Z tohoto d˚uvodu je nezbytn´e, aby se vl´akno snaˇzilo co nejrych-leji tento buffer vyprazdˇnovat pomoc´ı syst´emov´eho vol´an´ı recf(). Velikost vstupn´ıho bufferu pro vˇsechny UDP sokety lze sice zvˇetˇsit netrivi´aln´ım z´ asa-hem administr´atora operaˇcn´ıho syst´emu, ale m´a to samozˇrejmˇe sv´a bezpeˇ
c-SUBSCRIBED
CREATING
CREATED DELETING
DELETED node_create
ack(node_create)
timeout
node_destroy
timeout UNSUBSCRIBED
ack(node_destroy) unsubscribe/timeout
Obr´azek 6.2: Stavy uzlu nostn´ı rizika.
P˚uvodn´ı Verse server byl implementov´an jako jednovl´aknov´a aplikace, kter´a pro vˇsechna spojen´ı pouˇz´ıvala jeden soket. Server potom pˇri velk´em poˇctu klient˚u a velk´em datov´em pˇrenosu nest´ıhal vyb´ırat dostateˇcnˇe rychle vstupn´ı buffer UDP soketu a operaˇcn´ı syst´em znaˇcnou ˇc´ast pˇrenesen´ych pa-ket˚u zahazoval.
6.2 Klient
Pro tvorbu Verse klient˚u byla vytvoˇrena knihovna a navrˇzeno nov´e API, jehoˇz podstatn´a ˇc´ast jiˇz je plnˇe implementov´ana. Komunikace klienta s kaˇ z-d´ym serverem prob´ıh´a tak´e pomoc´ı dvou samostatn´ych vl´aken, kter´a jsou vy-tvoˇrena po zavol´an´ı funkce verse send connect request(). Datagramov´e vl´akno je vytvoˇreno opˇet aˇz po ´uspˇeˇsn´e autentizaci a dohodnut´ı nov´eho datagra-mov´eho spojen´ı. Samotn´a v´ymˇena dat mezi hlavn´ım vl´aknem a datagra-mov´ym vl´aknem prob´ıh´a pomoc´ı funkc´ı zaˇc´ınaj´ıc´ıch ˇretˇezcem verse send , jeˇz jsou uvedeny v pˇr´ıloze na stranˇe 165.
Aby bylo hlavn´ı vl´akno schopn´e dost´avat data od datagramov´eho vl´akna, tak si mus´ı klient zaregistrovat pˇr´ısluˇsn´e callback funkce, jeˇz jsou opˇet uve-deny v pˇr´ıloze na stranˇe 165. Vlastn´ı v´ymˇena dat mezi vl´akny se prov´ad´ı opˇet pomoc´ı speci´aln´ı fronty pˇr´ıkaz˚u. V´yhoda v´ıce vl´aken u klienta spoˇc´ıv´a
Obr´azek 6.3: Vl´akna verse klienta
v tom, ˇze hlavn´ı vl´akno m˚uˇze b´yt zanepr´azdnˇeno napˇr´ıklad renderov´an´ım rastrov´eho obr´azku, v´ypoˇctem fyzik´aln´ı simulace, atd. Datagramov´e vl´akno mezit´ım prov´ad´ı komunikaci se serverem a uchov´av´a pˇrijat´a data dokud si o nˇe hlavn´ı vl´akno neˇrekne zavol´an´ım funkce verse callback update(). Verse klient samozˇrejmˇe m˚uˇze komunikovat s v´ıce servery z´aroveˇn a pro kaˇzd´e spo-jen´ı jsou vytvoˇrena dvˇe vl´akna, jak je uvedeno na obr´azku 6.3.
P˚uvodn´ı implementace protokolu Verse tak´e poskytovala knihovnu umoˇzˇ nu-j´ıc´ı implementaci Verse klient˚u. Komunikace ovˇsem neprob´ıhala v samo-statn´em vl´aknˇe, ale jen v okamˇzic´ıch, kdy Verse klient zavolal bud’ nˇejakou funkci zaˇc´ınaj´ıc´ı ˇretˇezcem verse send nebo funkci verse callback update().
Kdyˇz bylo hlavn´ı vl´akno klienta zanepr´azdnˇeno napˇr´ıklad renderov´an´ım, kter´e trvalo d´ele jak 30 sekund, server komunikaci s klientem ukonˇcil. Pro-gram´ator se mohl pokusit ˇreˇsit tento nedostatek implementac´ı komunikace ve vlastn´ım vl´aknˇe, ale knihovna implementuj´ıc´ı p˚uvodn´ı protokol Verse nebyla naprogramov´ana jako vl´aknovˇe bezpeˇcn´a. Napˇr´ıklad v´ysledek vol´an´ı funkce verse session get() z´aviselo na hodnotˇe glob´aln´ı promˇenn´e.
6.3 Fronta pˇ r´ıkaz˚ u
Jednotliv´a vl´akna na serveru i klientovi si mezi sebou potˇrebuj´ı efektivnˇe pˇred´avat data. Kdyby byla pouˇzita jednoduch´a fronta pˇr´ıkaz˚u, mohlo by doj´ıt
k situaci, kdy hlavn´ı vl´akno zaplˇnuje frontu pˇr´ıkaz˚u rychleji neˇz je datagra-mov´e vl´akno schopn´e odes´ılat. N´asledkem toho by se mohly v jednom paketu ocitnout dva pˇr´ıkazy se stejnou adresou, coˇz je znaˇcnˇe neefektivn´ı, protoˇze prvn´ı pˇr´ıkaz by byl pˇri pˇrijet´ı u pˇr´ıjemce okamˇzitˇe pˇreps´an druh´ym pˇr´ıkazem.
Z tohoto d˚uvodu byla implementov´ana speci´aln´ı fronta, jej´ıˇz struktura je na-znaˇcena na obr´azku 6.4.
Obr´azek 6.4: Pˇrid´an´ı pˇr´ıkazu do fronty pˇr´ıkaz˚u
Fronta pro pˇred´av´an´ı pˇr´ıkaz˚u se skl´ad´a z nˇekolika speci´aln´ıch front a 256 prioritn´ıch front, jeˇz odpov´ıdaj´ı jednotliv´ym priorit´am uzl˚u. Frontu pro prioritu pi; i ∈ h0, 255i si oznaˇc´ıme jako Fi. Kaˇzd´y uzlov´y pˇr´ıkaz cmd obsa-huje svoji adresu adr = (node id, . . .) a vlastn´ı data. Na kaˇzd´em spojen´ı lze pro kaˇzd´y uzel urˇcit jeho prioritu pi = f (node id). Pˇr´ıkaz je n´aslednˇe podle node id, kter´y odkazuje, vloˇzen do odpov´ıdaj´ıc´ı fronty Fi.
Nov´y pˇr´ıkaz cmdn nesm´ı b´yt automaticky vloˇzen na konec fronty Fi. Pokud totiˇz fronta jiˇz obsahuje pˇr´ıkaz cmdo se stejnou adresou jako pˇr´ıkaz cmdn, tak p˚uvodn´ı pˇr´ıkaz cmdomus´ı b´yt nahrazen nov´ym. Vyhled´an´ı pˇr´ıkazu se stejnou adresou by se nemˇelo prov´adˇet sekvenˇcn´ım prohled´av´an´ım dan´e fronty, ale je vhodn´e implementovat k vyhled´av´an´ı haˇsovac´ı tabulku, kter´a na z´akladˇe adresy nov´eho pˇr´ıkazu cmdn bud’ rychle najde existuj´ıc´ı pˇr´ıkaz cmdo nebo ohl´as´ı, ˇze pˇr´ıkaz s touto adresou se ve frontˇe Fi nenach´az´ı. V druh´em pˇr´ıpadˇe je pˇr´ıkaz cmdn vloˇzen na konec fronty.
K frontˇe pˇr´ıkaz˚u pˇristupuj´ı vˇzdy dvˇe vl´akna, takˇze je nutn´e zajistit, aby s danou frontou Fi pracovalo vˇzdy jen jedno vl´akno. Tento poˇzadavek byl
implementov´ano pomoc´ı mutex˚u. Kaˇzd´a fronta Fije zamknut´a bˇehem operac´ı pˇrid´an´ı a odebr´an´ı pˇr´ıkazu.
Komunikaˇcn´ı vl´akno by mˇelo pˇr´ıkaz vyb´ırat z jednotliv´ych front Fi n´ asle-duj´ıc´ım zp˚usobem. Nejprve je nutn´e vybrat vˇsechny pˇr´ıkazy z jednotliv´ych front Fi; i ∈ h128, 255i. Do kaˇzd´eho paketu jsou pakety vkl´ad´any pomoc´ı al-goritmu Wighted Fair Queuing (WFQ), jak je pops´ano v [24]. Teprve, kdyˇz jsou fronty v rozsahu h128, 255i pr´azdn´e, tak je moˇzn´e zaˇc´ıt vyprazdˇnovat fronty Fi; h0, 127i opˇet pomoc´ı WFQ. Navrˇzen´y zp˚usob m˚uˇze za urˇcit´ych podm´ınek zp˚usobit vyhladovˇen´ı front z rozsahu h0, 127i, coˇz je paradoxnˇe ˇ
z´adouc´ı chov´an´ı. Klient by mˇel uzl˚um nastavovat prioritu menˇs´ı jak 128 v pˇr´ıpadˇe, ˇze nen´ı nutn´e informace z takov´ych uzl˚u dost´avat, protoˇze jsou napˇr´ıklad mimo jeho zorn´y ´uhel.
Klient i server mus´ı m´ıt nastavenou maxim´aln´ı velikost fronty zpr´av pro pˇr´ıchoz´ı spojen´ı a s kaˇzd´ym pˇrijat´ym paketem spoˇc´ıtat dostupn´e voln´e m´ısto.
Dostupn´e voln´e m´ısto se pak pˇrepoˇc´ıt´a na hodnotu rwin (viz. Flow Control na stranˇe 4.11), kter´a je deklarov´ana v kaˇzd´em odeslan´em paketu v poloˇzce Window.
6.4 Historie pˇ r´ıkaz˚ u
Resend mechanismus datagramov´eho spojen´ı vyˇzaduje, aby byly pˇreposl´ a-ny pouze aktu´aln´ı pˇr´ıkazy. Kdyˇz je v historii odeslan´ych paket˚u uloˇzen pˇr´ıkaz cmdo a dojde k odesl´an´ı nov´eho paketu obsahuj´ıc´ıho pˇr´ıkaz cmdn se stej-nou adresou, tak pˇri uloˇzen´ı nov´eho paketu mus´ı doj´ıt k zneplatnˇen´ı star´eho pˇr´ıkazu cmdo. Obdrˇz´ı-li odes´ılatel pˇr´ıkaz NAK(node id), tak mus´ı odes´ılatel z historie odeslan´ych paket˚u naˇc´ıst pˇr´ısluˇsn´y paket a vˇsechny platn´e pˇr´ıkazy cmdlmus´ı vloˇzit na zaˇc´atek odes´ılac´ıch front Fi. Pokud se ve frontˇe jiˇz nach´az´ı novˇejˇs´ı pˇr´ıkaz se stejnou adresou jako m´a pˇr´ıkaz cmdl, pˇr´ıkaz cmdl nebude pˇreposl´an, protoˇze jiˇz ve frontˇe existuje jeho novˇejˇs´ı varianta.
Zp˚usob implementace historie pˇr´ıkaz˚u je uveden na obr´azku 6.5. Nov´e pakety jsou pˇrid´av´any na konec dvojcestn´eho dynamick´eho seznamu. Kaˇzd´y paket uloˇzen´y v historii paket˚u v obsahuje sv´e ID a dvoucestn´y dynamick´y seznam uzlov´ych pˇr´ıkaz˚u, kter´e obsahoval. Samotn´e pˇr´ıkazy v tomto seznamu ovˇsem obsahuj´ı pouze odkaz na buket s adresou pˇr´ıkazu a jeho daty. Tento buket z´aroveˇn obsahuje zpˇetn´y odkaz na pˇr´ıkaz v dynamick´em seznamu ode-slan´eho paketu. Navrˇzen´a struktura umoˇzˇnuje efektivnˇe pˇrid´avat odeslan´e pakety a jejich pˇr´ıkazy a jednoduˇse zneplatnit zastaral´e pˇr´ıkazy.
Obr´azek 6.5: Sch´ema historie odeslan´ych paketu
Kapitola 7
V´ ysledky mˇ eˇ ren´ı
Pro testov´an´ı byla vytvoˇrena speci´aln´ı klient-server aplikace, kter´a simu-lovala velk´e mnoˇzstv´ı uˇzivatel˚u ASVR pomoc´ı ˇc´asticov´eho syst´emu.
7.1 Podm´ınky experiment˚ u
S´ıt’ov´e protokoly byly testov´any jednak v re´aln´em s´ıt’ov´em prostˇred´ı, ale pro jejich vz´ajemn´e porovn´an´ı bylo potˇreba zvolit jin´y pˇr´ıstup. Bylo nezbytn´e nastavit pˇresn´e parametry datov´eho okruhu a zajistit, aby tento okruh ne-pouˇz´ıvaly dalˇs´ı pˇrenosy. Toho bylo dosaˇzeno vytvoˇren´ım spojen´ı mezi hos-tuj´ıc´ım a virtualizovan´ym operaˇcn´ım syst´emem, kde obˇe linky byly upra-veny pomoc´ı n´astroje Traffic Control (tc) upravuj´ıc´ı traffic control j´adra operaˇcn´ıho syst´emu Linux. Queueing discipline (qdisc) Netem [16] byla pou-ˇ
zita k nastaven´ı zpoˇzdˇen´ı a rozptylu zpoˇzdˇen´ı. TBF qdisc byla pouˇzita k ome-zen´ı ˇs´ıˇrky p´asma.
Obr´azek 7.1: Sch´ema omezen´ı datov´eho okruhu
Na obr´azku 7.1 je patrn´e, ˇze bylo nutn´e Netem qdisc pˇripojit na konec (ingress) a TBF qdisc na zaˇc´atek (egress) kaˇzd´e linky. D˚uvod je ten, ˇze obˇe qdics jsou classless a nebylo moˇzn´e je na sebe pˇripojit pˇr´ımo. Je d˚uleˇzit´e
zm´ınit, ˇze nemodifikovan´e linky mˇely pr˚umˇern´e zpoˇzdˇen´ı okolo 0,5 ms a je-jich delay jitter byl 0,03 ms. Nejmenˇs´ı nastavovan´e hodnoty byly minim´alnˇe desetkr´at vˇetˇs´ı.
7.2 Metody experiment˚ u
Pro experimenty byly vygenerov´any v programu Blender dva ˇc´asticov´e syst´emy. Pro testov´an´ı na virtu´aln´ı lince byl vytvoˇren ˇc´asticov´y syst´em ˇc´ıtaj´ıc´ı 100 ˇc´astic a pro testov´an´ı ve skuteˇcn´em s´ıt’ov´em byl vygenerovan´y ˇc´asticov´y syst´em obsahuj´ıc´ı 1000 ˇc´astic. Oba ˇc´asticov´e syst´emy byly vˇzdy uloˇzeny na stranu klienta i serveru. 100 ˇc´astic umoˇzˇnovalo vytv´aˇret pˇri testov´an´ı na virtu´aln´ı lince n´azornou vizualizaci a z´aroveˇn bylo moˇzn´e efektivnˇe omezit ˇs´ıˇrku p´asma pro generovan´y datov´y tok.
Obr´azek 7.2: ˇCasov´y pr˚ubˇeh poˇctu pos´ılan´ych ˇc´astic
C´ˇasticov´y syst´em byl vygenerov´an pro animaci s 25 sn´ımky za vteˇrinu.
Vˇsechny testovan´e transportn´ı protokoly pouˇz´ıvaly na aplikaˇcn´ı vrstvˇe velmi jednoduch´y protokol. Klient zahajuje komunikaci se serverem zasl´an´ım jed-noduch´e zpr´avy. Server na tuto ˇz´adost reaguje t´ım, ˇze zaˇcne klientovi pos´ılat kaˇzd´ych 40 ms pozice vˇsech pohybuj´ıc´ıch se ˇc´astic. Prvn´ıch 10 pˇr´ıchoz´ıch paket˚u nebo zpr´av se pouˇzilo k v´ypoˇctu pr˚umˇern´eho zpoˇzdˇen´ı na lince.
Vˇsechny testovan´e transportn´ı protokoly pouˇz´ıvaly na aplikaˇcn´ı vrstvˇe velmi jednoduch´y protokol. Klient zahajuje komunikaci se serverem zasl´an´ım jed-noduch´e zpr´avy. Server na tuto ˇz´adost reaguje t´ım, ˇze zaˇcne klientovi pos´ılat kaˇzd´ych 40 ms pozice vˇsech pohybuj´ıc´ıch se ˇc´astic. Prvn´ıch 10 pˇr´ıchoz´ıch paket˚u nebo zpr´av se pouˇzilo k v´ypoˇctu pr˚umˇern´eho zpoˇzdˇen´ı na lince.