Mobil hálózatok és alkalmazásaik tehetséggondozó program Dr. Bilicki Vilmos bilickiv@inf.u-szeged.hu Szoftverfejlesztési Tanszék
A mai előadás témája HTTP XMPP Web Szolgáltatások P2P 2018.11.15.
HTTP(Hyper Text Transfer Protocol) Kliens-szerver modell Állapotmentes Alkalmazásszintű protokol Megbízható átviteli közegre épül Új fogalmak: Webszerver Proxy szerver
HTTP 1.1 Kapcsolatorientált Részletes proxy specifikáció 80-as port URI (Universal Resource Identifier)
URI Rfc2396 <protokol>:<protokol specifikus rész> <protokol>://<azonosítás><elérési- útvonal>?<Lekérdezés> US-ASCII Más karaterek: %
URL HTTP specifikus: URL (Universal Resource Locator) http : // host [ : ] [ port ] [ abszolút-útvonal [ ? query ] ] ftp://felhasznalo:jelszo@amadea.inf.u-szeged.hu Relatív útvonal
HTTP üzenetek Kérés (request) Válasz (response) kezdő sor fejléc sorok üres sor az üzenet tartalma
Kérés üzenetek(kezdő sor) GET OPTIONS POST HEAD TRACE
GET GET / HTTP/1.1 Host: sirius.cab.u-szeged.hu HTTP/1.1 200 OK Date: Thu, 13 Dec 2001 16:55:37 GMT Server: Apache/1.3.20 (Unix) PHP/4.0.6 Transfer-Encoding: chunked Content-Type: text/html 8a0 <HTML> <HEAD> <TITLE>Irinyi Kabinet</TITLE> </HEAD> <body... </ADDRESS> </BODY> </HTML>
OPTIONS OPTIONS /cgi-bin/szotarE HTTP/1.1 Host: sirius.cab.u-szeged.hu HTTP/1.1 200 OK Date: Mon, 17 Dec 2001 10:05:54 GMT Server: Apache/1.3.20 (Unix) PHP/4.0.6 Content-Length: 0 Allow: GET, HEAD, POST, OPTIONS, TRACE
HEAD HEAD /teszt/ HTTP/1.1 Host: wilma.cab.u-szeged.hu HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Cache-Control: max-age=86400 Expires: Tue, 18 Dec 2001 14:47:33 GMT Content-Location: http://wilma.cab.u-szeged.hu/teszt/index.html Date: Mon, 17 Dec 2001 14:47:33 GMT Content-Type: text/html Accept-Ranges: bytes Last-Modified: Mon, 17 Dec 2001 14:03:32 GMT ETag: "fc50cd9c387c11:88e" Content-Length: 83
POST POST /teszt/ HTTP/1.1 Host: wiliam.u-szeged.hu adat: research
TRACE TRACE / HTTP/1.1 Host: wiliam.u-szeged.hu Adat: research HTTP/1.1 200 OK Server: Netscape-Enterprise/6.0 Date: Sun, 23 Dec 2001 12:49:45 GMT Content-type: message/http Content-length: 62
Egyéb CONNECT DELETE PUT
Fejléc mezők Host If-Modified-Since User-Agent Adat: research …
Válasz üzenet Állapot mező Válasz fejléc mezők Erőforrás erőforrás fejléc erőforrás tartalom
Állapot mezők 1xx – Információs 2xx – Siker 3xx – Átirányítás 4xx – Kliens oldali hiba 5xx – Szerver oldali hiba
Válasz fejléc WWW-Authenticate Age Cache-Control Expires Content-Type
MIME Text Plain Html Image Audio Video Application
Biztonság HTTP -> magas rendelkezésre állás Más szempontok: adatok titkossága adatok megbízhatósága egyének azonosítása
PKI és társai Kivonat (Hash) Titkos kulcsú titkosítás (Symetric) Nyilvános kulcsú titkosítás (Asymetric) Digitális aláírás (Digital Siganture) Digitlis tanúsítvány (Digital Certificate) Tanúsítvány hatóság (Certificate Authority)
Kivonat Tetszőleges bemenet Pl.: 128 bites kimenet A bemeneten egy kis változtatás is megváltoztatja a kimenete is Nem visszafejthető
Szimmetrikus kulcsú titkosítás Közös kulcs Gyors Kulcselosztás?
Aszimmetrikus kulcsú titkosítás Nyilvános kulcs Titkos kulcs Lassú
Digitális aláírás
Digitális tanúsítvány
Tanúsítvány hatóság
Biztonsági megoldások
TLS (Tranport Layer Security) Új réteg bevezetése: Netscape SSL Microsoft PCT IETF TLS Megbízhatóság, Adatvédelem, Azonosítás Definiálja a csatorna paramétreinek egyeztetési módszerét Viszony/Kapcsolat
TLS felosztása I. TLS Handshake Session identifier Peer certificate Compression method Cipher spec Master secret Is resumable
TLS felosztása II. TLS Record Fragmentálás Tömörítés Tartalom védelem Titkosítás
Kapcsolat felépítés Hello üzenetcsere Rejtjelezési paraméter csere Bizonyítvány csere Főkulcs Adatcsere
Azonosítási eljárások Basic Authentication Digest Authentication
Basic Authentication UID Password Realm HTTP/1.1 401 Authorization Required
Példa HTTP/1.1 401 Authorization Required Date: Fri, 28 Dec 2001 08:24:32 GMT Server: Apache/1.3.20 (Unix) PHP/4.0.6 X-Powered-By: PHP/4.0.6 WWW-Authenticate: Basic realm="My Realm" Transfer-Encoding: chunked Content-Type: text/html Authorization: Basic base64(user:pass)
Hátrányok Nem biztonságos Használata mellőzendő, veszélyes Lehallgatható Nem titkosított Nincs megoldva a jelszó elosztása Használata mellőzendő, veszélyes Ha mégis akkor: Csak generált jelszavakkal szabad
Digest Authentication challenge-response nonce URI Idő Véletlen szám … Kivonatoló függvény (hash) MD5 Nehéz visszafejteni
A kérés paraméterei Challenge Domain Nonce Opaque Stale Algorithm Qop-int
A válasz paraméterei username digest-URI message-qop cnonce nonce-count response
message-qop Nincs Auth Auth-int A1 = username-value:realm-value:passwd A2 = Method:digest-uri-value response = "KD(H(A1),nonce:H(A2))" Auth response = "KD(H(A1),nonce:nonce-count:cnonce:qop:H(A2))" Auth-int A2 = Method:digest-uri-value:H(entity-body)
Példa WWW-Authenticate: Digest realm="testrealm@host.com", HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest realm="testrealm@host.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Válasz: Authorization: Digest username="Mufasa", uri="/dir/index.html", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1",
Előnyök Titkosított jelszó Szótáras támadás védhető(cnonce) Megvéd a replay támadásoktól Biztosít bizonyos adatbiztonságot
Hátrányok Nem mond semmit a jelszó kiosztásáról Nincs titkosítva a tartalom Limitált integritás védelem A nonce használatának teljesítménybeni korlátai vannak
Felhasznált technológia Szimmetrikus kulcsú titkosítás Gyors Probléma a közös kulcs eljuttatása Aszimmetrikus (nyilvános) kulcsú titkosítás Lassú Nem jelent problémát a kulcs publikálása Digitális Aláírás Digitális Bizonyítvány
Új megoldások Két megközelítési mód: Új réteg: Módosított HTTP TLS SHTTP
SHTTP Felülről kompatibilis a HTTP protokollal Üzenetek becsomagolása CMS,MOSS Digitális aláírás MAC nonce Kulcssere és titkosítás Üzenet integritás és küldő azonosítás Aktualitás ellenőrzése Sok titkosító algoritmus
SHTTP Hasonló üzenet mint a HTTP protokollnál: Kérés: Secure * Secure-HTTP/1.4 Válasz: Secure-HTTP/1.4 200 OK
TLS (Tranport Layer Security) Új réteg bevezetése: Netscape SSL Microsoft PCT IETF TLS
XMPP RFC 3920 Extensible Messaging and Presence Protocol (XMPP) Jabber open-source community Közel valósidejű üzenetcsere IM, Jelenlét alkalmazások Nincs különösebb architektúra kötöttsége de jelenleg kliens-szerver Szerver: Kapcsolat menedzsment Útvonal választás Adat tárolás (legtöbb implementáció) Átjátó (IRC, SIP, SMS, …)
XMPP Címzés Aszinkron adatcsere TLS/SASL használat URI- JID : user@host/resource Aszinkron adatcsere XML folyamok <stream> </stream> Egyirányú to, from, id, xml:lang, … XML strófa, versszak (stanza) Önnáló XMl elem <presence> <iq> TLS/SASL használat
XMPPP Több mint 50 bővítmény: Jingle User Geolocation: building,… street User Mood: afraid, …, in_love User Activity: drinking, … traveling User Tune: atrist, title, … Jingle P2P kapcsolatok menedzselése Jelzés, adat elkülönítése Felépítése: Viszony menedzsment Tartalom kezelés Étvitel kezelés
XMPP - Jingle
Web Szolgáltatások Bevezető Web Szolgáltatás szabványok SOAP WSDL JAX-RPC JEE – WS UDDI WS profilok WS-Security WS-Interoperability Web Szolgáltatás architektúrák
Bevezető Trendek Szolgáltatás Orientált Architektúra Jellemzői Integráció Üzleti folyamatok teljes automatizálása (EDI) Szolgáltatás Orientált Architektúra Szolgáltatás gyártó Szolgáltatás közvetítő Szolgáltatás fogyasztó Jellemzői A kliens nem a szerverhez, hanem a szolgáltatáshoz kötődik Az új és a régi komponensek blokkokba vannak csomagolva ezek web szolgáltatáson csatlakoznak A komplex alkalmazásokon belül az üzleti logika el van különítve Szolgáltatásokat futásidőben lehet cserélgetni A csatolások konfigurációs fájlokban vannak definiálva
A SOA fő elemei XML SOAP WSDL WSIL UDDI
A web szolgáltatások jellemzői Önhordó Önleíró A weben keresztül van publikálva, fellelve és használva Moduláris Nyelv független Nyílt szabvány Lazán csatoltak Dinamikusak Programozható hozzáférést biztosítanak
Története Web sikersztori H2A működik A2A nem igazán 1999: Microsoft XML alapú protokol: SOAP IBM, Microsoft, Ariba: WSDL Ma több mint 40 ajánlás/specifikáció
Web szolgáltatás szabványok
Alapvető szabványok SOAP: Simpe Object Access Protocol Struktúrált és típusos XML dokumentumok cseréjét írja le elosztott környezetben Önhordó, önleíró Alapesetben állapotmentes, egyirányú kommunikáció WSDL: Web Service Description Language A web szolgáltatást mind absztrakt végpontot definiálja A műveletek és az üzenetek is megfelelő absztrakcióval vannak leírva Az aktuális üzentekre építő protokoll pedig konkrét szolgáltatásokat specifikál UDDI: Universal Description, Discovery, and Integration Web szolgáltatások felderítése és publikálása
Leírás és felderítés WS-Inspection: Web Services Inspection Language (WSIL) UDDI nélküli felderítés WS-Discovery Többesküldés alapú web szolgáltatás felderítés WS-MetadataExchange Üzenetváltás a kezdeti infócseréhez (XSD,WSDL, WS-Policy) WS-Policy Szíbályok leírása (azonosítás, QoS, …) WS-PolicyAssertions Általános követelmény gyűjtemény (szöveg kódolás, …) WS-PolicyAttachment Kapcsolatok leírása DNS Endpoint Discovery (DNS-EPD) DNS alapú felderítés
Üzenetküldés ASAP: Asynchronous Services Access Protocol SOAP Messages with Attachments (SwA) MIME kezelés SOAP Message Transmission Optimization Mechanism Szelektív kódolás WS-Addressing WS-Notification Publish/Subscirbe WS-Eventing WS-Enumeration WS-MessageDelivery WS-ReliableMessaging WS-Resources WS-Transfer
Menedzsment WSDM: Web Services Distributed Management WS-Manageability SPML: Service Provisioning Markup Language WS-Provisioning
Üzleti folyamatok BPEL: Business Process Execution Language WS-CDL WS-CAF
Tranzakciók WS-Coordination (WS-COOR) WS-Transaction WS-AtomicTransaction (WS-AT) WS-BusinessActivity (WS-BA)
Biztonság XML-Encryption XML-Signature WS-Security WS-SecureConversation WS-SecurityPolicy WS-Trust WS-Federation SAML: Security Assertion Markup Language
SOAP XML alapú protokol Envelope Header Body Független az átviteli protokolltól (HTTP, JMS, FTP, …) Jelenleg HTTP (WS-I Basic Profile 1.0) Üzenetváltás minta (Message Exchange Pattern - MEP) Egyirányú/Kétirányú
SOAP elemei Boríték (Envelope) Egy vagy több fejléc (Header) Ez tárolja a többit Vezérlő információk Cím, … Egy vagy több fejléc (Header) Vezérlő információk (QoS) Ki és hogyan kezelje az üzenetet? Egy törzs (Body) Üzenet azonosítás Paraméterek Mit csináljunk? Kódolási szabályok Megadja, hogy az adatot hogyan sorosítsuk Programozási nyelv független adat séma (XSD)
Fejlécek Általános és flexibilis mechanizmus a SOAP üzenetek kiterjesztésére Nem szükséges a felek között előzetes egyeztetés Előre definiált fejléc attribútum: SOAP köztes entitás A fejlécek egy része ezekhez az entitásokhoz szól SOAP-ENV:actor A hibák kezelése a MEP-től függ (mustUnderstand fault WS-I BP 1.0) A fejlécek viszik át a biztonság, tranzakció, titkosítás, .. infókat is Hordozhatnak kliens vagy projekt specifikus információkat is
WS-I konformancia fejléc
Törzs (Body) A végső címzettnek szóló információcserére szolgáll A Body elemen belül található XML elemek a test bejegyzések (body entries) A bejegyzések egymástól függetlenül vannak kódolva A legtöbb esetben a body tartalma: Üzenet neve Egy referencia a szolgáltatás példányra Egy vagy több paraméter
Hibakezelés A SOAP definiál egy body elemet erre a célra Fault element (nulla vagy egy lehet belőle) faultcode soapenv:Client soapenv:Server sopaenv:VersionMismatch soapenv:MustUnderstand faultstring Ember által értelmezhető szöveges leíárs faultactor Opcionális, a hiba forrását adja meg (URI) A köztes elemeknek ezt kötelező kitöltenie detail Alkalmazás specifikus mező, opcionális
Adatmodell Nyelvfüggetlen absztrakció Egyszerű XSD típusok Összetett típusok Struktúrák Tömbök (benne lehet struktúra vagy tömb, …) A SOAP-ENC névtérben specifikálják az elemeket A SOAP csak azt mondja meg, hogy hogyan lehet az adattípusokat megadni, azt nem hogy ezek milyenek
Tömbök
Kommunikációs stílusok Dokumentum Üzenet orientált stílus Alacsonyabb absztrakciós megoldás Az in paraméter egy XML dokumentum A válasz bármi (vagy semmi) RPC Szinkron kommunikáció Részei A távoli objektum címe (URI) A metódus neve Paraméterek Opcionális fejléc adatok
Kódolás/Üzenetváltás módok A sorosítás, visszaállítás módját adja meg Programozás nyelv független! Típusai: SOAP encoding (SOAP adat modell elemek) Literal (XSD) – ezt támogatja a WS-I basic profile Literal XML (nem használják) Üzenetváltás módok Document/Literal – a legjobb megoldás Java és nem Java alkalmazások együttműködésére RPC/Literal – Java – Java RPC/Encoded – régi java implementációk Document/Encoded – Nem használt
SOAP megvalósítások
WSDL XML alapú Megadja, hogy Mit csinál a web szolgáltatás Hol tudjuk elérni Hogyan lehet meghívni A web szolgáltatás biztosítója megadhatja: A nevét A protokollt és a kódolást Tipus információkat (műveletek, paraméterek, adattípusok)
A WSDL szerkezete Types – adattípus definiciók tárolója. Pl.: XSD Message – Az átküldött adat absztrakt típusos megadása Port type – egy vagy több prot által támogatott absztrakt műveletek megadása Operation – a szolgáltatás által támogatott akció leírása (kimenő/bejövő üzenet esetleg hiba) Binding – Konkrét protkol és adatformátum egy adott prot típushoz. (protokol név, meghívási mód, szolgáltatás id, kódolás) Service – összetratozó portok listája Port – egy végpont kötés – hálózati cím összekapcsolása
types
message Egy vagy több logikai részt tartalmaz Egy interakciót ír le
Port type Absztrakt műveletek és a felhasznált absztrakt üzenetek halmaza Műveletek Egyirányú Kérés-Válasz Megszólítás-Válasz Értesítés
Bindings Protokol specifikus általános csatoló adatok (pl.: SOAP kommunikációs stílus)
Service definition/port definition Szolgáltatás Összefog több portot egy név alatt Port Egy konkrét végpont egy konkrét címmel
WSDL csatolás típusok Kiegészítő fejlécek SOAP – binding, operation, body, fault, address, header, headerfault HTTP – get/post (address, binding) MIME – több részből állhat, … (content, multipartRelated, body, mimeXml) EJB JMS …
JAX-RPC Java API for XML based RPC Programozás model a SOAP alapú alkalmazásokhoz Leképezést biztosít a Java és a WSDL között Java alkalmazás könnyedén kommunikálhat nem Java alkalmazással RPC alapon
JAX-RPC
WS kliensek Statikus csonk WSDL-ből generált csonkokat használ Szolgáltatás végpont interfész (SEI) Szolgáltatás interfész (hogyan kapjuk meg a SEI-t) Szolgáltatás kereső osztály (hozzáférés a SEI-hez) Kapcsolódó csonk (az aktuális hívásokat kezeli)
WS kliensek Dinamikus proxy A web szolgáltatás cím változhat
WS kliensek Dinamikus hívó interfész A WSDL változhat Nem használ proxy fájlokat hanem a WSDL-t használja futás időben
Adat típus csatolás Java-XML, XML-Java Egyszerű típusok automatikusan Egyes adatstruktúrákra is adott
Web Szolgáltatások JEE környezetben WSEE Hogyan valósítsuk meg a web szolgáltatásokat J2EE környezetben? Kliens Szerver Web konténer EJB konténer Kezelők Egy feldolgozási láncban kezelhetik a SOAP fejléceket Tranzakció (a helyi tranzakciókat felfüggesztik)/Biztonság nincs (HTTPS, …) (?)
UDDI Univerzális Leírás, Felderítés és Integráció Segítségével egyszerűbbek a B2B tranzakciók UDDI felépítés Üzleti entitás Üzleti szolgáltatás Kötő minta tModel Takszonómia Publákációs megjegyzések
Web Szolgáltatás biztonság Tipikus problémák Megoldások TLS-SSL WS-Security Üzenet szintű biztonsági beállítások Vég-Vég megoldás
WS-Security
Példa
WS-I Web Szolgáltatások együttműködése A web szolgáltatás elvileg azért jó mert platform független , … Sok SOAP megvalósítása Sok szabványosítási testület (OASIS, IETF, W3C, …) WS-I együttműködési minimum specifikálása WS-I profilok Implementációs javaslatok Basic Profile v1.1 (pl.: document/literal vagy RPC/literal kötelező, SOAP/HTTP kötés, HTTP POST metódus, …) Attachements Profile v1.0 Simple SOAP binding Profile v1.0 Basic Security Profile Minta alkalmazások Teszt eszközök
WS architektúra
MEP
SOAP modell
Központosított vs. Elosztott rendszerek Erőforrás fellelés Lehet közponosított, elosztott Két lépés: Fellelő szolgáltatás felfedezése Keresés Példák (DNS, Jini keresés, Jxta randevú pont, JNDI, UDDI, LDAP,…) Egyébb pl.: Google Erőforrás rendelkezésre állás Központosított : Web szerver (weboldal - IP cím) Elosztott: absztrakt erőforrás leíró Erőforrás kommunikáció Közvetített kommunikáció – egy központi szerveren keresztül érhető el (JMS, ) Pont-pont kommunikáció
P2P rendszerek Egyenrangú felekből áll ARPANET Kései kötés DNS bejegyzés örök PC kliensek? Kései kötés Definició: A P2P olyan alkalmazás csoport mely felhasználja az Internet végein fekvő erőforrásokat. Minden egyed kliensként és szerverként is működhet Nincs központi menedzsment
P2P kategóriák Központosított Közvetített Elosztott A csomópontok egy központi szerverhez csatlakoznak (SETI@Home) Közvetített Egy központon közvetíti egymásnak a feleket, de közvetlenül kommunikálnak Elosztott Minden fél egyenrangú Bármelyik csomópontnál lehet csatlakozni
Problémák/Megoldások NAT Tűzfal Megoldások Fedő (Overlay) hálózat
Példák
Skálázhatóság Szociális analógia 1995 Stanley Milgram 200 millió címzett 160 levél különböző helyeken egy címzettel 42 érkezett meg Az átlagos ugrás szám 5.5 volt Nagyon csomópontos Elosztott rendszerrel is ezt kellene elérni
P2P rendszerek Hasonló a szociális hálózathoz Gyakran Ad-Hoc módon szerveződik Megbízhatatlan környezet, csomópontok. Mérőszámai: Meddig tart egy keresés? Mennyi sávszélességet igényel egy keresés? Mennyi ugrást kell megtennie a csomagnak a társ csomópontig? Amennyiben elveszek/hozzáadok egy csomóponot a hálózat hibatűrő marad? Mennyire skálázható a rendszer?
P2P rendszerek Kihívások: Kommunikáció Keresés Terhelés elosztás A felhasználók többsége DSL vonalat használ Nem optimális útvonal választás (IP réteg feletti réteg) Keresés Nincs központi szerver Párhuzamos keresések Terhelés elosztás Elméletben egyenrangú felek Gyakorlatban 70% csak felhasználó
P2P topológiák Központosított Gyűrű Hierarchikus Decentralizált Kliens - Szerver Gyűrű Hierarchikus Gyors keresés Decentralizált Hibatűrő Lassú keresés Központosított/Gyűrű Web szerver farm Központosított/Központosított N rétegű alkalmazás Központosított/Decentralizált Üzembiztos Relatív gyors keresés KaZaA, FastTrack
Gnutella Receptek cseréjére lett kifejlesztve Elosztott Servent Szomszédok felderítése Protokoll: Ping Pong Query QueryHit Push Gnutella2 Hub-ok Keresés – séta Kivonattal azonosított fájlok
Freenet Cenzúra kijátszó hálózat Freemail Üzenő fal Weboldalak A felhasználók sávszélességet és merevlemezt osztanak meg Minden titkosítva van Csak kulcs alapján lehet keresni Az egyes csomópont nem határozhatja meg, hogy mit tárol http://127.0.0.1:8888/SSK@fjfkHAbxdwM yTMFgtZjcP2ge-AYPAgM/sites//
Hogyan kezdődött? Egy killer alkalmazás: Naptser Ingyen zene az Interneten keresztül Alap ötlet: Osszuk meg az egyes felhasználók tartalmát, tárolóját és a sávszélességét Internet
Model Minden felhasználó egy fájlhalmazt oszt meg Mindenki mindenki fájlát eléri, letölti
Probléma Hol az az adott fájl E F D E? C A B
Problémák Skálázhatóság: Több százezer gép? Dinamizmus: a gépek jönnek, mennek
Napster Közponosított trendszer, működő gépekhez köti a zeneszámokat Hogyan találjunk meg egy zeneszámot? Keresni kell az index-ben, a troló gépet kell visszaadni Ideális esetben a legközelebbit ftp hozzáférés Előnyök: Egyszerűség, egyszerű fejlett kereső megoldásokat implementálni az index rendszer tetején Hátrányok: Robosztusság, skálázhatóság
Napster: Példa m5 E m6 E? F D m1 A m2 B m3 C m4 D m5 E m6 F m4 E? m5 C
Gnutella Elosztott fájl fellelés Ötlet: elársztásos keresés Hogyan keressük meg a fájlt: Minden szomszédnak küldünk egy kérdést A szomszédok hasonló módon továbbküldik A gép amely rendelkezik a válasszal visszaküldi azt Előnyök: Teljesen decentralizált, robosztus Hátrányok: Nem skálázható, az egész hálózat leültethető a kereséssel (TTL)
Gnutella: Példa Felépítés: m1 szomszédai m2 és m3; m3 szomszédai m4 és m5;… m5 E m6 E E? F D m4 E? C A B m3 m1 m2
Freenet További célok: Architektúra: A publikáó anonimitása, biztonsága Támadásoknak ellenálló – egy harmadik fél nem tudja leállítani a hálózatot, a hozzáférést egy adott fájlhoz Architektúra: Minden fájl egyedi azonosítóval azonosított Minden gép a fájlok egy csoportját tárolja és egy forgalomirányítótáblát tart karban az egyes kérések irányítására
Adat struktúra … … Minden csomópont azonos algoritmust futtat id – fájl azonosító next_hop – mások csoópont amely az adott id-t tárolja file – a fájl Továbbítás: Minden üzenet tartalmazza a fájl id-t amire hivatkozik Amennyiben lokálisan megvan akkor megáll Ha nincs akkor a legközelebbi id alapján keres és a következő ugrásnak továbbítja id next_hop file … …
Kérés API: file = query(id); Adott fájl id keresés beérkezése seté Megvan-e lokálisan Igen akkor visszaadja Ha nem akkor továbbküldi Megjegyzés: Minden lekérdezés TTL-lel rendelkezik (a kereső elrejtése érdekében): TTL véletlenszám adott keretek között Amikor TTL=1 akkor véges valószínűséggel továbbítják Hurkok kezelése, minden csomópont naplózza, hogy mi ment át rajta Amikor a fájlt visszaküldik akkor az útvonal mentén gyorsítótárazzák
Más megoldások Cél: Mindég találjuk meg a fájlt Absztrakció: elosztott kivoinat tábla DHT insert(id, item); item = query(id); Note: item can be anything: a data object, document, file, pointer to a file… Megoldások CAN, Chord, Kademlia, Pastry, Viceroy, Tapestry, etc
Content Addressable Network (CAN) Minden csomópont egy egyedi azonosító egy d dimmenziós térben Cél Többszázezer csomópntra is skálázható A csomópontok gyors váltakozását is elviseli Tulajdonságok A forgalomirányító tábla mérete O(d) Garantálja, hogy a fájllegfeljebb d*n1/d megtalálható
CAN példa Space divided between nodes All nodes cover the entire space Each node covers either a square or a rectangular area of ratios 1:2 or 2:1 Example: Node n1:(1, 2) first node that joins cover the entire space 7 6 5 4 3 n1 2 1 1 2 3 4 5 6 7
Példa (2 dimmenzió): Node n2:(4, 2) joins space is divided between n1 and n2 7 6 5 4 3 n1 n2 2 1 1 2 3 4 5 6 7
CAN példa Node n2:(4, 2) joins space is divided between n1 and n2 7 6 n3 5 4 3 n1 n2 2 1 1 2 3 4 5 6 7
CAN példa Nodes n4:(5, 5) and n5:(6,6) join 7 6 n5 n4 n3 5 4 3 n1 n2 2 1 2 3 4 5 6 7
CAN példa Nodes: n1:(1, 2); n2:(4,2); n3:(3, 5); n4:(5,5);n5:(6,6) Items: f1:(2,3); f2:(5,1); f3:(2,1); f4:(7,5); 7 6 n5 n4 n3 5 f4 4 f1 3 n1 n2 2 f3 1 f2 1 2 3 4 5 6 7
CAN példa Each item is stored by the node who owns its mapping in the space 7 6 n5 n4 n3 5 f4 4 f1 3 n1 n2 2 f3 1 f2 1 2 3 4 5 6 7
CAN lekérdezés Minden csomópont ismeri a d térbeli szomszédjait Továbbítja a célhoz legközelebbi szomszédjának Példa: n1 f4-et kérdezi 7 6 n5 n4 n3 5 f4 4 f1 3 n1 n2 2 f3 1 f2 1 2 3 4 5 6 7
Hiba kezelés Egyszerű hibák Komplex meghibásodások Tudja a szomszéd szomszédjait Ha a csomópont kiesik akkor a szomszédhoz fordul A szomszédok egyike átveszi a zónáját Komplex meghibásodások A szomszédok tömeges meghibásodása Célzott elárasztás a szomszédok felderítésére Remélhetőleg ritkán jelentkezik
Chord Minden csomópontnak egy id egy egydimmenziós térben Célok Több százezer csomópontot kezelhet Kezeli a csomópontok gyors váltakozását Tulajdonságok A forgalomirányító tábla mérete O(log(N)) Garantálja, hogy a fájlt megtalálják O(log(N)) lépésben
Adatstruktúra Az azonosító tér pl.: 0..2m Minden csomópont karbantartja: Mutató tábla Az i bejegyzés az n csomópont mutató tábláblájában a n + 2i szomszédjára mutat Előző csomópont Az id azonsítójú elem az id azonosítójú csomópont utáni csomópontban tárolódik
Chord Példa Succ. Table i id+2i succ 0 2 1 1 3 1 2 5 1 1 7 6 2 5 3 4 Assume an identifier space 0..8 Node n1:(1) joinsall entries in its finger table are initialized to itself Succ. Table i id+2i succ 0 2 1 1 3 1 2 5 1 1 7 6 2 5 3 4
Chord Példa Node n2:(3) joins Succ. Table i id+2i succ 0 2 2 1 3 1 i id+2i succ 0 2 2 1 3 1 2 5 1 1 7 6 2 Succ. Table i id+2i succ 0 3 1 1 4 1 2 6 1 5 3 4
Chord Példa Nodes n3:(0), n4:(6) join Succ. Table i id+2i succ 0 1 1 0 1 1 1 2 2 2 4 6 Succ. Table i id+2i succ 0 2 2 1 3 6 2 5 6 1 7 Succ. Table i id+2i succ 0 7 0 1 0 0 2 2 2 6 2 Succ. Table i id+2i succ 0 3 6 1 4 6 2 6 6 5 3 4
Chord Példa Succ. Table Items i id+2i succ 7 0 1 1 1 2 2 2 4 6 Nodes: n1:(1), n2(3), n3(0), n4(6) Items: f1:(7), f2:(2) i id+2i succ 0 1 1 1 2 2 2 4 6 7 Succ. Table Items 1 7 i id+2i succ 0 2 2 1 3 6 2 5 6 1 Succ. Table 6 2 i id+2i succ 0 7 0 1 0 0 2 2 2 Succ. Table i id+2i succ 0 3 6 1 4 6 2 6 6 5 3 4
Lekérdezés Succ. Table Items i id+2i succ 7 0 1 1 1 2 2 2 4 6 Upon receiving a query for item id, a node Check whether stores the item locally If not, forwards the query to the largest node in its successor table that does not exceed id Succ. Table Items i id+2i succ 0 1 1 1 2 2 2 4 6 7 Succ. Table Items 1 7 i id+2i succ 0 2 2 1 3 6 2 5 6 1 query(7) Succ. Table 6 2 i id+2i succ 0 7 0 1 0 0 2 2 2 Succ. Table i id+2i succ 0 3 6 1 4 6 2 6 6 5 3 4
Csomópont csatlakozás Node n joins the system: n picks a random identifier, id n performs n’ = lookup(id) n->successor = n’
Amikor n’’ éretsítést kap erről Állapot karbantartás Periodikusan Megkérdezi az utódját n’, az elődjéről n’’ Amennyiben n’’ ő ezek között van akkor n->successor = n’’ értesíti n’’ that hogy ő az elődje Amikor n’’ éretsítést kap erről Amenniyben n n’’ elődje után van akkor n’’->predecessor = n Rovosztusságf növelés Minden csomópont utód listát tart karban (általában 2*log N méretűt)
CAN/Chord optimalizáció RTT alapú súlyozás A szomszéd kiválasztásánál az RTT alapján dönt Csökkenti az útvonal késleltetést Több fizikai csomópont egy virtuális mögött Csökkenti az útvonal hosszát(kevesebb virtuális csomópont) Csökkenti az útvonal késleltetst (RTT alapú vrituális csomópont választás) Nagyobb hibatűrés (a virtuálsi csomópont elemeiből csak egynek kell működnie)
Konklúzió DHT kritikus fontosságú CAN: O(d) állapot, O(d*n1/d) távolság Chord: O(log n) állapot, O(log n) távolság Egyszerűek
Jxta Középréteg Elemek Randevú pontok Csövek Szabványos elemek a P2P hálózat használatához, létrehozásához Platform független Nyelv független Hálózat független Elemek Csomópontok felderítése Önszervezés Szolgáltatások hirdetése, fellelése Kommunikáció Monitorozás Randevú pontok Csövek