4. Nem TCP protokollok: UDP és ICMP

Eddig csak olyan kapcsolatokkal foglalkoztunk, amelyek TCP-t használnak. Emlékezzünk vissza, hogy a TCP az üzenetek datagrammokra darabolásáért és helyes sorrendben történõ visszaállításáért felelõs. Sok alkalmazás során találjuk magunkat szembe olyan üzenetekkel, amelyek elférnek egyetlen datagrammban is. Egy példa erre a nevek kikeresése. Amikor egy felhasználó egy másik rendszerrel kapcsolatba akar lépni, akkor általában az adott rendszer nevét fogja megadni, és nem az IP címét. Mielõtt bármit is kezdhetne vele, a felhasználó rendszerének ezt a nevet le kell fordítania IP címre. Az erre a célra szolgáló adatbázissal viszont nem minden rendszer rendelkezik, ezért a felhasználó rendszere az adatbázissal bírót kéri meg a fordításra. A kérés annyira rövid, hogy biztosan elfér egyetlen datagrammban. Ugyanez mondható el a válaszról is. Úgy látszik, hogy nem érdemes a TCP-t használni. Persze a TCP az üzenetek darabolásán kívül még mást is csinál. Biztosítja, hogy az üzenetek megérkezzenek: ahol szükséges, ott a datagrammokat újraadja. Viszont az olyan kérdéshez, amely egyetlen datagrammban elfér, nincs szükség a TCP teljes bonyolultságára. Ha egy pár másodpercen belül nem kapunk választ, akkor egyszerûen megismételjük a kérdést. Az ilyen alkalmazásokra a TCP mellett létezik más alternatíva.

A legszélesebb körben használt ilyen protokoll az UDP (user datagram protocol -- felhasználói datagrammprotokoll), amelyet olyan alkalmazásokhoz találtak ki, ahol nincs szükség datagramok sorozatba állítására. Hasonlóképpen illeszkedik a rendszerbe, mint a TCP. A hálózati szoftver az adatok elejére ráilleszti az UDP fejlécet ugyanúgy, ahogy a TCP fejléc esetében teszi. Az UDP ezek után az IP-nek továbbítja az adatot. Az IP hozzáteszi a saját fejlécét, amibe a TCP helyett az UDP protokollszámát helyezi el a Protokoll mezõben (lásd IP fejléc). Az UDP nem végez annyi feladatot, mint a TCP: nem tördeli szét az üzenetet datagrammokra, nem figyeli a már elküldött adatokat, hogy majd esetleg újraadja õket. Az UDP csak portszámokat biztosít, hogy egyszerre több program is használhassa a protokollt. Az UDP portszámok ugyanúgy használatosak, mint a TCP portszámok. Az UDP-t használó kiszolgálókhoz is léteznek jól ismert portszámok. Megjegyezzük még, hogy az UDP fejléc sokkal rövidebb, mint a TCP fejléce. Ebben is szerepel a forrás- és a célport száma, valamint egy ellenõrzõ összeg, de ennyi az egész. Nincs benne sorszám, mert nincs szükség rá. Az UDP fejléc így néz ki:

Az UDP-t a nevek kikeresését végzõ (lásd az IEN 116, az RFC 882 és az RFC 883 dokumentumokat), illetve az ezekhez hasonlóan mûködõ protokollok használják.

Egy másik alternatív protokoll az ICMP (Internet control message protocol -- internet vezérlõüzenet protokoll) nevet viseli. Az ICMP-t a hibaüzenetek és a TCP/IP-t megvalósító szoftvernek szánt üzenetek kezelésére használják. Kapcsolat kérésekor a kezdeményezõ rendszer kaphat például olyan ICMP üzenetet, hogy "host unreachable" (elérhetetlen gép). Az ICMP-t használják még arra is, hogy magáról a hálózatról információkat gyûjtsenek. A protokollt az RFC 792 dokumentum írja le teljes részletességében. Az ICMP abban hasonlít az UDP-hez, hogy mindketten olyan üzenetekkel foglalkoznak, amelyek egyetlen datagrammban elférnek. Az ICMP azonban annál is egyszerûbb. Még csak portszámok sincsenek a fejlécében. Mivel minden egyes ICMP üzenetet maga a hálózati szoftver értelmez, ezért nincs szükség olyan portszámokra, amelyek megmondják, hogy egy adott ICMP üzenet hova menjen.

5. Név- és információszervezés: a tartomány (domain) rendszer

Ahogyan már korábban jeleztük, a hálózati szoftvernek egy 32 bites Internet címre van szüksége ahhoz, hogy egy kapcsolatot felépíthessen, vagy hogy datagrammokat küldhessen. A felhasználók viszont inkább a számítógépek neveivel mintsem számokkal szeretnének hivatkozni rájuk (a neveket könnyebben meg lehet jegyezni). Ezért létezik egy adatbázis, amelybõl a hálózati szoftver kikeresheti a névnek megfelelõ címet, és fordítva. Amikor az Internet még nem volt ilyen kiterjedt, akkor ez viszonylag könnyen megoldódott: minden gépnek volt egy adatállománya, amelyben az összes többi rendszer nevét és címét felsorolták. Ma már túl sok rendszer létezik ahhoz, hogy az ilyen megközelítés praktikus legyen. Emiatt ezeket az állományokat olyan névkiszolgálók váltották fel, amelyek a gépek neveit és a megfelelõ címeket tartják nyilván. (A sokfajta információ közül ez csak egy. Valójában ezek a kiszolgálók sokkal általánosabb feladatot látnak el.) A valóságban egyetlen központi gép helyett az ilyen kiszolgálók egymással összekapcsolt halmaza használatos. Manapság már olyan sok különbözõ intézmény kapcsolódik az Internethez, hogy nem lenne praktikus, ha egy központi hatóságot kellene értesíteniük minden olyan esetben, amikor egy gépet a hálózatba be- vagy abból kikapcsolnak. Éppen ezért a névadásra az egyes intézmények a rendszerükön belül saját maguk jogosultak. Az így kialakított névkiszolgálók közösen egy fa struktúrát alkotnak, amely az intézmények hálózati szerkezetének felel meg. Ezt a szerkezetet a nevek is tükrözik.

Tipikus példa erre a BORAX.LCS.MIT.EDU név, amely a MIT számítástechnikai laboratóriumának (LCS) egy számítógépét jelöli (ilyen példa lehetne még: maxi.inf.elte.hu, ami az ELTE Általános Számítástudományi tanszékének maxi nevû gépét adja). A gép Internet címének meghatározásához 4 potenciális kiszolgálót kellene megkérdezni. Elõször egy központi kiszolgálótól (root - gyökér, ld. a fa struktúrát) kellene megtudakolni, hogy hol található az EDU kiszolgáló, amely nem más, mint a hálózatba kapcsolt oktatási intézmények nyilvántartása. A gyökérként szereplõ kiszolgáló több EDU kiszolgáló nevét és Internet címét adná meg. (Minden szinten több ilyen névkiszolgáló van, hogy az esetleges meghibásodások ne okozzanak fennakadást.) A következõ feladat lenne az EDU kiszolgáló lekérdezése a MIT névkiszolgálójáról. Itt is több kiszolgáló nevét és Internet címét kapnánk meg. Ezek közül általában nem mindegyik található az intézmény területén (egy esetleges áramszünet fellépte miatt). Ez után a MIT-tõl kérdeznénk le a számítástechnikai laboratórium (LCS) névkiszolgálójának adatait, majd végül a laboratóriumi névkiszolgálók egyike adná a BORAX adatait.A végsõ eredmény a BORAX.LCS.MIT.EDU gép Internet címe lenne. A fenti szintek mindegyike egy tartományt (domain) jelöl. A teljes BORAX.LCS.MIT.EDU név pedig egy tartománynév (domain name). (Ugyanígy a felsõbb tartományok nevei is tartománynevek: LCS.MIT.EDU, MIT.EDU és EDU.)

Az esetek nagy többségében szerencsére nem kell a fenti lépések mindegyikét végrehajtani. A legfelsõ kiszolgáló (gyökér) ugyanis egyben a legfelsõ szinten lévõ tartományok (pl. EDU) névkiszolgálójaként is szerepel. Tehát a gyökér kiszolgáló felé irányuló egyetlen kérdéssel a MIT névkiszolgálójához lehet eljutni. Az alkalmazott szoftverek pedig a már feltett kérdésekre kapott válaszokra emlékeznek. Ez azt jelenti, hogy a LCS.MIT.EDU kiszolgáló lekérdezése után tudja, hogy hol keresse a LCS.MIT.EDU, a MIT.EDU és az EDU tartománybeli kiszolgálókat. A BORAX.LCS.MIT.EDU fordítására szintén emlékszik. Persze minden ilyen információnak van egy megfelelõ élettartama, ami tipikusan pár napnak felel meg. Az élettartam lejárta után az információkat fel kell frissíteni. Az intézmények ilyen módon változtathatnak, ha akarnak. A tartományrendszer feladata nem merül ki az Internet címek megtalálásában. Minden egyes tartománynév csomópontként szerepel egy adatbázisban. A csomópontnak különbözõ tulajdonságokat jellemzõ rekordjai lehetnek. Ilyen az Internet cím, a számítógép típusa, és a számítógép által biztosított szolgáltatások felsorolása. Egy program egy adott névvel kapcsolatban kérheti ezen információk valamelyikét, vagy az összeset. Megoldható az is, hogy egy adatbázisbeli csomópont egy másik csomópont álneveként (alias) szerepeljen. Az is lehetséges, hogy a tartományrendszerben felhasználókról, levelezési listákról, vagy más objektumokról tároljunk adatokat.

A fenti adatbázisok mûködését, illetve az azok lekérdezését megvalósító protokollokat is Internet szabvány írja le. Minden hálózati alkalmazásnak meg kell tudnia valósítani ezeket a lekérdezéseket, mivel hivatalosan így történik a hosztnevek kiértékelése. Az alkalmazások általában saját rendszerükön (tartományukon) belül keresnek egy névkiszolgálót. Ez a kiszolgáló aztán a felsõbb szinten (az õ tartományán) lévõ kiszolgálókkal veszi fel a kapcsolatot. Ezzel a módszerrel az alkalmazásokban lévõ kód mennyiségét lehet lecsökkenteni. A tartományrendszer fontos szerepet tölt be az elektronikus levelezésben. Az adatbázisokban szerepelhetnek olyan bejegyzések, amelyek megmondják, hogy melyik gép kezeli egy adott név leveleit, egy felhasználó levelei hová érkezzenek, illetve levelezési listákat is definiálhatnak.

• A tartományrendszerrõl az RFC 1034, 1035 és 1101 dokumentumok írnak. Ezek régebbi verziói: RFC 882, 883 és 973. Az RFC 974 pedig a tartományrendszernek az elektronikus levelezésben betöltött szerepérõl szól.