Hálózati címfordítás, NAT

Láthattuk, hogy a 32 bites címzéssel nagyjából 2.000.000.000 végpontot lehet megcímezni, de azt is láttuk az el˝oz˝oekben, hogy nagyjából 4.500.000.000 felhasználó van. Ez alapján nem jut minden felhasználónak IP cím. Az IP sikeres m˝uködéséhez viszont elengedhetetlen, hogyegy IP cím csak egy helyen legyen használva. Gondoljuk a postás analógiára, ha ugyanazt a címet többször is használjuk, akkor a postás nem tudná, hogy az azonos címek mögött lév˝o különböz˝o emberek közül kinek és hova kézbesítse a levelet (pl.: Budapesten vannak azonos nev˝u utcák, melyeket a kerület tesz egyedivé). Az IP címtartomány kimerülése nem mai probléma, még a 1990-es évek második felében felmerült a forgalomirányító tábla méret robbanással együtt. A címtartomány kimerülésére akkor “ideiglenes” megoldást dolgoztak ki, mert a végs˝o, korrekt megoldásnak az IPv6-ot szánták (a maga 128 bites címtartományával). Ez az “ideiglenes” hack azóta is m˝uködik és annyira sikeres, hogy az IPv6 penetrációja még mindig 30% alatti. Az ötlet lényege az volt, hogy kezeljük az IP címeket és UDP/TCP portokat együtt. Egy-egy IP címhez 65.000 TCP és 65.000 UDP port tartozik. Az így létrejöv˝o címtartomány kell˝oen nagy. Az egyes programok, operációs rendszerek azonban külön kezelik (helyesen) az IP címet és a TCP vagy UDP portot. Ezen címek összevonására és kicserésélésre köztes dobozokat helyeznek a hálózatba. Ezen dobozok a bejöv˝o/kimen˝o IP címeket és portokat más IP címre és portra cserélik mindkét irányban. Ezt nevezik NAT - hálózati címfordításnak (network address translation). Ezt az ötletet valósították meg új címosztályok és új hálózati elemek/funkciók kialakításával. Az IP címtartományból kiválasztottak 3 tartományt, amelyek szabad felhasználásúvá váltak.Ezek a privát címtartományok. Ezek nem

5.11: Privát címtartományok

egyediek világszinten, ezeket bárki bárhol használhatja. Ezzel megoldódott a hálózat hozzáférési részein a címtartomány kimerülése, hiszen ezeket a tartományokat bárki újrahasznosíthatta. Ezen címeket tartalmazó csomagok azonban értelemszer˝uennem küldhet˝oek tovább az interneten, mivel több helyre is mehetnének. Itt jönnek képbe az új elemek. A megoldás lényege, hogy ahogyan azt leírtuk eddigi állapotmentes rendszerben beiktatunkköztes dobozkat (middle box), amelyek állapottartóak ésátírják a rajtuk áthaladó csomagok cél és forrás címét, illetve cél és forráspontját. Azaz a helyi hálózat és az Internet hozzáférési pont között (vagy mélyebben ez a CGNAT) van egy olyan eszköz amely a privát IP cím és port párokat publikus IP cím port párra cseréli a kifelé tartó csomagokban és ugyanezt megteszi visszafelé is. Az hogy mit mire cserélt ki, amemória táblában van nyilvántartva (állapot tartás). Így ha a szolgáltatótól kapok egy darab publikus IP címet az otthoni hálózatomban ehhez a címhez és küls˝o porjaihoz rendelhetek 65000 darab eszközt amennyiben mindegyik egy-egy kapcsolatot tart fenn. Összegezve tehát, a privát IP cím tartományokkal és a köztes dobozokkal (NAT átjáró) megoldódott az IPv4 címtartomány kimerülése. Mert itt egy-egy IP cím mögé 65.000 másik címet tudok elrejteni. A NAT szembe megy az Internet filozófiájával, ha ugyanis egy NAT átjáró újraindul, akkor az összes rajta keresztülmen˝o adatfolyamot újra kell indítani, mert nem tudja, hogy melyik címet melyik címre és portra cserélt le. Nagyobb gond az, amikor a NAT mögött lév˝o eszközök egymással szeretnének beszélgetni. Ilyenkor különböz˝o eljárásokra van szükség, hogy megtalálják egymás publikus IP/port párját. Van olyan eset is, amikor ez nem lehetséges. Ennek ellenére ma az Interneten lév˝o eszközök nagyon nagy hányada (90% feletti része) NAT mögött van.

5.12: NAT m˝uködése¹ 5.3.5 Dinamikus cím kiosztás (DHCP)

Láthattuk, hogy a cím tartományokat az IANA osztja ki a különböz˝o szervezeteknek, akik ezt felbontják és eladják, majd ezt újra felbontják és újra eladják. Ez azonban csak logikai kiosztás volt.

Arra továbbra sem válaszoltunk, hogy ha elindul egy PC, akkor az honnan tudja hogy mi az ˝o IP címe.

Erre a problémára több megoldás is van különböz˝o környezetekben. A legelterjedtebb megoldás a DHCP - dinamikus host konfiguráló protokoll - (dynamic host configuration protocol) protokoll. Ez egy kliens-szerver protokoll. A kliens címet kér, a szerver pedig ad neki egy címet. Az

5.13: DHCP m˝uködése¹

IP protokollal kapcsolatban eddig csak a pont-pont kommunikációs képességr˝ol beszéltünk, azaz egy állomás megcímez egy másik állomást. Ezt nevezikegyes küldésnek (unicast). Van azonban olyan eset is, amikor egy állomás mindenkinek szeretne üzenet küldeni. Ez Internet méretben persze értelmetlen, az ilyen forgalmat a forgalomirányítók nem továbbítják, de helyi hálózaton az ilyen kommunikációs paradigma teszi lehet˝ové a P2P szerver mentes megoldások megvalósítását. Amikor egy állomás mindenkihez szólni szeretne, aztüzenetszórásnak (broadcast)nevezzük. A DHCP esetén is ez jelenti a megoldást. A PC elindul és nem tud a világról semmit sem. Elkezd “kiabálni”

hogy kér egy IP címet. Ezt minden, az adott alhálózaton lév˝o állomás megkapja és a szerver meg is érti, majd válaszol is rá. Az üzenetszórásnak speciális IP cím van minden hálózaton dedikálva (minden host részen lév˝o bit 1-es értékkel). Az ilyen csomagokat minden gép, amely megkapta feldolgozza. Az üzenetszórás egy finomabb formája acsoportküldés (multicast), ilyenkor nem mindenkinek, hanem csak a csoportnak szól. Ekkor az egyes állomások amelyek megkapják (ha el˝otte nincs intelligens eszköz, amely csak a célokhoz küldi ki), megnézik, hogy a célcím által leírt csoport érdekli-e ˝oket. A csoportküldésnek egy speciális címtartomány van kijelölve amely, hasonlóan a privát címtartományokhoz, helyi jelent˝oség˝u. A DHCP protokollban a kliens tehát csoportküldés, vagy üzenet szórás segítségével kér címet. A szerver nem örökre, hanem adott id˝ore

adja bérbe a címet a kliensnek. Ezt is üzenetszórás csatornán hirdeti meg. A kliens kérésére több szerver is válaszolhat.Ez egy jó példája annak, hogy hogyan lehet magas rendelkezésre állást megvalósítani protokoll szinten (több szerver is lehet, ezeknek nem kell egymásról tudnia).

A kliens ezután kiválasztja a címet amelyet újra üzenetszórással, vagy csoportküldéssel tudat a szerverekkel. A kiválasztott szerver által adott IP címet az a szerver nyugtázza.

Fontos A forgalomirányítók nem továbbítják az üzenetszórás és csoportküldés csomagokat.

Ez nem véletlenül van így, az ilyen tartományt, ahol mindenki hallja mindenki kiabálását, üzenetszórási tartománynak (broadcast domain)nevezzük. Célszer˝u teljesítmény és biztonsági okok miatt a hálózatot minél kisebb üzenetszórási tartományokra bontani.

Ez a bontás akkor jelenthet gondot, ha nincs minden üzenetszórási tartományban DHCP szerver (ami valószín˝u), ez esetben több megoldási lehet˝oség is van. Az egyik, hogy a forgalomirányítót bekonfiguráljuk aDHCP üzenetek továbbítására (DHCP relay). A másik gyakori eset, hogy maga aforgalomirányító játssza el a DHCP szerepet. A DHCP protokoll nem csak IP címek kiosztására szolgál, hanem itt lehet meghirdetni a helyi DNS szerver címét, a helyi nyomtatót, az alhálózati maszkot és sok egyéb paramétert is.A DHCP az eszköz menedzsment els˝o szintje.

5.3.6 IPv6

Az IPv6 protokoll tervezésekor nem szerettek volna forradalmat csinálni, csak az IPv4 hiányosságait szerették volna kiküszöbölni az új protokollal. A 5.14 ábrán látható, hogy bár a WWW-vel egyid˝os, korántsem futott be olyan sikeres életutat. Ma is csak 30% alatti az elterjedtsége (azaz azon eszközök száma, amelyek IPv6 hálózathoz is hozzáférnek). Nincs az IPv4-hez összemérhet˝o világméret ˝u IPv6-os gerinc. Több helyen hiába szeretne adott helyi hálózat vagy felhasználó IPv6-ot használni, ha a szolgáltatója nem biztosít ilyen szolgáltatást. Az IPv6 legfontosabb újításai:

5.14: IPV6 penetráció, csomagformátum

• 128 bites címtér: ez ma kifogyhatatlannak tartott címtér. Gyakran két 64 bites részre osztják, az els˝o 64 bit a prefix - hálózati cím, míg a második 64 bites rész pedig az eszköz hardver azonosítója.

• nincs csomag darabolás: van de alapértelmezésben nem támogatja az IP csomagok darabonkénti továbbítását

• nincs fejléc ellen˝orz˝o összeg: ezen összeg számítása minden egyes csomag továbbítása esetén igen komoly dedikált hardver megoldást igényelt az IPv4-nél. Itt a hop count csökkentése után nem kell újraszámolni a CRC-t, mert nincs.

• fejléc szkóp: az opcionális fejléceket nem kell minden egyes ugrásnál feldolgozni, vannak olyan fejlécek, amelyek csak a végállomáson feldolgozandók.

• nincs üzenetszórás: viszont van egy új kommunikációs paradigma a bárkinek küldés (anycast), ekkor egy csoportnak küldi az állomás de elegend˝o ha a csoportagokból csak egy

állomás kapja meg. Ilyen lehet pl.: a DNS kérés elég ha egy DNS szerver megkapja. A kliensnek meg elegend˝o tudnia egy világszinten elfogadott DNS szervereknek szánt anycast címet.

Az IPv6 ma még szigetekként jelenik meg az IPv4 tengerben. Ezen szigetek között leginkább alagutakkal teremtik meg a transzparens összeköttetést. Az alagút bejáratánál IPv4-es csomagba teszik az IPv6-os csomagot, míg a kijáratnál a beérkez˝o IPv4-es csomagból kiveszik az IPv6-os csomagot és azt továbbítják.

5.15: IPv4 alagút IPv6 csatorna részére¹

5.3.7 Általánosított továbbítás - Szoftverrel Definiált Hálózat - SDN

A fent vázolt elvek alkalmazása: állapotmentes forgalomirányító, gyors döntés a cél cím alapján, sokáig elegend˝o volt az Internet gerincén de még mélyebben, a hozzáférési hálózatokban is. Ahogy azonban megjelentek a plusz funkciókat megvalósító köztes dobozok, egyre bonyolultabbá vált a hálózatok menedzsmentje. Külön elv mentén ment a forgalomirányítás és továbbítás, külön elv mentén az olyan funkcionalitások mint az NAT, t˝uzfal, adott folyamok megkülönböztetése, HTTP szint˝u terheléselosztás stb. Egy másik kritikus terület a felh˝o szolgáltatók világa, ahol a nagyon nagyfokú virtualizációt a hálózati virtualizációnak is követnie kellett volna. Itt nagyon nem váltak be a klasszikus számítógép hálózati protokollok. Ezen problémák megoldására két irányból kezdtek el egy jóval dinamikusabb, programozhatóbb megoldást fejleszteni. Az adatközpontok irányából érkezett az SDN szoftverrel definiált hálózat (software defined networking). A távközlés világából érkezett azNFV hálózati funkcionalitás virtualizálás (network function virtualization). Az SDN megközelítésmóda vezérlés és az adattovábbítás elkülönítésér˝ol szól.

Az adattovábbítás továbbra is a hálózati eszközök dolga, de a vezérlés ki van szervezve jellemz˝oen egy felh˝o alapú platformra. A vezérl˝o algoritmusok, protokollok fejlesztése sokkal gyorsabb, err˝ol a következ˝o fejezetben b˝ovebben írunk. Magával a konkrét fizikai eszközzel, annak megvalósításával nem foglalkozik. Az NVF más utat követett, a f˝o cél itt minden virtualizációja egyvirtualizációs réteg felett (hypervisor)megjelenik olyan mint virtuális forgalomirányító, virtuális kapcsoló, stb...

A továbbiakban az adathálózatokban jóval elterjedtebb és praktikusabb SDN-nel foglalkozunk.

Az SDN nem csak a vezérlést szervezi ki, hanem az egyes hálózati eszközökben új képességet is specifikál. Ez azáltalánosított továbbítás (generalized forwarding). A forgalomirányító tábla helyett folyamtáblánk van amely találat - akció (match - action) alapon írja le egy-egy folyam kezelési módját. A találat szemben a klasszikus továbbítás IP célcím fókuszával, mely ezzel csak a 3. rétegbéli információra fókuszál, itt 3 réteg mez˝oit öleli át (L4,3,2). Ezzel egy helyen mindhárom réteg információira hivatkozó szabályokat lehet megadni. A mez˝ok a 5.16 ábrán láthatóak. Ilyen

5.16: Hálózati réteg adatsík vs. vezérl˝osík, általánosított továbbítás sz˝ur˝o mez˝ok¹

szabály lehet például a 5.16 ábrán látható, mely az egyes bemeneti porton érkez˝o csomagoknál azokat, amelyek a 10.3.x.x cím tartományból érkeztek és a 10.2.x.x címtartományba mennek, továbbítja a 4. porton. Az alapvet˝o akciók az alábbiak lehetnek:

• továbbítás: adott portján továbbítja

• eldobás: t˝uzfal funkcionalitás

• mez˝o módosítás: ilyen lehet a NAT megvalósítása A témával részletesebben foglalkozunk a vezérl˝osík fejezetben.

5.4 Hálózati réteg: vezérl˝osík

Az el˝oz˝o fejezetben láttuk, hogy a helyi döntések vagy a forgalomirányító tábla vagy a folyam tábla alapján történnek meg. Egy igen fontos kérdés az, hogy hogyan és ki tölti és ki frissíti ezeket a táblákat? Gondoljunk bele, hogy ezen tábláknak valamilyen módon konzisztensnek kell lennie.

Legyen A és B forgalomirányító, problémát okoz ha az A forgalomirányító úgy gondolja hogy B felé kell adott forgalmat terelnie míg a B szomszéd meg úgy gondolja, az A helyes irány. Ekkor hurok alakul ki.Fontos, hogy a forgalomirányító táblák konzisztens és a valóságnak megfelel˝o világképet képviseljenek. Ezzel a feladattal foglalkozik a vezérlés.

5.4.1 Bevezet˝o

Ahogyan láttuk a vezérlés lehetelosztottésközpontosított. Elosztott vezérlés esetén a forgalomirányítók egy-egy szoftvert futtatnak és ezek a szoftverek egymással együttm˝uködve kialakítják a világképüket és ez alapján mindegyik kitölti a helyi forgalomirányító táblát. Ez egy valós P2P rendszer központi szerver nélkül, csak az egyenrangú szoftverek együttm˝uködéséb˝ol tud építkezni. Ezen szoftvere forgalomirányító protokollokat valósítanak meg, ezen protokollok mentén kommunikálnak egymással. A másik irány az SDN/NFV ahol a vezérlés egy központban van kihelyezve, itt nem kell P2P algoritmust megtervezni és megvalósítani, az elosztott rendszer komplexitása el van fedve alattunk (SDN vezérl˝o platform pl.: OpenDaylight).

5.4.2 Forgalomirányító protokollok

A klasszikus hálózatokban és az internet gerincében ma ilyen protokollok biztosítják a forgalomirányító táblák helyes tartalmát.

Fontos A hálózati réteg forgalomirányító és link szinten modellezi a hálózatot. E modell absztrakt reprezentációja egy gráf amely csomópontjai a forgalomirányítók, míg élei linkek. Az

éleknek súlyai vannak, ezek mentén kell meghatározni a legrövidebb útvonalat (G=(N,E)).

A csomópontok nem hordoznak fontos információt az útvonalválasztás számára ezzel szemben az élek súlya kritikus fontosságú. Hogyan mérjük a jó útvonalat? Mi a legrövidebb útvonal? Egy naiv megközelítés lehet a távolság mérésére az ugrásszám (A és B pont között található forgalomirányítók száma), ez azonban nem veszi figyelembe a linkek kapacitását. Vegyük akkor figyelembe a linkek kapacitását. Mi a jobb egy leterhelt nagy sávszélesség˝u link vagy egy üres kis sávszélesség˝u vonal.

Gyorsan eljutottunk oda, hogy valamilyen fizikai mennyiség dinamikus változó értéke lehet a legjobb metrika. Azt is láttuk azonban, hogy nagyon fontos a forgalomirányítókon átível˝o tudás, / információ homogenitása - azaz minden forgalomirányító ugyanazt kell, hogy lássa a világról.

Minél változékonyabb metrikákat választunk ez annál nehezebben valósítható meg. Majd látni fogjuk, hogy nincs egy mindenhol alkalmas metrika. A hálózat különböz˝o szintjein különböz˝o metrikákat alkalmaznak.

5.17: Hálózat gráf modell¹

A forgalomirányító protokollokat többféleképpen tudjuk csoportosítani. Els˝o körben a dinamizmus alapján a forgalomirányítás lehet:

• statikus- ekkor az útvonalak be vannak égetve és nem függnek az aktuális valóságtól. Ez egy nagyon kedvez˝otlen megközelítésnek t˝unhet - nem alkalmazkodik a valósághoz. Ahol azonban nincs alternatív útvonal ilyenek például a vég hálózatok, ahol csak egy Internet kijárat van ott célszer˝u ilyen egyszer˝u forgalomirányítást használni. Használjak ezt nagy léptékben is amikor adott típusú forgalmakat adott szabályok szerint szeretnének terelni.

• dinamikus- ez a legtermészetesebb, a világképe dinamikus és ez alapján alakítja a forgalomirányító tábláját.

Az információ pontossága alapján lehet:

• globális: Ez esetben a résztvev˝o forgalomirányítónak globális és részletes ismerete van a hálózat adott részleteir˝ol. E megközelítésmód el˝onye a pontosság, mivel minden forgalomirányító tud mindenkir˝ol mindent (kinek milyen szomszédai vannak, ezek között milyen linkek vannak), ezért itt minden egyes helyi döntés tökéletes szinkronban van. Ez a megoldás bár jónak t˝unik a skálázhatósága miatt, csak adott méret˝u hálózatig alkalmazható (egyrészt a túl pontos ismeret folyamatos fluktuációt okoz a rengeteg részlet ismerete miatt - miért kell nekem tudnom a legtávolabbi forgalomirányító összes interfészének adott állapotát?, másrészt komoly terhelés okoz az állapotinformáció folyamatos elárasztása). Ebbe az

osztályba tartoznak alink-állapot (link-state)alapú forgalomirányító algoritmusok.

• pletyka alapú vagy lokális: Itt senkinek sincs pontos információja, mindenki csak feldolgoztt információt ad át (pl.: “azt hallottam, hogy t˝olem balra x távolságra van a Z hálózat”). Ilyen információval nem lehet egy teljes hálózati gráfot felépíteni, de mivel fel van dolgozva, ezért az atomi változások kevésbé propagálódnak. Ennek a megoldásnak viszont komoly problémája a konvergencia, azaz hogy mennyi id˝o után lesz minden forgalomirányítónak egységes a világképe. Egyes esetekben soha sem lesz az. Ebbe az osztályba tartoznak a távolságvektor (distance vector) és a távolság - út vektor (distance - path vector) algoritmusok.

Alink állapot alapú protokollokalapja az, hogy minden forgalomirányító ismeri minden forgalomirányító szomszédjait és az ezekhez tartozó távolságokat, metrikákat. Ennek az információnak a kialakítása általában elárasztásos megoldással valósul meg: minden változásnál mindenkinek elküldi a változásokat az adott forgalomirányító. Így kialakul minden forgalomirányítóban a G(N,E) gráf adathalmaza. Ezen a gráf adathalmazon futtatja le minden egyes forgalomirányító aDijkstra féle feszít˝ofa keres˝o algoritmust. Így alakítja ki mindenki saját számításokkal a forgalomirányító táblát.

A Dijkstra algoritmus rövid összefoglalása látható a 5.18 árbrán. A jelölések a következ˝oek: D(v) a legkisebb költség˝u útvonal a futtató csomóponttól a v csomópontig az adott iterációban, p(v) az adott csomópont és v csomópont közötti úton a v-t megel˝oz˝o csomópont, N’ azon csomópontok halmaza amelyekhez ismert a legrövidebb útvonal. Dinamikus metrika (pl.: terheltség, aktuális sávszélesség)

5.18: Dijsktra algoritmusa¹

esetén a hálózat instabil lesz, mert adott linkek súly változása folyamatos újraszámolást eredményez.

5.19: Változó metrika okozta fluktuáció¹

Távolságvektor alapú protokollok esetén nincs meg a precíz információ a világról. Ennek az algoritmus családnak jól ismert képvisel˝oi aBellman Ford egyenl˝oségreépít˝o megoldások. Ez azt mondja ki, hogy az x és y csomópontok között úgy tudjuk meghatározni a legrövidebb útvonalat,

ha minden lehetséges v köztes csomópontra megkeressük a v és y közötti legrövidebb útvonalat.

dx(y) =minv{c(x,v) +dv(y)} (5.1)

Ezen egyenletre alapuló elosztott algoritmus pszeudokódja és egy lefutása látható a 5.20 ábrán. A

5.20: Távolságvektor alapú forgalomirányítás algoritmusa¹

távolságvektor alapú protokollok számára ugyanolyan gond a dinamikus metrikák alkalmazása, azonban itt az információ vesztéssel (pletyka) megjelennek olyan problémák, amellyel a link állapot alapú protokollnál nem találkoztunk. Egy ilyen probléma a jó hír gyors (megfelel˝o) terjedése és arossz hír lassú (nem jó) terjedése. Amikor egy útvonalon egy link költsége csökken, akkor ez a hír gyorsan eljut mindenhova, mivel nem tud senki sem ett˝ol jobbat mondani, azaz a hír gyorsan terjed. A rossz hírnél viszont, mivel a hír forrása nem ismert, ezért a náluk lév˝o jobb információt hirdetik meg, míg az ˝o forrásuk el nem évül, de ekkor a meghirdetett információt már a szomszéd is hirdeti (persze teljesen alaptalanul). A 5.21 ábrán B részén az eddig jó útvonalon a 4-es költség felmegy 60-ra. Ezt az y érzékeli, de meghallja z hirdetéseit aki csak annyit állít, hogy tud egy 5 távolságú utat x-hez (ezt ugye y-tól “hallotta”, de ezt nem tartja nyilván). Ezután y is elkezdi hirdetni ezt az útvonalat 6 távolságra. Z ezt meghallva ismét növeli a távolságot és elkezdi hirdetni 7 távolságban, ez addig pattog oda-vissza, míg 50 fölé nem megy, mert akkor az 50-es link már jó lesz. Láthatjuk, tehát, hogy egy igen egyszer˝u hálózatban is komoly gondot okozhat az információvesztés (pletyka). Erre több megoldást is szoktak alkalmazni, de ezek mindegyike csak

5.21: Hír terjedése pletyka alapú hálózaton¹ tüneti kezelés, nem oldja meg garantáltan a problémát. Ilyen heurisztikák:

• adott szám a végtelen- RIP (Routing Information Protocol) esetén például 15 távolságnál nagyobb távolság esetén azt mondják, hogy nincs útvonal. Ezzel a végtelen ideig tartó iterációt korlátozza, de ezzel egy korlátot ad a hálózat méretére is.

• osztott horizont (split horizon)- Itt megjegyzi, hogy honnan hallotta és oda nem mondja vissza ugyanazt az információt. Ez a megoldás egy egyszer˝u háromszög és egy csomóponthoz

kapcsolódó további csomópont esetén sem m˝uködik, ott is visszaér az információ, csak más úton.

• mérgezett hirdetések (poisoned updates)- Ekkor egy visszafelé végtelen távolságot hirdetnek meg az útvonalon (amikor z, y után következik az útvonalon akkor y felé nem, hogy nem hirdeti meg ugyanazt, hanem végtelen távolsággal hirdeti azt meg). Itt ismét egy kicsit bonyolultabb topológián visszatérhet a régi információ.

Ebben a fejezetben két elméleti protokollt ismertünk meg, a következ˝o fejezetben ezen elméleti protokollok konkrét megvalósításával fogunk találkozni. Az elméleti és gyakorlati protokollok összevetéséhez számos elvet, metrikát szoktak alkalmazni, ezek közül a legfontosabbak:

• üzenet komplexitás- Az információ terjesztéshez mennyi üzenetre van szükség. A link

• üzenet komplexitás- Az információ terjesztéshez mennyi üzenetre van szükség. A link

In document Számítógép hálózatok programozóknak (Pldal 111-0)