A szállítási réteg az OSI modell 4. rétege. Az eddigi részekben megismerkedtünk a fizikai rétegekkel. A 4. rétegtől kezdve már olyan rétegekkel találkozunk, amelyek kialakítása nem veszi figyelembe a fizikai hálózatot. A szállítási réteg feladata, hogy megbízható adatátvitelt valósítson meg két hoszt között. Mint az előbb említettük, ezt úgy kell megoldani, hogy az független legyen a hálózat kialakításától.

Nagyon fontos a szállítási réteg, mivel ez biztosítja a kapcsolatot a hardver és a szoftver között. A felette elhelyezkedő rétegeknek szolgálatokat nyújt, amelyek által biztosítja azok működését. A szállítási rétegben elhelyezkedő munkavégző elemet szállítási funkcionális elemnek, vagy szállítási entitásnak (transport entity) nevezzük. Ezek lehetnek szoftveresek és/vagy hardveresek egyaránt. Ezen túlmutatva az entitások lehetnek az operációs kernelbe épített funkciók, önálló felhasználói funkciók vagy akár hálózati kártyák is.

A szállítási szolgálatokat két típusba sorolhatjuk, az egyik az összeköttetés alapú a másik pedig az összeköttetés mentes. Ha visszaemlékeznek a kedves olvasók, akkor a hálózati rétegnél is megkülönböztettük ezt a két csoportot. Az összeköttetés alapú hálózati szolgálathoz nagyon hasonlít az összeköttetés alapú szállítási szolgálat. Mindegyik esetében a kommunikáció három lépésből áll, a kapcsolat felépítéséből, az átvitelből és a kapcsolat bontásából. Ugyanilyen analógia vonható az összeköttetés mentes hálózati és szállítási szolgálatok között is. Ha ennyire hasonló a két szolgálattípus, akkor miért van szükség mindkét rétegre? A választ nem egyszerű megadni erre a kérdésre.

Vizsgáljuk meg egy nagy kiterjedésű hálózat működését. Ilyen esetekben a hálózattal kapcsolatos feladatokat a szolgáltató végzi el, abba a felhasználónak semmilyen befolyása sincs. Ilyen például a telefonvonalon keresztüli kapcsolat is. Abban az esetben, ha a hálózat fizikai kiépítése nem megfelelő, gyakran elveszhetnek csomagok, vagy felesleges csomagok lesznek a vonalon. Ugyanígy fennáll annak a lehetősége, hogy a kapcsolóelemek közötti vonal megszakad. Ezeknek a hibáknak a javítását nem lehet helyi szinten kiküszöbölni. A szolgáltatót viszont nem tudjuk minden esetben elérni. Hiába lenne szoftvert szinten megoldva a biztonságos átvitel, a fizikai hálózat ezeket a csomagokat ugyanúgy elronthatná. Ha viszont a hálózati réteg fölé elhelyezünk egy olyan rétegeket, amely a kommunikációs alhálózattól függetlenül képes lenne a kapcsolatokat felépíteni, lebontani és a biztonságos átvitelt megvalósítani, akkor azzal csökkenteni lehetne az alhálózat hibás működését, a beavatkozásokat egyszerűbben végre lehetne hajtani. Ezért van szükség a szállítási rétegre. Arra is lehetőség van, hogy a szállítási szolgálat sokkal megbízhatóbb legyen, mint a hálózati szolgálat.

A hálózati szolgálatokat, amelyek kihatással vannak a szállítási szolgálatok minőségére is, a minőségük alapján három csoportba sorolják:

  • A típusú hálózatok tökéletesek, mivel nincsenek elveszett-, kettőzött- vagy sérült csomagok. Ilyen esetben a szállítási protokoll az adatkapcsolati protokollhoz hasonló módon és feltételekkel működik. Ez a felépítés a helyi hálózatok esetében már gyakran (általában) megvalósul.
  • B típusú hálózatokban már előfordulnak hibás, vagy kettőzött csomagok. Előfordulhat csomagvesztés is, a hálózati rétegnek pedig bizonyos időközönként alaphelyzetbe kell állítania az alhálózatot. Ilyen esetekben a szállítási réteg feladata, hogy kitakarítsa az alhálózatot, újra létrehozza a kapcsolatokat, valamint lehetőleg onnan folytassa a kommunikációt, ahol az abbamarad. Amennyiben ez megvalósul, úgy az alkalmazói programok és ezzel együtt a felhasználók ebből semmit sem vesznek észre. Ez a felépítés a közepes és a nagy kiterjedésű hálózatokra jellemező. Általánosságban elmondható, hogy az ilyen típusú felépítés sokkal összetettebb szállítási protokollt igényel, mint az A típusú hálózatoknál.
  • C típusú hálózatok a legrosszabb minőségűek. Sok az elveszett vagy a kettőzött csomag, ezen kívül gyakran meg is sérülnek a blokkok. A hálózati rétegnek gyakran alaphelyzetbe kell állítania a hálózatot. Az átvitel folyamatossága érdekében nagyon bonyolult szállítási protokollt kell használni az ilyen hálózatokban. Ilyen típusúak a datagram szolgálatot nyújtó nagy kiterjedésű hálózatok.

A szállítási rétegre épülnek azok az alkalmazások, amelyeknek a szállítási réteg biztosít szolgálatokat. A rétegben lévő primitívek függetlenek a hálózati rétegtől. Így az alkalmazásokat egyszerűbben el lehet készíteni, azok függetlenné válnak a kommunikációs alhálózattól.

Szállítási szolgálati primitívek
A szállítási szolgálati primitívek teszik lehetővé, hogy folyamatok szállítási szolgálatokat érhessenek el. Minden szállítási szolgálat szállítási primitívekkel rendelkezik. A hálózati szolgálatokat csak a szállítási entitások használják, míg a szállítási primitíveket használják az alkalmazói programok. Egy egyszerű szállítási szolgálat primitívjeit mutatja az alábbi táblázat.

 
Szállítási primitív Elküldött adatelem Jelentése
LISTEN (nincs) Várakozik, amíg egy folyamat kapcsolódni nem próbál.
CONNECT CONNECTION REQUEST Megpróbálkozik az összeköttetés kialakításával.
SEND DATA Adattovábbítás.
RECEIVE (nincs) Várakozik, amíg adat nem érkezik.
DISCONNECT DISCONNECTION REQUEST Az ezt küldő oldal megpróbálkozik a kapcsolat bontásával.

Az adatátvitel ezeknek a felhasználásával történik. A működést nézzük meg egy példán keresztül:

A hálózatban lévő kiszolgáló (szerver) figyelő állásban van, tehát a LISTEN primitívet hajtja végre. Ez a szervert blokkolja, amíg a kliens nem kapcsolódik. Ha a kliensgép szeretne kapcsolódni a szerverhez, akkor egy CONNECT primitívet hajt végre. Ezt követi az adattovábbítás. Az információ továbbítás blokkonként történik, melyek elnevezésére az angol kifejezésből alkotott betűszót, a TPDU (Transport Protocol Data Unit, szállítási protokoll adatelem) használjuk. A TPDU-k a kapcsolat során először a hálózati rétegben csomagokba, majd az adatkapcsolati rétegben keretekbe szerveződnek. Egy ilyen adatcsoportot szemléltet a 73. ábra.


73. ábra. Az adatblokk felépítése

Amikor a kliens kapcsolódni szeretne a szerverhez, akkor egy CONNECTION REQUEST TPDU-t küld a szerver felé. Amikor ilyen blokk érkezett, a szállítási entitás meggyőződik arról, hogy a szerver figyelő állásban van-e, mivel csak így tudja a felmerülő igényeket kielégíteni. Amennyiben igen, úgy egy CONNECTION ACCEPTED adatblokkot küld a kliens számára. Ugyanebben az időben természetesen meg kell szüntetni a szerver blokkolását is. Ha az elfogadó csomagot megkapja a kliens feloldja a blokkolását és létrejön az összeköttetés. Az adatátvitelt a SEND és a RECEIVE primitív valósítja meg. A kapcsolat bontása már egy kicsivel bonyolultabb feladat, mivel lehet szimmetrikusan és aszimmetrikusan egyaránt.

Aszimmetrikus esetben bármelyik szállítási felhasználó kiad egy DISCONNECT REQUEST TPDU-t és ezzel megszüntetik a kapcsolódást. Az aszimmetrikus bontást olyan helyeken alkalmazzák, ahol bármikor előfordul, hogy az egyik fél bontani kívánja a vonalat, mivel nincs több mondanivalója. Mivel ez az esemény bármikor bekövetkezhet, esetenként előfordulhatnak adatvesztések. Ennek a kivédésére más, speciális bontási mechanizmusra van szükség. Erre lehet megoldás a szimmetrikus bontás.

Szimmetrikus esetben mindkét oldalt külön kell lebontani. Amikor az egyik kommunikációs állomás egy DISCONNECT primitívet küld a másiknak, azzal ezt jelzi, hogy nincs több elküldendő adata. A szétkapcsolódás csak akkor valósul meg, amikor mindkét állomás elküldi a DISCONNECT primitívet. Ez a megoldás nagyon jó olyan esetekben, amikor mindkét kommunikációs félnek rögzített darabszámú csomagja van. Az ilyen esetekben nem lehetnek váratlan események, mivel akkor a működés megbénul. Megoldás lehet a bontás kérésének nyugtázása. Ez is felvet sajnos egy problémát, mivel nem biztos, hogy a nyugta megérkezik. Ha ez bekövetkezik, akkor a rendszer működése szintén megbénulhat. A problémát a háromutas kézfogás alkalmazásával megfelelő módon lehet kezelni. Erről a módszerről még a későbbiekben részletesen fogunk írni.

A szállítási és az adatkapcsolati protokoll

A szállítási réteg működés szempontjából nagyon hasonlít az adatkapcsolati rétegre. Mindkettőnek meg kell oldania a hibakezelést, a sorszámozást és a forgalomszabályozást is. Természetesen ezeket a feladatokat más egységeken keresztül végzik el. Mindamellett természetesen van különbség is a két protokoll között, melyet a 74. ábra mutat.


74. ábra. A szállítási és az adatkapcsolati réteg közötti eltérés

Látható, hogy a hálózati rétegben a csomagok a fizikai vonalakon keresztül kerülnek továbbításra. A kapcsolatban IMP-ek vesznek részt. Ezzel szemben a szállítási réteg esetében az adattovábbítás már az alhálózaton keresztül zajlik, a résztvevő felek pedig a hosztok. A felépítésben lévő különbség kihatással van a két protokollra. Amikor az adatkapcsolati réteg kapcsolatot szeretne létesíteni, a kapcsolat felépítése egyszerű, mivel a másik végpontot nagyon könnyen meg tudja találni. Ezen a szinten minden egyes kimenő vonal egy kapcsolóelemet egyértelműen meghatároz. A szállítási rétegnek ennél sokkal bonyolultabb a feladata, mivel ezen a szinten a kommunikációs alhálózat az átviteli közeg.

A másik különbség, hogy ha az adatkapcsolati réteg elküld egy csomagot, akkor az vagy megérkezik, vagy elveszik. Ezzel szemben a szállítási szinten előfordulhat, hogy a kommunikációs alhálózat valamely részében tárolódik, majd egy pillanatban megjelenik. Ilyen tárolás a modell második szintjén nincsen.

A harmadik különbség az átmenetileg tárolandó adatok mennyiségében van. Az adatkapcsolati rétegnél, mint ahogy már azt az előző részekben megismertük, minden kimenő és bejövő vonalhoz átmeneti tárolók vannak hozzárendelve. Ezek száma természetesen korlátozott. A szállítási réteg esetében sokkal nagyobb mennyiségű adat átmeneti tárolására van szükség, mivel ezen a szinten az összeköttetések száma nagy, amelyhez kellően nagyszámú puffert lefoglalni az általában szűkös erőforrások miatt nem túl jó ötlet.

Amikor már felépült a kapcsolat, meg kell oldanunk, hogy az eltérő sebességű hosztok képesek legyenek egymással kommunikálni. Ez a probléma hasonló az adatkapcsolati réteg esetében megismertekkel, a megoldás is nagyon hasonlít hozzá. Általában a csúszóablakos protokollt használják, de természetesen más eljárás is elképzelhető. Van egy nagyon fontos különbség a két réteg között, mégpedig az, hogy egy kapcsolóelem viszonylag kevés kapcsolódási ponttal rendelkezik, míg a hosztok esetében ezek száma jóval nagyobb. Ebből kifolyólag a vonalak pufferelése ebben a rétegben meglehetősen gazdaságtalan lenne, túlságosan nagy lenne az erőforrásigénye.

Az adatkapcsolati rétegnek minden kimenő csatornát pufferelnie kell, mivel előfordulhat, hogy azt újra kell küldenie. Hasonló a helyzet datagram szolgálat esetén is. Ilyen esetekben nem szükséges a bemeneti vonalakat a szállítási rétegnek pufferelnie, a szabad tárolókat dinamikusan kioszthatja azokra a csatornákra, amelyeknek mégis szükségük van erre.

Amennyiben a hálózati szolgálat megbízhatatlan, akkor a szállítási rétegnek természetesen ugyanúgy pufferelnie kell, mint az adatkapcsolati rétegnek. Amennyiben a vevőnek biztosan van szabad puffere, vagyis minden bemenő csomagot elfogad, akkor az adnak nem szükséges fenntartania puffereket a TPDU-k tárolására.

A szállítási protokoll címzési rendszere

Mind az összeköttetés alapú, mind az összeköttetés mentes szolgálat esetében az adattovábbítás során ki kell jelölni a célállomást. Mint az esetek többségében, itt is címzési rendszert használunk. Ezeken a szállítási címeken tudják a folyamatok az összeköttetés kéréseket figyelni. A szállítási rétegben a TSAP (Transport Service Access Point, szállítási szolgálat elérési pont) elnevezést használják általánosságban a szállítási címekhez. Ezen módszer alapján a hálózati rétegben lévő címek azonosítására a NSAP (Network Service Access Point, hálózati szolgálat elérési pont) kifejezést használhatjuk. Ezek a konkrét protokollok esetében más néven szerepelnek, de a funkciójuk ugyanez.

A következő ábra mutatja egy összeköttetés alapú hálózatban folyó adattovábbítás folyamatát, ahol feltüntettünk a különböző rétegeket is.
 


75. ábra. Egy összeköttetés alapú hálózat működése

Bizonyos hálózatok megengedik a többszörös szállítási és/vagy többszörös hálózati címek használatát is. Amikor egy folyamat kapcsolódni kíván egy másik hoszthoz, akkor az alatta lévő TSAP-n keresztül a második hoszt TSAP címére elküld egy kérést, amelyben a kapcsolódást kezdeményezi (CONNECT). Ha a kapcsolódás lehetséges, akkor az első hoszt szállítási entitása létrehoz a hálózati címek között egy hálózati összeköttetést. Ezen a kapcsolaton keresztül az első hoszt kéri a kapcsolat létrehozását a saját és a szomszéd TSAP-ja között. A második hoszt leellenőrzi, hogy az a folyamat, amely a megszólított TSAP-hez kapcsolódik, alkalmas-e a kérés kiszolgálásra. Amennyiben igen, akkor létrejön a szállítási kapcsolat is. Ebből is látható, hogy a szállítási kapcsolat két TSAP között jön létre, míg a hálózati kapcsolat ennek csak egy része és az egyik hoszt NSAP-jétől a másik NSAP-jéig tart.

Az olvasóban felmerülhet a kérdés, hogy honnan tudják a hosztok, hogy a kívánt szolgáltató melyik TSAP-n található? Vannak olyan folyamatok, amelyek mindig ugyanazon a TSAP ponton kapcsolódnak az alsóbb rétegekhez. Ezeknek a címe ismert, tehát a folyamatokat erre fel lehet készíteni. Ez a megoldás nagyon jól működik egészen addig, amíg viszonylag kis, de állandó számú folyamatot kell kiszolgálni. Amennyiben a folyamatok dinamikusan változnak, akkor ez a módszer nem megvalósítható.

A fix (statikus) címeknél jobb módszer az, ha a TSAP-kat dinamikusan kezeljük. Egyik ilyen megoldás a kezdeti összeköttetést létesítő protokoll (Initial Connection Protocol), amelyet a Unix rendserekben használnak. Ebben a megoldásban minden gépen, amely szolgáltatásokat kínál a távoli felhasználók részére, egy folyamatszolgáltatót (process server) futtat Ez figyeli a kéréseket. Amennyiben egy felhasználónak nincs igénye, úgy az a folyamatszolgáltatóval kerül kapcsolatba. Amennyiben a folyamatszolgáltató kap egy kérés, úgy létrehozza a kívánt kiszolgálót, majd felépíti a kapcsolatot a felhasználó és a kiszolgáló között. Ezután a folyamatkiszolgáló ismételten a kérésekre várakozik.

Ez a megoldás sem tökéletes, ugyanis nem működik olyan esetekben, amikor a szolgáltatások a folyamatszervertől függetlenül működnek. Ilyenkor nem lehet a szolgáltatásokat akkor létrehozni, amikor az igény felmerül rájuk. Ezekben az esetekben a kiszolgálónak egy névkiszolgálót (name server) vagy katalógusszolgáltatót (directory server) speciális folyamatot kell működtetnie. Amikor egy felhasználó valamely szolgáltatást szeretne használni, akkor felveszi a kapcsolatot a névszolgáltatóval. Elküldi neki a használni kívánt szolgáltatás nevét, amire válaszul a névszolgáltató visszaküldi, hogy az melyik TSAP címen érhető el. Ezután a névszolgáltatóval bontja a kapcsolatot, majd felépíti a kívánt szolgáltatással. Természetesen a névszolgáltatónak ismerni kell a TSAP címét, aminek állandónak kell lennie.

Ismét felmerül egy kérdés, nevezetesen az, hogy honnan tudja a felhasználó, hogy a kapott TSAP cím melyik hoszton található? Ahhoz, hogy a kapcsolat létrejöjjön, a hálózati entitásnak tudnia kell, hogy az adott TSAP cím melyik NSAP címen keresztül érhető el. Ennek a problémának az áthidalására a TSAP cím felépítése adja a megoldást. A címrendszert hierarchikusan alakítják ki. Az ilyen cím mezők sorozatából áll, amelyek a címtartományt részekre osztják. A TSAP cím megadható az alábbi módon:

cím = <ország><hálózat><hoszt><port>

Így bármelyik cím megtalálható az egész Földön. Van egy másik módszer is, amivel ki lehet hagyni a hierarchikus címek használatát. Ebben az esetben egyszerű címeket (flat address) használunk. Kell lennie egy olyan szolgáltatásnak, amely egy TSAP cím vételekor egy NSAP címet ad válaszul. Ezzel a módszerrel is megtalálható bármely TSAP.

Összeköttetés létesítése

Amennyire egyszerűnek tűnik egy összeköttetés létesítése, annyira bonyolultan zajlik le a gyakorlatban. Ha az alhálózat tökéletes lenne, akkor elegendő lenne két primitív használata erre Aa célra. A forrás elküldene egy CONNECTION REQUEST primitívet, majd válaszul várna egy CONNECTION ACCEPT primitívet. A probléma az, hogy tökéletes hálózatok nincsenek, mivel előfordulhatnak elveszett, kettőzött, vagy tárolt csomagok is. Ilyen esetekben ez természetesen gátat szab az előbbi módszernek. Nagyon fontos a kapcsolatok biztonságos felépítése.

A problémák alapvető oka a csomagok késleltetéséből adódó kettőződések. Az egyik legegyszerűbb módszer, amikor a szállítási címek egyediek. Amennyiben egy szállítási címre van szükség, mindig újat hozunk létre. A kapcsolat lebontása után a régi címet eldobjuk. Ez a kezdeti összeköttetést létrehozó protokoll működését megbénítja.

A megoldás az lehet, amikor nem engedjük, hogy a csomagok örök életűek legyenek, vagyis korlátozzuk azok élettartamát. Olyan megoldást kell alkalmaznunk, amely összegyűjti a régi és kettőzött csomagokat, majd eltávolítja ezeket az alhálózatból. Természetesen a működőképesség érdekében garantálni kell, hogy egyik csomag se lehessen egy bizonyos kornál öregebb. Ezt az alábbi módszerek alkalmazásával biztosítható:

  • Csomópontátlépés számlálót építünk be a csomagokba, amelynek értéke minden csomópontátlépés során eggyel növekszik. Amikor elér egy megadott értéket, akkor a csomag élettartama lejárt, tehát el kell dobni. Akkor lehet ezt hatékonyan alkalmazni, ha hálózattervezéssel biztosítjuk, hogy a csomagok ne kerülhessenek hurokba, illetve a leghosszabb késleltetésű útvonalakon korlátozza a késleltetést.
  • Csomaglétrehozásának időpontját tároljuk a csomagban. Minden csomagot vevő IMP leellenőrzi ezt a dátumot. Amennyiben a csomag öreg, akkor az IMP eldobja azt. Ennek a megoldásnak a nehézsége, hogy a megfelelő működés érdekében a csomópontokban lévő órákat szinkronizálni kell. Ez a művelet nagy kiterjedésű hálózatokban legalább olyan nehéz feladat, mint a csomagok kezelése.
  • Háromutas kézfogást Tomlison vezette be a hálózatok kialakításába. Ennél a módszernél az adó és a vevő más-más sorszámmal kezdi meg az adását,így a szinkronizálás a globális időtől eltérően is megvalósítható. A megoldás működését szemlélteti a 76. ábra.

76. ábra. A háromutas kézfogás vázlatos működése

Az első hoszt kezdeményezi az átvitelt, amely során kiválaszt egy véletlen sorszámot, amelyet jelöljünk "x"-szel. A 2. hosztnak elküld egy CONNECTION REQUEST primitívet. Amennyiben az képes a kérést fogadni, a visszaküld egy CONNECTION ACCEPTED TPDU-t. Amikor ezt elküldi, nyugtázza "x"-et, majd elküldi a saját sorszámát, amely legyen "y". A kapcsolat felépítésének utolsó fázisában az 1. hoszt nyugtázza "y"-lont, amelyet az első általa küldött adatblokkban tesz meg.

Kissé más a helyzet, amikor késleltetett kettőzött TPDU-k vannak a hálózatban. Ilyen helyzet látható a 77. ábrán.
 


77. ábra. A háromutas kézfogás működése késleltetett kettőzött TPDU-k esetén

A legelső TPDU egy előző kérés felbukkanó CONNECTION REQUEST primitívje. Ennek megérkezéséről természetesen az 1. hoszt mit sem tud, mivel már régen küldte el. Erre a 2. hoszt a kérés elfogadásával válaszol, de ezt kiegészíti egy kéréssel, amelyben arra kér megerősítést, hogy az 1. hoszt tényleg összeköttetést akar-e létesíteni. Ha ezt az 1. hoszt elutasítja (ami valószínű, hiszen kapcsolódási igény már elmúlt vagy már lezárult), akkor abból tudni fogja a 2. hoszt, hogy kettőzött kérésről volt szó és felhagy a további kapcsolódási szándékkal.

Van még ennél is rosszabb eset, amelyre szintén megoldást nyújt ennek a módszernek az alkalmazása. A felépítését az ilyen rendszernek a 78. ábrán vehetjük szemügyre.
 


78. ábra. A háromutas kézfogás működése kettőzött adat TPDU és kettőzött kapcsolódás kérés TPDU esetén

Ebben az esetben nem csak egy kapcsolódás kérés, hanem annak nyugtája is eltévedt a hálózatban, ami jelentős kését okoz. A folyamat itt is úgy kezdődik, mint az előző esetben, tehát a 2. hoszt kap egy kapcsolódási kérést. Erre nyugtát küld a másik hosztnak. Ha szemügyre veszik az ábrát, akkor észrevehetik, hogy a 2. hoszt saját sorszáma "y". A bejövő nyugtában (aminek "y"-ra kellene vonatkoznia) "z" szerepel. Ebből rögtön tudja a 2. hoszt, hogy nem a saját kérésére érkezett nyugta, hanem ismételten késleltetett csomagot kapott.

A fentiekben látható, hogy ez a módszer nagyon rugalmasan képes a különböző helyzeteket lekezelni.

Ha egy csomagot eldobunk, akkor annak esetleges nyugtáit is el kell távolítani az alhálózatból. Ennek érdekében be kell vezetni egy időváltozót, amely a valóságos csomagélettartam néhányszorosa. A szorzószám értéke protokoll függő, de a szerepe közös: a késleltetési idő értékének növelése. A csomag elküldésekor ennek az időnek a kivárása után a csomagot már biztosan eltávolította az egyik csomópont, tehát nyugtákat sem kell várni erre a csomagra.

Összeomlás utáni helyreállítás

A működés során előfordulhat olyan eset, amikor a rendszer egy részében, vagy a teljes hálózatban megbénul a forgalom. Ilyenkor gyakorlatilag összeomlik a hálózat, amelyet valamilyen szinten meg kell akadályozni, vagy ha bekövetkezik, akkor újra kell indítani a rendszert és kijavítani a hibát.

Amennyiben a teljes szállítási entitás a hoszton belül kerül kialakításra, akkor a helyzet egyszerűbb, azt hoszt szinten kell megoldani. Általános követelmény, ha egy rendszer összeomlik, akkor annak felélesztése után ugyanonnan lehessen folytatni a munkát, ahol az abbamaradt. Ha egy rendszerben adatküldés során újraindulás következik be egy esetleges leállás után, akkor nem tudja, hogy a küldésben éppen hol tartott. Erre jó megoldás lehet, ha az újraindult állomás elküld egy olyan TPDU-t, amelyben közli, hogy tönkrement és mindenkitől azt kéri, hogy küldje el a megszakadt összeköttetések állapotát.

Amennyiben a hálózati réteg datagram szolgáltatást nyújt, akkor a szállítási entitásnak minden esetben számolnia kell elveszett csomagokkal, ezek kezeléséről gondoskodniuk kell.

A hibakezelésnek ez a módozata meglehetősen speciális. A cikksorozat későbbi részeiben még visszatérünk, amikor már konkrét protokollokat vizsgálunk meg (például a TCP/IP protokoll esetében).

Ezzel a szállítási réteg ismertetését befejeztük, amelyre a későbbiekben még vissza fogunk térni. A következő részben megismerkedünk a felsőbb rétegek működésével.