2. Fejezet Alkalmazási réteg A note on the use of these ppt slides: We’re making these slides freely available to all (faculty, students, readers). They’re in PowerPoint form so you can add, modify, and delete slides (including this one) and slide content to suit your needs. They obviously represent a lot of work on our part. In return for use, we only ask the following: If you use these slides (e.g., in a class) in substantially unaltered form, that you mention their source (after all, we’d like people to use our book!) If you post any slides in substantially unaltered form on a www site, that you note that they are adapted from (or perhaps identical to) our slides, and note our copyright of this material. Thanks and enjoy! JFK/KWR All material copyright 1996-2007 J.F Kurose and K.W. Ross, All Rights Reserved Computer Networking: A Top Down Approach, 4th edition. Jim Kurose, Keith Ross Addison-Wesley, July 2007. 2: Alkalmazási réteg

2. Fejezet: Alkalmazási réteg 2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 E-Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

2. Fejezet: Alkalmazási réteg Célunk: alapfogalmak, alkalmazási-réteg protokollok implementációs szempontjai szállítási-réteg szolgáltatási modellek kliens-szerver paradigma peer-to-peer (társ-társ) paradigma alkalmazási-réteg protokollok ismertetése HTTP FTP SMTP / POP3 / IMAP DNS hálózati alkalmazások programozása socket API 2: Alkalmazási réteg

Néhány hálózati alkalmazás e-mail web instant messaging távoli bejelentkezés P2P file-megosztás multi-user hálózati játékok tárolt video streaming hang IP-n keresztül valósidejű video-konferencia grid számítások 2: Alkalmazási réteg

Hálózati alkalmazások írása application transport network data link physical programok írása, amelyek (különböző) végerndszereken futnak hálózaton keresztül kommunikálnak pl. web szerver szoftver kommunikál a böngésző szoftverrel kevés szoftver a hálózat magja részére a hálózat magjának eszközei nem futtatnak felhasználói alkalmazásokat application transport network data link physical application transport network data link physical 2: Alkalmazási réteg

2. Fejezet: Alkalmazási réteg 2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 E-Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

Alkalmazás architektúrák Kliens-szerver Társ-társ (P2P) Hibrid: kliens-szerver és P2P 2: Alkalmazási réteg

Kliens-szerver architektúra folyamatosan működő host valós rögzített IP cím szerver farmok bővítéshez (skálázás) kliens: a szerverrel kommunikál nem kell folyamatosan működjön dinamikus IP címe is lehet nem kommunikálnak közvetlenül egymással kliens/szerver 2: Alkalmazási réteg

Tiszta P2P architektúra nincs folyamatosan működő szerver tetszőleges perem-rendszerek szabadon kommmunikálnak a párok alkalmanként kapcsolódnak, IP címet váltanak példa: Gnutella Könnyen bővíthető, de nehezen kezelhető társ-társ 2: Alkalmazási réteg

Hibrid kliens-szerver és P2P Skype „voice-over-IP” P2P alkalmazás központi szerver: távoli partner címének megkeresése kliens-kliens kapcsolat: közvetlen (nem a szerveren keresztül) Instant messaging két felhsználó közti chat P2P központosított szolgáltatás: felhasználó jelenlétének detektálása/lokalizálás a felhasználó regisztrálja az IP címét a központi szerveren amikor bejelentkezik a felhasználó a központi szerverhez fordul hogy megtudja egy partner IP címét 2: Alkalmazási réteg

Kommunikáló folyamatok Kliens folyamat: kezdeményezi a kapcsolatot Szerver folyamat: várja, hogy kapcsolatba lépjenek vele Folyamat: egy hoston futó program ugyanazon a hoston futó két folyamat folyamatok közti (interprocess) kommunikációval kommunikál (op. rendsz.) különböző hostokon futó folyamatok, alkamazási-réteg protokollok segítségével kommunikálnak Megjegyzés: a P2P alkalmazásoknak kliens folyamataik és szerver folyamataik is vannak 2: Alkalmazási réteg

Socketek a folyamat üzeneteket küld/fogad a socket-nek/től pufferes TCP, változók socket hoszt vagy szerver Pufferes Internet a folyamat üzeneteket küld/fogad a socket-nek/től A socket hasonlít egy ajtóra a küldő folyamat átküldi az üzenetet az ajtón az ajtó másik oldalán levő infrastruktúrára alapoz, amely eljuttatja az üzenetet a fogadó folyamat socket-jéhez az alkalmazás- fejlesztő irányítja Az OR irányítja API: (1) szállítási protokoll választása; (2) néhány paraméter beállítása (bővebben később) 2: Alkalmazási réteg

Folyamatok címzése Ahhoz, hogy egy folyamat fogadóképes legyen, kell legyen egy azonosítója Minden hostnak van egy 32-bites IP címe K: Elegendő a host IP címe, amelyen a folyamat fut a folyamat felismerésére? 2: Alkalmazási réteg

Folyamatok címzése Ahhoz, hogy egy folyamat fogadóképes legyen, kell legyen egy azonosítója Minden hostnak van egy 32-bites IP címe K: Elegendő a host IP címe, amelyen a folyamat fut a folyamat felismerésére? V: Nem, több folyamat futhat ugyanazon a hoston Az azonosító magában foglalja a folyamathoz társított IP címet és a port számát. Példa port számokra: HTTP szerver: 80 Mail szerver: 25 HTTP üzenet küldése a gaia.cs.umass.edu web szervernek: IP cím: 128.119.245.12 Port szám: 80 Bővebben később … 2: Alkalmazási réteg

Az alkalmazási-réteg protokoll meghatározza: A kicserélt üzenetek típusát, pl. kérés, válasz Az üzenetek szintaxisát: milyen mezőket tartalmaz az üzenet, mi válassza el a mezőket Az üzenetek szemantikáját: a mezőkben lévő információ jelentését Az üzenetek küldésére illetve fogadására vonatkozó szabályokat Nyilvános protokollok : RFC-kben meghatározott lehetővé teszik az együttműködést pl. HTTP, SMTP Védett protokollok (Proprietary protocols): pl. Skype 2: Alkalmazási réteg

Milyen szállítási szolgáltatásokra van szüksége egy alkalmazásnak? Adatvesztés vannak alkalmazások, amelyek megengednek bizonyos mértékű adatvesztést (pl. audio) más alkalmazásnak (pl. file-ok másolása , telnet) 100%-an megbízható adat-szállításra van szükségük Sávszélesség vannak alkalmazások (pl. multimédia), melyeknek szükségük van egy bizonyos sávszélességre más alkalmazások („rugalmas alkalmazások”) felhasználnak bármilyen sávszélességet Időzítés vannak alkalmazások (pl. Internetes telefon, interaktív játékok), melyek nem tűrik a késéseket 2: Alkalmazási réteg

Alkalmazások szállítási szolgáltatásainak követelményei állományátvitel e-mail Web dokumentumok „élő” audio/video tárolt audio/video interaktív játékok chat Adatvesztés nem megengedett Sávszélesség rugalmas audio: 5kbps-1Mbps video:10kbps-5Mbps --- néhány kbps Időzítés nem igen, 100 ms igen, néhány s igen és nem 2: Alkalmazási réteg

Internet szállítási protokollok szolgáltatásai TCP szolgáltatásai: összeköttetés alapú: a kliens és a szerver közti kapcsolatteremtés szükséges megbízható szállítás a küldő és fogadó folyamatok között folyamellenőrzés: a küldő nem terheli túl a fogadót zsúfoltság ellenőrzés: lassítja a küldőt, ha a hálózat foglalt nem biztosít: időzítést, garantált minimális sávszélességet UDP szolgáltatásai: nem megbízható adatszállítás nem biztosítja: a kapcsolat beállítását, megbízhatóságot, folyamellenőrzést, zsúfoltság felügyeletet, időzítést, garantált sávszélességet K: Miért létezik akkor UDP 2: Alkalmazási réteg

Internetes alk.: alkalmazás, szállítási protkollok Alkalmazási- réteg protokoll SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] védett (pl. RealNetworks) (pl. Dialpad) Szállítási protokoll TCP TCP vagy UDP tipikusan UDP Alkalmazás e-mail távoli terminál hozzáférés Web file átvitel áramlott multimédia Internetes telefon 2: Alkalmazási réteg

2. Fejezet: Alkalmazási réteg 2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 E-Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

Web és HTTP Zsargon A weboldal objektumokból áll Az objektum lehet HTML file, JPEG kép, Java, applet, audio file,… A weboldal alap HTML-file, amely beágyazott (hivatkozott) objektumokat tartalmaz Minden objektum egy URL-vel címezhető Példa URL-re: www.someschool.edu/someDept/pic.gif host név elérési út neve 2: Alkalmazási réteg

HTTP áttekintés HTTP: hypertext szállítási protokoll Web alkalmazási réteg protokoll kliens/szerver modell kliens: böngésző, mely kér, fogad, „megmutat” webes objektumokat szerver: webszerver a kérésekre válaszol, objektumokat küld HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068 HTTP kérés PC–n Explorer fut HTTP válasz HTTP kérés Szerveren Apache Web server fut HTTP válasz Mac-on Navigator fut 2: Alkalmazási réteg

HTTP áttekintés (folytatás) TCP-t használ: kliens inicializálja a TCP kapcsolatot (létrehoz egy socket-et) a szerverrel, a 80-as porton szerver elfogadja a TCP kapcsolatot HTTP üzenetek (alkalmazási-réteg protokoll üzenetek) a böngésző (HTTP kliens) és webszerver (HTTP szerver) között TCP kapcsolat zárul HTTP „állapot nélküli” A szerver nem tart meg információt a kliens régebbi kéréseiről kiegészítés Az olyan protkoll, mely megtartja az „állapotot”, komplex Megőrzi a régebbi kéréseket Ha a szerver/kliens lefagy, az állapotinformáció inkonszisztens lehet 2: Alkalmazási réteg

HTTP kapcsolatok Nemperszisztens HTTP Legfeljebb egy objektumot küld egy TCP kapcsolaton. HTTP/1.0 nemperszisztens HTTP-t használ Perszisztens HTTP Összetett objektumok küldhetőek egyetlen TCP kapcsolaton keresztül a kliens és szerver között. HTTP/1.1 perszisztens kapcsoaltot használ alapértelmezésben 2: Alkalmazási réteg

Nemperszisztens HTTP (tartalmaz szöveget, és hivatkozást 10 jpeg képre) A felhasználó beírja az alábbi URL-t www.someSchool.edu/someDepartment/home.index 1a. HTTP kliens inicializál egy TCP kapcsolatot a HTTP szerverhez a www.someSchool.edu címre, a 80-as porton 1b. A HTTP szerver a www.someSchool.edu hoszton TCP kapcsolatra vár a 80-as porton, „fogadja” a kapcsolatot, visszajelez a kliensnek 2. HTTP kliens küld egy HTTP kérést (URL) a TCP kapcsolat socket-én. Az üzenet kéri az alábbi objektumot someDepartment/home.index 3. HTTP szerver fogadja a kérést, létrehozza a választ benne az objektummal, és elküldi az üzenetet a megfelelő socket-re idő 2: Alkalmazási réteg

Nemperszisztens HTTP (folyt.) 4. HTTP szerver zárja a TCP kapcsolatot. 5. HTTP kliens megkapja az üzenetet, megjeleníti a html fájlt, elemzi azt és talál 10 referenciát 10 jpeg objektumokra idő 6. 1-5 lépések ismétlődnek mind a 10 jpeg objektumra 2: Alkalmazási réteg

Nemperszisztens HTTP: válaszidő RTT (Round Trip Time) definícója: az az idő, ami alatt egy kis csomag eljut a klienstől a szerverig és vissza. Válaszidő: egy RTT a TCP kapcsolat inicializálására egy RTT a HTTP kérés elküldésétől a válasz első byte-jai megárkezéséig állomány lekérése össz = 2RTT+elküldési idő állomány küldési ideje TCP kapcsolat inicializálása RTT kérése fogadva idő 2: Alkalmazási réteg

Perszisztens HTTP Nemperszisztens HTTP : 2 RTT / obj szükséges OR közreműködése minden TCP kapcsolathoz A böngészők gyakran párhuzamos TCP kapcsolatokat nyitnak a hivatkozott objektumok letöltéséhez Perszisztens HTTP A szerver megnyitva hagyja a kapcsolatot a válasz elküldése után a következő HTTP üzenetek ugyanazon kliens és szerver között ugyanazt a TCP kapcsolatot használják Perszisztens csővezeték nélkül : a kliens csak akkor küld új kérést, ha már kapott választ az előbbire egy RTT hivatkozott objektumonként Perszisztens csővezetékkel : alapértelmezett HTTP/1.1-en a kliens kérést küld amint egy objektum-hivatkozást talál megközelítőleg egy RTT az összes hivatkozott objektumra 2: Alkalmazási réteg

HTTP kérés üzenet kétféle HTTP üzenet: kérés (request), válasz (response) HTTP kérés üzenet: ASCII (olvasható formátum) kérés sor (GET, POST, HEAD parancsok) GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: close Accept-language:fr (extra carriage return, line feed) fejléc sorok Carriage return, line feed jelzi az üzenet végét 2: Alkalmazási réteg

HTTP kérés üzenet: általános alak 2: Alkalmazási réteg

Form bemenet feltöltése Post metódus: A weboldal gyakran tartalmaz form bemenetet A bemenet az üzenet testében (entity body) jut el a szerverhez URL módszer: GET metódust használ A bemenet a kérés sor URL mezőjébe kerül : www.somesite.com/animalsearch?monkeys&banana 2: Alkalmazási réteg

Metódusok HTTP/1.0 GET POST HEAD HTTP/1.1 GET, POST, HEAD PUT DELETE kéri a szervert, hogy hagyja ki az objektumot a válaszból HTTP/1.1 GET, POST, HEAD PUT feltölti az üzenet testében szereplő file-t az URL-ben megadott címre DELETE törli az URL mezőben megadott file-t 2: Alkalmazási réteg

HTTP válaszüzenet állapot sor (protokoll állapot kód állapot mondat) HTTP/1.1 200 OK Connection close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html data data data data data ... fejléc sorok adat, pl. a kért HTML file 2: Alkalmazási réteg

HTTP válasz állapotkódok A szerver->kliens válaszüzenet első sorában. Néhány példa : 200 OK kérés sikeres, a keresett objektum az üzentben 301 Moved Permanently a keresett objektum áthelyezve, az új helye később az üzenetben (Location:) 400 Bad Request a szerver nem érti a kérést 404 Not Found a keresett dokumentum nincs a szerveren 505 HTTP Version Not Supported 2: Alkalmazási réteg

Próbáljuk ki a HTTP-t (kliens-oldal) 1. Telnet a kedvenc webszerverünkre: telnet cis.poly.edu 80 TCP kapcsolatot nyit a 80-as portra (alapértelmezett HTTP szerverport) a cis.poly.edu-ra. Mindent, amit beírunk elküldi a cis.poly.edu 80-as portjára 2. Írjuk be a GET HTTP kérést: Ezt beírva (két ENTER utána), minimális (de teljes) GET kérést küldtünk a HTTP szervernek GET /~ross/ HTTP/1.1 Host: cis.poly.edu 3. Nézzük meg a HTTP szerver által küldött választ! 2: Alkalmazási réteg

Kövessük a HTTP-t munka közben telnet példa Ethereal példa 2: Alkalmazási réteg

Felhasználó-szerver állapot: cookie-k (sütik) Példa : Susan mindig ugyanazzal a PC-vel internetezik először nyit meg egy kereskedelmi oldalt az első HTTP kérés vételekor a site létrehoz: egyedi azonosítót (ID) egy új bemenetet az adatbázisban az azonosító számára Számos weboldal használ cookie-kat Négy komponens: 1) cookie fejlécsor a HTTP válaszüzenetben 2) cookie fejlécsor a HTTP kérésüzenetben 3) cookie állomány a felhasználó hostján, amelyet a böngésző kezel 4) adatabázis a web-oldalon (szerver) 2: Alkalmazási réteg

Cookie-k: állapotmegjegyzés (folytatás) kliens szerver ebay 8734 usual http request msg Amazon szerver létrehozza az 1678-as ID-t a felhasználónak bemenet létrehozás cookie file usual http response Set-cookie: 1678 ebay 8734 amazon 1678 usual http request msg cookie: 1678 cookie-ra jellemző művelet hozzáférés usual http request msg cookie: 1678 cookie-ra jellemző művelet hozzáférés usual http response msg adatbázis egy héttel később: ebay 8734 amazon 1678 usual http response msg 2: Alkalmazási réteg

Cookie-k (folytatás) Cooki-k és „magánélet” (privacy): kiegészítés Cooki-k és „magánélet” (privacy): cookie-k révén a site-ok információt kaphatnak a felhasználóról megadhatunk nevet, e-mail-címet, stb Mire használható a cookie: engedélyezés bevásárlókocsi ajánlatok, reklám felhasználói „ülés” (session) állapota (pl. webmail) Hogyan jegyezhető meg az állapot: protokoll végpontoknál: a küldő/ fogadó megtartja az állapotot több tranzakción keresztül cookie-k: a http üzenet tartalmazza az állapotot is 2: Alkalmazási réteg

Web cache-ek (proxy szerver) Cél: a kliens kérésének kielégítése a célzott szerver beavatkozása nélkül böngésző beállítása: Web hozzáférés cache-en keresztül a böngésző minden HTTP kérést a cache-hez küld objektum a cache-ben: a cache visszatéríti az objektumot ha nincs, akkor a cache az eredeti szervertől kéri az objektumot s elküldi a kliensnek szerver HTTP válasz HTTP vélasz Proxy szerver HTTP kérés HTTP kérést kliens HTTP kérés HTTP response kliens szerver 2: Alkalmazási réteg

Bővebben a Web cache-ről a cache kliensként és szerverként egyaránt működik általában a cache-t az ISP telepíti (egyetem, cég) Miért jó a Web cache? csökkenti a válaszidőt a kliens kérésére csökkenti a forgalmat egy intézmény kimenő vonalán. cache-ekben „bővelkedő” Internet: lehetővé teszi, hogy „gyenge” adatforgal-mazók is kézbesítsék adataikat (ezt eléri a P2P állománymegosztás is) 2: Alkalmazási réteg

Cache példa Feltételezzük, hogy Következmények adatszolgáltató szerverek Feltételezzük, hogy átlagos objektum méret = 100000 bit egy intézmény böngészőitől másodpercenként átalagosan 15 kérés megy a szerverekhez késés az intézmény routerétől valamely szerverig és vissza = 2 sec Következmények LAN kihasználtsága = 15% kimenő kapcsolat kihasználtsága = 100% teljes késés = Internet késés + hozzáférési késés + LAN késés = 2 s + percek + ms-ok nyilvános Internet 1.5 Mbps-os kimenő kapcsolat intézményi hálózat 10 Mbps-os LAN 2: Alkalmazási réteg

Cache példa (folytatás) adatszolgáltató szerverek lehetséges megoldás növeljük a kimenő kapcsolat sávszélességét pl. 10 Mbps-ra következmény LAN kihasználtsága = 15% kimenő kapcsolat kihasználtsága = 15% teljes késés = Internet késés + hozzáférési késés + LAN késés = 2 s + ms-ok + ms-ok gyakran költséges felújítás nyilvános Internet 10 Mbps-os kimenő kapcsolat intézményi hálózat 10 Mbps-os LAN 2: Alkalmazási réteg

Cache példa (folytatás) adatszolgáltató szerverek lehetséges megoldás: cache telepítése feltételezzük, hogy a találati arány 0.4 következmény 40%-át a kéréseknek szinte azonnal teljesíti 60%-át a kéréseknek az adatszolgáltató szerverek teljesítik a kimenő kapcsolat kihasznált-sága 60%-ra csökken minimális késésnövekedéssel (pl. 10 ms) teljes átlagos késés = Internet késés + hozzáférési késés + LAN késés = 0,6*(2,01) s + 0,4*ms-ok < 1,4 s nyilvános Internet 1.5 Mbps-os kimenő kapcsolat intézményi hálózat 10 Mbps-os LAN intézményi cache 2: Alkalmazási réteg

If-modified-since: <date> If-modified-since: <date> Feltételes GET cache szerver Cél: ne küldjük el az objektumot, ha a cache-ben megvan a naprakész verzió cache: megadja a cache-elt másolat dátumát a HTTP kérésben If-modified-since: <date> szerver: a válasz nem tartalmazza az objektumot, ha az időközben nem változott: HTTP/1.0 304 Not Modified HTTP request msg If-modified-since: <date> az objektum nem változott HTTP response HTTP/1.0 304 Not Modified HTTP request msg If-modified-since: <date> az objektum változott HTTP response HTTP/1.0 200 OK <data> 2: Alkalmazási réteg

2. Fejezet: Alkalmazási réteg 2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 E-Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

FTP: az állományátviteli protokoll felhasz. interfész kliens file átvitel FTP szerver felhaszn. a hoszton lokális állomány rendszer távoli állomány rendszer Állomány letöltése / feltöltése távoli hosztról kliens/szerver modell kliens: inicializálja az átvitelt (fogadja/küldi a file-t) szerver: távoli hoszt ftp: RFC 959 ftp szerver: port 21 2: Alkalmazási réteg

FTP: külön vezérlő, illetve adatkapcsolat kliens szerver TCP vezérlő-kapcsolat 21-es port TCP adatkacsolat 20-as port FTP kliens kapcsolatba lép az FTP szerverrel a 21-es porton, TCP szállítási protokollal a kliens engedélyezése a vezérlő kapcsolaton a kliens kereshet a távoli katalógusokban a vezérlő-kapcsolaton küldött parancsokkal. állomány-átviteli parancs érkezésekor a szerver nyit egy második TCP kapcsolatot a klienshez az állomány átvitele után a szerver zárja az adatkapcsolatot. a szerver új TCP kapcsolatot nyit egy második file átvitelére vezérlő kapcsolat: „sávon kívül” az FTP szerver megtartja az „állapotot”: jelenlegi katalógus, előbbi engedélyezés 2: Alkalmazási réteg

FTP parancsok, válaszok példák parancsokra: ASCII szövegként küldi el a vezérlőkapcsolaton USER username PASS password LIST az aktuális katalógus tartalmának lekérdezése RETR filename állomány letöltése STOR filename feltöltése a távoli hosztra visszatérésikód példák ugyanúgy, mint a HTTP-ben) 331 Username OK, password required 125 data connection already open; transfer starting (adatkapcsolat már nyítva, átvitel indul) 425 Can’t open data connection (Nem nyitható meg az adatkapcsolat) 452 Error writing file 2: Alkalmazási réteg

2. Fejezet: Alkalmazási réteg 2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 E-Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

Elektronikus posta Három fő komponens: SMTP SMTP SMTP Felh. postaláda Kimenő üzenetsor felh. Három fő komponens: felhasználói alkalmazás mailszerverek levélszállítási protokoll: SMTP (Simple Mail transfer protocol) Felhasználó „levélolvasó” levél- írás, olvasás, küldés pl., Eudora, Outlook, elm, Mizilla Thunderbird ki-/bemenő leveleket a szerver tárolja mail szerver felh. SMTP mail server felh. SMTP mail szerver SMTP felh. felh. felh. 2: Alkalmazási réteg

Elektronikus posta: mailszerverek felh. Mailszerverek a postaláda tartalmazza a felhasználó beérkezett üzeneteit üzenetsor: kimenő üzenetek sora SMTP protokoll mailszerverek közti üzenetek küldését biztosítja kliens: küldő mailszerver „szerver”: fogadó mailszerver mail szerver felh. SMTP mail szerver felh. SMTP mail szerver SMTP felh. felh. felh. 2: Alkalmazási réteg

Elektronikus posta: SMTP [RFC 2821] TCP-t használ a megbízható adatkapcsolat érdekében, a 25-ös porton kommunikál közvetlen átvitel: küldő szerver  fogadó szerver három lépés kézfogás üzenetek elküldése zárás parancsok/válaszok parancsok: ASCII szöveg válasz: állapotkód és magyarázat az üzenet 7-bites ASCII formátumban kell legyen 2: Alkalmazási réteg

Forgatókönyv: Alice üzenetet küld Bobnak 1) Alice levelezőprogramját használja, hogy levelet írjon és elküldje a bob@someschool.edu címre 2) Az üzenet elmegy az Alice mailszerveréhez; bekerül a várakozási sorba 3) az SMTP kliens nyit egy TCP kapcsolatot Bob mailszerveréhez 4) Az SMTP kliens elküldi Alice üzenetét a TCP kapcsolaton 5) Bob mailszervere beteszi az üzenetet a Bob postaládájába 6) Bob elolvassa az üzenetet a levelezőprogramja segítségével mail szerver mail szerver 1 felh. közv. felh. közv. 2 3 6 4 5 2: Alkalmazási réteg

SMTP kommunikáció példa S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <alice@crepes.fr> S: 250 alice@crepes.fr... Sender ok C: RCPT TO: <bob@hamburger.edu> S: 250 bob@hamburger.edu ... Recipient ok C: DATA S: 354 Enter mail, end with "." on a line by itself C: Do you like ketchup? C: How about pickles? C: . S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection 2: Alkalmazási réteg

Próbáljuk ki az SMTP kapcsolatot: telnet szervernév 25 figyeljük meg a 220-as választ a szervertől próbáljuk ki a következő parancsokat: HELO, MAIL FROM, RCPT TO, DATA, QUIT ezen parancsok segítségével e-mailt lehet küldeni levelezőprogram használata nélkül 2: Alkalmazási réteg

SMTP: következtetés Összehasonlítás HTTP-vel: SMTP perszisztens kapcsolatot használ az SMTP csak 7-bites ASCII üzenetekkel dolgozik SMTP szerver CRLF.CRLF használ az üzenet végének detektálására Összehasonlítás HTTP-vel: HTTP: pull SMTP: push ASCII parancs/válasz kölcsönhatás, státus kódok mindkettőnél HTTP: mindegyik objektumot külön üzenetben küldi el SMTP: többszörös objektumokat többrészes üzenetben küldi el 2: Alkalmazási réteg

A levél formátuma fejléc test SMTP: protokoll RFC 822: standard szöveges üzenetekre: fejléc, pl. To: From: Subject: különbözik az SMTP parancsoktól ! test maga az „üzenet”, ASCII karakterek fejléc üres sor test 2: Alkalmazási réteg

Levél formátum: multimédia kiterjesztések MIME: multimedia mail extension, RFC 2045, 2056 további sorok a fejlécben jelzik a MIME tartalom típusát From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data MIME verzió kódolási módszer multimédia adat típus, altípus, paraméterek kódolt adat 2: Alkalmazási réteg

MIME típusok típus/altípus; paraméterek Text (szöveg) pl. altípusok: plain, html Image (kép) pl. altípusok: jpeg, gif Audio (hang) pl. altípusok: basic (8-biten kódolt), 32kadpcm (32 kbps kódolt) Video pl. altípusok: mpeg, quicktime Alkalmazás Olyan adatok, amelyeket át kell dolgozni, mielőtt olvasható lesz pl. altípus: msword, octet-stream 2: Alkalmazási réteg

Multipart (Többrészes) típus From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=StartOfNextPart --StartOfNextPart Dear Bob, Please find a picture of a crepe. Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data Do you want the reciple? 2: Alkalmazási réteg

Mail elérési protokollok SMTP SMTP elérési protokoll felh. közv. felh. közv. A küldő mailszervere A fogadó mailszervere SMTP: küldés/tárolás a fogadó szerverére Mail elérési protokollok: adat fogadása a szervertől POP: Post Office Protocol [RFC 1939] engedélyezés (levelezőprogram <-->szerver) és letöltés IMAP: Internet Mail Access Protocol [RFC 1730] komplexebb dolgozni lehet a szerveren tárolt üzenetekkel HTTP: gmail, Hotmail , Yahoo! Mail, etc. 2: Alkalmazási réteg

POP3 protokoll engedélyezési fázis C: list tranzakció fázis, kliens: S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on engedélyezési fázis kliens parancsok: user: felh. név megadása pass: jelszó szerver válaszok +OK -ERR tranzakció fázis, kliens: list: üzenetek számai retr: üzenet lekérése számuk szerint dele: törlés quit: kilépés C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> C: dele 1 C: retr 2 S: <message 2 contents> C: dele 2 C: quit S: +OK POP3 server signing off 2: Alkalmazási réteg

POP3 (folytatás) és IMAP Az előbbi példa „download és delete”-et használ. Bob nem olvashatja újra az üzenetet, ha klienst cserél “Download-and-keep”: másolja az üzenetet különböző kliensekre a POP3 állapotmentes az ülések között IMAP Minden üzenetet egy helyen, a szerveren tárol A felhasználó az üzeneteket könyvtárakban tárolhatja IMAP elmenti az állapotot: könyvtárak nevei, megfeleltetés az üzenet azonosítója és a könyvtár neve között, stb. 2: Alkalmazási réteg

2. Fejezet: Alkalmazási réteg 2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 E-Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

DNS: Domain Name System (Doméniumnév rendszer) Emberek: számos azonosító: „CNP”, név, útlevélszám Internet hosztok, ruterek: IP cím (32 bit) a datagrammok címzésére „név” pl., gaia.cs.umass.edu – emberek által használt K: IP cím és név közti kapcsolat? Domain Name System: osztott adatbázis számos névszerver hierarchiájában implementált alalmazási-réteg protokoll hosztok, routerek, névszerverek kommunikálnak a nevek „megfejtése” érdekében (cím/név fordítása) megjegyzés: Internet-mag funkció, amit mégis alkalmazási-réteg protokoll implementál komplexitás a hálózat „peremén” 2: Alkalmazási réteg

DNS Miért nem központosítják a DNS-t? DNS szolgáltatások egyetlen kritikus pont nagy adatforgalom nagy távolság karbantartás nehezen bővíthető! DNS szolgáltatások hosztnév IP címre fordítása hoszt álnév (alternatív név, alias) Kanonikus, alias nevek mail szerver aliasing forgalom megosztása másolt Web szerverek: több IP cím egy kanonikus névhez 2: Alkalmazási réteg

Osztott, hierarchikus adatbázis Root DNS Servers com DNS servers org DNS servers edu DNS servers poly.edu DNS servers umass.edu yahoo.com amazon.com pbs.org a kliens a www.amazon.com IP címét keresi; 1. megközelítés: a kliens egy root szerverhez fordul, hogy megkapja a com DNS szervert a kliens megkérdezi a com DNS szervert, hogy megkapja az amazon.com DNS szervert a kliens megkérdezi az amazon.com DNS szervert, hogy megkapja a www.amazon.com IP címét 2: Alkalmazási réteg

DNS: Root névszerverek a lokális névszerver lép vele kapcsolatba, ha nem ismeri a nevet root névszerver: kapcsolatba lép a parancsoló (authoritative) névszerverrel, ha a név megfeleltetést nem ismeri elküldi a megfeleltetést a lokális névszerverhez a Verisign, Dulles, VA c Cogent, Herndon, VA (also LA) d U Maryland College Park, MD g US DoD Vienna, VA h ARL Aberdeen, MD j Verisign, ( 21 locations) k RIPE London (also 16 other locations) i Autonomica, Stockholm (plus 28 other locations) e NASA Mt View, CA f Internet Software C. Palo Alto, CA (and 36 other locations) m WIDE Tokyo (also Seoul, Paris, SF) 13 root név- szerver a világon b USC-ISI Marina del Rey, CA l ICANN Los Angeles, CA 2: Alkalmazási réteg

TLD és parancsoló szerverek Top-level domain (TLD) szerverek: hatáskörükben a com, org, net, edu, stb., illetve a legfelsőbb szintű országdoméniumok, pl. uk, fr, ca, jp. Network Solutions tartja fenn a com TLD szervereit Educause az edu TLD-t Parancsoló (authoritative) DNS szerverek: szervezetek DNS szerverei, az adott szervezet szervereinek hosztnév – IP cím megfeleltetéseit szolgáltatja (pl.,Web, mail). az adott szervezet vagy az internet szolgáltató működtetheti 2: Alkalmazási réteg

Lokális névszerverek nem tartozik szigorúan a hierarchiához minden ISP (lakótelepi ISP, cég, egyetem) rendelkezik eggyel. alapértelmezett (default) névszervernek is hívják egy hoszt a DNS kérését a lokális névszerverhez küldi proxy-ként működik, továbbítja a kérést a hierarchiába 2: Alkalmazási réteg

parancsoló DNS szerver DNS név megoldás példa root DNS szerver 2 A cis.poly.edu keresi a gaia.cs.umass.edu IP címét 3 TLD DNS szerver 4 5 iterált lekérés: a megkeresett szerver a hierarchiában következő szerver nevével válaszol „Nem ismerem ezt a nevet, de kérdezd meg ettől a szervertől” lokális DNS szerver dns.poly.edu 7 6 1 8 parancsoló DNS szerver dns.cs.umass.edu kérdező hoszt cis.poly.edu gaia.cs.umass.edu 2: Alkalmazási réteg

parancsoló DNS szerver DNS név megoldás példa kérdező hoszt cis.poly.edu gaia.cs.umass.edu root DNS server lokális DNS szerver dns.poly.edu 1 2 4 5 6 parancsoló DNS szerver dns.cs.umass.edu 7 8 TLD DNS server 3 recurzív lekérés: átadja a név megoldásának feladatát a következő névszervernek nagy terhelés? 2: Alkalmazási réteg

DNS: cache és bejegyzések frissítése ha egy névszerver megtanul egy megfeleltetést, akkor megjegyzi azt (cache) a cache bemenetek egy idő után eltűnnek (timeout) a lokális névszerverek általában megjegyzik a TLD szervereket így csak ritkán kell a root névszerverekhez fordulni frissítés/értesítés mechanizmusát még tervezik az IETF-nél RFC 2136 http://www.ietf.org/html.charters/dnsind-charter.html 2: Alkalmazási réteg

RR formátum: (név, érték, típus,ttl) DNS rekordok DNS: az osztott adatbázis erőforrás rekordokat tárol (RR - Resource Record) RR formátum: (név, érték, típus,ttl) Típus=A név a hosztnév érték az IP cím Típus=CNAME név egy kanonikus (valódi) név álneve (alias) www.ibm.com valójában servereast.backup2.ibm.com érték a kanonikus név Típus=NS név a doménium (pl. foo.com) érték ezen doménium parancsoló névszerverének a neve Típus=MX érték a névhez tartozó mailszerver neve 2: Alkalmazási réteg

DNS protokoll, üzenetek DNS protokoll : kérdés- és válasz- üzenetek, az üzenetformátum egyforma üzenet fejléc azonosító: 16 bites szám a kérésben, a válasz ugyanazt a számot használja flag-ek: kérés vagy válasz rekurzió kivánatos rekurzió lehetséges a válasz parancsolt 2: Alkalmazási réteg

DNS protokoll, üzenetek Név, típus mezők a kérés számára RR-ek kérésre válaszként rekordok parancsoló szerverek számára más „hasznos” információk 2: Alkalmazási réteg

Bejegyzés beszúrása a DNS-be pálda: új hálózat „Network Utopia” networkuptopia.com név bejegyzése egy DNS iktatóba (pl. Network Solutions) megadjuk a nevet, a parancsoló névszerver IP címeit (elsődleges és másodlagos) az iktató két RR bejegyzést készít a com TLD szerveren: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A) parancsoló névszerver bejegyzések létrehozása: A típusú bejegyzés www.networkuptopia.com-nak; MX típusú bejegyzés networkutopia.com-nak Hogy kapható meg a honlapunk IP címe? 2: Alkalmazási réteg

2. Fejezet: Alkalmazási réteg 2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 E-Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

P2P állománymegosztás Alice kiválaszt egyet a társak (peer) közül, pl. Bob-ot HTTP-n keresztül lemásolja az állományt Bob géperől az Alice gépére miközben Alice másol, más felhasználok tőle másolnak Alice gépe egyben webkliens és egy alkalmi webszerver is. Minden társ (peer) egy szerver  bővíthetőség Példa Alice–nak a számítógépén fut egy P2P alkalmazás alkalmanként kacspolódik az Internetre; mindig új IP címmel keresi a „Hey Jude” számot az alkalmazás kiírja, melyik gépeken találta meg a számot 2: Alkalmazási réteg

Centralizált katalógus katalógus szerver társak Alice Bob 1 2 3 eredeti „Napster” vázlat 1) ha egy peer kapcsolódik, szól a központi szervernek: IP cím tartalom 2) Alice érdeklődik a „Hey Jude” számoról 3) Alice kéri az állományt Bobtól 2: Alkalmazási réteg

Problémák a centralizált katalógussal egyetlen meghibásodási pont teljesítmény „szűkkeresztmetszet” Copyright problémája az állományátvitel nem centralizált, de a keresett anyag lokalizálása nagyon is centralizált 2: Alkalmazási réteg

Lekérdezés „elárasztással”: Gnutella teljesen osztott nincs központi szerver nyilvános protokoll különböző Gnutella kliensek valósítják meg a protokollt átfedő hálózat (overlay network): gráf él X és Y társ között, ha TCP kapcsolat van köztük az összes aktív társ és a köztük meglevő élek alkotják az átfedő hálózatot él: virtuális kapcsolat (nem közvetlen fizikai kapcsolat) egy társnak jellemzően < 10 overlay szomszédja 2: Alkalmazási réteg

Gnutella: protokoll Állományátvitel: HTTP lekérdezés (kérés üzenet) meglevő TCP kapcsolatokon a társak továbbít- ják a kérést találat visszaküldése fordított útvonalon Kérés Találat Lekérdezés Bővíthetőség: korlátozott távolságú elárasztás 2: Alkalmazási réteg

Gnutella: társ (peer) csatlakozása Alice, a csatlakozó társ kell találjon egy másik társat a Gnutella hálózatban: jelöltlisták használata Alice sorban próbálkozik TCP kapcsolatok létesítésével a jelölt társakkal, amíg talál egy aktívat, pl. Bobot Elárasztás: Alice Ping üzenetet küld Bobnak; Bob továbbítja a Ping üzenetet a szomszédjainak (akik a maguk során továbbítják a saját szomszédjaiknak….) a társak, akik megkapják a Ping üzenetet egy Pong üzenettel válaszolnak Alicenak Alice számos Pong üzenetet kap, ezek alapján újabb TCP kapcsolatokat létesíthet 2: Alkalmazási réteg

Hierarchikus lefedés a központosított katalógus és az elárasztás kombinációja minden társ vagy csoport-vezető, vagy egy csoport-vezetőhöz tartozik. TCP kapcsolat egy társ és a csoportvezetője között. TCP kapcsolat egyes csoportvezetők között. a csoportvezető számontartja a csoportjabeli társak katalógusait 2: Alkalmazási réteg

Kliens-szerver és P2P architektúrák összehasonlítása Kérdés : Mennyi időbe telik az eredetileg egy szerveren meglevő állomány eljuttatása N másik gépre? us: szerver upload sávszélesség Szerver ui: i. kliens/társ upload sávszélessége u1 d1 u2 d2 us di: i. kliens/társ download sávszélessége File, mérete F dN Hálózat (nagy sávszélesség) uN 2: Alkalmazási réteg

Kliens-szerver: állomány szétküldési idő a szerver sorban elküld N másolatot: NF/us i. kliensnek F/di időbe telik a letöltés F u2 u1 d1 d2 us Hálózat (nagy sávszélesség) dN uN = dcs = max { NF/us, F/min(di) } i F szétküldési ideje N kliensnek – kliens/szerver lineárisan nő N szerint (nagy N-re) 2: Alkalmazási réteg

P2P: állomány szétküldési idő Szerver a szerver el kell küldjön egy másolatot: F/us time i. kliensnek F/di időbe telik a letöltés NF bitet kell letölteni (összesen) F u2 u1 d1 d2 us Hálózat (nagy sávszélesség) dN uN lehető legnagyobb feltöltési sebesség (feltételezve, hogy minden csomópont ugyanannak a társnak küld darabokat): us + Sui i=1,N dP2P = max { F/us, F/min(di) , NF/(us + Sui) } i i=1,N 2: Alkalmazási réteg

Összehasonlítás: kliens-szerver  P2P 2: Alkalmazási réteg

P2P esettanulmány: BitTorrent P2P állomány szétosztás (darab = chunk) nyomkövető (tracker): figyeli a torrentben résztvevő társakat torrent: társak csoportja, akik egy állomány darabjait cserélik társak lisájának lekérése darbok cseréje társ 2: Alkalmazási réteg

BitTorrent (1) az állományt 256KB-os darabokra (chunks) osztja. társ belépése a torrentbe: nincsenek darabjai, de idővel megszerzi őket regisztrál a nyomkövetőnél, hogy megkapja a társak listáját, kapcsolódik néhány társhoz („szomszédok”) mialatt letölt, a társ darabokat tölt fel más társaknak. társak beléphetnek és kiléphetnek mikor egy társ megkapta az egész állományt (önzően) kiléphet, or (altruistically) remain 2: Alkalmazási réteg

BitTorrent (2) Pulling Chunks Sending Chunks: tit-for-tat at any given time, different peers have different subsets of file chunks periodically, a peer (Alice) asks each neighbor for list of chunks that they have. Alice issues requests for her missing chunks rarest first Sending Chunks: tit-for-tat Alice sends chunks to four neighbors currently sending her chunks at the highest rate re-evaluate top 4 every 10 secs every 30 secs: randomly select another peer, starts sending chunks newly chosen peer may join top 4 2: Alkalmazási réteg

P2P Case study: Skype Skype clients (SC) P2P (pc-to-pc, pc-to-phone, phone-to-pc) Voice-Over-IP (VoIP) application also IM proprietary application-layer protocol (inferred via reverse engineering) hierarchical overlay Skype login server Supernode (SN) 2: Alkalmazási réteg

Skype: making a call User starts Skype SC registers with SN list of bootstrap SNs Skype login server SC logs in (authenticate) Call: SC contacts SN will callee ID SN contacts other SNs (unknown protocol, maybe flooding) to find addr of callee; returns addr to SC SC directly contacts callee, overTCP 2: Alkalmazási réteg

Chapter 2: Application layer 2.1 Principles of network applications 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P file sharing 2.7 Socket programming with TCP 2.8 Socket programming with UDP 2: Alkalmazási réteg

2. Fejezet: Alkalmazási réteg 2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 E-Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

Socket programming Goal: learn how to build client/server application that communicate using sockets Socket API introduced in BSD4.1 UNIX, 1981 explicitly created, used, released by apps client/server paradigm two types of transport service via socket API: unreliable datagram reliable, byte stream-oriented a host-local, application-created, OS-controlled interface (a “door”) into which application process can both send and receive messages to/from another application process socket 2: Alkalmazási réteg

Socket-programming using TCP Socket: a door between application process and end-end-transport protocol (UCP or TCP) TCP service: reliable transfer of bytes from one process to another controlled by application developer controlled by application developer process TCP with buffers, variables socket process TCP with buffers, variables socket controlled by operating system controlled by operating system internet host or server host or server 2: Alkalmazási réteg

Socket programming with TCP Client must contact server server process must first be running server must have created socket (door) that welcomes client’s contact Client contacts server by: creating client-local TCP socket specifying IP address, port number of server process When client creates socket: client TCP establishes connection to server TCP When contacted by client, server TCP creates new socket for server process to communicate with client allows server to talk with multiple clients source port numbers used to distinguish clients (more in Chap 3) TCP provides reliable, in-order transfer of bytes (“pipe”) between client and server application viewpoint 2: Alkalmazási réteg

Client/server socket interaction: TCP Server (running on hostid) Client create socket, port=x, for incoming request: welcomeSocket = ServerSocket() TCP connection setup close connectionSocket read reply from clientSocket create socket, connect to hostid, port=x clientSocket = Socket() wait for incoming connection request connectionSocket = welcomeSocket.accept() send request using clientSocket read request from connectionSocket write reply to 2: Alkalmazási réteg

Stream jargon A stream is a sequence of characters that flow into or out of a process. An input stream is attached to some input source for the process, e.g., keyboard or socket. An output stream is attached to an output source, e.g., monitor or socket. Client process client TCP socket 2: Alkalmazási réteg

Socket programming with TCP Example client-server app: 1) client reads line from standard input (inFromUser stream) , sends to server via socket (outToServer stream) 2) server reads line from socket 3) server converts line to uppercase, sends back to client 4) client reads, prints modified line from socket (inFromServer stream) 2: Alkalmazási réteg

Example: Java client (TCP) import java.io.*; import java.net.*; class TCPClient { public static void main(String argv[]) throws Exception { String sentence; String modifiedSentence; BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); Socket clientSocket = new Socket("hostname", 6789); DataOutputStream outToServer = new DataOutputStream(clientSocket.getOutputStream()); Create input stream Create client socket, connect to server Create output stream attached to socket 2: Alkalmazási réteg

Example: Java client (TCP), cont. Create input stream attached to socket BufferedReader inFromServer = new BufferedReader(new InputStreamReader(clientSocket.getInputStream())); sentence = inFromUser.readLine(); outToServer.writeBytes(sentence + '\n'); modifiedSentence = inFromServer.readLine(); System.out.println("FROM SERVER: " + modifiedSentence); clientSocket.close(); } Send line to server Read line from server 2: Alkalmazási réteg

Example: Java server (TCP) import java.io.*; import java.net.*; class TCPServer { public static void main(String argv[]) throws Exception { String clientSentence; String capitalizedSentence; ServerSocket welcomeSocket = new ServerSocket(6789); while(true) { Socket connectionSocket = welcomeSocket.accept(); BufferedReader inFromClient = new BufferedReader(new InputStreamReader(connectionSocket.getInputStream())); Create welcoming socket at port 6789 Wait, on welcoming socket for contact by client Create input stream, attached to socket 2: Alkalmazási réteg

Example: Java server (TCP), cont DataOutputStream outToClient = new DataOutputStream(connectionSocket.getOutputStream()); clientSentence = inFromClient.readLine(); capitalizedSentence = clientSentence.toUpperCase() + '\n'; outToClient.writeBytes(capitalizedSentence); } Create output stream, attached to socket Read in line from socket Write out line to socket End of while loop, loop back and wait for another client connection 2: Alkalmazási réteg

Chapter 2: Application layer 2.1 Principles of network applications 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P file sharing 2.7 Socket programming with TCP 2.8 Socket programming with UDP 2.9 Building a Web server 2: Alkalmazási réteg

2. Fejezet: Alkalmazási réteg 2.1 Hálózati alkalmazások alapelvei alkalmazás-architektúrák alkalmazások igényei 2.2 Web és HTTP 2.3 FTP 2.4 E-Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P alkalmazások 2.7 Socket programozás TCP-vel 2.8 Socket programozás UDP-vel 2: Alkalmazási réteg

Socket programming with UDP UDP: no “connection” between client and server no handshaking sender explicitly attaches IP address and port of destination to each packet server must extract IP address, port of sender from received packet UDP: transmitted data may be received out of order, or lost application viewpoint UDP provides unreliable transfer of groups of bytes (“datagrams”) between client and server 2: Alkalmazási réteg

Client/server socket interaction: UDP Server (running on hostid) create socket, clientSocket = DatagramSocket() Client Create, address (hostid, port=x, send datagram request using clientSocket create socket, port=x, for incoming request: serverSocket = DatagramSocket() read request from serverSocket close clientSocket read reply from clientSocket write reply to serverSocket specifying client host address, port number 2: Alkalmazási réteg

Example: Java client (UDP) process Input: receives packet (recall thatTCP received “byte stream”) Output: sends packet (recall that TCP sent “byte stream”) client UDP socket 2: Alkalmazási réteg

Example: Java client (UDP) import java.io.*; import java.net.*; class UDPClient { public static void main(String args[]) throws Exception { BufferedReader inFromUser = new BufferedReader(new InputStreamReader(System.in)); DatagramSocket clientSocket = new DatagramSocket(); InetAddress IPAddress = InetAddress.getByName("hostname"); byte[] sendData = new byte[1024]; byte[] receiveData = new byte[1024]; String sentence = inFromUser.readLine(); sendData = sentence.getBytes(); Create input stream Create client socket Translate hostname to IP address using DNS 2: Alkalmazási réteg

Example: Java client (UDP), cont. Create datagram with data-to-send, length, IP addr, port DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, 9876); clientSocket.send(sendPacket); DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); clientSocket.receive(receivePacket); String modifiedSentence = new String(receivePacket.getData()); System.out.println("FROM SERVER:" + modifiedSentence); clientSocket.close(); } Send datagram to server Read datagram from server 2: Alkalmazási réteg

Example: Java server (UDP) import java.io.*; import java.net.*; class UDPServer { public static void main(String args[]) throws Exception { DatagramSocket serverSocket = new DatagramSocket(9876); byte[] receiveData = new byte[1024]; byte[] sendData = new byte[1024]; while(true) DatagramPacket receivePacket = new DatagramPacket(receiveData, receiveData.length); serverSocket.receive(receivePacket); Create datagram socket at port 9876 Create space for received datagram Receive datagram 2: Alkalmazási réteg

Example: Java server (UDP), cont String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivePacket.getAddress(); int port = receivePacket.getPort(); String capitalizedSentence = sentence.toUpperCase(); sendData = capitalizedSentence.getBytes(); DatagramPacket sendPacket = new DatagramPacket(sendData, sendData.length, IPAddress, port); serverSocket.send(sendPacket); } Get IP addr port #, of sender Create datagram to send to client Write out datagram to socket End of while loop, loop back and wait for another datagram 2: Alkalmazási réteg

Chapter 2: Summary our study of network apps now complete! specific protocols: HTTP FTP SMTP, POP, IMAP DNS P2P: BitTorrent, Skype socket programming application architectures client-server P2P hybrid application service requirements: reliability, bandwidth, delay Internet transport service model connection-oriented, reliable: TCP unreliable, datagrams: UDP 2: Alkalmazási réteg

Chapter 2: Summary Most importantly: learned about protocols typical request/reply message exchange: client requests info or service server responds with data, status code message formats: headers: fields giving info about data data: info being communicated Important themes: control vs. data msgs in-band, out-of-band centralized vs. decentralized stateless vs. stateful reliable vs. unreliable msg transfer “complexity at network edge” 2: Alkalmazási réteg