November 21, 2024

A Kliens – Szerver szerkezet

A számítógépek közötti adatcsere leginkább egy beszélgetésre hasonlít. Az egyik gép kérdez (kliens – a szolgáltatást igénylő gép), majd a mások gép válaszol (szerver – szolgáltatási kérést kiszolgáló gép). Mint minden párbeszédnek, ennek is megvannak a maga szabályai. A Linux az ARPA modell felépítését használja a kommunikáció lebonyolításához. Az adatok az ARPA verem szintjein le és fel haladva jutnak az egyik gépből a másikba.

A beszélgetést a kliens gép alkalmazási rétege kezdeményezi. Az adat először lefelé halad a kliens gép rétegei között, majd a legalsó szinten megtörténik a fizikai adatátvitel a két gép között. Végül a szerver gépen az adatok a rétegeken felfelé haladva eljutnak a kiszolgáló alkalmazásig, amelyik a kérdést értelmezve elkészíti a válasz, majd ugyanazon az útvonalon, amelyen a kérdés érkezett elindítja visszafelé. A válasz először a szerver gép alkalmazási rétegéből elindul lefelé a verem rétegein keresztül, majd a legalsó rétegen keresztül megtörténik a fizikai adatátvitel a kliens gép fel. A kliens gépen, a legalsó rétegen keresztül felfelé haladva eljut a válasz a kliens gép alkalmazási rétegébe, ahol megkapja a kérdést feltevő alkalmazás.

Az, hogy a kérdés és a válasz milyen típusú és milyen méretű, mindig az alkalmazásoktól függ. Minden egyes alkalmazás csak a neki megfelelő alkalmazással beszél (pl. a WWW böngésző a Web-szerverrel, a levelező kliens viszont a levelező szerverrel).

Az adatok útja a kliens-szerver kapcsolatban
29. ábra Az adatok útja a kliens-szerver kapcsolatban

A szerverek osztályozása

Több osztályozási kritérium is létezik, ezek közül az egyik a szerver és a kliens közötti kapcsolat időtartama. Ez alapján két alapvető szerver-típust különböztetünk meg:

iteratív szerverek ebben az esetben a szerver maga kezeli le a kapcsolattartást. ez azt feltételezi, hogy a kérés időtartalma s a kérés kiszolgálására szolgáló erőforrások megfelelően kicsik legyenek, mint például az időszolgáltatás esetében.

konkurens szerverek azok a szolgáltatók, amelyek esetében a kérés számára szükséges erőforrásokat maga a kérés határozza meg. Ilyen például a nyomtatószerver, a hálózati fájlrendszer, az adatbázisszerverek. Ezek a szerverek, miután fogadták a kérést, egy újabb folyamatot indítanak el, amely kiszolgálja a kérést és eközben a szerver maga újból várakozó állapotba mehet át, az újabb beérkező kérésekre várva.

Egy másik lehetséges kritérium az az információ-mennyiség, amely a szerver rendelkezésére áll a kliensről. E kritérium alapján is két alapvető típust különböztethetünk meg:

stateful ez a szervertípus a kliensekről folyamatosan információkat tárol, tehát tudja, hogy helyesen működnek-e, vagy nem

stateless ez a típus nem tárol információkat a klienseiről

Végül a harmadik lehetséges kritérium a használt kapcsolattípus, amely szerint szintén két fő szerver-csoportot ismerünk:

kapcsolat orientált ez a szervertípus tipikusan azt feltételezi, hogy a kliens és a szerver fizikailag egymástól távol vannak és/vagy nagy megbízhatóságra van szükség és emiatt egy speciális kommunikációs csatornát tartanak fenn.

kapcsolat nélküli ez tipikusan a helyi hálózatokban működő szerverek esete, ilyen például az NFS és NIS szolgáltatás

A továbbiakban néhány alapvető szervertípust mutatunk be.

Konkurrens szerverek

Minden, amit itt leírunk pillanatnyilag csak UNIX/LINUX típusú operációs rendszereken érvényes. Más operációs rendszerek is rendelkeznek hasonló mechanizmusokkal. Ezek leírását az illető operációs rendszer kézikönyvében remélhetőleg meg lehet találni.

Amint fentebb már volt szó róla, a konkurens szerver a kérés beérkezésének pillanatában a kérés végrehajtását átadja egy külön folyamatnak és a szerver maga visszakerül a várakozó állapotába, újabb kérésekre várva. Ez tipikus Unix mechanizmus, az operációs rendszer alapszolgáltatásait használja. Ezek közül a fork() eljárás teszi lehetővé az új folyamatok elindítását. Ennek a rendszerhívásnak a segítségével egy kérés beérkeztekor a szerver még egy példányban elindítja magát. Ez a másodpéldány fogja kiszolgálni a beérkezett kérést. A kérés kiszolgálása után ez a folyamat lezárja saját magát. Ez az alapmechanizmus teszi lehetővé, hogy mindig legyen egy szerver-folyamat, amely a beérkező kéréseket figyeli. Természetesen a valós implementációkban a helyzet egy kissé bonyolultabb, de az alapelv ugyanez.

Stateful szerver

Egy konkrét példája ennek a szervertípusnak az az eset, amikor egy nagyobb fájlból olvasunk be adatokat. A két alapvető kliens kéréstípus a megnyitás és az olvasás. A kliens olvasásra való megnyitást kér, válaszul egy leírót kap, ami a fájl legfontosabb jellemzőit tartalmazza. Majd újabb kéréseket küld a szervernek. A szerver meg kell jegyezze, hogy ki, milyen jogosultságokkal és milyen típusú műveletre kért hozzáférést a fájlhoz, és pontosan az állomány mely részére vonatkozik a kérés, és figyelnie kell, hogy a kliens helyesen működik-e, ha pedig nem, akkor a kapcsolatot egyoldalúan le kell zárnia.

Stateless szerver

Az előbbi szerver párja az a szolgáltatás, amely csak az adatok megjelenítését teszi lehetővé, tehát nincs megnyitási kérés, a kliens csak olvasási parancsokat adhat és neki kell nyilvántartania ka kapcsolat minden fontos adatát.

Melyik a jobb?

A helyes válasz az, hogy attól függ… Például hálózati hiba esetén a stateless szerver van előnyben, neki nem kell foglalkozzon a felmerülő problémák kezelésével, ez a kliens dolga. A kliens szempontjából a helyzet pontosan fordított. Más helyzetek is elképzelhetőek, a gyakorlat viszont azt mutatja, hogy minden konkrét esetben egyedileg mérlegelni kell, melyik megoldás az előnyösebb. Nincs előre meghatározott, általánosan alkalmazható recept.