Ellenőrző kérdések a Viszony szintű átvitel témaköréből

A VIK Wikiből
(SzgHaloVizsgaViszony szócikkből átirányítva)
Ugrás a navigációhoz Ugrás a kereséshez

Ez az oldal a korábbi SCH wiki-ről lett áthozva. Az eredeti változata itt érhető el.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor kérlek javíts rajta egy rövid szerkesztéssel.

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót


Előző: SzgHaloVizsgaSzallitas Következő: SzgHaloVizsgaMegjelen


1. Mi a viszony réteg célja, feladata, szolgáltatásai?

A felhasználói adatforgalom szervezését végzi, feladata a hálózat bonyolultságának elfedése, hálózat esetleges kiesésekor gondoskodik az újraindulásról - folytonos kapcsolatot biztosít.
Szolgáltatásai:

  • dialóguskezelés félduplex hozzáférés, pl. egy adatbázishoz
  • szinkronizáció: nagyméretű adathalmaz esetén, szakaszosan ellenőrzést hajt végre, ezáltal hiba esetén a felesleges ismétlésektől megkíméli a hálózatot.


2. Miért van szükség dialógus kezelésre? Hogyan valósítható meg e szolgáltatás?

Lehetőséget ad arra, hogy magas szinten kezeljük, valamely erőforráshoz éppen ki férhet hozzá. Pl. az adatbázis-hozzáférést a viszony-FE egy token átadásával engedélyezheti (miután a távoli folyamat végzett a használattal, visszaadja a tokent). Ezt, mint szolgáltatást kívülről a megfelelő primitívek alkalmazásával lehet igénybe venni.

-Ron

3. Miért van szükség szinkronizációs pontok elhelyezésére? Hogyan valósítható meg e szolgáltatás?

Nagy mennyiségű adat küldésekor hiba esetén nem kell az egészet újra átvinni, hanem csak a legutóbbi szinkronizációs pont óta küldött részt. (Példa: vegyük ezt az esetet: Sok adatot gyorsan áttolunk, viszont a nyugta késéssel érkezik csak. Ha már az első csomag negatív nyugtát kap, és nem szelektív ismétléses, hanem mondjuk go-back-n jellegű az ARQ, küldhetjük újra az egészet. Egy szinkronizációs pont mondjuk bevárhatná a nyugtákat). (Gondoljunk az adatkapcsolati réteg aktualizálási folyamatára, ott is valami ilyesmiről volt szó)

-Ron

-- adamo - 2005.12.27.