3. Ismertebb socket-ek és az alkalmazási réteg

Az eddigiekben azt vettük sorra, hogy egy üzenet hogyan darabolódik szét, hogyan jut el egy géptől egy másikig, majd ott hogyan áll ismét össze. Mindez még kevés ahhoz, hogy hasznos dolgot lehessen végezni. Szükség van valamilyen módszerre, amelynek segítségével egy másik számítógéppel kapcsolatba lehet lépni, oda be lehet jelentkezni, közölni lehet vele, hogy milyen adatokra van szükségünk, illetve amellyel az adatok átvitelét szabályozni tudjuk. (Más alkalmazás, pl. elektronikus levelezés, esetén is ezzel analóg protokollra van szükség.) Ezt a feladatot az alkalmazási réteg protokolljai végzik el, amelyek a TCP/IP tetején találhatóak. Ez annyit jelent, hogy üzenet küldésekor azt a TCP-nek továbbítják, amely gondoskodik róla, hogy eljusson a célállomáshoz. Mivel a TCP és az IP kezelik a hálózati vonatkozásokat, ezért az alkalmazási protokollok a hálózatot egyszerű byte-folyamnak tekintik, mint például egy terminál- vagy telefonvonalat.

Mielőtt az alkalmazói programokkal kapcsolatban további részletekbe bocsátkoznánk, meg kell vizsgálnunk, hogy hogyan lehet egy alkalmazást megtalálni. Tegyük fel, hogy egy állományt szeretnénk küldeni a hálózaton keresztül a 124.6.4.7 IP című gépnek. A folyamat elindításához azonban az Internet címnél többre lesz szükség. A célállomás oldalán az FTP kiszolgálóval fel kell venni a kapcsolatot. A hálózati programokat általában külön feladatok elvégzésére programozzák. A különböző feladatokat (állományátvitel, bejelentkezés távoli terminálról, levelezés stb...) a legtöbb rendszerben más-más programok végzik. Amikor a fenti példában a 124.6.4.7 című géppel kapcsolatot építünk ki, akkor azt is meg kell mondanunk, hogy az ottani FTP kiszolgálóval szeretnénk kommunikálni. Ennek megvalósítására minden kiszolgáló jól ismert socket-ekkel ( foglalatok, szolgálatelérési pontok) rendelkezik. Ennek magyarázataképpen tekintsük a következőket. Emlékezzünk vissza, hogy a TCP a különböző kommunikációk kézben tartására különböző portokat használ. A felhasználói programok többé-kevésbé véletlenszerűen választanak portot, de egyes portok eleve olyan programoknak felelnek meg, amelyek valamilyen kérés kiszolgálására várnak (ezek lennének a kiszolgálók). Állományátvitel esetén például egy "ftp" nevű programot indítunk el, amely a kapcsolat felépítéséhez a saját oldalán véletlenszerűen kijelöl egy portot, mondjuk az 1234-t. A céloldalon viszont a 21-es portot jelöli meg, amely az FTP kiszolgáló hivatalos portjának felel meg. Vegyük észre, hogy itt két különböző programról van szó. Az egyik az "ftp", amelyet a küldő oldalon indítottunk el, és amely a terminálról kapott parancsokat továbbítja a másik oldalhoz; a célállomáson lévő gépen viszont az FTP kiszolgálóhoz beszélünk. Ezt arra találták ki, hogy a hálózatról parancsokat fogadjon, nem úgy mint egy interaktív terminál. Semmi szükség arra, hogy az "ftp" program jól ismert socket-et használjon. A kiszolgálókkal teljesen más az eset, hiszen a kapcsolatokban parancsokat kell tudniuk fogadni. A hivatalos portok és a hozzájuk rendelt számok az RFC 997-től kezdve az "Internet Numbers" (Internet Számok) RFC dokumentumban olvashatók (az írás pillanatában a legutóbbi az RFC 1162). Ez a dokumentum régebben az "Assigned Numbers" (Kiosztott Számok) nevet viselte.

A fentiek után nyilvánvaló, hogy egy kapcsolatot négy szám jellemez: a két Internet cím, és a két TCP port száma. Ez a négy szám minden egyes datagrammban megtalálható. (Az Internet címek az IP fejlécben, a TCP portok száma pedig a TCP fejlécben van.) Az egyediség megkövetelése miatt semelyik két kapcsolat esetén sem lehet ugyanaz mind a négy szám. Ugyanakkor elég, ha csak egy szám tér el a másik négytől. Semmi nem tiltja például azt, hogy ugyanazon a gépen lévő két különböző felhasználó állományokat vigyen át ugyanarra a távoli gépre. Ennek a megvalósítása például az alábbi paraméterekkel lehetséges:

                   Internet cím             TCP port száma
        1. kapcsolat    128.6.4.194, 128.6.4.7  1234, 21
        2. kapcsolat    128.6.4.194, 128.6.4.7  1235, 21

Mivel ugyanazokról a gépekről van szó, az Internet címek ugyanazok. Továbbá, mivel mind a két kapcsolatban állományátvitelről van szó, ezért a kapcsolatok egyik végén az FTP port jól ismert száma (21) található. Az egyetlen dolog, ami különbözik: a felhasználók által futtatott programok portszáma. Ez tökéletesen elegendő. A kapcsolatok felépítésében az az általános gyakorlat, hogy legalább az egyik oldal utasítja a hálózati szoftvert arra, hogy számára egyedi port-ot allokáljon. A legtöbb esetben ezt a felhasználó felőli oldal teszi meg, mivel a kiszolgálónak egy mindenki által jól ismert számot kell használnia.

Most, hogy már tudjuk hogyan kell kapcsolatot felépíteni, menjünk vissza az alkalmazói programokhoz. Ahogy már fentebb említettük: miután a TCP megnyitott egy kapcsolatot, rendelkezésünkre áll egy vonal, ami akár egy egyszerű drót is lehetne. A feladat rázós részeit a TCP és az IP kezelik. Ez persze még nem elég, ugyanis tudnunk kell, hogy mit küldhetünk át a vonalon. Valójában ez nem más mint a küldhető parancsok és azok formátumának leírása. Az átküldött rész lényegében adatok és parancsok egyvelege, amiket a szövegkörnyezet különböztet meg egymástól. Például a levelezést megvalósító protokoll működése az alábbi: a felhasználói oldal levelező programja kapcsolatot épít fel a célállomás levelezést kiszolgáló programjával. A küldő program megadja a forrásgép nevét, a küldő címét és a címzetteket. Ezek után egy parancsot küld, amelyben arról tájékoztat, hogy az üzenet szövege következik. Ettől a ponttól a kiszolgáló az adatokat nem parancsokként, hanem üzenetként értelmezi mindaddig, amíg egy speciális, az üzenet végét jelentő jellel (egy egyedül álló pont a sor elején) nem találkozik. Ez után a két oldal ismét parancsokkal kommunikál. Ez a legegyszerűbb módja az üzenetek küldésének, és a legtöbb alkalmazás így is működik.

Az állományok átvitele ennél valamivel bonyolultabb. Átvitel esetén két különböző kapcsolat épül fel. Az elején minden úgy megy mint a levelezéskor. A felhasználó programja olyan parancsokat küld, mint "jelentkeztess be ilyen és ilyen felhasználóként", "ez a jelszóm", "küldd el ezt és ezt az állományt". Miután az adatkérésre a parancs elment, a tényleges adatok átvitelére egy második kapcsolat épül fel. Persze ezt meg lehetne oldani ugyanazon az egy kapcsolaton keresztül is, ahogy a levelezés teszi. Az ok, amiért ez mégsem így történik, abban rejlik, hogy az állományátvitel általában hosszú ideig tarthat. A tervezéskor úgy érezték, hogy jobb a felhasználónak meghagyni a menet közbeni parancskiadás lehetőségét (például megszakításhoz stb... Lehetséges az is, hogy két különböző géphez nyissunk meg kapcsolatot, és egy állományt az egyiktől a másikhoz küldjünk. Ebben az esetben az adatok nem keveredhetnek a parancsokkal.)

A távoli terminálhívások egy harmadik módszert használnak. A távoli bejelentkezéskor csupán egy kapcsolat épül fel. Normális esetben ezen csak adatok mennek keresztül. Amennyiben parancsot akarunk kiadni (pl. a terminál típusának a beállítására, vagy valamilyen üzemmód átállítására), akkor egy speciális karaktert kell küldeni, amely jelzi, hogy a következő karakter parancs. Ha ezt a speciális karaktert adatként akarjuk küldeni, akkor kettőt kell egymás után kiadni.

Ebben az ismertetőben az alkalmazási protokollokról részletesen nem szólunk. Ehelyett javasolható a megfelelő RFC dokumentumok tanulmányozása. Az alkalmazások viszont egy sor olyan konvención alapulnak, amelyeket érdemes részletesen érinteni. Az első ilyen a közös hálózati reprezentáció: a TCP/IP-t úgy tervezték, hogy minden számítógépen alkalmazható legyen. Sajnos nem minden számítógép tárolja ugyanúgy az adatokat. A karakterek (ASCII vs. EBCDIC), a sorvég-jelek kódolásában (kocsi-vissza, soremelés), és abban, hogy a terminálok a karaktereket egyenként vagy soronként küldjék, mind különbségek mutatkoznak. A különbözőképpen működő számítógépek kommunikációjának elősegítése miatt minden egyes alkalmazói protokoll szabványos reprezentációkat definiál. A TCP és az IP azonban nem törődik a reprezentációval: a TCP egyszerűen csak okteteket küld. Az oktetek értelmezését persze mind a két oldalnak ugyanúgy kell végeznie. Az alkalmazásokat leíró RFC dokumentumok minden egyes esetben az adott alkalmazás szabványos reprezentációját definiálják. Ez a legtöbbször "tiszta ASCII" formátumnak felel meg: ASCII karakterek használata, sorvég-jelként kocsi-vissza utáni soremeléssel. A távoli bejelentkezés definiál egy "szabványos terminált" is, amely egy visszhangos, félduplex működésű terminál. A legtöbb alkalmazásban azonban arra is lehetőség van, hogy két számítógép számukra megfelelőbb reprezentációban állapodjon meg. Például a PDP-10 számítógépekben egy szó 36 bites. Két ilyen gép között lehetséges 36 bites bináris állományok átvitele. Hasonlóan, ha két rendszer inkább teljes duplex kommunikációt preferál, akkor megegyezhetnek annak használatában. Azonban mindezektől függetlenül minden egyes alkalmazásnak van egy szabványos reprezentációja, amelyet minden gépnek támogatnia kell.


3.1 Egy példa az alkalmazásokra: SMTP

Az alkalmazói protokollok szerkezetének jobb átlátása végett álljon itt az SMTP (Simple Mail Transfer Protocol -- egyszerű levéltovábbítási protokoll), azaz a levelezést megvalósító protokoll egy példája. Tegyük fel, hogy a TOPAZ.RUTGERS.EDU nevű számítógép szeretné az alábbi üzenetet elküldeni.

 Date: Sat, 27 Jun 87 13:26:31 EDT
        From: hedrick@topaz.rutgers.edu
        To: levy@red.rutgers.edu
        Subject: meeting

        Let's get together Monday at 1pm.

Az üzenet formátumát egy Internet szabvány (RFC 822) írja le. A szabványban megfogalmazódik, hogy az üzenetet ASCII karakterekként kell továbbítani. Az üzenet szerkezetének az alábbiak szerint kell kinéznie: fejléc sorok, aztán egy üres sor, majd az üzenet szövege következik. Végül a fejléc sorok szintaxisát definiálja részletesen: általában egy kulcsszó, majd egy érték.

A fenti üzenet címzettje LEVY@RED.RUTGERS.EDU. Kezdetben ez úgy nézett ki, hogy csak a címzett nevét és a gépet írták bele: "személy és gép". A szabványok fejlődése azonban ezt sokkal rugalmasabbá tette. Ma már más rendszerek üzeneteinek a kezelésére is vannak előírások (ami persze "magától értetődő"). Ezzel lehetővé válik az Internetbe be nem kapcsolt gépek miatti automatikus átirányítás (forwarding): például az üzenetek egy sor rendszer számára egy központi (mail server) géphez kerülnek. Egyáltalán nem szükséges tehát, hogy létezzen a RED.RUTGERS.EDU névvel jelölt számítógép. A névkiszolgálókat úgy is be lehet állítani, hogy az üzenetek címzettet jelentő mezőjébe tanszékeket írunk, és minden egyes tanszék üzeneteit egy megfelelő számítógéphez irányítjuk. Az is lehetséges, hogy a @ jel előtti részbe ne egy felhasználónak a nevét írjuk, hanem valami mást. Egyes programokat fel lehet készíteni az üzenetek feldolgozására. A levelezési listák, illetve az olyan általános nevek, mint "postmaster" vagy "operator" kezelésére is felkészült a rendszer.

Az üzenet küldésének módját az RFC 821 és 974 dokumentumok tárgyalják. A küldést végző program párszor lekérdezi a névkiszolgálót, hogy meghatározza a célállomást. Az első lekérdezés alkalmával arról tájékozódik, hogy mely gépek kezelik a RED.RUTGERS.EDU gépnek szóló leveleket. Ebben az esetben a kiszolgáló válasza, hogy a RED.RUTGERS.EDU saját maga kezeli az üzeneteit. Ez után a program a RED.RUTGERS.EDU címét kéri le, ami 128.6.4.2. Ezek után a levelező program egy TCP kapcsolatot nyit meg a 128.6.4.2 gép 25-ös portjára. A 25-ös port a leveleket fogadó foglalatnak felel meg. Miután a kapcsolat létrejött, a levelező program megkezdi a parancsok küldését. Az alábbiakban álljon itt egy tipikus kommunikáció. A sorok előtt az szerepel, hogy az a TOPAZ vagy a RED nevű géptől származik-e. A példában TOPAZ kezdeményezte a kapcsolatot:

 RED     220 RED.RUTGERS.EDU SMTP Service at 29 Jun 87 05:17:18 EDT
        TOPAZ   HELO topaz.rutgers.edu
        RED     250 RED.RUTGERS.EDU - Hello, TOPAZ.RUTGERS.EDU
        TOPAZ   MAIL From: <hedrick@topaz.rutgers.edu>
        RED     250 MAIL accepted
        TOPAZ   RCPT To: <levy.red.rutgers.edu>
        RED     250 Recipient accepted
        TOPAZ   DATA
        RED     354 Start mail input; end with <CRLF>.<CRLF>
        TOPAZ   Date: Sat, 27 Jun 87 13:26:31 EDT
        TOPAZ   From: hedrick@topaz.rutgers.edu
        TOPAZ   To: levy@red.rutgers.edu
        TOPAZ   Subject: meeting
        TOPAZ
        TOPAZ   Let's get together Monday at 1pm.
        TOPAZ   .
        RED     250 OK
        TOPAZ   QUIT
        RED     221 RED.RUTGERS.EDU Service closing transmission channel

A parancsokban mindenütt normál szöveg szerepel: ez az Internet szabványokra tipikusan jellemző. A protokollok többsége szabványos ASCII parancsokat használ, ami arra is jó, hogy követhessük éppen mi történik, és a problémákat diagnosztizálni lehessen. A levelező program például minden ilyen beszélgetést egy állományban naplóz. Ha valami nem a megfelelő módon történik, akkor az állományt elküldhetjük a postmaster-nak. Mivel ez ASCII fomátumú, ezért látni, hogy mi történt. A dolog arra is jó, hogy közvetlenül a levelezést kiszolgáló géppel lépjünk kapcsolatba tesztelés céljából. (Néhány újabb protokoll annyira összetett, hogy ez nem praktikus. A parancsoknak olyan szintaxis felelne meg, amely szintaktikus elemzőt igényelne. Ez azt jelenti, hogy az újabb protokoll esetében a tendencia a bináris formátumok felé mutat. Általában olyan struktúrákról van szó, mint a C vagy a Pascal nyelvek rekordja.) Második észrevételként említjük, hogy a válaszok mindegyike számmal kezdődik: ez is az Internet protokollok jellemző vonása. A megengedett válaszokat a protokollok definiálják. A számok segítségével a felhasználói programok egyértelműen kommunikálhatnak. A válaszok maradék része szöveg, ami a könnyebb olvashatóság miatt szerepel, és nincs semmiféle kihatása a programok működésére. (Habár van egy pont, ahol a protokoll a válasz szövegének egy részét is felhasználja.) Maguk a parancsok arra használatosak, hogy a levelező program a kiszolgálóval közölje azokat az információkat, amelyek az üzenet továbbítása miatt szükségesek. A fenti kiszolgáló az információt az üzenetből is kiolvashatja. Bonyolultabb esetekben azonban ez nem lenne biztonságos. Minden kommunikáció a HELO paranccsal kezdődik, amit a kapcsolatot kezdeményező rendszer nevének kell követnie. Ezek után következik a küldő és a címzett meghatározása. (Lehet több RCPT parancsot is kiadni, ha több címzett van.) Végül maga az üzenet jön. A szöveget olyan sorral fejezzük be, amiben csak egy pont szerepel. (Ha a szövegben is szerepel ilyen sor, akkor a pont megduplázódik.) Miután az üzenet fogadása megtörtént, a küldő másik üzenetet küldhet, vagy befejezheti a kommunikációt, mint ahogy a fenti példában is történt.

A válaszokat jelölő számokat egy minta szerint képezzük. A protokoll definiálja azokat a válaszokat, amelyek egy adott parancsra adhatóak. Amennyiben nem érdekes a válaszok részletes elemzése, akkor elég csak az első számjegyet figyelembe venni. A 2-vel kezdődő válaszok sikeres parancsot jelölnek. A 3-mal kezdődőek esetén további parancsokat vár a kiszolgáló (ld. fent is). A 4 ideiglenes hibát jelez (pl. lemezterület megtelt). Az üzenetet ilyenkor el kell menteni, és később újra kell próbálkozni. Az 5 állandó jellegű hibára utal, például nem létezik a címzett. Az üzenetet egy hibaüzenet kíséretében vissza kell küldeni a feladónak.

(A fejezetben említett protokollokkal kapcsolatban további információt szolgáltat az RFC 821/822 a levelezésről, az RFC 959 az állományátvitelről, és az RFC 854/855 a távoli bejelentkezésről.)


Vissza a tartalomjegyzékhez