Az elsõ vizsgált protokoll a lehetõ legegyszerûbb: az adatátviteli sebesség, a feldolgozás nincs korlátozva: amilyen sebességgel küldi az ADÓ a kereteket, a VEVÕ ugyanilyen sebességgel képes ezt venni. Ez a gyakorlatban azt jelenti, hogy az ADÓ és a VEVÕ hálózati rétege mindig készen áll, a feldolgozási idõ elhanyagolható, és a keretek esetleges tárolására szolgáló puffer kapacitás végtelen. Az adatkapcsolati rétegek közötti csatorna hibamentes, kerethiba, keretvesztés nem fordul elõ. Az átvitel egyirányú.

A valóságban nagyon sok esetben a VEVÕ nem képes olyan sebességgel feldolgozni a kereteket, azaz valahogy az ADÓ-t le kell lassítani olyan mértékben hogy a VEVÕ küldött kereteket mindig fel tudja dolgozni. Ez csak egy módon lehetséges: informálni kell az adót arról, hogy mikor küldheti a következõ keretet, azaz a vétel és a feldolgozás tényét nyugtázni kell. Vagyis a protokoll megköveteli az ADÓ-tól, hogy egy keret elküldése után addig várjon, amíg a kis üres (nincs adat!!!) nyugtakeret meg nem érkezik. Ezt a protokollt szokták “megáll ás vár” (stop and wait) protokollnak nevezni.

Látható, hogy bár az adatforgalom szimplex, azért a keretek már különbözõ idõpontokban két irányban áramlanak, ezért fél-duplex csatorna kialakítást igényel a fizikai réteg vonatkozásában. A protokoll jól mûködik az adatkeretek átvitelekor, hiszen a VEVÕ csak akkor küld vissza nyugtát, ha a keret vétele helyes volt. Mi van azonban akkor, ha VEVÕ által küldött nyugtakeret sérül meg? Mivel nyugta nincs, az ADÓ egy bizonyos idõ múlva ismét elküldené a nem nyugtázott keretet, amit a VEVÕ ismételten venne, azaz a benne lévõ adatok megkettõzõdve kerülnének a hálózati réteghez. Ez sajnos súlyos hiba.

A VEVÕ-nek kell egy olyan módszert alkalmaznia, amely megkülönböztethetõvé teszi a számára az elõször látott kereteket az újraadásra kerültektõl.

Ennek egyszerû megoldása az, hogy az ADÓ egy számot helyez el minden elküldendõ keret fejrészébe, és ezáltal a VEVÕ eldöntheti, hogy elõször adott, vagy ismételt keretrõl van-e szó. Mivel a keretek és a nyugták egymás után vannak, ezért elegendõ 1 bittel jelezni az újraküldés tényét. Nézzük: a k-adik keretre (amelynek újraküldési bitje 0 volt, jelezve az elsõ küldést) a VEVÕ nyugtát küld, de az elvész. Az ADÓ mivel a k-adik keretet elküldte, de nem nyugtázták (legalábbis azt hiszi), egy adott idõzítés lejárta után ismételten elküldi a keretet, de már 1-es újraküldési bittel). A VEVÕ ezt véve, a bit alapján már tudja hogy ezt már vette, ezért nyugtát küld vissza az elveszett helyett, de a keretet eldobja.

Az elõzõ esetekben az adatátvitel egyirányú volt, bár az utolsó két esetnél a nyugtázás miatt az ellenirányú átvitelre is szükség volt az ADÓ informálása miatt. A gyakorlatban az adatátvitel is a legtöbbször kétirányú, ezért célszerû ezt a kialakítást is megvizsgálni. A megoldás lehetne két különálló, ellentétes irányú adatcsatorna használata, de az a nyugtázás miatt valójában négy információs utat jelentene, ahol a nyugtacsatornák kihasználása kicsi lenne.

Jobb megoldás, ha mindkét irány számára ugyanazt a csatornát használjuk, hiszen az adatkereteket a nyugtakeretektõl a keret fejrészében elhelyezett jelzõ meg tudja különböztetni, és ez a keret vételekor azonosítható.

Egy egyszerû megoldással az átviendõ keretek számát csökkenthetjük: bármelyik irányba tartó adatkeretre ráültethetjük az elõzõ ellenirányú adatkeret nyugtáját. Ezt szokták ráültetési (piggy-back) technikának is hívni. Hogy egy nyugta akkor is visszajusson, ha éppen nincs visszafelé küldött adatkeret, célszerû egy adott idõzítés lejártakor a VEVÕ-nek önállóan útnak indítani. Persze, ha az adó eltérõ idõzítése miatt újra elküldi a keretet, akkor ez problémát jelent.

Az eddigiekben feltételeztük hogy a csatornán mindig egy adatkeret, majd rá válaszul egy nyugtakeret halad. A valóságban a csatorna jobb kihasználását teszi lehetõvé, ha megengedjük, hogy a csatornán több keret is tartózkodhat. Az ezt lehetõvé eljárásokat csúszóablakos (sliding window) vagy forgóablakos protokolloknak nevezik. A könyvben az elsõ megnevezést fogjuk használni.

A protokollban minden egyes kimenõ keret egy 0-max (az ábrán:0-7) közötti sorszámot kap. A lényeg az, hogy a sorban elküldendõ keretek sorszámaiból egy aktualizált listát tart fenn az ADÓ. A listában szereplõ sorszámú keretek az adási ablakba (sending window) esnek. Az ADÓ adási ablakában az elküldött, de még nem nyugtázott keretek vannak. Mikor egy nyugta megérkezik az ablak alsó fele feljebb csúszik, lehetõvé téve újabb keret elküldését. Nem kell a kereteket egyenként nyugtázni, ha pl. az ADÓ az 1-es sorszámú keretre kap nyugtát, ez azt jelenti, hogy nyugtázott a 6,7,0,1 keret. (ld. ábra). Mivel a kereteket esetleg újra kell adni, ezért az ablakban lévõ kereteket ismételt adásra készen memória-pufferekben kell tartani. Az ADÓ ezenkívül az ablakban lévõ minden keret elküldésétõl eltelt idõt nyilván tartja, és ha ez egy értéknél (timeout) nagyobb, akkor újra adja.

A VEVÕ egy vételi ablakot (receiving window) tart fenn, amely az elfogadható keretek sorszámait tartalmazza. Bármelyik ablakon kívüli keret érkezésekor az eldobódik. Ha a k-adik keret érkezik, akkor rá a nyugta a következõ két feltétel teljesülése esetén lesz visszaküldve: 1. A k-adik keret még nem lett nyugtázva. 2. Minden keretet az elsõnek várt (az ábrán a 6.) és a k-adik között már vettünk.

Ez a legegyszerûbb ilyen jellegû protokoll. Hasonló a megáll-és-vár protokollhoz, de az átvitel mindkét irányban folyik, és az ellenirányú csomag hordozza az elõzõleg küldött nyugtáját. Legyen két állomás, A és B! Jelölések: küld, vesz, pl Avesz=A vesz. A keret jelölése: (sorszám, nyugta, az A vagy B által küldött adatcsomag jelölése). Mivel mindig csak akkor lehet új keretet küldeni, ha nyugtázva van az elõzõ, a sorszám és nyugta értéke csak 0 vagy 1 lehet.

A kezdi az adást, küldi B-nek a keretet: (itt az 1 nyugta csak azért van, hogy B “azt higgye” hogy az elõzõ küldése sikeres volt) Aküld(0,1,A0).

B veszi, és a nyugtát a saját keretével visszaküldi: Bvesz(0,1,A0), Bküld(0,0,B0)

A veszi B elsõ keretét és küldött kerete nyugtáját, és küldi az újabb keretet: Avesz(0,0,B0), Aküld(1,1,A1). A következõ ábrán összefoglalva:

A protokoll nagyon jól mûködik: Ha például A nem kapja meg pl. az A0-ra nyugtáját, azaz B (0,1,B0)-át küld, akkor ismét elküldi B-nek a (0,1,A0) keretet (mivel A nyugtázhatja a B0 keretet. Akár többször is küldheti (próbálkozhat), miközben B sorban adja a saját kereteit. A protokollt semmilyen elveszett keret, vagy a lejárt idõzítés miatt újraküldött keret nem készteti arra, hogy kettõzött keretet adjon tovább a hálózati rétegnek, vagy egy keretet kihagyjon. Azonban keretkettõzõdés lép fel, ha A és B egyszerre kezd adni. Ugyanis ehhez induláskor 1-es nyugtával kell elküldenie a saját keretét:

Aküld(0,1,A0) Bküld(0,1,B0), és a vétel:

Avesz(0,1,B0) Bvesz(0,1,A0) amit el is fogadnak.

Mivel mindkét vételben 1-es nyugta van a várt 0 helyett, mindkettõ újraküldi az elõzõ keretet: Aküld(0,0,A0) Bküld(0,0,B0), amelyeket mindkettõ vesz és továbbad.

Mind az ADÓ mind a VEVÕ számára egy elemes csúszóablak elegendõ: az ADÓ az ablakba 0-át ír mikor elküld egy 0 sorszámú keretet, és amíg nem kap ezzel egyezõ nyugtát, újra küldi. Ha megjön a nyugta, akkor 1-et ír az ablakba, és várja a nyugtát. A VEVÕ csúszóablaka kezdetben 0-át tartalmaz, azaz 0 sorszámot vár. Ha ilyen keretet kap nyugtázza, és az ablakba 1-es (várt) sorszámot ír.

Ha a keretek átviteli ideje hosszú, például mûholdas átvitel esetén, akkor nem jó az a megoldás, hogy újabb keretet, csak az elõzõ nyugtázása után indítunk. A megoldás az, hogy az ADÓ nem 1 hanem k darab keretet küld el nyugtázás nélkül. Az n. keret elküldése után kezdi várni a nyugtákat és folytatni az k+1,... keretek küldését. Az ilyen esetben a csúszóablak mérete k kell hogy legyen. Ezt a megoldást csõvonal-nak (pipelining) hívják, utalva arra a szemléletes képre, hogy a keretek egy csõbe haladnak, sorban egymás után.

Mi van azonban akkor, ha egy keret a sorban megsérül? Két megközelítés ismert: az egyik a címben már megnevezett visszalépés n-el (go back n) protokoll. Ennél a módszernél a VEVÕ, a hibás keret utáni kereteket nyugtázatlanul eldobja, kényszerítve az ADÓ-t az ismétlésre. Ez a stratégia 1 méretû vételi ablaknak felel meg. Zajos vonalak esetén ez a megoldás nagymértékben csökkenti az adatátviteli sebességet a sok újraküldés miatt.

A másik, csõvonal esetén használható általános hibakezelési eljárást szelektív ismétlésnek (selective repeat) hívják, és mûködése már az elõzõek és az elnevezése alapján már kitalálható: ennél a hibás keretet követõ összes jó keret tárolásra kerül. Amikor az ADÓ felfedezi, hogy volt hibás keret (nem kap nyugtát róla), akkor csak a hibást küldi újra. Ennél a protokollnál, mind az ADÓ mind a VEVÕ fenntart ablakot, a keretsorszámoknak. Az ADÓ ablaka 0-tól sorszmax-ig növekszik. A VEVÕ ablaka rögzített méretû, a megfelelõ mûködés érdekében 1-nél nagyobb.

A következõkben néhány konkrét megoldást mutatunk be.

Ábrajegyzék

Bevezetés

1.fejezet: A hálózatok célja, alkalmazása, alapfogalmak

2.fejezet: Fizikai átviteli jellemzõk és módszerek

3.fejezet: Közeg-hozzáférési módszerek

4.fejezet: Adatkapcsolati protokollok: Keretek képzése, Hibakezelés, CCITT V.41-es ajánlása, IBM BISYNC, HDLC, Ellenõrzõ kérdések

5.fejezet: Hálózati réteg

6.fejezet: A felsõbb rétegek

7.fejezet: Lokális hálózatok

8.fejezet: A TCP/IP protokoll és az Internet

9. fejezet: Szótár

Irodalomjegyzék

Tárgymutató