Informatika | Tanulmányok, esszék » Veres József - Az Internet

AZ INTERNET Az Internet I. Az Internet - a közhiedelemmel ellentétben - jóval összetettebb, mint hálózatba kötött számítógépek sokasága. Az Internet valójában a hálózatok többszörös hálózata Az Internet kezdetei valahol a hatvanas években kezdődtek, amikor is az USA védelmi minisztériuma egy, a katonaság és a kormányzat számára kialakított titkos hálózat, az ARPANET (Advanced Research Projects Agency Network) építését határozta el. A hálózattal szemben támasztott követelmények a szabad fejleszthetőség, a - biztonsági korlátoktól eltekintve - teljes átjárhatóság, a lehetőségekhez képest gyors működés, a megbízhatóság és az akár teljes szegmensek kiesése esetén is tovább-működés képessége volt. Ezen igények alapvetően meghatározták a hálózati architektúrát és a rajta alkalmazható protokollok fő tulajdonságait. A Hálózat modularitását és viszonylag gyors működését fa-struktúrájú

topologiája biztosítja, ami lehetővé teszi a csomagok gyors és biztos továbbítását a célállomás felé, elhelyezkedésének közvetlen ismerete nélkül is. A Hálózat elemei az egységes Internet-protokoll, a TCP/IP révén képesek egymással kommunikálni - ezt biztosítja a hálózat bármely két pontja közötti kapcsolatlétesítés lehetőségét. A TCP/IP protokoll Általános elterjedt fogalom a "TCP/IP protokoll" - gyűjtőfogalomként, az Internet-en és a hozzá kapcsolodó alkalmazásokban használt protokollok összességét ezen a néven emlegetik Valójában maga a név sem egyetlen protokollt, hanem egy - az Inteneten leggyakrabban használt- átviteli protokoll-párost: a TCP (Transmission Control Protocol - átvitel-vezérlő protokoll) és az IP (Internet Protocol) kettősét jelenti. Az Interneten alkalmazott protokollok egy része ún. alacsony szintű (low-level) protokoll, melyek generális átviteli és adatcsere feladatokra

használhatók és amelyekre a magasabb szintű protokollok épülnek. Ilyen alacsony szintű protokoll a TCP, az IP, az UDP vagy a PPP Más, magasabb szintű protokollok specifikus feladatok végrehajtására alkalmazhatóak: fájlok átvitelére (FTP), levelek küldésére és fogadására (SMTP és POP) vagy távoli futtatásra (TELNET) - ezek az Internet klasszikus alkalmazásai. A TCP/IP rétegezett protokoll-készlet, azaz a teljes átviteli eljárás jól meghatározott, diszkrét feladatcsoportokra bontható. A legmagasabb szinten van az alkalmazási réteg, például a levelezési protokoll. Ez a protokoll a gépek közti kommunikáció, azaz a címezett és a feladó valamint magának az üzenet szövegének a meghatározására használt utasításokat és az ezekkel összefüggő szabály-rendszert határozza meg. Ez a protokoll azonban egy, a két gép közt fennálló 2 megbízható kapcsolatot feltételez. E megbízható adatcsere fenntartásának biztosítására

használható a TCP protokoll - az ő feladata az elküldött csomagok a célállomásra történő megérkezésének biztosítása. A TCP nyilvántartja az elküldött csomagokat és ha kell újraküldi azt amelyik valamilyen okból nem ért célba. Ugyancsak az ő feladata az átviendő adatblokk a hálózat által feldolgozható csomagokba történő szabdalása, illetve azok helyes sorrendben történő összeállítása a célállomáson. A TCP réteg a csomagokat az IP protokoll (a minden alkalmazás által igényelt funkciókat implementáló réteg) felé továbbítja - ez utóbbi feladata az egyes csomag elküldése a célállomás felé ill. azok fogadása azon Az IP a csomagokat a legalsó réteg: a fizikai hálózati médiumot (pl. Ethernet, modem, stb) kezelő réteg felé továbbítja ill fogadás esetén attól kapja meg. A hálózati protokollok rétegezése az alkalmazások sokrétűségében és felhasználásának rugalmasságában rejlik. Például nem minden

alkalmazásnak van szüksége megbízható adatkapcsolatra a küldő és a fogadó állomás között: egy élő video-sugárzást továbbító (szóró) alkalmazás számára elég, ha közvetlenül az IP réteggel kommunikál, hiszen számára nincs jelentősége (sőt!) egy-két adatcsomag elvesztésének az alkalmazás jellegéből adódóan. A TCP/IP olyan hálózatokon tud effektíven működni, ahol nagy számú csomagkapcsolt (al)hálózat áll egymással összeköttetésben átjárókon (gateway) keresztül (ezt a fajta hálózatokhálózatát szokás "catenet"-nek hívni). Ilyen hálózatokban az adatcsomagok általában (al)hálózatok tucatjain vándorolnak keresztül mire elérnek rendeltetési helyükre, a célállomásra. A művelet elvégézéséhez szükséges útvonal-vezetésnek (routing) azonban teljesen átlátszónak kell lennie az alkalmazási réteg számára - neki mindössze a célállomás "Internet-címét" kell tudnia. Az Internet-cím

(az IPv4-es protokollban) egy 32-bites szám, amely 4 darab, egyenként 8 bites számmá van felosztva a mindenki ismert pontokkal elválaszott formátumban (pl. "192.234161") Ez a hálózat topológiájából eredő (de a felhasználó számára kis mértékben érdekes) felbontás egyben a cím megjegyzését is könnyebbé teszi. A még egyszerűbben megjegyezhető DNS neveket (pl. "wwwcompanycom") a számítógép úgynevezett névszerverek (name server) segítségével fordítja tényleges IP címekké A TCP/IP alapvetően üzenet(datagram)-alapú (kapcsolat nélküli) protokoll. Az üzenet adatok csoportja mely egyetlen, összefüggő egységként kerül elküldésre. Bár magasabb szintű (a TCP/IP-re épülő) protokollok létrehozhatnak kapcsolat-alapú átviteli csatornákat is, ezen csomagok mindegyike különálló darabként került átvitelre a hálózaton, amely nem is tud(hat)ja, hogy ezek valójában esetleg egymással szorosan összefüggő,

folyamatos adatfolyamot alkotnak. Például egy több száz kilobájtos fájl átvitele nem történhet meg egyetlen csomagban, hiszen a 3 legtöbb hálózati médium nem képes ilyen nagy méretű blokkok átvitelére, így a protokoll ezeket több, általában 512 bájt méretű darabra "vágja fel", amelyek mindegyike a másik oldal felé kerül elküldésre. A túloldalon aztán újból összeállításra kerülnek és egyetlen csomagként jutnak el az alkalmazási réteg felé. Az egyes csomagok azonban az utazás közben akár teljesen eltérő csatornákon - és ebből eredően - a küldésitől teljesen eltérő sorrendben érkezhetnek meg a túloldalra, ahol azonban a protokoll feladata helyes sorrendbe állításuk és összefűzésük. A TCP (protokoll) A TCP feladata az üzenet-csomagok esetleges darabolása, azok rendbe- és összeállítása a túloldalon, valamint az esetlegesen elveszett rész-csomagok újraküldése, ezáltal két pont közt egy

megbízható átviteli csatorna biztosítása. Az adatátvitel során (az OSI modellnek megfelelően) a két TCP szint "beszélget" egymással az alattuk elhelyezkedő réteget (pl. IP) felhasználásával. Az adatkapcsolat kezdetén a két TCP szint megegyezik egymással a legnagyobb, mindkét hálózat által egy egységként feldolgozható rész-csomag (chunk) méretében. A továbbiakban minden átvitelre kerülő üzenet-csomagot a küldő fél maximálisan ekkora méretű darabkákra "szabdal fel". A csomag vétele után a fogadó TCP réteg egy nyugtázást (acknowledge) küld vissza a már fogadott rész-csomagok megjelölésével. Amennyiben a küldő fél megadott időn belül nem kap ilyen nyugtázást úgy a kérdéses csomagot újraküldi. Mivel nem effektív minden egyes csomag küldése után annak nyugtázását megvárni, ezért a TCP réteg egy ún. sliding window technikát alkalmaz Ez azt jelenti, hogy egyszerre (az előzőek nyugtázása

nélkül is) több csomagot is útjára bocsát a célállomás felé, majd a window limit (az egyszerre úton lévő csomagok maximális száma) elérésekor megvárja a nyugtázásokat. A TCP a csomagok továbbításakor az alsóbb rétegek felé egy ún. TCP fejlécet illeszt azok elé Ez a fejléc a küldő- és a célállomás IP címének megjelölése mellett a két pont közti kapcsolatot azonosító egyedi kapukat (port) és egy sorszámot is tartalmaz. A kapu-azonosítók a két azonos csomópont közti párhuzamos üzenet-átviteli csatornák megkülönböztetésére szolgálnak. A sorszám mező kapcsolat folytonosságának, azaz az esetlegesen meg nem kapott csomagok ill. az összeállítási sorrend megállapítására használhatóak. Ez a mező azonban nem a csomag sorszámát (1,2,3.stb) hanem az adott csomag első bájtának az üzeneten belüli elhelyezkedését adja meg Így az 512 bájtos darabokban átvitt üzenetek csomagjainak sorszám mezői rendre a 0, 512,

1024 stb. értékekeket fogják kapni Ezen kívül a fejléc rendelkezik még egy ellenőrző-összeg (checksum) mezővel is, melynek segítségével az átvitel fizikai hibái is kiszűrésre kerülhetnek. 4 Az Internet II. Az előző részben áttekintettük a Hálózat működését és megismerkedtünk működtetésében résztvevő protokollok általános jellemzőivel. Most folytatjuk a TCP/IP protokollpáros működésének leírását, valamint megismerkedünk az alkalmazási protokollok jellemzőivel és működésükkel. A TCP/IP protokoll (folytatás) A TCP után most ismerkedjünk meg az IP (protokollal). (Azért rakosgatom a TCP, IP, stb után zárójelbe a “protokoll” szót, mert ugye az már magában mozaikszóban is benne van (pl. IP – Internet PROTOKOLL) és így igazából nem szabadna kiírni utána - nélküle mégis furcsán hangzanak) Az IP (protokoll) Mint azt az előzőekben tisztáztuk a TCP feladatai közé tartozik az alkalmazási réteg (pl. FTP

protokoll) felől érkező üzenetek az IP (vagy valamilyen őt helyettesítő protokoll) által már feldolgozható darabokra, azaz csomagokra bontása. Az IP protokoll egyetlen feladata a TCP réteg felől érkező adatcsomagok eljuttatása a meghatározott célállomásra. A protokoll az átvivendő csomagot az alsóbb réteg felé történő továbbítása előtt egy IP-fejéccel látja el. Ez a fejléc a forrás- ill. a célállomás IP címén, valamint a csomagok sorrendjét meghatározó információn kívül egy ún. protokoll-számot és egy ellenőrző-összeget is tartalmaz A protokollszám jelentősége annak meghatározása, hogy a célállomáson az IP réteg a csomag fogadása után azt melyik felsőbb réteg (protokoll) felé továbbítsa (erre azért van szükség mert az IP protokoll szolgáltatásait nem feltétlenül csak a TCP, hanem más azonos szintű protokollok is használhatják). Az alkalmazási réteg és a socket-ek Az előbbiekben tisztáztuk, hogyan

juttathat el információt az alkalmazási réteg a TCP/IP protokollpáros felhasználásával a Hálózat egyik pontjából egy másikba. De hogyan tudja az egyik számítógép “megmondani” a másiknak, hogy az fogadjon egy üzenetet vagy küldjön el egy fájlt? Nos, az adatátvitelnél magasabb szintű műveletek elvégzése az ún. alkalmazásprotokollok feladata E protokollok mindegyike a TCP (protokollra) épül, azaz futása során annak szolgáltatásait felhasználva kommunikál a Hálózaton. A TCP biztosítja az elküldött adatok 5 átvitelét a célállomásra, ezáltal az alkalmazási protokollok számára egy bájtfolyam-jellegű, telefonvonalhoz hasonló – látszólag – közvetlen, megbízható adatkapcsolatot nyújtva. De hogyan nyílik lehetőségünk annak meghatározására, hogy a kommunikáció során az egyetlen hálózati csomóponton (gépen) esetlegesen elérhető több alkalmazási protokoll közül melyikhez intézzük kérésünket? E probléma

megoldására a TCP protokoll logikai csatornákat, ún. socketeket (csatlakózókat) definiál Amikor egy alkalmazási protokollt aktiválnak egy kiszolgálón, akkor egy egyedi – általában jól ismert és előre meghatározott – sorszámú socketet (portot) nyitnak meg a számára. A TCP réteg a beérkező csomagokat mindig a csomag által meghatározott port, azaz alkalmazási protokoll felé fogja továbbítani. Ezek után a kliensalkalmazásoknak nincs más dolguk, mint hogy kéréseiket a célállomás azon socket-je “felé” intézzék, amelyiket az adott alkalmazás szerver-protokollja felügyel. Amennyiben az alkalmazások véletlenszerűen vagy pl. indítási sorrendnek megfelelően foglalnák le maguknak a különböző socket-számokat, úgy a szolgáltatások eléréséhez nyilvánvalóan minden egyes szerverről pontosan tudnia kellene a kliens alkalmazásnak, hogy az adott gépen a szerverprotokollnak milyen sorszámú socket-et sikerült megnyitnia. Ennek

elkerülésére az általános célú, szabványosított protokollok gépenként eltérő, véletlenszerű, hanem minden gépen azonos sorszámú socket-en keresztül érhetőek el (pl. az FTP szerver-protokoll a 21-es portra “ül rá”) (Nyilvánvalóan a kliens oldalon ez a probléma nem lép fel – magyarul: ott nem érdekes, hogy éppen milyen sorszámú socketet sikerül “megkaparintani” a kapcsolat megnyitásának kezdetén – hiszen az első (a kapcsolatot megnyitó) csomag a szerver felé történő elküldése után az a fogadott TCP-fejlécből már könnyen megállapíthatja a kezdeményező alkalmazás socketszámát.) E “foglalt” port-számokat és a hozzájuk kapcsolódó szabványosított protokollokat tartalmazó listát “Assigned Number” (Hozzárendelt Számok) címmel időről-időre közzéteszi az Internet-et “felügyelő” Network Working Group. A fentieknek megfelelően egyetlen kapcsolatot összesen két számpáros határoz meg: a küldő

ill. a fogadó oldal Internet címei, valamint a küldő ill. fogadó oldali port-szám E négy szám közül bármelyiket megváltoztatva egy újabb logikai csatornát definiálunk. Ennek megfelelően nyugodtan elképzelhető, hogy ugyanaz a kliens gép ugyanarról a szerverről párhuzamosan két fájl-átviteli műveletet is végrehajtson. Ez esetben a kapcsolatot meghatározó számpárosok valahogyan így nézhetnek ki: 6 Kliens Internet- és port száma címe Szerver Internet- és port száma címe Kapcsolat 1 192.23441 1234 123.45678 21 Kapcsolat 2 192.23441 4567 123.45678 21 Mivel mindkét kapcsolat során azonos gépek kommunikálnak egymással ezért mindkét kapcsolat kliens és szerver oldali IP-címei is egyeznek, és mivel mind a kettő során fájl-transzfer történik az FTP protokoll felhasználásával, ezért mindegyiket a kliens oldal ugyanahhoz a jól ismer, szabványosított szerver oldali socket-hez címzi megnyitásakor. Az egyetlen eltérés

– ami azonban elég a kapcsolatok megkülönböztetéséhez és a csomag szétválasztásához – az a kliens oldali port-szám. Maga az alkalmazási-protokoll felépítése és működése általában jóval egyszerűbb, mint az alatta elhelyezkedő rétegeké. Az alkalmazási-protokollok általában a két fél által megértett parancsok, valamint az esetleges adatátvitel módjának és szabályozásának meghatározására korlátozódnak. A hagyományos Internet alkalmazási-protokollok (mail, FTP, stb.) a két fél közti parancsokat és a válaszokat általában standard ASCII formátumban küldik el egymásnak. E megoldás egyértelmű hátránya a sávszélesség rossz kihasználása a bináris átvitelhez képest (éppen ezért a tisztán bináris adatokat általában nem ilyen módon küldik), vitathatatlan előnye azonban platform-függetlensége (hiszen a standard ASCII jelkészletet használja, így nem okozhat problémát a két kommunikáló fél esetlegesen

eltérő szó-mérete, vagy bájt-sorrendje) valamint az, hogy a parancsok valamint üzenetek (lévén szövegesek) ember által is könnyen olvasható formában kerülnek elküldésre, ezáltal elősegítve az adatcsere felügyelését (monitoring) valamint esetlegesen azok közvetlen kiadását (célalkalmazás nélkül) is egy egyszerű terminálprogram segítségével. Egy konkrét alkalmazás: az SMTP A könnyebb érthetőség érdekében lássunk egy tipikus levél-küldési folyamatot az SMTP (Simple Mail Transfer Protcol – Egyszerű Levél-Átviteli Protokoll) (protokoll) segítségével. E protokoll segítségével nyílik lehetőségünk a munkaállomásunkon megírt levél elküldésére egy Internetpostafiókba. Tegyük fel, hogy a “Hétfőn mennek a cikkek. Az operációs rendszerről majd beszélünk.” 7 üzenetet szeretnénk elküldeni barátunknak az ’proghu@freemail.hu’ postafiókra Magának a levélnek a formátumát, azaz a feladó, a címezett, maga

üzenet és esetleges egyéb információk kódolását, sorrendiségét és megjelenítését az RFC822-es dokumentum (lásd később) definiálja. Az ennek megfelelő formára történő hozás után az üzenetünk (nagyon leegyszerűsítve, minimális tartalommal) valahogyan így néz ki: “Date: Sun, 03 Jan 99 20:59:27 CET From: sting@freemail.hu To: proghu@freemail.hu Subject: Cikkek Hetfon mennek a cikkek. Az operacios rendszerrol majd beszelunk.” A levelet elküldeni szándékozó program először is megnézi, hogy mi a címzett mail-szerver (freemail.hu) IP-címe a címfordító-szolgáltatás (DNS) segítségével Ennek megállapítása után egy adatcsatornát próbál nyitni a távoli gép (a mail-szerver) felé. A csatorna megnyitása során a DNS-szervertől kapott IP-címet és a SMTP által használt standardizált 25-ös port számot használja fel a célcím meghatározására. A kapcsolat megnyitása után a következő “beszélgetés” folyik le a

munkaállomás és a mail-szerver között (WKST a munkaállomás, FREE a levelezőkiszolgáló): FREE 220 FREEMAIL.HU SMTP Service at 03 Jan 99 21:00:35 CET WKST HELO 192.23441 FREE 250 FREEMAIL.HU WKST MAIL From: <sting@freemail.hu> FREE 250 MAIL accepted WKST RCPT To: <proghu@freemail.hu> FREE 250 Recipient accepted WKST DATA FREE 354 Start mail input; end with <CRLF>’.’<CRLF> WKST Date: Sun, 03 Jan 99 20:59:27 CET WKST From: sting@freemail.hu WKST To: proghu@freemail.hu WKST WKST Hetfon mennek a cikkek. WKST Az operacios rendszerrol majd beszelunk. 8 WKST . FREE 250 OK WKST QUIT FREE 221 FREEMAIL.HU Service closing transmission channel Mint az a fentiekből látható a teljes átvitel során tisztán ASCII formátumú szöveges kommunikáció zajlik a két gép között. Ezen kívül megfigyelhető, hogy a mail-szerver által küldött üzenetek mind egy számmal kezdőnek. Ennek jelentősége a gép-gép közti kommunikáció során van, hiszen

amennyiben a küldő fél gép (program), azaz a felhasználó nem egy terminálkapcsolaton keresztül kommunikál a mail-szerverrel (nem közvetlenül üt be minden egyes parancsot a billentyűzetről) úgy ezek a standard, az SMTP protokoll által szintén definiált számok jóval könnyebben és biztosabban azonosíthatók, mint az után következő szöveges információ. (Ez utóbbi a közvetlen, terminál-kommunikáció során hasznos, hiszen így a levet küldő felhasználónak nem kell a különböző nyugtázó- és hibakódokat megjegyeznie, az esetleges kliens-program pedig úgy sem veszi figyelembe a sort nyitó szám után szereplő karaktereket.) Ez a kettős, szám + szöveges információ típusú kommunikáció mindegyik hagyományos szabvány Internet alkalmazási-protokollra jellemző. A fentiekben többször említettem RFCxxxx jelzéssel ellátott dokumentumokat. Nos, ezek nem mások, mint a már említett, maga az Internet működését felügyelő ill. az azon

használt standard protokollok és formátumok kidolgozását és koordinálását végző Network Working Group által kibocsájtott, folyamatos sorszámmal ellátott tervezetek, javaslatok és szabványok. 9 Az Internet III. Az előző részekben megismerkedtünk az adatcsere lebonyolításának elemi lépéseivel, valamint az alkalmazási szintű protokollok működésével. Most azonban nézzük, hogyan is tartják nyilván az információk elhelyezkedését a hálózaton. A domain-rendszer Avval már tisztában vagyunk, hogy hogyan tud az alkalmazás a Hálózaton keresztül információt eljuttatni az egyik pontból a másikba. De vajon hogyan határozza meg az alkalmazás a célállomás azonosítóját, IP-címét, amikor mi, a felhasználók általában a célállomás kilétére vonatkozóan csak szöveges információkat, ún. URL-eket (Universal Resource Locator – Univerzális Erőforrás Helymeghatározó) adunk meg? (Az igazsághoz hozzátartozik azért, hogy az

URL jóval több információt tartalmazhat mint a gazdagép azonosítására szolgáló szöveges kód, de erről majd a későbbiekben.) Az ember alapvetően könnyebben memorizál jelentéstartalommal is bíró szöveges információkat, mint egyszerű számsorokat, még akkor is ha azok jóval kevesebb kódból (karakterből) állnak. E felismerés eredményeként az Internet tervezői olyan adatbázisokat kezdtek el kialakítani, amelyek a használatban lévő IP-címekhez és szolgáltatásokhoz szöveges információkat rendeltek, illetve a tárolt címek visszakeresését tették lehetővé ez utóbbiakon keresztül. A kezdeti időkben ilyen adatbázis akár mindegyik, a hálózatba kötött gépen lehetett, amely akár csak azon gépek címeit tartalmazhatta, amelyekkel az illető munkaállomás szoros kapcsolatban állt. A hálózat méretének növekedésével azonban annyira megnőtt e adatbázisok mérete, valamint annyira gyorsan váltak elavulttá a bennük

tárolt információk, hogy e adatok nyilvántartását később néhány speciális, kiválasztott szerverre bízták, amelyektől aztán bármelyik gép lekérdezhette a kérdéses címeket. Ezeket a gépeket Domain Name Server-eknek, az általuk nyújtott szolgáltatásokat pedig Domain Name Services-nek hívják (ez utóbbi valójában sokkal több szolgáltatást takar, mint az említett egyszerű URL®IP cím-fordítás, de mi egyelőre csak ezzel foglalkozunk). E gépek egymással is kommunikáló, folyamatos adat-cserét folyató, jól szervezett rendszerek, melyek segítségével a legfrissebb információk “maguktól” is eljutnak a legtávolabbi pontokig is függetlenül annak eredeti keletkezési helyétől. A domain-rendszer létrehozásának több előnye is volt. A nyilvánvaló észszerűségi megfontolásokon túl e megoldás egy általános elnevezési séma kialakításával (pl. www.cégnévcom) a korábban esetlegesen nem ismert erőforrásokat is könnyen

elérhetővé tette, ráadásul függetlenítette azokat (mármint az elnevezéséket) a referált gépek a hálózat 10 topológiáján belüli elhelyezkedésétől. Ugyanakkor lehetővé tette, pl a kérdéses csomópontok geológia elhelyezkedésének megállapítását is megfelelő kiegészítő információk eltárolásával. Ráadásul a hálózati csomópontokat azonosító szöveges információk, az ún. domain-nevek kezelését is központosította, ezáltal elkerülhetővé téve az esetlegesen önkényesen választott, véletlenül azonos nevekből származó konfliktusokat, valamint lehetővé tette a kapcsolódó adatok a mindenkori lehetőségekhez képesti frissességének megőrzését. Természetesen ez a központosítás nem egyetlen gép totális kontrollját jelentette az összes többi felett - hiszen ez előbb-utóbb túlterhelési problémákhoz vezetett volna -, hanem inkább a nagyteljesítményű gépek bázis-jellegét a topológiában lejjebb

elhelyezkedő, általában kisebb kapacitású DNS-szerverek számára, amelyek azonban ugyanúgy keletkeztethettek újabb, lokálisan tárolt, a topológiában lejjebb elhelyezkedő gépekre vonatkozó információt a rendszer számára, mint nagyobb teljesítményű társaik. Mint azt mindannyian tudjuk a DNS-ek egy-két (legtöbb esetben három) pontokkal elválaszott szóból álló kódsorozatok. Egy ilyen tipikus azonosító lehet például a PMMFKJPTEHU, a WWW.MICROSOFTCOM vagy a WWWGNUORG Bár az URL-ek domain-nevei igazából tetszőleges számú pontokkal elválasztott szóból állhatnak, a legtöbb esetben az egyszerűség és a szabványosítás kedvéért ezeket három tagból rakják össze. A domain-nevek szoros hierarchiát alkotnak, amelyek alapján mindenkor megállapítható, hogy mely DNS-szerver tárolja az elérni kívánt (cím-)információt. A legmagasabb szintet a domain-nevek tulajdonosainak földrajzi elhelyezkedése, valamint tevékenységi és működési

jellegéből adódó besorolás adja. Ennek megfelelően pl minden magyarországi domain-név .HU-ra, minden holland NL-re és minden német szerver URL-je .DE-re végződik Az USA-ban kiosztott domain-nevek ilyen szempontból speciális kategóriát alkotnak, mert ezeket működési profiljuk és jellegük alapján is megkülönböztetik. Ilyen azonosítók pl a. COM (Commerical) – kereskedelmi, EDU (Education) Oktatás és ORG (Organization) egyéb, általában non-profit jellegű szervezetek, alapítványok, stb. A következő szintet az intézmények nevei valamint az egyéb önkényes módon választott azonosítók szolgáltatják, amelyek azonban csak a fő-domain-en belül kell, hogy egyediek legyenek (pl. a WWWHPCOM és a WWWHPHU egy teljesen más szervert is jelenthet – és általában jelent is – függetlenül attól, hogy ugyanannak a cégnek az üzemeltetésében állnak-e vagy sem). Ennél lejjeb elhelyezkedő struktúrálási szintek is kialakíthatók, amelyeket

azonban csak nagyon kevés esetben használnak ki. 11 Amikor browser-ünknek megadjuk mondjuk a WWW.MICROSOFTCOM címet, akkor az részeire bontja azt és elkezdi keresni az azonosítót a beállított - vagy pl. PPP esetén az ISP-től (Internet Service Provider – Internet-Szolgáltató) automatikusan megkapott – DNS-szerveren. Ennek során általában eljut a legmagasabb szintet kezelő DNS-szerverig, amely megmondja neki, hogy annak a DNS-szervernek a címét amelyik a MICROSOFT.COM-ra végződő címeket tartja nyilván. Ettől a szervertől aztán megkapja a WWWMICROSOFTCOM domain-name-hez rendelt IP-címet, amelynek felhasználásával már kapcsolatot kezdeményezhet a szerver felé. Ez persze a kiindulási DNS-szerver beállításától függően teljesen automatikusan is megtörténhet, mert az egyrészt bizonyos - az eredeti DNS-szerver által meghatározott - ideig nyilvántartja a leggyakrabban elért címeket (cache-eli azokat), másrészt amikor megkérdezzük

tőle a WWW.MICROSOFTCOM címet, akkor a helyett hogy átirányítana minket a legmagasabb szintű DNS-szerverig akár saját maga is elvégezheti a keresést és visszaadhatja nekünk az kérdéses IP-címet, mintha már eleve tudta volna azt. E hierarchikus felépítés lehetővé teszi az adatok áttekinthető, struktúrált tárolását és karbantartását, valamint a topológiában egyel lejjebb elhelyezkedő szint kezelését mindig kihelyezi a megfelelő szervezetnek. Így pl amennyiben mi regisztráltatva lettünk mint XYZHU, abban az esetben egy, a saját, XYZ.HU domain-név alatt elérhető gépünkön futó DNS-szerver szolgáltatással akár tovább is bonthatjuk azt, és újabb a struktúrában lejjebb elhelyezkedő szinteket is kialakíthatunk (pl. TRADEXYZHU, és karbantarthatunk a fentebb elhelyezkedő szintek bevonása nélkül. Fontos megjegyezni, hogy a domain name-ek által kialakított struktúra teljesen független a hálózat fizikai topológiájából, vagy a

szervezet felépítéséből adódó struktúrától. Ennek megfelelően akár több domain-név is jelentheti ugyanazt az IP-címet, valamint látszólag bizonyos szintig azonosan eredeztetett domain-nevek (pl. WWWABCHU és FTPABCHU) is jelölhetnek valójában teljesen más fizikai helyen - és ennek megfelelően általában teljesen más hálózati szegmensben – fellelhető gépeket is. Ennek megfelelően lehetőség van ún. alias-ok kialakítására is, melyek valójában nem igazi IPcímeket tartalmazó referenciák, hanem csak “átirányítják” a kérést egy másik domain-névre, amely – lévén esetlegesen szintén egy alias - vagy továbbhivatkozik egy következő névre, vagy egy tényleges IP-címet tartalmaz magában. (Pl így lehetséges, hogy a wwwmsncom ugyanarra címre visz minket, mint a home.microsoftcom – az előbbi egyszerűen átirányít minket az utóbbira.) 12 Az Internet IV. Miután áttekintettük az Internet alapvető működési elveit ideje

megismerkednünk a leggyakrabban alkalmazott Internet alkalmazási-protokollok működésével és használatával. Az Internet klasszikus alkalmazásai I. Az FTP (protokoll) Az FTP (File Transfer Protocol – Fájl Átviteli Protokoll) az egyik legrégebbi Internetprotokollok egyike – legelső változatát még 1971-ben dolgozták ki. A protokoll feladata a számítógépek közti fájl-csere biztosítása: a különböző platformok fájl-rendszereinek eltéréseit elrejtve, az állományok ellenőrzött és biztos átvitele az Internetre kapcsolt bármely két egység között. A protokoll eredményesen használható mind interaktív, mind program által vezérelt automatikus üzemmód esetén. Bár megjelenése óta hasonló feladatok ellátására számos új protokollt is kidolgoztak, kiforrottságának és egyszerűségének köszönhetően még mindig az egyik leggyakrabban használt Internet-protokollok közé tartozik. Az FTP a fájlok átvitele során az eddig

megismertektől alapvetően eltérő, azonban hatásfok és mechanizmus szempontjából indokolt adatátviteli modellt alkalmaz. Az FTP kliens a kapcsolat kezdeményezése során a már megismert módon hozza létre az ún. vezérlő-csatornát (control channel/control connection). A vezérlő-kapcsolat felépülése után a felhasználó különböző, alapvetően szöveges parancsokat adhat ki a távoli számítógép számára, amelyeket az értelmez és végrehajt. Ebben az üzemmódban minden adatcserét a felhasználó (kliens) kezdeményez, amelyre a szerver a parancsnak megfelelő üzenettel vagy hibakóddal válaszol. (Természetesen ezekre az üzenetekre is jellemző, a már előző részben is említett tulajdonság, ti. hogy a válaszkód egy, programok által is könnyen azonosítható szabványosított szám-kódból, valamint a felhasználók által is könnyen értelmezhető szöveges információ összefűzéséből áll, ezáltal egyszerűvé téve mind a közvetlen,

mind a célprogram közbeiktatásával lefolytatott kommunikációt.) Fájl-átvitel (küldés v. fogadás) kezdeményezése során azonban a parancs hatására a szerver egy második ún. adat-csatornát (data channel) nyit a kliens-számítógép felé, amelyen aztán az adatcsere bonyolítása történik. E csatorna – a vezérlő-kapcsolatban alkalmazottól eltérően szigorúan csak bináris adatok átvitelére alkalmazható – az átvitelt és a kapcsolat további részeit befolyásoló parancsok továbbra is a vezérlő-kapcsolaton keresztül adhatók/adandók ki. Az átvitel befejeztével a szerver automatikusan lezárja (bontja) az adat-csatornát. Ez az architektúra 13 több szempontból is előnyös: egyrészt elméletileg egyetlen kontroll-csatorna felhasználásával is lehetőség nyílik több, szimultán adatátvitel kezdeményezésére (akár feltöltés és letöltése egyszerre is). Másrészt, mivel nem keveri a kis mennyiségű szöveges parancsok és az

általában jóval nagyobb mennyiségú bináris adattömegek átvitelét, ezért a rendelkezésre álló sávszélesség jobb kihasználása céljából elképzelhető, hogy a kontroll csatornán keresztüli kommunikáció egy viszonylag lassú, de ez által általában olcsóbb médium segítségével, míg az adatátviteli csatorna egy jóval gyorsabb, de így költségesebb – azonban szigorúan csak a tényleges adatátvitel idejére igénybe vett – hálózati közegen keresztül valósul meg. Ez utóbbi lehetőségből egyenesen következhet a harmadik előnyös tulajdonság is, mely szerint adatátvitel kezdeményezhető két olyan állomás között is, melyek közül egyik sem lokális (magyarul egy harmadik gépről felépítünk egy-egy kontroll kapcsolatot mindkét géphez, ahol az egyiket utasítjuk az adatok küldésére, míg a másikat a fogadásra – ezek után a két gép automatikusan felépíti az adatkapcsolatot egymás közt és elvégzik a fájl(ok)

átvitelét). A kommunikáció befejezését a kliens-oldal kezdeményezi, de valójában a szerver hajtja végre. Az FTP parancsokat a könnyebb áttekinthetőség érdekében érdemes funkciójuk alapján csoportokba sorolnunk. Az első csoportot az adat-reprezentációs parancsok alkotják, melyeknek a különböző platformokon keletkezett/platformokra szánt információk értelmezését és továbbításának módját határozzák meg. Ide tartoznak a TYPE, STRU(CTURE) ill MODE parancsok A TYPE paranccsal az adatátvitel során a bájtok kódolásának módját határozhatjuk meg, azaz azt, hogy az eredeti gépen tárolt adatfolyamot a továbbítás (küldése) előtt hogyan alakítsa át a szerver, hogy az a kliens által értelmezhető formára kerüljen. A kódolási eljárást a parancs paramétereként megadott kulcsszó határozza meg, mely ASCII, EBCDIC, IMAGE ill. LOCAL Az alapértelmezett formátum itt általában az ASCII, ami az eredeti fájlban található szöveg –

esetlegesen platform-specifikus - karaktereit standard ASCII kódokra cseréli. E formátum azonban csak szöveges fájlok átvitelére használható, mert a bináris állományok átvitele esetén is “minden szívfájdalom nélkül” lecseréli a megfelelő kódokat ez által a szóban forgó programot tökéletesen használhatatlanná téve. Így általában tömörített fájlok, vagy bináris futtatható állományok átvitele előtt érdemes egy “TYPE IMAGE” v. “TYPE BINARY” paranccsal indítani, hogy biztosan egy-az-egyben jöjjön át minden letöltött fájl. Ugyancsak az adatok megjelenési formáját határozza meg a STRU(CTURE) parancs is, amellyel az átviendő adathalmaz belső szerkezetét határozhatjuk meg. Alapértelmezett értéke általában a fájl-struktúra, azaz amikor az adathalmaz (fájl) egyetlen komplett, nem megbontható egységet 14 alkot. Bár e utasítás segítségével akár lapokból álló, ill komplett rekord-szerkezeteket is

definiálhatunk az adathalmazra gyakorlati jelentősége PC-s környezetben elég kicsi, így nem is térnék ki taglalására. A harmadik említett parancs, a MODE, segítségével az adatfolyamban elhelyezendő információkat határozhatjuk meg. Alapértelmezett esetben az átvitel ún STREAM módban folyik, ami a nyers adatok folyamatos bitfolyamként történő továbbítását jelenti. Ez a mód a leggyorsabb átviteli módot nyújtja – hiszen nem csatol kiegészítő információkat az adathalmazhoz – de ugyanakkor nem nyújt lehetőséget pl. a megszakadt átviteli folyamat folytatására egy későbbi időpontban. Ilyen irányú igény esetén érdemes a BLOCK átviteli módot aktiválni, ami a teljes adathalmazt diszkrét blokkokra bontva – és azokhoz kiegészítő információkat csatolva – küldi el a célállomás felé. Mivel ez az átviteli mód minden egyes blokkhoz mellékeli annak adathalmazon belüli pontos pozícióját is, így egy esetlegesen megszakadt

kapcsolat után a kliens könnyen újrakérheti a hiányzó részeket tartalmazó blokkokat. A COMPRESSED mód a biztonság mellett adattovábbítás gyorsaságát helyezi előtérbe, hiszen az adatok tömörített formában, a BLOCK módhoz hasonló kiegészítő információkkal “megtűzdelt” módon történő átvitelét teszi lehetővé. Alacsony tömörítési rátájának azonban elsősorban csak rendkívül lassú átviteli közegek esetén van jelentősége és az alkalmazott egyszerű algoritmus (RLE) miatt általában csak szöveges információ hatékony tömörítését teszi lehetővé. Az FTP parancsok legnagyobb csoportját a közvetlen adat-transzferre utasító ill. az azokhoz történő hozzáférést szabályozó/lehetővé tevő parancsok alkotják. Minden FTP kapcsolat megnyitásakor először be kell lépnünk (login) a távoli gépen, azaz azonosítanunk kell magukat. Erre a USER (NAME) parancs használatával nyílik lehetőségünk. A felhasználó-név

megadása után általában még egy ahhoz kapcsolódó jelszót is meg kell adnunk, amit a PASS(WORD) parancs kiadásával tehetünk meg. Érdemes megjegyeznünk, hogy a legtöbb publikus FTPszerverre az “anonymous” felhasználónév és a saját e-mail címünk, mint jelszó megadásával léphetünk be. Ez utóbbi általában csak a felhasználó egyedi azonosítását teszi lehetővé (hiszen maga a user-név ez esetben nem egyedi), de gyakorlatilag bármilyen e-mail címre hasonlító szöveges információt elfogad, hiszen igazából nem állhat módjában az ellenőrizni. Ez persze nem jelenti azt, hogy szabadon garázdálkodhatunk a rendszeren belül, hiszen saját, egyedi IP címünk továbbra is ott “csücsül” minden elküldött csomagunk elején, ezáltal lehetővé téve azonosításunk. 15 A sikeres belépés után kedvünkre tallózhatunk a jogosultságainknak megfelelő könyvtárakban és szintén ez utóbbitól függ, hogy mely állományokat tölthetjük

le (download), ill. hogy egyáltalán tölthetünk –e fel (upload) a szerverre bármilyen saját információt. Érdemes megjegyezni, hogy a navigáció során a UNIX rendszerek szintaxisa a mérvadó, azaz például az elérési utakban a DOS-ban megszokott visszaperjel () karakter helyett itt a sima perjel (/) használandó, valamint az esetleges kapcsolókat nem perjellel, hanem mínusz-jellel (-) kell prefixálni. A navigáció során könyvtárat CD parancs segítségével válthatunk. Amennyiben a prompt nem jelzi ki, úgy aktuális könyvtárat a PWD parancs beírása után tudhatjuk meg. Az egy szinttel feljebb elhelyezkedő szülő-könyvtárba történő váltáshoz mind a CDUP, mind a “CD .” parancs használható Az aktuális könyvtár tartalmát az LIST (LS) ill. esetlegesen a DIR parancs segítségével listázhatjuk ki. Amennyiben az átvitel során a kontroll-kapcsolattól eltérő címmel szeretnénk felépíttetni az adat-csatornát, úgy annak IP-címét a PORT

parancsnak kell átadnunk. Ez esetben a mások távoli gépet a PASSIVE (PASV) parancs segítségével kell utasítanunk, hogy készüljön fel az érkező fájl fogadására. A fájlok a szerver gépről a kliensre történő letöltése a RETRIEVE (RETR) parancs kiadásával lehetséges. Ugyanezt a folyamatot a másik irányba (azaz a feltöltést) a STORE (STOR) parancs segítségével tehetjük meg. Mindkét parancs első paramétereként a le- ill feltöltendő távoli ill lokális fájl nevét kell megadnunk, míg második paraméterként opcionálisan egy, az eredetitől eltérő fájl nevet is megadhatunk – az adatok ilyen néven kerülnek majd tárolásra a kliens ill. szerver oldalon. Amennyiben véletlenül sem szeretnénk valamilyen állományt felülírni a feltöltés során a szerveren – vagy egyszerűen csak lényegtelen a feltöltött fájl neve – úgy a STORE UNIQUE (STOU) parancsot érdemes használnunk, ami garantáltan egyedi néven fogja létrehozni a fájlt

a célkönyvtárban. Ha pedig éppen az lenne a célunk, hogy egy, a szerveren már létező állományhoz fűzzünk hozzá plusz adatokat, úgy azt az APPEND (APPE) parancs kiadásával tehetjük meg. A fent felsoroltakon kívül még számos parancs létezik elsősorban a könyvtár-szerkezet manipulálására (MKD(IR), RMD(IR)), a fájlok átnevezésére (RENAME FROM és. RENAME TO) ill. törlésére (DELETE), valamint egyéb kiegészítő információs funkciók ellátására (SYSTEM, STATUS, stb.), de ezekre kis gyakorlati jelentőségük miatt jelen cikkben nem térnék ki. 16 Amennyiben szeretnénk látni a használható parancsok listáját, vagy szeretnénk bővebb információt kapni egy-egy parancs paramétereiről és használatáról, úgy a HELP parancs lehet segítségünkre. A kapcsolat lezárása és a rendszerből történő kilépésre a QUIT ill. BYE parancsok használhatók Az Internet V. Az Internet klasszikus alkalmazásai II. A WWW Az Internet mai szerepe

a világban, kiterjedése és mérete, valamint robbanásszerű terjedése legnagyobb mértékben egyetlen protokollnak, nevezetesen a HTTP-nek köszönhető – ez az a protokoll amitől az Internetből, Világháló, azaz Web lesz A WWW (World Wide Web – Világméretű Hálózat) alapjait az 1990-es évben Tim Berners-Lee, a CERN (az Európai Nagyenergiájú Részecskék Fizikai Kutatólaboratóriuma) egyik munkatársa fektette le. Bár ötleteit elsősorban a már létező Gopher protokoll “ihlette”, sikerült annak számos hátulütőjét és viszonylagos zártságát kiküszöbölve egy olyan rendszert kialakítania, amely alapjaiban napjainkig nem szorult módosításra. Az általa megálmodott világháló a már említett Gopher rendszerező szerepén kívül képes volt szöveges információ, képek, és ami legfontosabb: ezekbe ágyazott hyperlinkek segítségével összekapcsolt elemek hitetetlen bonyolult rendszerét kialakítani. Ráadásul a protokollok

kialakítása is olyan módon történt, hogy ne zárják ki más média-típusok (pl. mozgókép, hang, stb) továbbítását sem Maga a hypertext és hyperlink kifejezések nem a Web sajátjai (már a 1970-es években is működtek ilyen elveken alapuló rendszerek), de azok ilyen széles mértékű megosztását és összekapcsolását csak is a Web tette lehetővé. A teljesen WWW alapvetően három jól elkülöníthető típusú komponensből épül fel: a HTMLnyelven íródott Web-oldalak tartalmazzák magukat az információkat illetve abba beágyazva a más információ-forrásokra mutató hyperlinkeket. Ezeket a web-oldalakat az ún Web-szerverek teszik elérhetővé az Internetre kapcsolódó más gépek számára a HTTP protokoll felhasználásával. Az ügyfél programok vagy más néven Web-browserek feladata ezen oldalak lekérése a szerverektől és a bennük található információ formázott megjelenítése a felhasználó számára. 17 A HTML (HyperText Markup

Language – hypertext jelölő-nyelv) az SGML (Standard Generalized Markup Language) egy specifikusan a Web számára átalakított módozata. A nyelv lehetőséget nyújt a normál információs szövegben bizonyos jelölő blokkok, ún. tag-ek elhelyezésére, melyek információkat és utasításokat tartalmaznak a browserek számára a dokumentumok tartalmával, megjelenítésével és viselkedésével kapcsolatban. Mivel így az információk egy új, az addig létező formátumoktól teljesen eltérő módon kerültek kódolásra, ezért azok megjelenítése is értelemszerűen csak a megfelelő dekódoló, egy browser program segítségével volt lehetséges. Nyilvánvalóan nem terjedt volna el fantasztikus ütemben a Web, amennyiben az ilyen szoftverekért hasonlóan magas árat kértek volna mint az egyéb kereskedelmi programokért. Szerencsére ez a probléma nem vethetett gátat a fejlődésnek minekután az Illionis-i Egyetemen működő NCSA (National Center for

Supercomputing Applications) kibocsátotta az első ingyenes browser-t, az NCSA Mosaic-ot. A programot Marc Andreeseen tervezte és diákok egy csapata valamint az egyetem néhány munkatársának közreműködésével fejlesztették ki. A Mosaic úgy terjedt az Interneten, mint a futótűz: a megjelenéstől számított egy éven belül már kb. 2 millióan használták világszerte Hamarosan mindenki használta a Világhálót és mindenki saját web-oldalának kialakításán fáradozott – a Web sokkal gyorsabban terjedt mint bármely más újítás a számítástechnikai történelmében. Míg 1993 közepén mindössze kb. 130 web-site létezett, addig az év végére már közel 600, egy évvel később már majdnem 3000 és 1996 elején már több mint 90,000 site volt elérhető. Napjainkban e számot mintegy ? millióra becsülik. Mivel nem csak a Mosaic futtatható állományai, de maga a program forráskódja is szabadon terjeszthető volt, ezért egyre több browser

program jelent meg. Ezek közül a legsikeresebb – a Microsoft Internet Explorerjének megjelenéséig - a mindenki által ismert Netscape Navigator lett. (Mellesleg a Netscape-et pont ugyanaz a Marc Andreessen alapította – Jim Clarkkal, a Silicon Graphics egykori munkatársával közösen -, aki magának a Mosaic-nak a fejlesztését is koordinálta.) A felhasználók nyomására a nagy online szolgáltatók is kénytelenek voltak – addig általában egyedi megoldásokkal működő - szolgáltatási kínálatukat átalakítani és a web-központúság felé eltolni. A webre hamaros minden éjszaka szörfözők milliói léptek fel, hogy újabb és újabb információk után kutassanak a Háló végtelen útjain. 18 Az HTTP (protokoll) A Web kliens-szerver architektúrát alkalmaz az információk megosztására és terjesztésére. A rendszer működése során a felhasználó gépén futtatott kliens program – a web-browser – kérést intéz az Internetre rákapcsolt

web-szerverhez, ami az üzenetet értelmezi és a kért dokumentumot ill. kiegészítő információkat küld vissza a kliens felé A megkapott fájlt aztán értelmezi a browser és annak tartalmától függően megjeleníti, lemezre menti vagy éppenséggel – pl. Java kód esetén – elkezdi futtatni azt a felhasználó gépén. A két gép között az információ-csere a HTTP protokoll segítségével zajlik. Az HyperText Transfer Protocol (Hipertext Átviteli Protokoll) kialakítása során elsődleges szempont volt az egyszerűség és gyorsaság, amik elengedhetetlen feltételei egy jól működő oszott, hipermédia alapú információs rendszernek. A HTTP egy objektum-orientált, állapot nélküli általános protokoll, ami azonban jóval több feladat ellátására is képes lehet, mint weboldalak továbbítása. Az, hogy a protokoll állapot nélküli azt jelenti, hogy a teljes kommunikáció folyamata jól behatárolható, egyedi kérések sorozatából áll melyek

mindegyike során a kliensnek minden szükséges információt újból el kell küldenie a szerver felé. Bár e megközelítés ineffektívnek bizonyul egy viszonylag állandó kapcsolat – pl. helyi hálózat szervere és a munkaállomások – esetén, egyértelműen sokkal hatékonyabb az olyan hipermédia rendszerek, mint pl. a web esetén is, ahol alapvetően alacsony (<50%) az esélye annak, hogy a kliens két egymás utáni kérése ugyanarra a szerverre fut be, hisz a hiperlinkek segítségével a felhasználó - teljesen észrevétlenül - keresztül-kasul vándorol az hálózaton. Az egy-egy oldal lekérése során végrehajtásra kerülő átviteli tranzakció a következő alapvető lépésekből áll: • a kliens és a szerver közti kapcsolat felépítése (a HTTP általában a 80-as TCP/IP portot használja a szerver gépen, de az URL segítségével bármilyen más, tetszőleges port is megadható) • a kliens egy kérést (request) intéz a szerver felé •

a szerver a kérés fogadása és az annak megfelelő feladatok elvégzése után egy választ (response) küld vissza a kliens felé • mindkét fél bontja a kapcsolatot A kliens az összeállított kérésben információkat küld saját magáról (pl. a browser típusa és verziója), az alkalmazott formátumról (pl. az alkalmazott HTTP protokoll verzió) valamint az URL-ben a host-név utáni – a felhasználó által közvetlenül begépelt, vagy egy hiperlinkben megadott – kiegészítő paramétereket, melyek további információkat nyújthatnak a szervernek az 19 információ típusát, jellegét illetően vagy speciális futtatható modulok esetén végrehajtási módozatával kapcsolatban. Ezen kívül egy ún metódust is meghatároz, azaz megmondja, hogy milyen műveletet kíván a megadott objektumon elvégezni. Az objektumokon elvégezhető metódusok az alkalmazott információs rendszer jellegétől függenek és a WWW esetén pl. a következő feladatok

elvégzésére alkalmasak: lekérdezni, hogy egy objektum állapota megváltozott –e (azaz, hogy újra kell –e olvasnia, vagy előveheti egy régebbi verzióját), letölteni, törölni, stb. Ezen információkat a kliens egy, az Internel Mail-ben is alkalmazott fejléchez hasonló, alapvetően szöveges jellegű információs blokkban kódolja és ezt küldi el a szerver felé. A szerver a kért információs blokk előállítása után azt egy hasonló fejléccel ellátva küldi vissza a kliensnek. A szöveges blokk elsősorban a visszaküldött objektum jellemzőit írja le: pl kódolási formátum (sima szöveg, UUENCODE, zip, stb.), típus (szöveges információ, kép, video, hang, bináris állomány, stb.), alkalmazott nyelv, stb A választ megkapva azután a browser ezen információk alapján tudja eldönteni, hogy mit is kell csinálnia az objektummal: megjelenítenie, lemezre menteni vagy éppenséggel lefuttatni. 20 Az Internet VI. Az Internet klasszikus

alkalmazásai III. IRC Az IRC (Internet Relay Chat) protokoll első változatát Jarkko Oikarinen dolgozta ki 1988-ban a Unix “Talk” programjának továbbfejlesztéseként. Eredetileg elsősorban BBS-ek számára, valós idejű szöveg-alapú telekonferenciák létrehozására szánta, azonban a protokoll szerver-kliens architektúrájának és rugalmasságának köszönhetően sikeresen alkalmazható jóval nagyobb kiterjedésű kommunikációs hálózatokon, meglehetősen nagy felhasználószám mellett is. Bár a protokoll jelenlegi implementációi szinte kizárólag TCP/IP-ra épülve működnek, egyéb megbízható átviteli protokollok is alkalmasak a kapcsolati réteg funkcióinak ellátására. Az IRC-n belül a kliensek bizonyos csoportokba, ún. csatornákba (channel) szerveződnek A csatornának küldött üzenetet minden, az adott csatornába bejelentkezett felhasználó megkapja ill. ő maga is hasonló üzeneteket küldhet a csatorna felé. A csatornát az első, a

belépéskor a csatorna nevét használó kliens hozza létre, és a csatorna megszűnik létezni amint az utolsó kliens elhagyja. (Valójában a csatorna mint fix, permanens kapcsolat vagy erőforrás soha nem is létezik – ez a megközelítés szigorúan logikai jellegű.) A csatornát létrehozó felhasználó automatikusan a csatorna operátorává (channel operator – ChanOp) válik, aki speciális jogosultságokkal bír a hagyományos kliensekkel szemben: módosíthatja a csatorna jellemzőit, meghívásos csatornák esetén meghívhat klienseket, átmenetileg eltávolíthat ill. véglegesen kizárhat bizonyos – pl nem megfelelően viselkedő – felhasználókat, vagy akár hasonló jogosultságokkal ruházhat fel a csatornát csak később felkereső felhasználókat. Alapvetően két fajta csatorna létezik: a nyílt, az összes kapcsolódó szerver által ismert, mindenki által szabadon elérhető csatornák, ill. a zárt, általában meghívásos jelleggel működő

csatornák, melyet kizárólag csak azok a felhasználók érhetnek el, amelyek a csatornát tartalmazó szerver közvetlen kliensei. Magukat a csatornákat egy max. 200 karakter hosszú sztring, az ún csatorna-név azonosítja A nyílt csatornák nevét egy ‘#’, míg a zártakét egy ‘&’ jel előzi meg. A csatornákat általában a rajtuk keresztül folytatni kívánt beszélgetések témájáról vagy annak egy-egy kulcsszaváról kapják a nevüket: ennek megfelelően pl. a #biking csatornán a kerékpározás megszállottai, míg a #magyar csatornán a magyar nyelvű felhasználók csevegnek. 21 Egy új csatorna létrehozásához vagy egy már meglévőhöz történő kapcsolódáshoz a felhasználónak a JOIN parancs segítségével be kell lépnie az adott csatornába. Amennyiben a szóban forgó csatorna eddig nem létezett, úgy az létrehozásra kerül és a felhasználó automatikusan a csatorna operátorává válik (nevét a felhasználók listájában egy

‘@’ előzi meg). Ha a csatorna már létezett, abban az esetben a belépés sikere a csatorna jellemzőitől függ: pl. meghívásos csatornákra kizárólag az után lehet belépni, hogy meg lettünk hívva, ill. jelszóval védett channelre nyilvánvalóan csak a jelszó ismeretével tudunk bejelentkezni. Bár elméletileg egy kliens tetszőlegesen sok csatorna tagja is lehet ugyanabban az időben, de humán felhasználó esetén nyilvánvaló okokból ennek sok gyakorlati jelentősége nincs. Az IRC-ben alapvetően két fajta egységet különböztetnek meg: a kliens és a szerver egységeket. Az IRC kommunikációs lánc gerincét a szerverek szigorúan lefelé bomló, fa struktúrába szervezett hálózata alkotja. A szerverekhez kapcsolódnak a kliensek, amelyeket egyedi azonosítójuk, az ún. nickname (becenév) alapján lehet megkülönböztetni Ha az IRC gerinc bármilyen (pl. fizikai) okból “kettétörik”, azaz bizonyos szerverek közti kapcsolat megszakad, úgy

mindkét oldalon két külön csatorna keletkezik, melyeknek nyilvánvalóan csak a megfelelő hálózati szegmenshez kapcsolódó kliensek lesznek tagjai. Amennyiben a kapcsolat a későbbiekben helyreáll, úgy a két csatorna újból egyesítésre kerül. (Ez igazából logikusan következik a kapcsolat kizárólag logikai jellegéből adódóan.) A kliensek és a szerverek üzeneteken keresztül kommunikálnak egymással. Minden egyes üzenet három részből áll: egy prefixből (opcionális, az üzenet keletkezési helyét határozza meg), magából a parancsból ill. a hozzá kapcsolódó opcionális paraméterekből, melyek mindegyike szóközzel van elválasztva egymástól. Az üzenetet minden esetben egy CR-LF karakter-páros zárja. Az egyes üzeneteket követheti válasz (is), ami maga is egy üzenet – ennek (ti a válasz küldésének) bekövetkezése elsősorban a parancs jellegétől függ (pl. az érvényes IRC parancsokat általában a szerver egy válasz-üzenettel

nyugtázza). A szerver által küldött válasz-üzenetek a szöveges információk előtt – az egyszerűbb és egyértelműbb gépi feldolgozás céljából – egy három-jegyű kódot tartalmaznak, melyek mind nyugtázó, mind hibakódokat magukban foglalnak. A kliensek számára érkező üzenetek alapvetően négy csoportba sorolhatók. Az információs üzenetek (informational messages) az IRC valamint a csatorna változásairól tájékoztatják a felhasználót: segítségükkel szerzünk információt az új kliensek belépéséről, mások kilépéséről, a nickname-ek valamint a csatorna jellemzőinek megváltozásáról. A nyilvános üzeneteket (public messages) minden, az adott csatornába bejelentkezett kliens láthatja – minden, egyéb megjelölés 22 nélkül az adott csatornára küldött üzenet nyilvános. Ezzel szemben a privát üzeneteket (private messages) – bár ezek szintén végigfutnak az IRC hálózaton – kizárólag csak a címzett(ek)

olvashatják. Az üzenetek negyedik csoportját alkotó értesítések (notices) elsősorban automatikus rendszerek által küldött válaszok. A mIRC Ahhoz, hogy az IRC-ben részt tudjunk venni, szükségünk lesz egy IRC-kliens programra. Ezek közül Windows alatt a legnépszerűbb a mIRC, ami elsősorban kezdők számára nyújt nagy segítséget azzal, hogy a legfontosabb IRC funkciókat menükön és dialógusokon keresztül bocsátja a felhasználó rendelkezésére. A mIRC indítása utáni első lépésként meg kell adnunk annak az IRC szervernek a nevét amelyre kapcsolódni kívánunk. Magyarországon a három legnépszerűbb szerverek a következők: irc.bmehu, ircschbmehu, darmoleltehu Ezek közül bármelyikre felléphetünk, hiszen ezek egymással – és persze az IRC hálózat többi szerverével - szoros kapcsolatban állnak, így a nyilvános csatornákat mindegyikükön megtaláljuk. Elméletileg lehetőségünk van (speciális esetekben – pl. zárt csatornák

– szükséges is) külföldi szerverekre is fellépni, de nyilvános, bármely IRC szerverről elérhető csatornák esetén inkább magyar szervert válasszunk. Így egyrészt kevésbé terheljük a hálózatot és gyorsabban érkeznek meg az üzenetek hozzánk, másrészt a nyilvános célú szerverek nagy része ellenőrzi, hogy milyen földrajzi helyről csatlakozunk rá, és ha úgy ítéli meg, hogy nem az “ő körzetébe” tartozunk akkor egyszerűen nem enged belépni. 23 Amennyiben először indítottuk a mIRC-et úgy még néhány adatot meg kell adnunk, hogy rá tudjunk kapcsolódni a kiválasztott szerverre. A kitöltendő mezők a következők: • real name (valós név) ide a nevünket írjuk be (persze nem kell feltétlenül az igazit) • e-mail – amennyiben nincs e-mail címünk, úgy “n/a”-t írjunk ide • nickname – a használni kívánt becenév • alternate – amennyiben a feni becenév már használatban van, úgy ezt próbálja meg

használni Olyan becenevet érdemes választani, amilyent valószínűleg senki más nem használ a hálózaton, hiszen egyéb esetben nem fogunk tudni fellépni a szerverre, vagy ha éppen nem is ütközünk másokkal – mert nem egy időben használjuk az IRC-t – de sokan össze fognak téveszteni bennünket azonos becenevű társunkkal, aminek elég kellemetlen következményei is lehetnek. Az olyan slágerek, mint pl. “Jani”, “Tomi” stb nem valószínű, hogy be fognak jönni – e helyett érdemes inkább valami egyedi “művésznevet” kitalálni, vagy a nevek előtti, utáni speciális karakterekkel (pl. [], , stb) játszadozni A fenti adatok megadása után máris ráléphetünk a kiválasztott szerverre. Sikeres kapcsolódás után a mIRC felhozza az általa ismert legnépszerűbb csatornák listáját, amelyből kiválaszthatjuk, hogy melyiken kívánunk csevegni. Mivel ez alapesetben egyetlen magyar csatornát sem tartalmaz, ezért mindjárt kezdjük a

következő néhány csatorna felvételével: • #alpina • #erdely • #hungary • #internetto • #viccparty 24 A #magyar csatornára is ráfigyelhetünk, de szerintem mindenki aki rálép erre, egy idő után rá fog jönni, hogy ez nem egészen az amire feltétlen szüksége van Egyébként amennyiben kíváncsiak vagyunk rá, úgy a /list parancs kiadásával kilistázhatjuk az összes, az éppen kapcsolódó szerver keresztül elérhető csatorna nevét, de készüljünk fel rá, hogy a teljes lista kiírása sok esetben egy percet is igénybe vehet A csatorna kiválasztása vagy nevének beírása után a mIRC egy új ablakot nyit. Minden kliens ablak három jól elkülöníthető részből áll. Jobb oldalt a csatornára bejelentkezett kliensek becenevei láthatóak. Alul a saját üzenet- ill parancs-szerkesztő sorunk található, míg az ablak fennmaradó részét a magát a csatornán folyó beszélgetést tartalmazó üzenet-ablak található. Az üzenet

ablakban megjelenő első sor általában a belépésünkről tudósító: “* [nickname] has joined channel #channel” üzenet, amelyet az éppen aktuális témáról (topic) tudosító üzenet, majd a többi kliens által küldött, magát a beszélgetést jelentő üzenetek követnek. Amennyiben a csatornának még egyetlen tagja sem volt – mi hoztuk létre – úgy automatikusan mi válunk a csatorna operátoráva, amit becenevünk előtti “@” is jelölni fog. Ha már létező csatornára lépünk be, úgy a belépés után illik a többieket köszönteni: írjuk be az üzenet-sorba, hogy “sziasztok!”, nyomjunk egy Enter-t és üzenetünk máris megjelenik a saját és az összes többi – a csatornára éppen bejelentkezett – felhasználó képernyőjén. Az üdvözlésekre általában nem szokás reagálni (elég hülyén nézne ki ha minden egyes belépésre mind a 200 aktív kliens visszaválaszolna) – így ezt egyszerűen vegyük nyugtázottnak. Mielőtt

elkezdünk mi is “beszélni” praktikus néhány üzenet-váltás kivárni - hogy egyáltalán lássuk éppen miről beszélnek – és csak ez után bekapcsolódni a témába. Alapvetően tartózkodjunk az erőszakos megnyilvánulásoktól és a vulgáris kifejezésektől. Amennyiben mégsem tesszük ezt úgy előbb-utóbb egyik vagy másik chanelop kirúg (/kick) minket a csatornáról. Bár a kitiltás ez a fajtája csak átmeneti (csak az aktuális kapcsolatot szakítja meg, így később újra be tudunk jelentkezni a csatornára) de kitartó “munkával” elérhetjük, hogy meghatározott időre permanensen vagy akár végleg kitiltsanak (/ban) minket a csatornáról. Amennyiben a beszélgetés során valakivel esetleg “négyszemközt” szeretnénk megtárgyalni valamit úgy egyszerűen egy DCC (Direct Client Chat – Közvetlen Kliens-Csevegés) csatornát kell nyitnunk az adott felhasználó felé. Ugyancsak a DCC segítségével nyílik lehetőségünk fájlok

átküldésére is, bár ettől alapvetően tartózkodjunk, mert elég erősen leterheli a hálózatot. 25 A fenti rövid kis ismertetés korántsem teljes – mindössze egy kis kiindulópontot szerettem volna nyújtani a kevésbé kísérletező kedvű felhasználóknak az IRC-n történő barangoláshoz. Aki tud angolul annak mindenképpen érdemes átnéznie az mIRC súgóját, hiszen még nagyon sok hasznos funkcióval rendelkezik, amiről itt egy szó sem esett. A CD-n egyébként megtalálható az IRC protokoll teljes leírása az RFC1459.HTM-ben , ill egy AliasesINI file is melyet a mIRC alkönyvtárunkba bemásolhatunk (az eredetit mentsük el!), és számos hasznos funkcióval gazdagodhat chatelésünk. A bemásolás (és a mIRC újraindítása) után próbáljuk ki pl a /b1 Hello! (vagy /b1, /b2, ., /b9) kapcsolókat, ill nézzük meg a Tools/Aliases menüpontot a részletesebb parancsok megismerése végett Az Internet klasszikus alkalmazásai IV. NEWS A NEWS

rendszer – vagy ismertebb nevén a USENET – nem más, mint egy hatalmas, világméretű vitafórum. A teljes fórum jól elkülöníthető, témájuk és ennek megfelelően kialakított nevük alapján szoros (fa-)hierarchiába szervezett ún. hírcsoportok (newgroups) sokaságából áll. A felhasználók által a hírcsoportokba küldött üzenetek (messages) ill cikkek (articles) a USENET szerverek világméretű hálózatába jutnak ahonnan aztán a hírcsoport többi tagja igénye szerint letöltheti azokat, majd esetleg azokra reflektálva – vagy újabb témát ill. kérdést felvetve – maga is üzeneteket küldhet a fórumon keresztül a többiek felé. A USENET maga folyamatosan változik és átalakul amint újabb és újabb hírcsoportok kerülnek létrehozásra, 26 és az információk cseréje fórumok egyre szélesebb skáláján zajlik. Több mint 25000 hírcsoportjával és mintegy 20 millió felhasználójával pillanatnyilag a világ legnagyobb osztott

rendszerű elektronikus hirdetőtáblájának tekinthető. Maga a USENET az Internettől független hálózat – számos, az Internettel közvetlen kapcsolatban nem álló (pl. vállalati intranet) szerverrel rendelkezik, de természetesen a legnagyobb forgalmat azon keresztül bonyolítja. Érdemes megemlíteni, hogy a USENET-tel párhuzamosan napjaikban is létezik az üzenetszórásos levelezés egy másik, a hírcsoportok elődjének tekinthető formája: az ún. levelezési listák. Bár az átlagos felhasználó számára e két rendszer működése szinte azonosnak tűnhet, jelentős eltérés mutatkozik technikai megvalósításukban, céljukban és egyéb tulajdonságaikban. A klasszikus levelezési listák esetében a postázni kívánt cikkeket egy előre meghatározott e-mail címre kell elküldeni, ahol is azt a mail-szerver annak fogadása után – esetleg egy lista-moderátor közbeiktatásával - továbbítja a listára feliratkozott felhasználók e-mail címeire,

mindegyiküknek egy-egy példányt elküldve az eredeti levél - általában az eredeti feladóra vonatkozó fejléc- ill. a listára vonatkozó lábléc-információkkal kiegészített – másolatát. Érdemes észrevenni, hogy e módszer a részben vagy teljesen azonos hálózati úton elérhető felhasználók esetében redundáns módon, azaz a szóban forgó hálózati szakaszon teljesen feleslegesen több, azonos példányt is továbbít, ami egy bizonyos számú listatag esetén már jelentős időbeli eltéréshez (ez rossz esetben akár több óra is lehet) vezethet az üzenet feladása ill. fogadása között Ezzel szemben a USENET a rendelkezésre álló sávszélességet jóval effektívebben használja ki. Ez egyrészt annak köszönhető, hogy a USENET-en belül az üzenetek azok olvasása előtt kizárólag magukon a hír-szerveren kerülnek tárolásra, tehát letöltésükig nem foglalnak feleslegesen helyet a fogadó postaládájában. (Ennek köszönthetően többek

között nem jelentkezhet az, a levelezési listák esetében egyébként előforduló probléma, hogy egy vagy több tag nem kap meg bizonyos üzeneteket, mert – ciklikus ürítés hiányában - a posta-ládájának fenntartott tárterület megtelt, és így a posta-ládát üzemeletető gép “visszadobta” azt.) Másrészt az NNTP protokoll kialakítása lehetővé teszi, hogy a hír-csoportok tagjai az összes postázott üzenet közül – azok fejléce alapján – kiválaszthassák, hogy mely üzeneteket kívánják elolvasni, ezáltal is kiküszöbölve az érdektelen (egyébként valószínűleg azonnal törlésre kerülő) üzenetek felesleges továbbítását a kliens felé. (Bár ez utóbbi módszer megvalósítására elméletileg hagyományos posta-ládák – tehát levelezési-listák esetén – is lehetőség lenne, azonban mivel maga a mail-protokoll nem ilyen célra került kialakításra, így a legtöbb levelezőprogram nem nyújt lehetőséget a

felhasználók számára a letöltendő üzenetek interaktív szelektálására.) 27 Ugyanakkor, mivel a levelezési listák létrehozásához elegendő egyetlen – akár viszonylag kis teljesítménnyel rendelkező – az Internet-re kapcsolódó szerveren egyetlen ún. mailer-daemon futtatása, így az nélkülözi a NEWS rendszer centralizált menedzsmentjét, ami jóval dinamikusabb és szabadabban formálható kialakítást tesz lehetővé. Még egy érdekes szempontot érdemes megemlítenünk a különbségek esetén: a disztribúció szkópját. Ahhoz, hogy egy levelezési lista üzeneteit megkapjuk fel kell iratkoznunk a listára Ez azt jelenti, hogy egy, a listára postázott üzenetet kizárólag azok kapják meg, akik az eredeti üzenet fogadásának pillanatában a levelezési lista tagjai voltak. Ezzel szemben a USENET nyílt fórum: bárki, aki el képes érni a globális hálózat valamely szerverét lehetősége nyílik az adott szerver által “futtatott”

hírcsoportokra küldött üzenetek fogadására ill. maga is azonnal képessé válik azokra üzenetek küldésére. Itt kell megjegyeznünk, hogy bár a levelezési listákhoz hasonlóan a hírcsoportokba is fel kell iratkoznunk, de ez a feliratkozás kizárólag a helyi szerveren kerül adminisztrálásra és kizárólag belső célokra. (Ez azt jelenti, hogy az üzenet feladója a USENET-en – egy levelezési listával ellentétben – technikailag képtelen megállapítani üzenet fogadóinak listáját, hiszen az “előfizetők” listája nincs globális szinten, centralizáltan menedzselve.) Ráadásul a USENET szerverek a postázott üzeneteket lejártukig (expire) - ált legalább egy hétig - meg is őrzik, ami elméletileg lehetővé teszi a később feliratkozók számára akár korábban feladott üzenetek megtekintését is. Általánosságban elmondható, hogy viszonylag alacsony tagszám (max. 100-150) és nem túl magas forgalom (max. 50-100 üzenet naponta) esetén

hírcsoport létrehozása helyett jóval célszerűbb egy egyszerű levelezési lista üzemeltetése. A hírcsoportoknak alapvetően két fajtája létezik: a moderált ill. a moderálatlan csoportok Ez utóbbiak közös jellemzője, hogy a rájuk postázott üzenetek – korlátozás nélkül - automatikusan továbbításra kerülnek a USENET világhálózat felé. Ezzel szemben a moderált csoportok mindegyike egy vagy több ún. moderátorral rendelkezik, aki(k) a csoportba érkező üzeneteket tartalmuk és stílusok alapján megszűri(k): a tartalmi (pl. a csoport témájához nem kapcsolódó, durva kifejezéseket v. egyéb antiszociális megnyilvánulásokat tartalmazó) vagy formai (pl csatolt bináris állományok, az csoportban alkalmazandótól eltérő nyelv használata, stb) okból megjelentetésre alkalmatlannak tartott üzeneteket egyszerűen nem engedik tovább a hírcsoport felé. Mint arról a korábbiakban már szó volt: a USENET hírcsoportjai témájuk alapján

szoros hierarchiába vannak szervezve. Minden hírcsoportot egy pontokkal elválasztott szavakból álló név azonosít (pl. altcompannounce), amely egyben magában foglalja az adott hírcsoporton 28 folyó “beszélgetések” témáját is. A hierarchia legmagasabb szintjén az első pontot megelőző szó adja: ez határozza meg, hogy az adott hírcsoport a USENET mely legnagyobb alcsoportjába tartozik. Ilyen globális alcsoport például az alt (alternative –egyéb kategóriába be nem sorolt), a sci (scientific – tudományos) vagy a rec (recreational – szórakozás). A legmagasabb szint aztán természetesen további alszintekre bomolhat amelyet a főcsoport nevét követő pontokkal elválasztott szavak jelölnek. A hierarchián belül a hírcsoportok száma természetesen változó, de általában valahol a hierarchia 3. és 6 szintje között helyezkednek el A hírcsoportokba küldött – és moderált csoportok esetén a moderátorok által elfogadott –

üzenetek a USENET globális szerver-hálózatába kerülnek. A klasszikus hír-terjesztési modellben a szerverek ún. telítéssel (flooding) terjesztik egymás között az üzeneteket, azaz a beérkezett új üzeneteket a szerver továbbítja minden vele közvetlen kapcsolatban álló szerver felé, amelyek azután azokat szintén további szerverekhez küldik el. Ez a terjesztési módszer azonban az Internet hálózati topológiájában erősen redundáns üzenettovábbításhoz vezetne, hiszen egy-egy szerver akár több százszor is megkapná ugyanazt az üzenetet, ami a rendelkezésre álló sávszélesség komoly pazarlásához vezetne. Ezzel szemben a USENET-en alkalmazott NNTP (Network News Transfer Protocol – Hálózati Hírtovábbítási Protokoll) egy interaktív mechanizmust biztosít a szerverek közötti hírcsere lebonyolítására, amelynek segítségével minimalizálható az adatforgalom és elkerülhető a redundáns hírküldés. Egy tipikus NNTP kapcsolat

során egy új üzeneteket a hálózaton propagálni kívánó, vagy új üzenetek érkezését ellenőrizni kívánó gép egy kapcsolatot kezdeményez egy másik USENET szerver felé. A kapcsolat felépítése után a kliensnek lehetősége nyílik az esetlegesen létrehozott új hírcsoportok, valamint az utolsó kapcsolat óra érkezett üzenetek lekérdezésére. Végül a szerver áltál elküldött válasz alapján a kliens kezdeményezheti a számára még ismeretlen üzenetek elküldését amelynek befejezése után a kapcsolatot lezárja. Ennek következtében ténylegesen csak azok az üzenetek kerülnek majd átvitelre a kapcsolat során amelyek még nem érkeztek már meg egy esetleges másik csatornán a klienshez. A hírcsoportokban történő aktív részvétel előtt érdemes a következő tanácsokat megfogadnunk: • Ismerkedjünk meg alaposabban a news kliens-programunkkal! Így könnyen elkerülhetjük a téves kezelésből adódó akaratlan postázásokból ill.

egyéb félreértésekből adódó bonyodalmakat (ne feledjük, hogy leveleinket akár több millióinyian is olvashatják) • Olvassuk el a hírcsoport FAQ-jét (Frequently Asked Questions – Gyakran Ismételt Kérdések)! E dokumentumot direkt az új felhasználók által feltett leggyakrabb 29 kérdésekből és az azokra adott válaszokból állítják össze. Ezzel elkerülhetjük, hogy “hülyének állítsuk be magunkat” a többiek előtt valamint gyorsan és “fájdalommentesen” megismerkedhetünk a hírcsoport egyedi szabályaival és szokásaival is. A Proxy szerver Bevezető LASSÚÚÚ!!!! Hányszor kiáltunk fel így, bosszankodva amikor a WWW böngészőnkkel egyegy távoli szerveren kalandozunk és alig győzzük kivárni amíg a kért oldal megjelenik a képernyőnkön. Persze hogy lassú, miért is lenne gyors amikor - szerencsére - olyan sokan, egyre többen használjuk a hálózatot, de sajnos a távközlési vonalak kapacitása igen korlátos. A

kedvenc WWW pedig sokat fogyaszt, egy-egy szép (vagy csúnya) színes oldal letöltése igen nagy mennyiségű adat átvitelét igényli. Hogyan lehet segíteni ezen a problémán? Hogyan lehet a “nagy fogyasztású” alkalmazásokat úgy használni hogy a hálózatot ne terheljük agyon? Természetesen kézenfekvő megoldás lenne a távközlési vonalak kapacitásának megfelelő bővítése. Csakhogy ez elsősorban pénzkérdés, mivel az ilyen vonalak ma Magyarországon hihetetlenül drágák. Másik megoldás a hatékonyság növelése, és ezzel együtt a takarékoskodás Mivel a legnagyobb fogyasztó a WWW, a legjobb eredményt a WWW forgalom hatékonyságának javításával érhetjük el. Ennek egyik kitűnő módja a WWW cache-ek alkalmazása. Világszerte előtérbe kerültek az ilyen rendszerek, még azon országokban is ahol lényegesen nagyobb sávszélességű Internet kapcsolatok szolgálják a felhasználókat. Magyarországon sincs semmi akadálya annak

hogy minél többen igénybe vegyék ezt a korszerű eszközt és ezáltal még jobban használhassuk a Hálózatot. Mi az a cache? A "cache" fogalommal gyakran találkozunk a korszerű számítástechnikai rendszerek leírásánál. A szó eredeti jelentése “rejtekhely”, és ez némileg utal a cache funkciójára is. A cache egy olyan nagyon gyors működésű tároló, amelyben a gyakran használni kívánt adatokat átmenetileg tároljuk (“rejtjük”) azért mert így azokhoz sokkal gyorsabban hozzáférhetünk mintha mindig az eredeti, lassabb elérésű forráshoz kellene nyúlnunk. Manapság leggyakrabban a korszerű mikroprocesszor architektúrák leírásánál találkozunk a cache fogalommal. A processzor és a memória között elhelyezkedő gyorsítótárba bekerült 30 utasítás- és adatbyte-ok hozzáférési ideje nagyságrenddel kisebb mint a normál memóriában levőké, és a hozzáférés a rendszerbuszt sem terheli. (1 ábra) 1. ábra -

Cache a számítógép architektúrában Nem csak a memória működését szokták cache-el gyorsítani. Gyakran találkozunk egyéb, pl szoftver segítségével megvalósított cache-ekkel is. Legjellemzőbb példa erre a UNIX operációs rendszer kernelének ún. buffer-cache mechanizmusa, amely az operációs rendszer diszk kezelését gyorsítja meg. (2 ábra) Szoftver cache-eket alkalmaznak többek között a TCP/IP protokollcsomaghoz tartozó ARP (Address Resolution Protocol) és a DNS (Domain Name Service) protokollokban is. 2. ábra - Cache az operációs rendszer architektúrában A cache mechanizmus igen hatékonyan használható az Internet információs rendszerek működésének gyorsítására és a nagy távolságú hálózati összeköttetések sávszélességével való takarékoskodásra is. Az ilyen Internet cache-ek felállítása különösen a World Wide Web rohamos elterjedésével került előtérbe. A WWW igen nagy sávszélesség igényű alkalmazás, és a

forgalom cache-elésével a működés gyorsítható, a hálózat terhelése csökkenthető. A HTTP protokoll alkalmas arra hogy a WWW szerverek és kliensek közé ún. WWW cache-eket iktassunk. 31 Hogyan működik a WWW cache? A HTTP cache szerver használata esetén a WWW kliens (böngésző) nem közvetlenül az eredeti forráshoz fordul amikor egy objektumot le akar tölteni, hanem egy úgynevezett cache szerverhez (HTTP cache, proxy szerver). A cache szerver ellenőrzi hogy a kívánt objektum megtalálható-e a saját lokális tárolójában (a cache-ben) és ha igen, akkor azt innen adja és nem a forrás WWW szerverről tölti le. Ezáltal nem kell a sokszor igen leterhelt és ezért lassú működésű nemzetközi vagy belföldi nagy távolságú összeköttetéseket igénybe venni és ezzel tovább terhelni. Mivel egy cache szervert sok felhasználó használ, ezért jó esélye van annak hogy a kívánt objektumot nem sokkal előttünk valaki már lekérte és így az

bekerült a cache-be és ott megtalálható. Egyetlen független cache szerver használata esetén is a találati arány általában >20%, azaz legalább minden ötödik lekérdezni kívánt objektum a cache-ben megtalálható. Ha az objektum még sincs a cache-ben, akkor a cache szerver vagy más közeli cache szerverektől próbálja meg azt letölteni (hierarchikus cache rendszer) és továbbítani a kérdező WWW böngésző programnak, vagy az eredeti forráshoz (WWW szerverhez) fordul. 3. ábra Független, intézményi cache szerver Az együttműködő cache szerverekből nagy hatékonyságú hierarchikus cache rendszer építhető ahol a találati arány még nagyobb mint a független cache szervereknél (gyakran 30% fölé emelkedik). A hierarchikus cache rendszerbe kapcsolt cache szerverek együttműködnek, egymással szomszéd vagy szülő-gyerek viszony alapján kommunikálnak. A párbeszédre egy külön erre a célra kifejlesztett Internet protokollt, az ICP-t

(Internet Cache Protocol) használják. A felhasználók WWW kliens programjaiban konfigurálható az hogy melyik cache szervert vegyék igénybe. 32 Nem csak a HTTP, hanem az FTP és gopher forgalom is cache-elhető, és a legtöbb cache szerver és WWW kliens erre lehetőséget ad. Mindazonáltal a leghatékonyabb működés - épp a forgalom volumene miatt - a HTTP cache-eléssel érhető el. Hogyan használjuk? A WWW cache használata igen egyszerű. A legtöbb elterjedt WWW böngésző (kliens) programot (Netscape, Mosaic, Lynx, Internet Explorer) könnyű úgy konfigurálni hogy cache szervert (proxy-t) vegyen igénybe. Figyelem: most nem az adott böngésző lokális cache-éről van szó (amely sokkal kisebb hatékonyságú), hanem az igazi, külső cache szerverről (proxy szerver)! Az egyetlen adat amire szükségünk van az a legközelebbi, általunk is használható cache szerver domain neve és a cache szolgáltatás számára felhasznált TCP port száma. (A port

szám leggyakrabban - persze facto szabványként - a 3128.) A hálózati értelemben (hálózati összeköttetés szempontjából) vett legközelebbi cache szerverről van szó, előfordulhat hogy földrajzi értelemben nem ez a legközelebbi. Általában egy-egy intézmény, cég üzemeltet cache szervert a saját felhasználóinak a kiszolgálására. Rendszerint egy cache szervert csak egy meghatározott, a szerver üzemeltetője által megszabott felhasználói kör vehet igénybe. (Ennek főként gazdasági okai vannak.) Ezért nem minden cache szervert használhat mindenki Tételezzük fel hogy az általunk használni kívánt cache szerver neve: cache.SLDhu (ez fiktív név, ilyen nevű cache a valóságban nem létezik!) Ebben az esetben a cache használatának konfigurálása a népszerűbb WWW kliensek esetében a következő: Netscape 2.*, 3.*: Menüből kiválasztható konfigurációs ablak: Options -> Network Preferences -> Proxies -> Manual Proxy Configuration

(View) Az "FTP Proxy, Gopher Proxy és HTTP Proxy" mezőkbe rendre be kell írni azt hogy "cache.SLDhu", a "Port" mezőkbe pedig azt hogy 3128 Mosaic 2.7: Menüből kiválasztható konfigurációs ablak: Preferences -> Proxy A "HTTP Proxy Server, FTP Proxy Server, Gopher Proxy Server" mezőkbe rendre be kell írni azt hogy "http://cache.SLDhu:3128/" Lynx 2.4: 33 Állítsuk be a "http proxy, ftp proxy és gopher proxy" környezeti változókat a következő értékre: http://cache.SLDhu:3128/ MS Internet Explorer 2.10: Menüből kiválasztható konfigurációs ablak: View -> Options -> Proxy A "HTTP, Gopher és FTP" ablakokba be kell írni azt hogy "cache.SLDhu", a kis ablakokba pedig azt hogy 3128. A legtöbb browser esetében még megadható az is hogy mit NEM akarunk a cache-en keresztül lekérdezni (pl. a saját WWW szerverünket) Ezt követően böngészőnk már használja is a cache-t.

Ez valószínűleg meg fog nyilvánulni abban is hogy sok dokumentum gyorsabban töltődik le mint korábban. Ha valamilyen ok miatt szeretnénk kikényszeríteni azt hogy ne a cache-be már korábban letöltött, hanem biztosan az eredeti forrásból származó legfrissebb dokumentumot kapjuk, akkor használjuk a böngésző “reload” funkcióját. Ekkor a cache újra letölti az eredeti objektumot A cache szerverek rendszerint maximum 24 órán át tárolnak egy objektumot, azt követően - ha az megváltozott igény esetén újra letöltik. Így semmiképpen sem fordulhat elő az hogy egy napnál régebbi dokumentumot kapjunk, de azért ez egy kicsit kínos is lehet, mondjuk ha egy tőzsdei információ már egy napos akkor nem ér semmi J Előnyök, hátrányok Minden éremnek két oldala van. Ennek is, de az egyik szerencsére sokkal fényesebb Vizsgájuk meg tehát a cache használatából származó előnyöket és hátrányokat is. Előnyök • A WWW dokumentumok

elérése gyorsabbá válik. Mivel a statisztika szerint legalább minden ötödik letöltendő dokumentum a cache-ben már megtalálható, ezek - ha az eredeti forrás nagy távolságra van, vidéki vagy nemzetközi vonalakon érhető csak el sokkal gyorsabban érkeznek. A többi objektum esetében a letöltés sebessége ugyanakkora mint cache használata nélkül. (A cache szerverek által hozzáadott késleltetés olyan kicsi hogy nem érzékelhető.) • A belföldi és nemzetközi Internet vonalak túlterheltségének csökkenése. Nagyon sok dokumentum ugyanis ahelyett hogy sokszor - minden hozzáféréskor - áthaladna ezeken a 34 vonalakon, csak egyszer okoz forgalmat. A vonalak terheltségének csökkenése egyébként azt is jelenti, hogy minden egyéb forgalom - az is amelyik nem cache-elhető - gyorsulni fog! • Költségmegtakarítás. Az információtovábbítás - különösen nagy távolságra - igen költséges dolog. A megtakarított forgalommal tehát

jelentős költségmegtakarítás is elérhető. Hátrányok • Ritkán ugyan, de megtörténhet hogy egy-egy WWW oldalnak nem a legfrissebb verzióját kapjuk, hanem legfeljebb egy nappal régebbi változatát. Ez akkor fordulhat elő ha az eredeti dokumentumot megváltoztatták azóta amióta azt a cache tárolja. Mivel a cache-ek általában legfeljebb egy napig tárolják a HTML szövegeket majd szükség szerint újra frissítik, a napi gyakorisággal változó oldalak esetén okozhat ez leginkább problémát. A WWW adatbázisok dokumentumainak túlnyomó többsége azonban “statikus”, azaz nagyságrendekkel ritkábban változik. • A dinamikusan (az oldalra való hivatkozás pillanatában) generálódó dokumentumokkal nincsen probléma mert ezeket a cache-ek amúgy sem tárolják, tehát mindig az eredeti példányt töltjük le! • Ha gyanús hogy esetleg nem a legfrissebb dokumentumot látjuk és ki akarjuk kényszeríteni az eredeti letöltését, a böngésző

“reload” funkciójával ezt bármikor megtehetjük. • Vannak olyan esetek amikor egy-egy dokumentum letöltése során a böngészővel nem lehet a “reload” funkciót előidézni. Pl olyankor amikor nem HTML dokumentumot töltünk le hanem valami mást, rendszerint a diszkre vagy egy külső megjelenítő program számára. (pl amikor FTP helyett használjuk a WWW böngészőnket és olyasféle fájlokra hivatkozunk hogy: cikk.ps, MS-CSODAEXE, szoftvertargz, stb) Ilyen esetekben ha újra kellene tölteni, nem használhatjuk a “reload” funkciót (mert a böngészőkben nem implementálták) és ezért mindig a cache-ből kapjuk az esetleg elavult vagy hibás fájlt. Ilyenkor az a megoldás hogy az adott fájl letöltése idejére ki kell kapcsolni a böngészőnkben a cache használatát. A HUNGARNET cache hierarchiája 35 A magyar kutatói IP hálózat, az NIIF által üzemeltetett HUNGARNET bekapcsolódhatnak a HUNGARNET hierarchikus WWW cache rendszerébe. 4.

ábra Ez a cache rendszer jelenleg maximum három szintű. A felső szinten található az NIIF parent cache szerver, a cache.iifhu> (a helkaiifhu gépen) amelyen pillanatnyilag a Squid 11 verziója fut és 5 Gbyte diszket valamint 200 Mbyte operatív memóriát használ az objektumok tárolására. A cacheiifhu szolgálja ki a nagyobb vidéki és budapesti tagintézményekben már működő lokális cache szerverek kéréseit. Egyes nagy sávszélességű összeköttetéssel rendelkező budapesti cache szerverek egymást szomszédokként is használják. A cache.iifhu elegendő erőforrással és teljesítménnyel valamint jó hálózati kapcsolatokkal rendelkezik ahhoz hogy a központi cache szerepét ellássa. A fenti struktúra alkalmas arra hogy mind a külföldi, mind a belföldi vidéki vonalakon jelentős sávszélesség megtakarítást érjünk el. Az NIIF részt vesz a TERENA által koordinált CHOICE projektben, melynek célja a cache rendszerek építésének

összehangolása, és a jövőbeli összekapcsolásuk egy nagy európai cache rendszerré. A HUNGARNET cache hierarchiáját, az abba kapcsolódó cache szervereket a tagintézmények felhasználói vehetik igénybe, sőt, kell hogy igénybe vegyék, mivel ez a saját érdekük és a közös érdek egyaránt. 36 Cache szerver felállítása Kinek és hol érdemes cache szervert felállítani? Cache szerverek felállítása elsősorban ott célszerű ahol a kisebb vagy nagyobb helyi hálózaton (LAN) többen is használják a WWW-t és a hálózatot a külvilággal (Internettel) összekötő vonal kapacitása időnként vagy rendszeresen szűknek bizonyul. Tipikusan tehát intézményekben, cégeknél, Internet szolgáltatóknál. A cache szervert a hálózat olyan pontján kell felállítani amely jó (gyors) összeköttetéssel rendelkezik a külvilág felé. A magyarországi akadémiai hálózatot üzemeltető ill. koordináló NIIF Műszaki Tanácsa erőteljesen szorgalmazza a

tagintézményekben a lokális cache szerverek felállítását. Mi kell egy cache szerver felállításához? Hardver: egy megbízhatóan üzemelő, UNIX operációs rendszerű gép. Bármilyen manapság elterjedt architektúra és UNIX verzió alkalmas. (LINUX is!) Nincs szükség túl nagy CPU kapacitásra (sebességre)! A fontos az hogy legyen elegendő memória ( >= 16 Mbyte a cache számára) és diszk (min. 50 Mbyte) A szükséges diszk kapacitás függ a cache-t használók számától is, de túlságosan túlméretezni nem érdemes a diszkterületet mert attól NEM lesz jobb a cache! Nem feltétlenül szükséges a cache szerver számára külön gépet dedikálni. A cache mellett a gépen egyéb alkalmazások is futtathatók. Szoftver: több elterjedt, akadémiai környezetben ingyen használható cache szoftver van: • CERN httpd • Apache httpd • Harvest Cached 1.4 • Squid A fentiek közül a CERN httpd használatát nem ajánljuk mivel teljesítménye

lényegesen elmarad a többitől és hierarchiában is csak korlátozva használható. A Squid 11 a legújabb, és a Harvest Cached 1.4 továbbfejlesztéseként jött létre 37 Az IPX/SPX protokoll A Novell 1982-es indulásakor már számos egyedi hálózati kommunikációs protokoll létezett, melyek meglehetősen széles skálán helyezkedtek a sebesség, az egyszerűség és a kompatibilitás/hordozhatóság tekintetében. A Novell szakemberei hosszas mérlegelés után a Xerox által kidolgozott XNS protokoll mellett tették le voksukat és erre alapozva dolgozták ki saját IPX (Internetwork eXchange Protocol – hálózatok közti adatcsere protokoll) kommunikációs protokolljukat. Az IPX datagram, azaz csomag-alapú hálózati kommunikációs protokoll. A protokoll a csomagok céljának ill. forrásának azonosítására egy 12-bájtos címzési sémát alkalmaz Ez a 12 bájt három részre bontható: a 4-bájtos hálózati címre (amely a hálózati szegmenst

azonosítja), a 6-bájtos node-címre (ami a hálózaton belül a csomópontot azonosítja) valamint a 2-bájtos socketcímre, Ez utóbbi funkciója annak meghatározása, hogy a célállomáson futó process-ek (folyamatok) közül melyik kapja ill. küldte a csomagot (Ezek meghatározása elvileg teljesen önkényes lehet, de érdemes a Novell ill. más gyártók által fenntartottakon kívüli egyedi azonosítót használni a más programokkal történő ütközések kivédésére.) A $FFFFFFFF node-szám megadásával szórt (broadcast), azaz nem csak egy, hanem a szegmensen belüli minden állomáshoz eljutó üzenetek küldésére is lehetőségünk nyílik. A protokoll – mint az nevéből is kiderül – képes a különböző hálózati szegmensek között is csomagok továbbítására. Az IPX csomag a továbbítandó adatokon kívül magában hordoz egy ún IPX-fejlécet is, amely a szegmensek közti vándorlás során is megőrződik és változatlanul tartalmazza több

információ mellett a forrás- ill. a cél-állomás címét Ez azért fontos, mert csomagok küldésekor ill. fogadásakor azonban közvetlenül (!) nyilvánvalóan csak az azonos hálózati szegmensben elhelyezkedő csomópontnak küldhetünk ill. csak azoktól kaphatunk csomagokat. Ezek a csomópontok azonban természetesen lehetnek szegmenseket összekötő bride-ek is, amelyek ez esetben nem csak az aktuális, de egy másik hálózat részei is – ott egy másik címen láthatóak. A bridge a csomagot megkapva azt a másik hálózatban útjára indítja, ahol azt vagy a tényleges célállomás kapja meg vagy folytatja útját egy újabb bridge-en keresztül afelé. A hálózati topológia és az ennek megfelelő ún csomag-továbbítási útvonalak (routing pathways) nyilvántartása a hálózati operációs rendszer feladata – nekünk evvel nem kell törődnünk, de minden egyes csomag elküldése előtt meg kell kérdeznünk tőle az ún. local target (helyi cél) címet,

azaz azt, hogy hova az aktuális (!) szegmens mely csomópontjához kell elküldenünk csomagunkat a célállomás felé. 38 Fontos megkötés, hogy míg a szegmensen belüli maximális csomag-méretet a hálózati kártya általában 1KB-ban – limitálja, addig a szegmensek közötti forgalom maximális csomag-mérete 576 bájt. Így érdemes inkább fixen 576 bájtos maximális csomag-mérettel dolgozni, mert így szegmens-közi kommunikáció esetén sem dobja vissza az összekötő bridge a csomagjainkat. Természetesen az ezt meghaladó mennyiségű adatot több csomagban vagyunk kénytelenek elküldeni. Az IPX-szel szemben az SPX (Sequenced Packet eXchange – sorozatos csomag-csere) egy magasabb szintű stream-jellegű, kapcsolat-orientált protokoll. Az SPX az IPX-re épül, azaz amikor egy csomagot küldünk, akkor az SPX protokoll azt a belső adminisztrációs munkák elvégzése után az IPX felé továbbítja. Az SPX garantálja a csomagot átvitelét, azaz a

túloldali SPX-től érkező (vagy éppenséggel nem érkező) válasz függvényében a csomagot újra elküld(het)i. E mellett az SPX a küldött ill fogadott csomagot egy-egy sorozatszámmal is ellátja amely lehetővé teszi az esetleg csomag-vesztések detektálását a fogadó oldalon is. Ezen tulajdonságai rendkívül előnyössé teszik a kliens/szerver-architektúrákban történő felhasználásra, azonban jelentős feldolgozási időt vesznek igénybe és ennek megfelelően jelentősen - akár felére is - lassítják a kommunikációs sebességét. A kommunikáció A kommunikáció megkezdésekor először is meg kell nyitnunk egy új socket-et az IPXOpenSocket függvény segítségével. A megnyitás során meg kell adnunk a socket-számot ill azt, hogy a programból történő kilépés esetén az magától (pontosabban az “IPX-től”) bezáródjon, vagy maradjon nyitva (TSR programok). Az IPX a csomagok érkezéséről ill küldéséről egy kiegészítő

struktúrákon, az ún. ECB-ken (Event Contol Block – esemény-vezérlő blokk) segítségével kommunikál a felhasználói programokkal. Ha sikerült a socket-et megnyitnunk (nem léptük túl az egyszerre nyitva tartható socket-ek max. számát ill nem volt már eleve nyitva) akkor egy ún. listen-ECB-t (“fülelő-ECB”-t) kell nyitnunk az IPXListenForPacket segítségével amelyiken keresztül az IPX az esetlegesen beérkező csomagokról értesíthet minket. Minden egyes csomag beérkezése után újabb listen-ECB-t kell nyitnunk (amely persze lehet ugyanazon a területen, mint az előző) az újabb csomagok fogadásához. Hasonlóan, amennyiben csomagot szeretnénk küldeni úgy ezt egy megfelelő ECB felépítésével és annak az IPXSendPacket-nek történő átadásával tehetjük meg. (Fontos, hogy az ECB-ben célállomásként ne a tényleges, hanem az IPXGetLocalTarget által visszaadott címet adjuk meg. Amennyiben a tényleges célállomás az aktuális hálózati

szegmensben helyezkedik el, úgy ez a függvény azt, 39 míg egyéb esetben a célállomás hálózatához vezető, az aktuális szegmensben is jelenlevő bridge címét adja vissza.) A funkció-hívásból történő visszatérés nem feltétlenül jelenti a csomag elküldésének megtörténtét – erról csak az ECB megvizsgálásával szerezhetünk információt. Az tényleges elküldés után a csomag ECB-je megsemmisíthető, vagy helyette újabb hozható létre ugyanazon a memória-területen. Az ECB egyébként lehetőséget nyújt arra, hogy a csomag érkeztekor vagy továbbításakor egy általunk meghatározott rutin (melynek címét előzetesen az ECB-ben tároltuk) hajtódjon végre (megszakítás-szerűen) ezáltal feleslegessé téve az ECB-k állapotának állandó monitorozását. Az esetlegesen megnyitott, de még fel nem használt ECB-ket az IPXCancelEventsegítségével “vonhatjuk ki a forgalomból” ami után szabadon megsemmisíthetők. A

kommunikációt és a socket-et az IPXCloseSocket függvény meghívásával zárhatjuk le. A mellékletben (a forráskód.zip-ben) található IPXSPXPAS ()unit a fent felsorolt függvényeken és eljárásokon kívül egy objektumot is rendelkezésre bocsájt, aminek segítségével gyerekjátékká válik a kommunikáció még azok számára is, akiknek esetleg nem minden volt teljesen világos a fentiekben. Mindenki bátran kísérletezzen a unit és az IPXCHAT forráskódjával (Forráskód.ZIP) (Ja, és bár első látásra jó ötletnek tűnhet, de senki ne kísérlezetten azzal, hogy ugyanazon a gépen a Windows egyik taszkjából a másikba üzenetet küld – sajnos nem fog menni.) Az eredeti NetBIOS (Network Basic Input/Output System – hálózati alapvető ki-/beviteli rendszer) az IBM által a PC-khez gyártott LAN adaptereken ROM-ba égetett, a teljes - az OSI modell mind a 7 rétegét lefedő - hálózatkezelést megvalósító interface volt, amit azonban az idők

során továbbfejlesztettek és számos kiegészítéssel láttak el. A NetBIOS egy magas szintű, - kódméret szempontjából – kényelmesen programozható hálózati felület, ami sikerrel működhet akár más protokollokra épülő emuláció formájában is (pl. a Novell NetBIOS emulátora a parancsok végrehajtásánál valójában az IPX-et használja a csomagok átvitelére hálózaton), amely azonban nem alkalmas sebesség-kritikus valamint több hálózati szegmensre is kiterjedő kommunikációra. A NetBIOS napjainkban az Internet és a többszegmenses intranetek térhódításával veszt jelentőségéből, azonban még ma is szinte minden elterjedt hálózati operációs rendszer támogatja használatát. A NetBIOS lehetőséges nyújt mind kapcsolat-orientált, mind kapcsolat nélküli (üzenetszórásos) adatforgalom bonyolítására a hálózaton névvel azonosított (címzett) csomópontok között. A NetBIOS nevek 16 bájtos karakterláncok, melyek az alábbi két

nagy csoportba oszthatók. 40 az egyedi nevek (unique names) hálózati csomópontok azonosítására használhatók, melyekből ennek megfelelően mindig csak egy lehet a hálózati szegmensben. A hálózati név regisztrációja során a NetBIOS először mindig ellenőrzi, hogy a név már használatban van -e a hálózaton, ezáltal elkerülve az azonos nevek által okozott címzési konfliktusokat. a csoportnevek (group names) ezzel szemben akár több állomás által is használhatóak. Segítségükkel lehetőség nyílik a hálózati csomópontok egy jól meghatározott részhalmaza számára üzenetek küldésére. Amikor az üzenet küldése során célcímként egy csoportnevet adunk meg, akkor azt a csomagot minden, a csoportnevet használó munkaállomás megkapja. Natív (nem emulált) NetBIOS protokoll alkalmazása esetén a kommunikáció során a hálózat minden egyes csomópontja megkap minden elküldött üzenetet, amelyek közül aztán a NetBIOS felső

rétegei az egyedi név ill. a “csoport-tagságok” vizsgálatával döntik el, hogy továbbítsák -e a kapott csomagot az alkalmazási réteg felé vagy sem. Ennek megfelelően minden munkaállomás egy vagy több névvel rendelkezhet melyek között több egyedi és több csoportnév is lehet. A kommunikációnak szintén alapvetően két fajtája létezik: a kapcsolat nélküli (connectionless) kommunikáció során diszkrét, egyedi adatcsomagok ún. datagramok küldésére nyílik lehetőség más munkaállomás vagy csoport felé. A csomag vétele esetén a fogadó oldal(ak) semmilyen nyugtázást nem küld(enek) vissza, így nem garantált a csomag megérkezése a célállomásra sem. A csomag küldése során a specifikus (egyetlen állomásnak v. csoportnak szóló) küldési mód mellett lehetőségünk nyílik az IPXből már ismert broadcast üzenetek küldésére is, melyet minden – az broadcast üzenetekre figyelő - munkaállomás feltétel nélkül megkap. ennél

jóval magasabb szintű és biztonságosabb (de egyben lassabb) kommunikációra nyújt lehetőséget a kapcsolat-orientált (connection-oriented) üzenetváltási mód. A kapcsolat felépítésének kezdetén a munkaállomásnak egy ún. session-t kell nyitnia két név (egyedi vagy csoportnév) között. A session sikeres megnyitása után mind a két fél küldhet üzenetet egymásnak, melynek megérkezését (vagy a küldés sikertelenségét) a protokoll felügyeli, nyugtázás hiányában hibakódot visszaadva a küldő félnek. A NetBIOS protokoll lehetőséget nyújt az alkalmazások számára mind szinkron, mind aszinkron kommunikáció megvalósítására. A két mód a NetBIOS parancsok végrehajtásának módjában tér el egymástól. Szinkron mód alkalmazása esetén az alkalmazói program a parancsok sikeres végrehajtásáig (v. a timeout-ig) nem kapja vissza a vezérlést az interface-től Tipikusan szinkron parancs pl. a név hozzáadása, hiszen az alkalmazás

futása annak sikerétől v sikertelenségétől 41 függ. Ezzel szemben aszinkron parancsvégrehajtás esetén a hívás után az interface azonnal visszaadja a vezérlést a hívó alkalmazásnak, míg a parancs végrehajtásáról a későbbiekben gondoskodik. Ez esetben a parancs kiadásakor alkalmazott NCB (NetBIOS Conrol Block – NetBIOS vezérlő-blokk) vizsgálatával, vagy egy speciális ún. POST-rutin segítségével lehet észlelni a parancsvégrehajtásának megtörténtét valamint kimenetelét. Az interface Mint arról már szó volt a NetBIOS interface ún. NCB-kel kommunikál az alkalmazásokkal – ezek segítségével nyílik lehetőség a parancsok kiadására. Az NCB felépítése és mezőinek jelentése a következő: NCB Offset Méret Leírás 00h 1 Parancskód 01h 1 Visszatérési kód (végrehatási kód szinkron, inicializációs kód aszinkron parancs esetén) 02h 1 Helyi session-azonosító (az azonosítót a session megnyitásakor kapjuk

meg) 03h 1 Helyi név-azonosító (a név hozzáadásakor kapjuk meg) 04h 4 Pointer az adat-pufferre 08h 2 Adat-puffer mérete 0Ah 16 Hívónév (a célállomás v. –csoport azonosítója) 1Ah 16 Helyi név (csak név felvételekor v. törlésekor használt) 2Ah 1 Fogadási timeout ? másodpercekben (max. ennyi ideig vár egy csomag megérkezésére) 2Bh 1 Küldési timeout (? másodpercekben) 2Ch 4 POST-rution címe (ha más mint nil, akkor a parancs befejezése után erre a címre adja át a vezérlést) 30h 1 Hálózati(-adapter) azonosító (csak több adapter alkalmazása esetén van jelentősége) 31h 1 Befejezési kód (aszinkron parancsok esetén FFh a feldolgozás alatt) 32h 14 Fenntartva (a hálózati illesztő számára, belső célra) 42 A NetBIOS parancskódok és jelentéseik a következők: Kód Név Leírás 10h CALL Új session nyitása két név között 11h LISTEN Várakozás CALL-ra (session nyitására másik fél

által) 12h HANGUP Session lezárása 14h SEND Adat küldése egy session-ön keresztül 15h RECV Adat fogadása egy session felől 16h RECVANY Adat fogadása bármelyik session felől 17h SENDCH Két puffer küldése session-ön keresztül egyetlen paranccsal 20h SENDDG Datagram küldése 21h RECVDG Datagram fogadása 22h SENDBRC Broadcast datagram küldése 23h RECVBRC Broadcast datagram fogadása 30h ADDUNIQ Egyedi név hozzáadása a helyi név-táblához 31h DELNAME Név (egyedi és csoport) törlése a helyi táblából 36h ADDGRP Csoportnév hozzáadása a helyi táblához 32h RESET Adapter inicializásála és helyi névtáblázat törlése 33h STATUS Adapter állapotának és hibastatisztikájának lekérdezése 34h SESSSTAT Helyi session-ök állapotának lekérdezése 35h CANCEL Végrehajtás alatt álló (aszinkron) parancs visszavonása 37h ENUM Adapterek felsorolása 78h FIND Név keresése a hálózaton 79h TRACE

NCB-követés ki-/bekapcsolása Amennyiben a parancskód 7. bitje 0 (parancskód<128) úgy azt szinkron, míg bekapcsolt állapota mellett aszinkron módon hajtja végre. Reset A parancs alaphelyzetbe állítja és konfigurálja a NetBIOS session-réteget. A megengedni kívánt session-ök maximális számát (1-32) az NCB 02h ofszeten elhelyezkedő (helyi session-azonosító) mezőjében, míg az egyeszerre feldolgozás alatt álló parancsok maximális számát (szintén 1-32) a 03h ofszeten lévő (helyi-név azonosító) mezőbe kell tölteni a hívás előtt. A parancs meghívásakor minden session megszakad, a helyi név-tábla törlésre kerül és az összes várakozó 43 állapotú parancs megszakításra kerül. (Amennyiben a NetBIOS fölött az alkalmazásunkon kívül más réteg is elhelyezkedett – pl. a hálózati op rendszer – akkor az ettől a parancstól természetszerűen “lehal” – ennek megfelelően óvatosan kell bánni ezzel a paranccsal.) Cancel

A parancs segítségével egy, már feldolgozás alatt álló – a session layer által egy NCB híváson keresztül átvett – de még végre nem hajtott parancsot lehet visszavonni. A parancsot csak szinkron-módban lehet kiadni és a RESET, CANCEL, ADD NAME, ADD GROUP NAME, DELETE NAME, SESSION STATUS, SEND DATAGRAM, SEND BROADCAST parancsok kivételével bármely parancsra alkalmazható. (Érdemes itt megjegyezni, hogy bár a SEND és a CHAIN SEND parancsok is visszavonhatók, de visszavonásuk egyben a session megszakítását (lezárását) is maga után vonja.) Adater status E parancs segítségével nyílik lehetőségünk a helyi vagy akár egy távoli NetBIOS session layer hiba-statisztikájának, állapotának és név-táblázatának lekérdezésére. A parancs végrehajtása előtt a lekérdezni kívánt gép egyedi azonosítóját (nevét) vagy a helyi session layer lekérdezése esetén a “*”-ot kell elhelyezni a 0Ah ofszeten kezdődő hívónév mezőbe. Add

unique name A név-táblázathoz történő egyedi azonosító hozzáadására nyílik lehetősgünk a parancs segítségével. A parancs végrehajtása során a NetBIOS a teljes hálózatot átnézni, hogy a megadott (maximum 16 karakter hosszú) név nincs –e már használatban valahol. Amennyiben talál a megadottal egyező csoport- vagy egyedi nevet, abban az esetben a 0Dh (duplikált név) hibakódot kapjuk, egyébként pedig a név felvétele mellett egy egyedi (1-254) azonosítóval tér vissza a helyi név azonosító (03h) mezőben. Add group name Új név-csoport létrehozására vagy egy már létező csoportba történő belépésre nyílik lehetőségünk a parancs segítségével. A parancs sikeres végrehajtásának feltétele, hogy a megadott név ne legyen már egyedi névként regisztrálva a hálózaton (csoportnévként nyilvánvalóan lehet, hiszen a csoport lényege, hogy több gép is bele-tartozhat és a csoportnévnek küldött üzeneteket, minden ilyen

csoportnevet definiáló gép megkapja). 44 Delete name Egy már regisztrált egyedi vagy csoport-név a helyi név-táblázatból történő törlésére ad módot a parancs. Amennyiben a névet egy vagy több nyitott session használja, úgy az nem azonnal, hanem a csak a session-ök automatikus bezására után került törlésre, de addig is minden e név használatával kiadott parancs a 17h (a név már törlésre került) hibakódot fogja visszaadni. Call A parancs segítségével nyílik lehetőségünk egy helyi és egy másik név közötti session létrehozására. A kapcsolat sikeres felépítéséhez a hívónév mezőben megadott gépnek e parancs kiadása (v. a time-out lejárta) előtt egy LISTEN parancsot kell(ett) kiadnia az általunk használt helyi (vagy bármilyen (“*”) ) névre. A sikeres kapcsolatfelépítés esetén visszaadott helyi session-azonosító segítségével küldhetünk ill. fogadhatunk csomagokat a másik gép felől, illetve ennek

segítségével tudjuk a session lezárni a HANGUP paranccsal. Listen A parancs kiadásával utasítható a session layer egy beérkező session-nyitási kérelem fogadására. A kérelem fogadását egy specifikus vagy bármilyen névhez (“*”) köthetjük, melyet az NCB hívónév mezőjében kell elhelyeznünk. (Amennyiben egyedi nevet adtunk meg, úgy csak egyetlen, a megadott névtól a mi gépünk felé érkező session-nyitási kérelem került fogadásra, minden más session-felépítési próbálkozás sikertelen lesz.) Egy név illetve egy név-pár között akár több session is nyitható melyek egymástól teljesen függetlenül menedzselhetők. (Amennyiben egy bejövő session-nyitási kérelem (CALL) egy specifikus és egy bármilyen névre vonatkozó LISTEN-nek is megfelel, abban az esetben – az esetlegesen eltérő aktiválási sorrendtől függetlenül – a specifikus LISTEN parancs fog végrehajtódni.) Hangup A parancs egy már megnyitott session

lezárására használható. A session lezárását mind a hívó (aki a CALL-t aktiválta), mind a fogadó (aki a LISTEN-t aktiváltva) fél kezdeményezheti, melynek hatására a másik fél által a szóbanforgó session-re vonatkozó parancsok a 0Ah (session lezárva) hibakóddal fognak visszatérni. 45 Session status A parancs egy adott névvel (akár hívó, akár fogadó félként) megnyitott session-ök, illetve azok paramétereinek lekérdezésére használható. Send A parancs segítségével nyílik lehetőségünk egy másik géppel megnyitott session-ön keresztül adat-csomag küldésére. A csomag sikeres átviteléhez a célállomásnak legalább egy RECEIVE vagy RECEIVE ANY parancsot kell aktiválnia a parancs kiadása vagy a session megnyitásakor megadott küldési time-out lejárta előtt. A session layer a send parancsokat kiadásuk sorrendjében hajtja végre. Amennyiben egy csomag átvitele sikertelen, a session automatikusan bontásra kerül a küldő fél

által. Receive A parancs segítségével nyílik lehetőségünk egy másik géppel megnyitott session-ön keresztül adat-csomag fogadására. Amennyiben a session megnyitásakor megadott időn belül a másik oldal nem aktivál egy SEND parancsot, abban az esetben a parancs 05h (time-out) hibakóddal tér vissza. (A fogadási time-out – a küldésivel szemben – nem vonja maga után a session bontását) A RECEIVE parancsok kiadási sorrendben lesznek teljesítve elegendő számú fogadott csomag esetén, de amennyiben egy csomag egy RECEIVE és egy RECEIVE ANY parancsnak is megfelel, abban az esetben a RECEIVE parancs fogja megkapni. Amennyiben az NCB-ben megadott pufferméret túl kicsi a teljes fogadott csomag eltárolásához úgy a pufferméretnek megfelelő rész-csomag fogadása mellett a parancs 06h (data buffer to shoort) hibakóddal tér vissza. Receive any A parancs használatával több vagy az összes nyitott session-ön keresztül érkező adat-csomag fogadására

nyílik lehetőségünk. A fogadás feltételeire a RECEIVE parancsnál leírtak érvényesek. Sikeres fogadás esetén az NCB 02h ofszeten kezdődő (helyi session-azonosító) mezője annak a session-nek a számát tartalmazza, amelyiken keresztül a csomag érkezett. Send datagram A parancs segítségével kapcsolaton (session-ön) kívül küldhetünk csomagot egy, az NCB 0Ah ofszetén kezdődő (hívó-név) mezőjében meghatározott állomásnak vagy csoportnak. A NetBIOS 46 implementáció nem feltétlenül garantálja a csomag megérkezését a célállomás(ok)ra. Az átvitendő csomag mérete nem haladhatja meg az 512 bájtot. (Bizonyos NetBIOS implementációkban és alkalmazási környezetekben annyira rossz az átviteli biztonság, hogy az e módon elküldött és sikeresen fogadott csomagok aránya az 50%-ot sem éri el. Receive datagram A parancs segítségével a kapcsolaton kívül küldött csomagok fogadására nyílik lehetőségünk. Amennyiben a 03h ofszeten

elhelyezkedő (helyi név-azonosító) mező 0ffh értéket tartalmaz úgy bármely, egyébként pedig az által meghatározott névre érkező csomagot fogadhatjuk a parancs kiadásával. A parancs nem rendelkezik time-out-tal, így visszavonásáig aktív marad Sikeres csomag-fogadás esetén a küldő állomás által használt nevet a 0Ah ofszeten kezdődő (hívó-név) mező tartalmazza. Send broadcast A parancs segítségével minden aktív RECEIVE BROADCAST paranccsal rendelkezdő állomásnak történő üzenetküldésre nyílik lehetőségünk. A maximális csomagméret nem haladhatja meg az 512 bájtot. A parancs tipukus felhasználása a hálózaton jelenlévő szerverek enumeráltatása, vagy egy specifikus gép keresése. Receive broadcast A parancs segítségével a SEND BROADCAST segítségével szétszórt üzenetcsomag fogadására nyílik lehetőségünk. A RECEIVE DATAGRAM-hoz hasonlóan e parancs sem rendelkezik timeout-tal és sikeres fogadás esetén a

hívó-név mezőben tartalmazza küldő állomás nevét. 47