Hálózati protokoll tervezése A gyakorlat célja: Hálózati protokoll tervezésének a megvalósítása Elméleti bevezető: Ahhoz, hogy a hálózatba kötött gépek kommunikálni tudjanak egymással, szükség van egy egyességre, amelyet protokollnak nevezzünk. A kommunikáció mindig azonos szintű rétegek között zajlik. A párbeszéd írott és íratlan szabályait együttesen az n-edik réteg protokolljának nevezzük. A protokoll magába foglalhatja a következőket: adatátvitel kezdeményezése és befejezése küldők és fogadók szinkronizálása küldési hibák észlelése és kijavítása adatok formázása és kódolása Legalacsonyabb szinten az analóg jelből előállítódnak a bitsorozatok. Egy szinttel fennebb megtörténik a karakterkódolás. Ez után következik az üzenetek előállítása a karakter kódokból, majd az üzenetek keretekbe vagy csomagokba szervezése. Egy protokoll részei Egy protokoll a következő részeket kell tartalmazza, hogy teljes legyen: a szolgáltatást, amit a protokoll fog nyújtani feltételezéseket arról a környezetről, amelyben a protokoll végre fog hajtódni üzenetek szótárát, amely a protokollt implementálja a szótárban levő összes üzenet kódolási formáját eljárási szabályokat, melyek a stabil üzenetváltást felügyelik A protokoll ötödik alkotó részét a legnehezebb kivitelezni, ugyanakkor ennek az ellenőrzése a legnehezebb. A protokoll nyelve nem szabad megtévesztő legyen, hanem teljesen egyszerű és érthető formával kell rendelkezzen. A szolgáltatás specifikációja A protokoll célja szöveges állományok küldése, karaktersorozatok formájában, egy telefonvonalon keresztül, úgy, hogy védje az adatokat a küldés során felmerülő hibáktól. A protokoll full duplex állományátvitelre van meghatározva, vagyis az adatokat egyszerre két irányba is tudja küldeni. Pozitív és negatív acknowledge-t (nyugtát) küld. Mindenik üzenet két részből áll: az egyik rész tartalmazza magát az üzenetet, a másik rész egy ellenőrző részt foglal magába.
Feltételezések a környezetről A környezet, amelyben a protokoll végrehajtódik legalább két felhasználóból áll, melyek között az állomány átküldődik, és tartalmazza még az adataküldési csatornát. A felhasználók küldenek egy állományküldési kérést és megvárják annak befejezését. Az adatküldési csatorna tetszés szerint formálhatja az üzeneteket, de nem veszítheti el és nem duplázhatja meg őket, nem szúrhat be újabb üzeneteket és nem rendezheti át az üzenetek sorrendjét. A protokoll szótára A protokoll szótára három különböző üzenettípust különböztet meg: ack egy üzenet pozitív nyugtával való társítása esetén nak egy üzenet negatív nyugtával való társítása esetén err egy adatátviteli hibát tartalmazó üzenet esetén A szótár felírható halmaz formájában: V = {ack, err, nak}. Üzenetformátum Mindenik üzenet tartalmaz egy ellenőrző (control) mezőt, amely az üzenettípust azonosítja, és egy adatmezőt, amely karakterkódokból áll. Az adatmezőnek és az ellenőrző mezőnek konkrétan meghatározott mérete van. Az üzenet általános formája tehát: {control tag, data}. C nyelven a következőképpen írhatjuk fel: enum control {ack, nak, err}; struct message { enum control tag; unsigned char data; }; Eljárási szabályok A protokoll eljárási szabályai nem hivatalosan a következőképpen írhatóak le: 1. Ha az előző üzenetfogadás hibamentes volt, a következő üzenet, a fordított irányú csatornán, egy pozitív nyugtát fog szállítani. Ha az üzenetfogadásban hiba fordult elő, a vissza üzenet egy negatív nyugtát fog tartalmazni. 2. Ha az előző üzenetfogadás egy negatív nyugtát tartalmaz, vagy ha az előző fogadásnál hiba fordult elő, újraküldődik a régi üzenet. Ellenező esetben egy újabb üzenet készítődik elő egy újabb átvitelhez. Ahhoz, hogy hivatalossá tegyük ezeket a szabályokat, állapotdiagramokat, folyamatábrákat, algebrai kifejezéseket, vagy program formájú leírásokat használhatunk. Egy ilyen folyamatábra látható az alábbi ábrán:
A receive téglalap azt az állapotot szimbolizálja, amely várja, hogy a csatornáról egy új üzenet érkezzen meg. Annak függvényében, hogy milyen típusú üzenet érkezett, három lehetséges út közül fog egy végrehajtódni: nak, ack vagy err. A bevágott oldalú téglalap egy üzenettípus felismerését szemlélteti, míg a nyíl alakúra kinyújtott oldalú téglalap a megfelelő típusú üzenet küldését jelöli. A next:o címkéjű téglalap egy belső műveletet jelöl: készítsd elő a következő adatot (karaktert), amely el fog küldődni. Az ack:o elküldi az o adatot, az előző üzenet pozitív nyugtázásával. A bejövő adat az i változóba lesz eltárolva. A protokoll tervezése során felmerülő hibalehetőségek Ahhoz, hogy a protokoll használható formájú legyen, el kell dönteni, hogy melyik fél kezdeményezi az adatküldést, illetve melyik fél fejezi be azt. Ha nem döntjük el előre, komplikációk léphetnek fel az üzenetfeldolgozásnál. A két korábban említett eljárási szabály csak a normális adatküldést szabványosítja, de nem az indító és befejező eljárásokat.
Egy lehetséges üzenetküldési algoritmus a mellékelt ábrának megfelelően a következő: Feltételezzük, hogy A el szeretné küldeni B nek a karaktereket a -tól z -ig, és hogy B visszaválaszol neki úgy, hogy visszaküldi ezen karaktereket, csak forídott sorrendben. Az ábrán látható pontozott vonalak a sikeres üzeneteket jelölik, míg a szaggatott vonalak a közvetítő csatornán elkallódott üzeneteket jelzik. Két üzenet hibásodik meg ezáltal: egy pozitív nyugta A- tól B-nek, és egy negatív nyugta B-től A-nak. A szekvencia végén, amikor A megkapja az utolsó üzenetet B-től, nem tudja megállapítani, hogy az az üzenet amit kapott egy új vagy egy régi, ismétlődő üzenet. A nak negatív nyugta, ami ezt az információt közölte volna vele, meghibásodott. A mellékelt ábra szerint A hibamentesen elfogadja a kapott üzenetet. A protokoll hiába egyszerű, az üzenetátvitel során fellépő hibákat nagyon nehéz felfedezni. Protokoll felépítési módszerek A három leggyakrabban használt protokoll felépítési módszer a következő: 1. Bit orientált 2. Karakter orientált 3. Byte-számolás orientált Bit orientált A bit orientált protokoll egyszerre egy csatornaméretnyi bitet küld a küldendő adatból. Hogy a vevő meg tudja különböztetni, hogy hol kezdődik az üzenet és hol ér véget a bit csatornában, ez a protokoll egy kis egyedi bitminta halmazt vagy jelzéseket, úgymond flag-eket használ. Természetesen, ezek a bitminták a felhasználó által küldött adat részei is lehetnek. A keretet alkotó flag meghatározható a következőképpen: tartalmaz hat darab 1-es bitet, melyek két darab 0-ás bit közé vannak ágyazva: 01111110. Abban az adatban, amelyet a felhasználó küldeni szeretne, ez a minta nem fordulhat elő. Ezt úgy lehet kiküszöbölni, hogy ha a felhasználó
adatában mégis megtaláljuk a fenti mintát, akkor mindenik ötös 1-es csoport után beszúrunk egy nullást. Karakter oriental A karakter orientált protokollban csak egy minimális méretű struktúra küldődik át a bitcsatornán. Ha egy karakterben található bitek száma n méretű (általában 7 vagy 8), minden kommunikáció n többszöröse számú bitet tartalmaz. A protokoll ezeket az adatelemeket használja fel úgy a felhasználó által küldött adatok, mint az ellenőrző kódok megkülönböztetésénél. Példa ellenőrző kódra: az ASCII kód STX-el kezdődik (start of text) és ETX-el végződik (end of text), amelyek üzenetek elválasztására szolgálnak, de felhasználhatóak a felhasználó adatainak közrezárására is. Természetesen itt is vigyázni kell arra, hogy az elválasztó jelölések (STX, ETX) ne szerepeljenek a felhasználó által küldött adatcsomagban. Az IBM Bisync nevű protokolljában például ezeket a kontroll karaktereket extra kódok előzik meg, mint például a DLE (data link escape) karakter. Ha bármelyik kontroll üzenet, mint például a STX, ETX, DLE előfordul a felhasználó által küldött csomagban, akkor újabb DLE karakterek szúródnak be az üzenetbe. A vevő ezeket a karaktereket értelmezi, és az ez után következő karakter jelentését nem veszi figyelembe, ugyanakkor kitörli az első DLE kódot, melyet a karaktercsatornában talál, és az utána következő karaktert nem értelmezi. Az STX és ETX kódokat tehát csak akkor értelmezi úgy, mint elválasztó karaktereket, ha előttük nincs DLE karakter. Byte számolás orientált Ez a protokoll másabb, mint az előzőleg említett két protokoll. Az STX kontroll üzenet után az adó elküldi az üzenet pontos byte méretét. Az ETX üzenetre és a DLE karakterekre így már nincs szükség. Manapság a legtöbb protokoll ilyen típusú. Egy példa protokoll a DEC-nek a Digital Data Communication Message Protocol-ja, a DDCMP.
Üzenetformátum Akárcsak egy dokumentumnál, a küldendő üzenet esetében is megkülönböztethetünk egy fejlécet és egy láblécet. Egy üzenet tehát a következőképpen épül fel: forma = {fejléc, adat, lábléc} A fejléc és a lábléc a következő elemeket tartalmazza: fejléc = {típus, címzett, szekvenciaszám, hossz} lábléc = {hibaösszeg, feladó címe} Az adatmező hosszát a fejléc utolsó mezője határozza meg. A címzett és a feladó címe újabb alstruktúrákkal határozható meg. A típus mező arra használható, hogy azonosítsa az üzeneteket, melyek a protokoll szótárát építik fel. Protokolltervezési szabályok Egy protokoll tervezésekor a következő szabályokat kell figyelembe vennünk: 1. A protokoll legyen egyszerű egy jól struktúrált protokoll felbontható kis számú, jól érthető részekre. Ha meg akarjuk érteni a protokoll működését, elegendő megérteni ezen kis részek működését, mivel a protokoll ezekből épül fel. Azok a protokollok, melyek ilyen kis részek összeségeként voltak tervezve, könnyebben megérthetőek, és könnyebben implementálhatóak, könnyebben ellenőrizhetőek, és könnyebben kezelhetőek. 2. Modularitás függvények hierarchiája Az a protokoll, amely egy összetettebb feladatot végez el, felbontható kis részekre, úgynevezett modulokra. Mindenik rész külön fejleszthető, elenőrizhető és kezelhető, nincsenek egymás között összekeverve.például a hibaellenőrző rész nem feltételez semmit az operációs rendszerről, a fizikai címről, illetve az adatkódolási eljárásokról. Az így felépített protokoll tovább bővíthető, kiterjeszthető, anélkül, hogy a meglévő részeket újra kelljen írni. 3. A protokoll legyen jól formált Egy jól formált protokoll nem tartalmaz olyan kódot, ami nem elérhető és nem végrehajtható, ugyanakkor nem hiányos, nem tartalmaz olyan részeket, amelyek még nem készültek el. Egy ilyen protokoll ismeri a határokat, nem léphet túl bizonyos korlátokat, mint például az üzenetsor kapacitása. Tudja stabilizálni magát, hogyha egy hiba megváltoztatja a protokoll állapotát, akkor vissza tud térni a normális működési állapotba, véges időn belül. 4. Robusztusság A protokollt úgy kell megtervezni, hogy a nem előre látható esetekben is képes legyen helyt állni, bármilyen cselekedet szekvencia és feltételek között.
Minimális kötöttségekkel kell rendelkezzen, nem függhet a környezettől, annak érdekében, hogy elkerülhető legyen az a hibalehetőség, hogy valamilyen rész helytelen működése az ő működését is befolyásolja. 5. Konzisztencia Vigyázni kell azokra az állapotokra, melyek olyan feltételeket idézhetnek elő, melyek soha nem oldódnak meg. El kell kerülni az események sorozatos ismétlődését. Feladat: 1. Tervezzétek meg egy chat alkalmazás protokollját Könyvészet: [1]. Gerard J. Holzmann: Design and validation of computer protocols [2]. Andrew S. Tanenbaum: Számítógép Hálózatok