7.3.3 SCTP
Stream Control Transmission Protocol (SCTP) [34] je modern´ı trans-portn´ı protokol, kter´y pos´ıl´a data pomoc´ı nˇekolika nez´avisl´ych kan´al˚u. SCTP nen´ı proudovˇe orientovan´y transportn´ı protokol, ale data jsou pˇren´aˇsena ve zpr´av´ach. Doruˇcen´ı zpr´av ve stejn´em poˇrad´ı v jak´em byly zpr´avy odesl´any nen´ı zaruˇceno. Nav´ıc lze u kaˇzd´e zpr´avy nastavit ˇcasov´y limit po kter´y se m´a odes´ılatel snaˇzit zpr´avu pˇreposlat. V takov´em pˇr´ıpadˇe hovoˇr´ıme o ˇc´asteˇcnˇe spolehliv´e variantˇe protokolu SCTP, protoˇze dan´a zpr´ava nemus´ı b´yt doruˇcena.
V´ysledky mˇeˇren´ı spolehliv´e varianty protokolu SCTP jsou uvedeny na obr´azku 7.7 a v´ysledky pro ˇc´asteˇcnˇe spolehlivou variantu jsou na obr´azku 7.8 na stranˇe 110.
Spolehliv´a varianta d´av´a lepˇs´ı v´ysledky jak protokol TCP, ale pˇresto pouˇzit´ı SCTP je pro ASVR nevhodn´e. Spolehliv´a varianta se snaˇz´ı podobnˇe jako TCP pˇreposlat vˇsechny ˇc´astice, pˇrestoˇze jejich odesl´an´ı jiˇz nen´ı za-potˇreb´ı.
C´ˇasteˇcnˇe spolehliv´a varianta SCTP d´av´a podobn´e v´ysledky jako protokol UDP. ˇCasov´y limit u vˇsech odeslan´ych zpr´av byl nastaven na polovinu peri-ody mezi dvˇema obrazov´ymi sn´ımky, aby mˇel server pˇr´ıpadnˇe ˇcas ztracenou zpr´avu odeslat. ˇCasovˇe omezen´e pˇrepos´ıl´an´ı ztracen´ych zpr´av ovˇsem mˇelo sp´ıˇse negativn´ı vliv na celkovou spojitost pohybu ˇc´astic, protoˇze pˇrepos´ıl´an´ı sp´ıˇse zhorˇsovalo zahlcen´ı linky. Patrn´e to je u velk´eho zpoˇzdˇen´ı paket˚u na lince.
0
Obr´azek 7.7: V´ysledky mˇeˇren´ı za pouˇzit´ı spolehliv´e varianty protokolu SCTP
0
Obr´azek 7.8: V´ysledky mˇeˇren´ı za pouˇzit´ı ˇc´asteˇcnˇe spolehliv´e varianty proto-kolu SCTP
7.3.4 DCCP
Datagram Congestion Control Protocol (DCCP) [25] je modern´ı datagra-mov´y transportn´ı protokol navrˇzen´y prim´arnˇe jako transportn´ı protokol pro streamov´an´ı multimedi´aln´ach dat. DCCP implementuje nˇekolik variant Con-gestion Control [12] [13]. Mezi jeho dalˇs´ı vlastnosti patˇr´ı ˇctyˇrcestn´y hand-shake, pˇr´atelsk´e ukonˇcen´ı spojen´ı, dohadov´an´ı o vlastnostech spojen´ı a v ne-posledn´ı ˇradˇe podporuje Explicit Congestion Notification (ECN). D´ıky tomu by mˇel b´yt congestin control efektivnˇejˇs´ı, jak jeho implementace na aplikaˇcn´ı vrstvˇe jak to prov´ad´ı napˇr´ıklad Real-time Transport Protocol (RTP) [14]
v kombinaci s RTP Control Protocol (RTCP).
Tato pr´ace bohuˇzel neobsahuje v´ysledky testov´an´ı protokolu DCCP, proto-ˇ
ze pˇri ztr´atˇe paket˚u doch´azelo k nekorektn´ımu chov´an´ı operaˇcn´ıho syst´emu (p´ad virtualizovan´eho stroje, alokov´an´ı velk´eho mnoˇzstv´ı pamˇeti, apod.).
Mnoh´e internetov´e zdroje [35] popisuj´ı toto chov´an´ı a v budoucnu snad do-jde k jejich n´apravˇe. V souˇcasn´e dobˇe se protokol DCCP vzhledem ke stavu implementace nejev´ı jako pouˇziteln´y transportn´ı protokol pro ASVR.
7.3.5 Dalˇ s´ı transportn´ı protokoly
Kromˇe v´yˇse zm´ınˇen´ych transportn´ıch protokol˚u existuje cel´a ˇrada dalˇs´ıch jako je napˇr´ıklad Reliable Datagram Protocol (RDP) [36] navrˇzen´y pro dis-tribuovan´y operaˇcn´ı syst´em Plan 9. Protokol RDP ani dalˇs´ı transportn´ı pro-tokoly nebyly testov´any, protoˇze jejich testov´an´ı by ˇslo nad r´amec t´eto di-sertaˇcn´ı pr´ace. Nav´ıc je mal´a ˇsance, ˇze by se masivnˇe rozˇs´ıˇrili na hlavn´ı operaˇcn´ı syst´emy. Re´aln´e nasazen´ı jin´eho transportn´ıho protokolu neˇz TCP a UDP nav´ıc komplikuje ˇspatn´a nebo nulov´a podpora u firewall˚u.
7.4 Aplikaˇ cn´ı protokoly
Z aplikaˇcn´ıch protokol˚u byl otestov´an pouze p˚uvodn´ı a nov´y protokol Verse. V obou pˇr´ıpadech bylo potˇreba upravit testovac´ı aplikaci. Na vir-tualizovan´em operaˇcn´ım syst´emu bˇeˇzel vˇzdy Verse server a speci´aln´ı Verse klient, kter´y pos´ılal serveru ˇc´asticov´y syst´em. Server tento ˇc´asticov´y syst´em n´aslednˇe pˇrepos´ılal po upraven´e lince. Kombinace Verse serveru a tohoto kli-enta zast´avala dohromady stejnou funkci jako mˇel server pˇri testov´an´ı trans-portn´ıch protokol˚u. Verse klient bˇeˇz´ıc´ı na hostuj´ıc´ım operaˇcn´ım syst´emu opˇet pˇrij´ımal pakety poslan´e pˇres modifikovanou linku, porovn´aval je s vygenero-van´ym ˇc´asticov´ym syst´emem a zobrazoval rozd´ıly.
7.4.1 P˚ uvodn´ı protokol Verse
Z v´ysledk˚u mˇeˇren´ı p˚uvodn´ıho protokolu Verse je patrn´e, ˇze p˚uvodn´ı proto-kol m´a zpoˇzdˇen´ı doruˇcen´ı ˇc´astic vyˇsˇs´ı neˇz bylo dosaˇzeno pˇri pouˇzit´ı prost´eho UDP protokolu a spojitost pohybu ˇc´astic byla takt´eˇz niˇzˇs´ı. Na druhou stranu protokol Verse je schopen pˇrepos´ılat polohu ztracen´ych ˇc´astic, takˇze na konci simulace je ˇc´asticov´y syst´em na serveru i klientovi ve stejn´e podobˇe. Stejnou funkcionalitu byl schopn´y zajistit i protokol TCP za cenu velk´eho zpoˇzdˇen´ı doruˇcen´ıˇc´astic. V´ysledky mˇeˇren´ı p˚uvodn´ıho protokolu jsou uvedeny na obr´ az-ku 7.9.
0
Obr´azek 7.9: V´ysledky mˇeˇren´ı za pouˇzit´ı p˚uvodn´ıho protokolu Verse
7.4.2 Nov´ y protokol Verse
Pˇri testov´an´ı implementace nov´eho protokolu Verse bylo ovˇeˇreno, ˇze nov´y protokol je schopn´y efektivnˇe pˇrepos´ılat ztracen´e pakety, takˇze ˇc´asticov´y syst´em je na konci pˇrenosu na stranˇe klienta tak´e v konzistentn´ım stavu.
Mˇeˇren´ı z´aroveˇn uk´azalo, ˇze nov´y protokol Verse umoˇzˇnuje pˇren´aˇset polohu ˇ
c´astic efektivnˇeji neˇz p˚uvodn´ı protokol. Doch´azelo v mnohem menˇs´ı m´ıˇre ke ztr´atˇe paket˚u a ˇc´astic, coˇz lze pˇriˇc´ıst efektivnˇejˇs´ımu vyuˇz´ıv´an´ı m´ısta v pa-ketu, jak bylo uk´az´ano na obr´azku 5.21. Samotn´e v´ysledky mˇeˇren´ı nov´eho protokolu jsou uk´az´any na obr´azku 7.10, kde pro porovn´an´ı nebyla pouˇzita komprese pˇr´ıkaz˚u.
Kdyˇz byla pouˇzita komprese pˇr´ıkaz˚u, tak v´ysledn´y datov´y tok byl menˇs´ı neˇz nastaven´a ˇs´ıˇrka p´asma. D´ıky tomu t´emˇeˇr nedoch´azelo ke ztr´at´am paket˚u a zpoˇzdˇen´ı ˇc´astic bylo minim´aln´ı. Z graf˚u na obr´azku 7.11 je ovˇsem patrn´e, ˇ
ze se zvyˇsuj´ıc´ım se rozptylem zpoˇzdˇen´ı paket˚u doch´azelo k n´ar˚ustu ztr´aty ˇ
c´astic, coˇz bylo zapˇr´ıˇcinˇeno zmˇenou poˇrad´ı paket˚u. Pˇri zvyˇsuj´ıc´ım se rozptylu zpoˇzdˇen´ı se zvyˇsovala i pravdˇepodobnost zmˇeny poˇrad´ı paket˚u. Jelikoˇz se pˇri implementaci protokolu pouˇzila jednoduˇsˇs´ı varianty, tak byly pakety se zmˇenˇen´ym poˇrad´ım klientem zahazov´any.
Bohuˇzel se nepodaˇrilo prov´est mˇeˇren´ı pˇrenosu za pouˇzit´ı protokolu DTLS.
Implementace protokolu Verse totiˇz vyuˇz´ıv´a implementace protokolu DTLS z knihovny OpenSSL, kter´a obsahuje chybu jeˇz se projevuje n´ahodnˇe pˇri ztr´atˇe paketu. Pˇri v´yskytu t´eto chyby jsou vˇsechny n´asleduj´ıc´ı pakety dek´ odo-v´any ˇspatnˇe. Ve v´ysledku lze sice DTLS pouˇz´ıt na lince, kde nedoch´az´ı ke ztr´atˇe paketu, ale uˇz ho nebylo moˇzn´e otestovat.
V´ysledky experiment˚u v re´aln´e s´ıt’ov´em prostˇred´ı jsou uvedeny na obr´azku 7.12. Spojen´ı, na kter´em byly prov´adˇeny experimenty, mˇelo ˇs´ıˇrku p´asma 1,9 Mb/s a pr˚umˇern´e zpoˇzdˇen´ı na lince bylo 5 ms. K experiment˚um byl pouˇzit ˇ
c´asticov´y syst´em, kter´y obsahoval 1000 ˇc´astic. Z v´ysledk˚u experiment˚u je pa-trn´e, ˇze nov´y protokol Verse d´av´a i v re´aln´em s´ıt’ov´em provozu velmi dobr´e v´ysledky, kter´e jsou zp˚usobeny pˇredevˇs´ım efektivn´ı kompres´ı pˇren´aˇsen´ych dat.
0
Obr´azek 7.10: V´ysledky mˇeˇren´ı za pouˇzit´ı nov´eho protokolu Verse (bez kom-prese pˇr´ıkaz˚u)
0
Obr´azek 7.11: V´ysledky mˇeˇren´ı za pouˇzit´ı nov´eho protokolu Verse (s kompres´ı pˇr´ıkaz˚u)
0
Average number of particles received in time
UDP
Obr´azek 7.12: Porovn´an´ı v´ysledk˚u experiment´aln´ıho mˇeˇren´ı v re´aln´e s´ıt’ov´em provozu
Kapitola 8 Z´ avˇ er
Tato disertaˇcn´ı pr´ace obsahuje popis specifikace nov´eho protokolu Verse (kapitola 4) urˇcen´eho pro real-timov´e sd´ılen´ı dat v aplikac´ıch sd´ılen´e virtu´aln´ı reality. Specifikace ˇc´asteˇcnˇe vych´az´ı z p˚uvodn´ıho protokolu Verse (kapitola 3), ale cel´y protokol byl od z´akladu pˇrepracov´an s ohledem na vˇetˇs´ı bezpeˇcnost, spohlivost a efektivitu pˇrenosu dat. Specifikace obsahuje popis zah´ajen´ı spo-jen´ı, kter´e kromˇe autentizace uˇzivatele umoˇzˇnuje prov´est dohadov´an´ı o vlast-nostech datov´e komunikace mezi klientem a serverem. Pro dosaˇzen´ı ˇc´asteˇcn´e spolehlivosti byl navrˇzen nov´y robustnˇejˇs´ı a efektivnˇejˇs´ı resend mechanis-mus, kter´y pˇrepos´ıl´a pouze aktu´aln´ı data a zaruˇcuje efektivn´ı vyuˇz´ıv´an´ı pˇrenosov´ych linek. Nov´e vlastnosti protokolu Verse byly prezentov´any na konferenci BCONF 2010 [19].
Souˇc´ast´ı specifikace je i popis nov´eho datov´eho modelu (kapitola 5), kter´y sice klade na Verse klienty nˇekter´e nov´e poˇzadavky, ale zbyteˇcn´e poˇzadavky p˚uvodn´ıho protokolu ruˇs´ı. V koneˇcn´em d˚usledku je moˇzn´e prov´adˇet sd´ılen´ı dat, kter´e se star´ym protokolem nebylo moˇzn´e. Nav´ıc je moˇzn´e nastavovat u sd´ılen´ych dat pˇr´ıstupov´a pr´ava, coˇz p˚uvodn´ı protokol tak´e neumoˇzˇnoval.
Pro vˇsechny d˚uleˇzit´e ˇc´asti nov´e specifikace byly vytvoˇreny verifikaˇcn´ı mo-dely v programovac´ım jazyku PROMELA a provedena jejich verifikovace po-moc´ı n´astroje Spin (kapitoly 4.5.3, 4.5.2 a 4.10). V´ysledky verifikace resend mechanismu byly publikov´any ve sborn´ıku konference INTED 2009 [18].
Podstatn´a ˇc´ast specifikace byla implementov´ana v programovac´ım jazyku C. Popis implementace (kapitola 6) obsahuje pˇredevˇs´ım obecn´e struktury a postupy, kter´e umoˇzˇnuj´ı efektivnˇe implementovat nov´y protokol i v dalˇs´ıch programovac´ıch jazyc´ıch.
Tato implementace byla pouˇzita pro mˇeˇren´ı v experiment´aln´ım prostˇred´ı, kdy byla otestovan´a vhodnost jednotliv´ych transportn´ıch protokol˚u pro nov´y protokol Verse. Z´aroveˇn byly v tomto experiment´aln´ım prostˇred´ı provedeny testy p˚uvodn´ıho a nov´eho protokolu Verse, kter´e uk´azaly, ˇze nov´y protokol
d´av´a lepˇs´ı v´ysledky. V´ysledky tˇechto experiment˚u byly pˇrijaty na konferenci WSCG 2011 [20].
Shrnut´ı pˇ r´ınos˚ u k rozvoji vˇ edn´ıho oboru
V pr´aci je navrˇzen´y resend mechanismus pro efektivn´ı sd´ılen´ı dat v apli-kac´ıch sd´ılen´e virtu´aln´ı reality, kdy nen´ı vyˇzadov´an pˇrenos dat s ´uplnou spo-lehlivost´ı, ale jsou kladeny poˇzadavky na n´ızk´e latence doruˇcen´ı aktu´aln´ıch dat. Navrˇzen´e algoritmy nav´ıc umoˇzˇnuj´ı stanovit priority sd´ılen´ym dat˚um a tak efektivnˇe zv´yˇsit ˇsanci jejich vˇcasn´eho doruˇcen´ı.
Shrnut´ı pˇ r´ınos˚ u pro praxi
Navrˇzen´y protokol umoˇzˇnuje sd´ılet data mezi grafick´ymi aplikacemi bez-peˇcnˇeji, spolehlivˇeji a hlavnˇe efektivnˇeji neˇz p˚uvodn´ı protokol Verse. Pˇri pro-gramov´an´ı nov´ych Verse klient˚u je moˇzn´e efektivnˇe vyuˇz´ıt v´ıcevl´aknov´e cha-rakteru knihovny a v´ıcevl´aknov´a implementace Verse serveru umoˇzˇnuje lepˇs´ı ˇsk´alov´an´ı.
Dalˇ s´ı pr´ ace a experimenty
Dalˇs´ı pr´ace by mˇela spoˇc´ıvat pˇredevˇs´ım v dokonˇcen´ı implementace cel´e specifikace a opraven´ı chybn´e implementace DTLS v knihovnˇe OpenSSL, kter´a znemoˇzˇnuje praktick´e nasazen´ı zabezpeˇcen´eho pˇrenosu v praxi. Plno-hodnotn´a implementace DTLS protokolu by mˇela b´yt n´aslednˇe otestov´ana pˇredevˇs´ım s ohledem na velk´e datov´e toky a zat´ıˇzen´ı Verse serveru. Dalˇs´ı rozˇs´ıˇren´ı specifikace by se mˇelo t´ykat pˇredevˇs´ım Congestion Control (kapi-tola 4.12) v kombinaci s dohadov´an´ım o FPS (kapitola 4.5.3), protoˇze pos´ıl´an´ı paket˚u v pravideln´ych intervalech odpov´ıdaj´ıc´ıch FPS Verse klienta se jev´ı jako dalˇs´ı moˇzn´y zp˚usob jak zefektivnit pˇrenos dat.
Dalˇs´ı rozˇs´ıˇren´ı specifikace by se mˇelo t´ykat pravidel sd´ılen´ı dat na serveru pomoc´ı DED (kapitola 4.5.3). Grafick´e aplikace by mˇely m´ıt jednak moˇznost definovat si vlastn´ı pravidla, kter´a jsou jim uˇsita na m´ıru a z´aroveˇn by mˇelo b´yt vytvoˇrena sada pravidel, kter´a by umoˇzˇnovala sd´ılet data mezi r˚uzn´ymi grafick´ymi aplikacemi. V neposledn´ı ˇradˇe by mˇela b´yt provedena opˇetovn´a implementace nov´eho protokolu Verse do programu Blender.
Literatura
[1] Al-Regib, G., and Altunbasak, Y. 3TP: 3-D models transport pro-tocol. In Web3D ’04: Proceedings of the ninth international conference on 3D Web technology (New York, NY, USA, 2004), ACM, pp. 155–162.
[2] Allman, M., Paxson, V., and Stevens, W. TCP Congestion Con-trol. RFC 2581, IETF, apr 1999. http://www.ietf.org/rfc/rfc2581.
txt, Obsoleted by RFC 5681, updated by RFC 3390.
[3] Arnaud, R., and Barnes, M. C. Collada: Sailing the Gulf of 3d Digital Content Creation. AK Peters Ltd, 2006.
[4] Ayuso, P. N. Netfilter/iptables. http://www.netfilter.org/, 2010.
[5] Bennett, J. C. R., Partridge, C., and Shectman, N. Packet reordering is not pathological network behavior. IEEE/ACM Trans.
Netw. 7, 6 (December 1999), 789–798.
[6] Berners-Lee, T., Masinter, L., and McCahill, M. Uniform Resource Locators (URL). RFC 1738, IETF, dec 1994. http://www.
ietf.org/rfc/rfc1738.txt, Obsoleted by RFCs 4248, 4266, updated by RFCs 1808, 2368, 2396, 3986.
[7] Boulanger, J.-S., Kienzle, J., and Verbrugge, C. Comparing interest management algorithms for massively multiplayer games. In Proceedings of 5th ACM SIGCOMM workshop on Network and system support for games (New York, NY, USA, 2006), NetGames ’06, ACM.
[8] Bouras, C., Giannaka, E., and Tsiatsos, T. Partitioning of Dis-tributed Virtual Environments Based on Objects’ Attributes. In Pro-ceedings of the 11th IEEE International Symposium on Distributed Si-mulation and Real-Time Applications (Washington, DC, USA, 2007), DS-RT ’07, IEEE Computer Society, pp. 72–75.
[9] Brink, E., Steenberg, E., and Svensson, G. The Verse Networ-ked 3D Graphics Platform. In SIGRAD 2006, The Annual SIGRAD Conference (Link¨oping, Sweden, 2006), H. Gustavsson, Ed., SIGRAD, pp. 44–48.
[10] Cruz-Neira, C., Sandin, D. J., DeFanti, T. A., Kenyon, R. V., and Hart, J. C. The CAVE: audio visual experience automatic virtual environment. Commun. ACM 35, 6 (June 1992), 64–72.
[11] Dierks, T., and Allen, C. The TLS Protocol Version 1.0. RFC 2246, IETF, jan 1999. http://www.ietf.org/rfc/rfc2246.txt, Obsoleted by RFC 4346, updated by RFCs 3546, 5746.
[12] Floyd, S., and Kohler, E. Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Cont-rol. RFC 4341, IETF, mar 2006. http://www.ietf.org/rfc/rfc4341.
txt.
[13] Floyd, S., Kohler, E., and Padhye, J. Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC). RFC 4342, IETF, mar 2006. http:
//www.ietf.org/rfc/rfc4342.txt, Updated by RFC 5348.
[14] Group, A.-V. T. W., Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V. RTP: A Transport Protocol for Real-Time Applications. RFC 1889, IETF, jan 1996. http://www.ietf.org/rfc/
rfc1889.txt, Obsoleted by RFC 3550.
[15] Harcsik, S., Petlund, A., Griwodz, C., and Halvorsen, P.
Latency evaluation of networking mechanisms for game traffic. In Pro-ceedings of the 6th ACM SIGCOMM workshop on Network and system support for games (New York, NY, USA, 2007), NetGames ’07, ACM, pp. 129–134.
[16] Hemminger, S. Network Emulation with NetEm. In Linux Conf Au (April 2005).
[17] Hnidek, J. Integration of Verse protocol to Blender. Interantional Blender Conference, Blender Foundation, Amsterdam, the Netherlands, October 2005.
[18] Hnidek, J. Resend Mechanism for Reliable Datagram Protocol. An-nual Edition of the International Technology. Education and Develop-ment Conference (INTED) (2009).
[19] Hnidek, J. Introduction of New Verse Protocol. Interantional Blen-der Conference, Stichting BlenBlen-der Foundation, Amsterdam, the Nether-lands, October 2010.
[20] Hnidek, J. Network Protocols for Applications of Shared Virtual Re-ality. 19th International Conference in Central Europe on Computer Graphics, Visualization and Computer Vision Communication Papers Proceedings (2011).
[21] Holzmann, G. J. Design and validation of computer protocols.
Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1991.
[22] Jacobson, V. Congestion avoidance and control. SIGCOMM Comput.
Commun. Rev. 18, 4 (August 1988), 314–329.
[23] Kempf, J., Chander, A., and Jo, M. Optimizing avatar environ-mental update in shared virtual reality environments. In Proceedings of the First International Conference on Immersive Telecommunicati-ons (ICST, Brussels, Belgium, Belgium, 2007), ImmersCom ’07, ICST (Institute for Computer Sciences, Social-Informatics and Telecommuni-cations Engineering), pp. 1–1.
[24] Keshav, S. An Engineering Approach to Computer Networking: ATM Networks, the Internet, and the Telephone Network. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1997.
[25] Kohler, E., Handley, M., and Floyd, S. RFC 4340: Da-tagram Congestion Control Protocol (DCCP). RFC 4340, IETF, mar 2006. http://www.ietf.org/rfc/rfc4340.txt, Updated by RFCs 5595, 5596.
[26] Lui, J. C. S., and Chan, M. F. An Efficient Partitioning Algorithm for Distributed Virtual Environment Systems. IEEE Trans. Parallel Distrib. Syst. 13, 3 (March 2002), 193–211.
[27] Mills, D., Martin, J., Burbank, J., and Kasch, W. Network Time Protocol Version 4: Protocol and Algorithms Specification. RFC 5905, IETF, jun 2010. http://www.ietf.org/rfc/rfc4341.txt.
[28] Modadugu, N., and Rescorla, E. The Design and Implementation of Datagram TLS. In In Proc. NDSS (2004).
[29] Postel, J. RFC 768: User Datagram Protocol. RFC 768, IETF, aug 1980. http://www.ietf.org/rfc/rfc768.txt.
[30] Postel, J. RFC 793: Transmission Control Protocol. RFC 793, IETF, sep 1981. http://www.ietf.org/rfc/rfc793.txt, Updated by RFCs 1122, 3168.
[31] Rescorla, E., and Modadugu, N. Datagram Transport Layer Secu-rity. RFC 4347, IETF, apr 2006. http://www.ietf.org/rfc/rfc4347.
txt, Updated by RFC 5746.
[32] Steenberg, E. Brink, E. The Verse Specification. http://verse.
blender.org, 2007.
[33] Stevens, W. TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. RFC 2001, IETF, jan 1997. http:
//www.ietf.org/rfc/rfc2001.txt, Obsoleted by RFC 2581.
[34] Stewart, R. RFC 4960: Stream Control Transmission Protocol. RFC 4960, IETF, sep 2007. http://www.ietf.org/rfc/rfc4960.txt.
[35] The Linux Foundation. Networking ToDo List. Tech. rep., The Linux Foundation, 1796 18th Street, Suite C, San Francisco, CA 94107, 2010. http://www.linuxfoundation.org/collaborate/workgroups/
networking/todo.
[36] Velten, D., Hinden, R. M., and Sax, J. Reliable Data Protocol.
RFC 908, IETF, jul 1984. http://www.ietf.org/rfc/rfc908.txt, Up-dated by RFC 1151.
[37] Yergeau, F. UTF-8, a transformation format of ISO 10646. RFC 3629, IETF, nov 2003. http://www.ietf.org/rfc/rfc3629.txt.
Kapitola 9
Pˇ r´ılohy verifikaˇ cn´ıch model˚ u
Verifikace autentifikace uˇzivatele
41
103 : : timeout −> { goto e n d a u t h f a i l ; } ;
165 f o r c o m b i n a t i o n o f username and a u t h e n t i c a t i o n d a t a . ∗/
175 auth meth == AUTH METH DATA &&
176 a u t h d a t a == VALID DATA) −> { goto e n d a u t h s u c c ; } ; 177 : : ( a t t e m p t s < MAX AUTH ATTEMPTS &&
178 u s e r n a m e == i n i t u s e r n a m e &&
179 u s e r n a m e == VALID USER &&
180 auth meth == AUTH METH DATA &&
181 a u t h d a t a != VALID DATA) −> atomic {
188 auth meth == AUTH METH DATA) −> atomic {
189 a t t e m p t s ++;
227 chan q1 = [ 0 ] o f { bit , byte , b i t } ; 228 /∗ cmd type , a u t h m e t h ∗/
229 chan q2 = [ 0 ] o f { bit , byte } ; 230
231 atomic{run S e r v e r ( q1 , q2 ) ; run C l i e n t ( q2 , q1 ) ; } ; 232 }
V´ysledky verifikace autentifikace uˇzivatele Verifikace byla vˇzdy pro-vedena nejprve pro vyhled´an´ı nekorektn´ıch koncov´ych stav˚u a n´aslednˇe byla verifikace provedena pro nalezen´ı pˇr´ıpadn´ych nevyv´ıjej´ıc´ıch se cykl˚u.
$ spin -a user_auth.pml
$ gcc -o user_auth -DSAFETY pan.c
$ ./user_auth
(Spin Version 5.2.5 -- 17 April 2010) + Partial Order Reduction
Full statespace search for:
never claim - (none specified) assertion violations +
cycle checks - (disabled by -DSAFETY) invalid end states +
State-vector 52 byte, depth reached 68, errors: 0 1773 states, stored
244 states, matched
2017 transitions (= stored+matched) 1 atomic steps
hash conflicts: 1 (resolved) 2.598 memory usage (Mbyte)
unreached in proctype Client (0 of 90 states)
unreached in proctype Server (0 of 76 states)
unreached in proctype :init:
(0 of 4 states)
pan: elapsed time 0 seconds
$ spin -a user_auth.pml
$ gcc -o user_auth -DNP pan.c
$ ./user_auth -l
(Spin Version 5.2.5 -- 17 April 2010) + Partial Order Reduction
Full statespace search for:
never claim +
assertion violations + (if within scope of claim) non-progress cycles + (fairness disabled) invalid end states - (disabled by never claim)
State-vector 60 byte, depth reached 113, errors: 0 4541 states, stored (6623 visited)
5218 states, matched
11841 transitions (= visited+matched) 602 atomic steps
hash conflicts: 8 (resolved)
Stats on memory usage (in Megabytes):
0.329 equivalent memory usage for states (stored*(State-vector + overhead)) 0.372 actual memory usage for states (unsuccessful compression: 113.09%)
state-vector as stored = 70 byte + 16 byte overhead 2.000 memory used for hash table (-w19)
0.305 memory used for DFS stack (-m10000) 2.598 total actual memory usage
unreached in proctype Client (0 of 96 states)
unreached in proctype Server (0 of 76 states)
unreached in proctype :init:
(0 of 4 states)
pan: elapsed time 0.01 seconds
Verifikace dohadov´an´ı o nov´em datagramov´em spojen´ı
61 p r i n t f ( ” C l i e n t : TRY URL\n” ) ;
123 i f
185 /∗ cmd type , URL, cmd type , URL ∗/
186 chan q1 = [ 0 ] o f {mtype , byte , mtype , byte } ; 187 /∗ cmd type , URL, cmd type , URL ∗/
188 chan q2 = [ 0 ] o f {mtype , byte , mtype , byte } ; 189
190 atomic{run S e r v e r ( q1 , q2 ) ; run C l i e n t ( q2 , q1 ) ; } ; 191 }
V´ysledky verifikace dohadov´an´ı o nov´em datagramov´em spojen´ı
$ spin -a host_neg.pml
$ gcc -o host_neg -DSAFETY pan.c
$ ./host_neg
(Spin Version 5.2.5 -- 17 April 2010) + Partial Order Reduction
Full statespace search for:
never claim - (none specified) assertion violations +
cycle checks - (disabled by -DSAFETY) invalid end states +
State-vector 56 byte, depth reached 43, errors: 0 517 states, stored
56 states, matched
573 transitions (= stored+matched) 1 atomic steps
hash conflicts: 0 (resolved) 2.501 memory usage (Mbyte)
unreached in proctype Client (0 of 81 states)
unreached in proctype Server (0 of 79 states)
unreached in proctype :init:
(0 of 4 states)
pan: elapsed time 0.01 seconds
$ spin -a host_neg.pml
$ gcc -o host_neg -DNP pan.c
$ ./host_neg -l
(Spin Version 5.2.5 -- 17 April 2010) + Partial Order Reduction
Full statespace search for:
never claim +
assertion violations + (if within scope of claim) non-progress cycles + (fairness disabled) invalid end states - (disabled by never claim)
State-vector 60 byte, depth reached 83, errors: 0 1033 states, stored (1549 visited)
1255 states, matched
2804 transitions (= visited+matched) 2 atomic steps
hash conflicts: 0 (resolved) 2.501 memory usage (Mbyte)
unreached in proctype Client (0 of 81 states)
unreached in proctype Server (0 of 79 states)
unreached in proctype :init:
(0 of 4 states)
pan: elapsed time 0.01 seconds
Verifikace datagramov´eho spojen´ı
61 i n ?rPAY , rACK, rSYN , rFIN , rPAY ID , rACK ID , rMSG −>
123 : : e l s e −> skip ; 161 sPAY=1; sACK=1; sSYN=0; sFIN =1;
162 conn =0;
185 } ;
218 short rPAY ID=0 , rACK ID=0 , rMSG=0;
219 /∗ Send PayID , AckID and MSG ∗/
220 short sPAY ID=0 , sACK ID=0 , sMSG=0;
221
247 goto r e s p o n d ;
309 : : ( n f u l l ( o u t ) && t i m e r <TIMEOUT) −> atomic {
371 } ; 417 sPAY=1; sACK=1; sSYN=0; sFIN =1;
418 c o u n t =0;
431 : : (rPAY==1 && rFIN==1) −> atomic {
432 sMSG=rPAY ID ;
433 o u t ! sPAY , sACK, sSYN , sFIN , sPAY ID , sACK ID , sMSG ;
434 }
435 /∗ S i m u l a t i o n o f p a c k e t l o s s ∗/
436 : : ( 1 ) −> p r i n t f ( ” P a c k e t l o s s \n” ) ;
437 f i ;
438 } ;
439 : : timeout −> { goto e n d s u c c e s s ; } ;
440 od ;
441
442 e n d f a i l u r e :
443 p r i n t f ( ” S e r v e r : f a i l u r e \n” ) ;
444 do
445 : : i n ?rPAY , rACK, rSYN , rFIN , rPAY ID , rACK ID , rMSG ; 446 : : timeout −> goto end ;
447 od ;
448
449 e n d s u c c e s s :
450 p r i n t f ( ” S e r v e r : s u c c e s s \n” ) ;
451 do
452 : : i n ?rPAY , rACK, rSYN , rFIN , rPAY ID , rACK ID , rMSG ; 453 : : timeout −> goto end ;
454 od ;
454 od ;