Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Versjon 2.0 / 14.09.04 Kap 2: Applikasjonslaget1 Kapittel 2 Application Layer Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition.

Liknende presentasjoner


Presentasjon om: "Versjon 2.0 / 14.09.04 Kap 2: Applikasjonslaget1 Kapittel 2 Application Layer Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition."— Utskrift av presentasjonen:

1 Versjon 2.0 / Kap 2: Applikasjonslaget1 Kapittel 2 Application Layer Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July Slides adapted from the slides accompanying the book of Kurose & Ross. © J.F Kurose and K.W. Ross, All Rights Reserved Norsk versjon: © Christian F Heide, 2004.

2 Versjon 2.0 / Kap 2: Applikasjonslaget2 Kapittel 2: Application layer r 2.1 Principles of network applications r 2.2 Web and HTTP r 2.3 FTP r 2.4 Electronic Mail m SMTP, POP3, IMAP r 2.5 DNS r 2.6 P2P file sharing r 2.7 Socket programming with TCP r 2.8 Socket programming with UDP r 2.9 Building a Web server

3 Versjon 2.0 / Kap 2: Applikasjonslaget3 Kapittel 2: Application Layer Våre mål: r konseptuelle- og implementasjons- aspekter ved applikasjonslags- protokoller m transportlaget tjenestemodeller m klient-tjener- paradigmet m peer-to-peer paradigmet r lære om protokoller ved å studere noen populære applika- sjonslagsprotokoller m HTTP m FTP m SMTP / POP3 / IMAP m DNS r programmering av nettverksapplikasjoner m socket API

4 Versjon 2.0 / Kap 2: Applikasjonslaget4 Noen nettverksapplikasjoner r E-post r Web r Instant messaging (f. eks. MSN) r Remote login r P2P fildeling r Multi-user nettverksspill r Streaming av lagret video r Internettelefoni r Sanntids video- konferanse r Massive parallel computing

5 Versjon 2.0 / Kap 2: Applikasjonslaget5 Kapittel 2 – Hvor er vi? è 2.1 Principles of network applications r 2.2 Web and HTTP r 2.3 FTP r 2.4 Electronic Mail m SMTP, POP3, IMAP r 2.5 DNS r 2.6 P2P file sharing r 2.7 Socket programming with TCP r 2.8 Socket programming with UDP r 2.9 Building a Web server

6 Versjon 2.0 / Kap 2: Applikasjonslaget6 Nettverksapplikasjoner: terminologi Prosess: program som kjører på en maskin r innen samme maskin kommuniserer to prosesser ved interprosess- kommunikasjon (definert av OS). r prosesser på ulike maskiner kommuniserer ved en applikasjonslags- protokoll brukeragent: mellommann mellom bruker og nettverk r implementerer bruker- grensesnitt og applikasjonslags- protokoll m Web: nettleser (browser) m E-post: e-postleser m streaming audio/video: media player

7 Versjon 2.0 / Kap 2: Applikasjonslaget7 Lage nettverksapplikasjoner Skriv programmer som m kjører på ulike endesystemer og m kommuniserer over et nettverk m f.eks. Web: Web server programvare kommuniserer med nettleserprogramvare Ingen applikasjonsprogramvare skrives for noder i kjernen m Noder i nettets kjerne opererer ikke på applikasjonslaget m Dette designet muliggjør hurtig applikasjonsutvikling applikasjon transport nettverk link fysisk applikasjon transport nettverk link fysisk applikasjon transport nettverk link fysisk

8 Versjon 2.0 / Kap 2: Applikasjonslaget8 Applikasjoner og applikasjonslagsprotokoller Applikasjon: kommuniserende, distribuerte prosesser m f.eks. e-post, Web, P2P fildeling, meldingsformidling m kjører i endesystemer (vertsmaskiner, hosts) m utveksler meldinger Applikasjonslagsprotkoller m en del av en applikasjon m definerer meldinger som utveksles og handlinger som skal utføres m bruker kommunikasjons- tjenester som tilbys av protokoller på laget under (transportlaget), TCP og UDP appl transport nettverk link fysisk appl transport nettverk link fysisk appl transport nettverk link fysisk

9 Versjon 2.0 / Kap 2: Applikasjonslaget9 Applikasjonsarkitekturer r Klient-tjener (client-server) r Peer-to-peer (P2P) r Hybrid av klient-tjener og P2P

10 Versjon 2.0 / Kap 2: Applikasjonslaget10 Klient-tjener arkitektur tjener (server): m “always-on” maskin m permanent IP-adresse m “server farmer” for skalering klienter: m kommuniserer med tjener m kan være sporadisk tilkoblet m kan ha dynamisk IP- adresse m kommuniserer ikke direkte med hverandre

11 Versjon 2.0 / Kap 2: Applikasjonslaget11 Ren P2P arkitektur r ingen “always on” server nødvendig r endesystemer kommuniserer direkte med hverandre r maskiner er sporadisk tilkoblet og kan endre IP- adresser r eksempel: Gnutella Skalerer godt Noe vanskelig å drifte

12 Versjon 2.0 / Kap 2: Applikasjonslaget12 Hybrid av klient-tjener og P2P Napster m Filoverføring er P2P m Filsøk er sentralisert: Peers registrerer objekter de vil dele i sentral server Peers benytter samme server for å finne ønskede objekter Instant messaging m Chatting mellom to brukere er P2P m Deteksjon av tilstedeværelse og adresse er sentralisert: Brukere registrerer sin IP-adresse i en sentral server når de logger på Brukere kontakter sentral server for å finne venners IP- adresser

13 Versjon 2.0 / Kap 2: Applikasjonslaget13 Klient-tjener paradigmet appl transport nettverk link fysisk appl transport nettverk link fysisk request reply klient tjener

14 Versjon 2.0 / Kap 2: Applikasjonslaget14 Kommuniserende prosesser Prosess: program som kjører på en maskin r innen samme maskin kommuniserer to prosesser ved interprosess- kommunikasjon (definert av OS). r prosesser på ulike maskiner kommuniserer ved en applikasjonslags- protokoll Klientprosess: prosessen som initierer kommunikasjonen Tjenerprosess: prosessen som venter på å bli kontaktet r Merk: applikasjoner med P2P-arkitektur har både klientprosesser og tjenerprosesser

15 Versjon 2.0 / Kap 2: Applikasjonslaget15 Prosesskommunikasjon over et nettverk prosess TCP med buffere og variable socket prosess TCP med buffere og variable socket Internett kontrollert av OS kontrollert av applikasjons- utvikleren

16 Versjon 2.0 / Kap 2: Applikasjonslaget16 Prosessadresser: r For at en prosess skal kunne motta meldinger må den ha en adresse r Hver maskin har en unik 32-bits IP-adresse r Q: er IP-adressen tilstrekkelig for å identifisere en prosess? r Svar: Nei, siden mange prosesser kan kjøre på samme maskin r Prosessadressen består av både IP- adresse og et portnummer assosiert med prosessen på maskinen r Eksempel på portnumre: m HTTP server: 80 m Mail server: 25 r Mer om dette etterhvert

17 Versjon 2.0 / Kap 2: Applikasjonslaget17 Applikasjonslagsprotokoller definerer r Meldingstyper som utveksles, f.eks. request & response meldinger r Meldingssyntaksen: hvilke felter meldingen inneholder r Meldingssemantikken, dvs. betydningen av informasjonen i feltene r Regler for når og hvordan prosesser skal sende og svare på meldinger Åpne protokoller (public- domain) : r definert i RFCer r tillater interoperabilitet r f eks HTTP, SMTP Proprietære protokoller: r f eks KaZaA

18 Versjon 2.0 / Kap 2: Applikasjonslaget18 Hvilke transporttjenester trenger en applikasjon? Tap av data r noen applikasjoner (f.eks. lyd) tåler en del tap av data r andre applikasjoner (f.eks. fil- overføring, telnet) krever 100% pålitelig overføring Tidskrav r noen appl (f.eks. Internettelefoni og interaktive spill) krever liten forsinkelse for å fungere Båndbredde r noen appl (f.eks. multimedia) krever en viss båndbredde for å fungere r andre appl (“elastiske appl”) tar til takke med den båndbredden de får

19 Versjon 2.0 / Kap 2: Applikasjonslaget19 Krav til transporttjenester fra noen applikasjoner Applikasjon filoverføring e-post Web sanntidsaudio/-video lagret audio/video interaktive spill Tap ingen tap tapstolerant Båndbredde elastisk audio: 5kb/s-1Mb/s video:10kb/s-5Mb/s som over noen kb/s og høyere Følsom for forsinkelse nei ja, noen 100 ms ja, noen s ja, noen 100 ms

20 Versjon 2.0 / Kap 2: Applikasjonslaget20 Tjenester fra transport-protokoller i TCP/IP-nett TCP-tjenster: r forbindelsesorientert: oppkobling mellom klient- og tjenerprosessene nødvendig r pålitelig transport mellom sender- og mottakerprosess r flytkontroll: sender skal ikke oversvømme mottaker med data r metningskontroll: redusere senderate når nettet er overbelastet r gir ikke: tidsgaranti eller båndbreddegaranti UDP-tjenester: r upålitelig dataoverføring mellom sender og mottaker r gir ikke: oppsetting av forbindelse, pålitelig overføring, flytkontroll, metningskontroll, tidsgaranti eller båndbreddegaranti

21 Versjon 2.0 / Kap 2: Applikasjonslaget21 Internett apps: applikasjon- og transportprotokoll Applikasjon e-post remote terminalaksess Web filoverføring streaming av multimedia Internetttelefoni Applikasjons- lagsprotokoll SMTP [RFC 2821] Telnet [RFC 854] HTTP [RFC 2616] FTP [RFC 959] proprietær (f.eks. RealNetworks) proprietær (f.eks. Dialpad) Underliggende transportprotokoll TCP TCP eller UDP oftest UDP

22 Versjon 2.0 / Kap 2: Applikasjonslaget22 Kapittel 2 – Hvor er vi? r 2.1 Principles of network applications m app architectures m app requirements è 2.2 Web and HTTP r 2.4 Electronic Mail m SMTP, POP3, IMAP r 2.5 DNS r 2.6 P2P file sharing r 2.7 Socket programming with TCP r 2.8 Socket programming with UDP r 2.9 Building a Web server

23 Versjon 2.0 / Kap 2: Applikasjonslaget23 Web og HTTP Språkbruk r En webside består av objekter r Et objekt kan være en HTML-fil, et JPEG-bilde, en Java-applet, en lydfil osv. r Websider består av en basis HTML-fil som inkluderer mange refererte objekter r Hvert objekt adresseres ved en URL r Eksempel på URL: maskinnavn stinavn

24 Versjon 2.0 / Kap 2: Applikasjonslaget24 HTTP oversikt HTTP: hypertext transfer protocol r Webs applikasjonslags- protokoll r klient/tjener modell m klient: browser som forespør, mottar og viser web-objekter m tjener: web-tjeneren sender objekter som repsons på forespørsler r HTTP 1.0: RFC 1945 r HTTP 1.1: RFC 2616 PC med Explorer Tjener som kjører Apache Web server Mac med Navigator HTTP request HTTP response

25 Versjon 2.0 / Kap 2: Applikasjonslaget25 HTTP oversikt (fortsatt) Benytter TCP: r klient initierer TCP- forbindelse (åpner socket) til tjener, port 80 r tjener aksepterer TCP- forbindelsen fra klienten r HTTP meldinger (applika- sjonslagets protokoll- meldinger) utveksles mellom browser (HTTP klient) og web-server (HTTP tjener) r TCP-forbindelsen lukkes HTTP er tilstandsløs r tjener tar ikke vare på informasjon om tidligere forespørsler fra klienten Protokoller som har tilstands- informasjon er komplekse! r må huske hva som har skjedd r hvis tjener eller klient krasjer, kan deres syn på tilstanden bli inkonsistent på siden

26 Versjon 2.0 / Kap 2: Applikasjonslaget26 HTTP-forbindelser Ikkepersistent HTTP r En TCP-forbindelse overfører kun ett objekt r HTTP/1.0 benytter ikkepersistent HTTP Persistent HTTP r Flere objekter kan sendes over en TCP- forbindelse mellom klient og tjener r HTTP/1.1 benytter persistente forbindelser som default

27 Versjon 2.0 / Kap 2: Applikasjonslaget27 Ikkepersistent HTTP Bruker skriver inn URL 1a. HTTP klienten initierer en TCP- forbindelse til HTTP serveren (eller prosessen) på på port HTTP klienten sender en HTTP request melding (som URL) over TCP-forbindelsen. Meldingen indikerer at klienten ønsker objektet /cfh/tullogtoys/index.html 1b. HTTP server på maskinen venter på en TCP-forbindelse på port 80. Aksepterer forbindelsen og gir beskjed til klienten 3. HTTP serveren mottar fore- spørselen, lager en response melding som inneholder det forespurte objektet og sender meldingen inn på socket tid (inneholder tekst og referanser til 10 jpeg bilder)

28 Versjon 2.0 / Kap 2: Applikasjonslaget28 Ikkepersistent HTTP (forts.) 5. HTTP klienten mottar respons- meldingen som inneholder html-filen og viser denne. Ved “parsing” av html-fil finner den ti refererte jpeg- objekter 6. Trinn 1-5 repeteres for hvert av de ti jpeg-objektene 4. HTTP server lukker TCP- forbindelsen tid

29 Versjon 2.0 / Kap 2: Applikasjonslaget29 Estimering av responsetid Definisjon av RTT: tiden det tar for en liten pakke å vandre fra klienten til tjeneren og tilbake. Responstid: r én RTT for å initiere en TCP-forbindelse r én RTT for en HTTP request med ankomst av den første byte av HTTP responsen r sendetiden for fila totalt: 2RTT + sendetid sendetiden for fil initiere TCP- forbindelse RTT request RTT fil mottatt tid

30 Versjon 2.0 / Kap 2: Applikasjonslaget30 Persistent HTTP Ulemper med ikkepersistent HTTP: r trenger 2 RTT pr objekt r OS må allokere ressurser for hver TCP-forbindelse r men nettlesere åpner ofte parallelle TCP-forbindelser for å hente refererte objekter Persistent HTTP r tjener lar forbindelsen være åpen etter å ha sendt sin respons r etterfølgende HTTP- meldinger mellom samme klient og tjener sendes over samme forbindelse Persistent uten pipelining: r klient sender ny forespørsel først når respons er mottatt r en RTT for hvert referert objekt Persistent med pipelining: r default i HTTP/1.1 r klient sender forespørsel med en gang den kommer over et referert objekt r bare en RTT for alle de refererte objekter

31 Versjon 2.0 / Kap 2: Applikasjonslaget31 HTTP request-meldinger r HTTP request-melding: m Tekst (lesbart for mennesker) GET /somedir/page.html HTTP/1.1 Host: User-agent: Mozilla/4.0 Connection: close Accept-language:fr request linje (GET, POST, HEAD kommandoer) header linjer “Carriage return, line feed” indikerer slutten på meldingen

32 Versjon 2.0 / Kap 2: Applikasjonslaget32 HTTP request-melding: generelt format

33 Versjon 2.0 / Kap 2: Applikasjonslaget33 Metoder i HTTP HTTP/1.0 r GET r POST r HEAD m “send bare header, ikke selve objektet” HTTP/1.1 r GET, POST, HEAD r PUT m laster opp filer r DELETE m sletter filer spesifisert i URL-feltet

34 Versjon 2.0 / Kap 2: Applikasjonslaget34 HTTP respons-melding HTTP/ OK Connection close Date: Thu, 06 Aug :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... statuslinje (protokoll, statuskode, statusfrase) header- linjer data, f eks etterspurt HTML-fil

35 Versjon 2.0 / Kap 2: Applikasjonslaget35 HTTP respons-melding: generelt format

36 Versjon 2.0 / Kap 2: Applikasjonslaget36 Noen HTTP responsstatuskoder 200 OK m forespørsel lyktes, etterspurt objekt følger senere i meldingen 301 Moved Permanently m etterspurt objekt er flyttet, ny lokasjon spesifisert senere i meldingen (Location:) 400 Bad Request m forespørsel ikke forstått av serveren 404 Not Found m etterspurt dokument ikke funnet på serveren 505 HTTP Version Not Supported

37 Versjon 2.0 / Kap 2: Applikasjonslaget37 Cookies: tilstandsinformasjon Mange store nettsteder bruker cookies Fire komponenter: 1) cookie header linje i HTTP-responsmelding 2) cookie header linje i HTTP-requestmelding 3) cookie fil på brukerens maskin håndtert av nettleseren 4) “back-end” database på nettstedet Eksempel: m Susan bruker alltid Internett fra samme PC m Hun besøker en spesifikk e-handelsside for første gang m Når den første HTTP- requesten når nettstedet, lages det en unik ID for Susan og et innslag i back-end databasen for denne IDen

38 Versjon 2.0 / Kap 2: Applikasjonslaget38 Cookies klient server vanlig http request vanlig http respons + Set-cookie: 1678 vanlig http request cookie: 1678 vanlig http respons vanlig http request cookie: 1678 vanlig http respons cookie- spesifikk aksjon cookie- spesifikk aksjon server genererer ID 1678 for bruker entry i database aksess Cookie-fil amazon: 1678 ebay: 8734 Cookie-fil ebay: 8734 Cookie-fil amazon: 1678 ebay: 8734 en uke senere:

39 Versjon 2.0 / Kap 2: Applikasjonslaget39 Cookies (forts) Hva cookies kan gi: r autorisering r handlevogn r anbefalinger r sesjonstilstand (f eks for web e-post) Cookies og personvern: r cookies gjør at nettsteder kan holde øye med hva du foretar deg r kan gi navn og e-post- adresse til nettsteder r søkemotorer benytter redirigering sammen med cookies for å finne ut ennå mer r kan samle inn informasjon om deg fra flere nettsteder på siden

40 Versjon 2.0 / Kap 2: Applikasjonslaget40 Web caching (proxy server) r bruker setter nettleser: Web-aksess via cache r nettleser sender alle HTTP-forespørsler til cache m objektet finnes i cache: cache returnerer objektet m objektet finnes ikke i cache: cache forespør objektet fra opprinnelses-serveren, og returnerer objektet til klienten Mål: oppfylle klientens forespørsel uten å involvere opprinnelsesserver klient Proxy server klient HTTP request HTTP response HTTP request HTTP response opprinnelses- server opprinnelses- server

41 Versjon 2.0 / Kap 2: Applikasjonslaget41 Mer om web-caching r Cache opptrer som både klient og tjener r Cache installeres ofte av ISP (høgskole, bedrift, privat ISP) Hvorfor web-caching? r redusere responstid for klientforespørsler. r redusere trafikken på institusjonens aksesslink. r cacher gjør at “fattige” innholdsleverandører kan gi gode leveranser

42 Versjon 2.0 / Kap 2: Applikasjonslaget42 Caching eksempel Antagelser r gjennomsnittlig objektstørrelse = 100,000 bit r gjennomsn. foresp. rate fra nettlesere = 15 pr sekund r forsinkelse fra institusjonens ruter til opprinnelsesservere og tilbake = 2 sekunder Konsekvenser r utnyttelse av LAN = 15% r utnyttelse av aksesslink = 100% r total forsinkelse = Internett- forsinkelse + aksessforsinkelse + LAN forsinkelse = 2 s + minutter + ms opprinnelses servere Internett institusjonens nettverk 10 Mb/s LAN 1.5 Mb/s aksesslink institusjonell cache

43 Versjon 2.0 / Kap 2: Applikasjonslaget43 Caching eksempel (forts.) Mulig løsning r øke aksesslinkens båndbredde til f eks 10 Mb/s Konsekvenser r utnyttelse av LAN = 15% r utnyttelse av aksesslink = 15% r Total forsinkelse = Internett- forsinkelse + aksessforsinkelse + LAN forsinkelse = 2 s + ms + ms r ofte en kostbar oppgradering Internett institusjonens nettverk 10 Mb/s LAN 10 Mb/s aksesslink institusjonell cache opprinnelses servere

44 Versjon 2.0 / Kap 2: Applikasjonslaget44 Caching eksempel (forts.) Installere cache r anta at treffraten er 0.4 Konsekvenser r 40% av forespørslene vil besvares umiddelbart av cache r 60% av forespørslene besvares av opprinnelses- server r utnyttelse av aksesslink reduseres til 60%, noe som resulterer i neglisjerbare forsinkelser (størrelse 10 ms) r gjennomsnittlig forsinkelse = Internettforsinkelse + aksessforsinkelse + LAN forsinkelse = 0.6 * 2.01 s + noen ms < 1.4 s Internet institusjonens nettverk 10 Mb/s LAN 1.5 Mb/s aksesslink institusjonell cache opprinnelses servere

45 Versjon 2.0 / Kap 2: Applikasjonslaget45 Betinget GET: klient-side caching r Mål: ikke send objektet dersom klienten har en oppdatert versjon i sin cache r klient: specifisere dato for sin cachede kopi i HTT- forespørselen If-modified-since: r tjener: respons inneholder ikke noe objekt dersom det ikke finnes en nyere versjon enn den cachede kopien: HTTP/ Not Modified klient tjener HTTP request mld If-modified-since: HTTP respons HTTP/ Not Modified objekt ikke endret HTTP request mld If-modified-since: HTTP respons HTTP/ OK objekt endret

46 Versjon 2.0 / Kap 2: Applikasjonslaget46 Kapittel 2 – hvor er vi? r 2.1 Principles of app layer protocols r 2.2 Web and HTTP è 2.3 FTP r 2.4 Electronic Mail m SMTP, POP3, IMAP r 2.5 DNS r 2.6 Socket programming with TCP r 2.7 Socket programming with UDP r 2.8 Building a Web server r 2.9 Content distribution m Network Web caching m Content distribution networks m P2P file sharing

47 Versjon 2.0 / Kap 2: Applikasjonslaget47 FTP: the file transfer protocol filoverføring FTP server FTP bruker- grense- snitt FTP klient lokalt filsystem fjerntliggende filsystem bruker

48 Versjon 2.0 / Kap 2: Applikasjonslaget48 FTP: the file transfer protocol FTP klient FTP server TCP kontrollforbindelse port 21 TCP dataforbindelse port 20

49 Versjon 2.0 / Kap 2: Applikasjonslaget49 FTP: separat kontroll og dataforbindelse r FTP klient kontakter FTP- server på port 21, spesifiserer TCP som transportprotokoll r Klient får autorisasjon over kontrollforbindelsen r Klient lister serverens kataloger ved å sende kontroll- meldinger over kontroll- forbindelsen r Når server mottar en kommando for en filoverføring vil den åpne en TCP dataforbindelse til klienten r Etter overføring av en fil vil server lukke forbindelsen FTP klient FTP server TCP kontrollforbindelse port 21 TCP dataforbindelse port 20 r Server åpner en ny TCP dataforbindelse for hver ny fil som skal overføres r Kontrollforbindelse: “out of band” r FTP server har tilstands- informasjon: stående katalog og tidligere autentisering

50 Versjon 2.0 / Kap 2: Applikasjonslaget50 FTP kommandoer og responser Noen kommandoer:  USER username  PASS password  LIST returnerer liste av filer i katalogen  RETR filename henter fil til lokal maskin  STOR filename lagrer (laster opp) fil på fjernliggende maskin Noen responser r 331 Username OK, password required r 125 data connection already open; transfer starting r 425 Can’t open data connection r 452 Error writing file

51 Versjon 2.0 / Kap 2: Applikasjonslaget51 Kapittel 2 – hvor er vi? r 2.1 Principles of network applications r 2.2 Web and HTTP r 2.3 FTP è 2.4 Electronic Mail m SMTP, POP3, IMAP r 2.5 DNS r 2.6 P2P file sharing r 2.7 Socket programming with TCP r 2.8 Socket programming with UDP r 2.9 Building a Web server

52 Versjon 2.0 / Kap 2: Applikasjonslaget52 Elektronisk post Tre hovedkomponenter: r brukeragenter r mail-servere r simple mail transfer protocol: SMTP Brukeragent r samme som “epost-leser” r skrive og lese epost- meldinger r Eksempler: Eudora, Outlook, pine, Netscape Messenger r utgående og innkommende meldinger lagres på server brukerens postkasse utgående meldingekø mail server bruker agent bruker agent bruker agent mail server bruker agent bruker agent mail server bruker agent SMTP

53 Versjon 2.0 / Kap 2: Applikasjonslaget53 Elektronisk post: mailservere Mailservere r mailbox inneholder innkommende meldinger r meldingskø for utgående meldinger r SMTP protokoll mellom mailservere for å overføre eposter m klient: mailserver som sender m “server”: mailserver som mottar mail server user agent user agent user agent mail server user agent user agent mail server user agent SMTP

54 Versjon 2.0 / Kap 2: Applikasjonslaget54 Elektronisk post: SMTP [RFC 2821] r benytter TCP for pålitelig overføring av epost fra klient til tjener, port 25 r direkte overføring: fra avsenders mailserver til mottakers mailserver r overføringens tre faser m hilsing (“handshaking”) m overføring av melding m nedkobling (closure) r kommando/respons interaksjon m kommandoer: ASCII tekst m respons: statuskode og -frase r meldinger må være 7-bits ASCII

55 Versjon 2.0 / Kap 2: Applikasjonslaget55 Scenario: Alice sender melding til Bob 1) Alice benytter UA for å skrive melding og legger adressen og trykker “send” 2) Alices UA sender meldingen til hennes mailserver; melding legges i meldingskø 3) Klientsiden av SMTP åpner en TCP-forbindelse til Bobs mailserver 4) SMTP-klienten “hilser på” SMTP-serveren og sender deretter Alices melding over TCP-forbindelsen 5) Bobs mailserver legger meldingen i Bobs postkasse (mailbox) 6) Bob bruker sin UA (epost- program) for å lese meldingen user agent mail server mail server user agent

56 Versjon 2.0 / Kap 2: Applikasjonslaget56 Eksempel på SMTP interaksjon S: 220 brage.ia.hiof.no C: HELO mail.halden.net S: 250 Hello mail.halden.net, pleased to meet you C: MAIL FROM: S: 250 Sender ok C: RCPT TO: S: 250 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 brage.ia.hiof.no closing connection

57 Versjon 2.0 / Kap 2: Applikasjonslaget57 Forsøk SMTP interaksjon:  telnet 25 r motta svar “220” fra server r skriv HELO, MAIL FROM, RCPT TO, DATA og QUIT kommandoer Lar deg sende epost uten bruk av UA (epost-leser)

58 Versjon 2.0 / Kap 2: Applikasjonslaget58 SMTP: avrunding r SMTP benytter persistente forbindelser r SMTP krever at meldingen er i 7-bits ASCII  SMTP-server benytter CRLF.CRLF for å finne hvor meldingen slutter Sammenligning med HTTP: r HTTP: pull r SMTP: push r begge har ASCII kommando/respons interaksjon og status koder r HTTP: hvert objekt sendes i sin egen responsmelding r SMTP: flere objekter kan sendes i samme melding

59 Versjon 2.0 / Kap 2: Applikasjonslaget59 Meldingsformat for epost SMTP: protokoll for utveksling av epost RFC 822: standard for meldingsformat: r headerlinjer, f.eks. m To: m From: m Subject: forskjell fra SMTP kommandoer! r meldingskropp (body) m selve meldingen, kun ASCII-tegn header body blank linje

60 Versjon 2.0 / Kap 2: Applikasjonslaget60 Meldingsformat: multimedia-utvidelser From: To: Subject: Fint bilde MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64-kodede data base64-kodede data multimedia-data type, subtype, parameterdeklarering kodings- metode MIME versjon kodede data

61 Versjon 2.0 / Kap 2: Applikasjonslaget61 MIME typer Content-Type: type/subtype; parametere Text  eksempel på subtyper: plain, html Image  eksempel på subtyper: jpeg, gif Audio  eksempel på subtyper: basic (8-bit μ-lov koding), 32kadpcm (32 kb/s koding) Video  eksempel på subtyper: mpeg, quicktime Application r andre typer data som må prosesseres før de er “lesbare”  eksempel på subtyper: msword, octet-stream

62 Versjon 2.0 / Kap 2: Applikasjonslaget62 Multipart Type From: To: Subject: Fint bilde MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=StartOfNextPart --StartOfNextPart Hei Christian! Sjekk disse blomstene! --StartOfNextPart Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64-kodede data base64-kodede data --StartOfNextPart Fine å ha på kontoret?

63 Versjon 2.0 / Kap 2: Applikasjonslaget63 Epost aksessprotokoller bruker agent senders mailserver bruker agent SMTP aksess protokoll: POP3 IMAP mottakers mailserver

64 Versjon 2.0 / Kap 2: Applikasjonslaget64 POP3 protokoll autorisasjonsfase r klient-kommandoer:  user: brukernavn  pass: passord r server-responser m +OK  -ERR transaksjonsfase, klient:  list: liste meldinger  retr: hente meldinger  dele: slette r quit: avslutte C: list S: S: S:. C: retr 1 S: S:. C: dele 1 C: retr 2 S: S:. C: dele 2 C: quit S: +OK POP3 server signing off S: +OK POP3 server ready C: user bob S: +OK C: pass hungry S: +OK user successfully logged on

65 Versjon 2.0 / Kap 2: Applikasjonslaget65 POP3 og IMAP Mer om POP3 r Forrige eksempel benyttet “download and delete” modus. r Kan da ikke lese epost på ny dersom man bytter lokasjon/klient r “Download-and-keep”: kopier av meldinger på ulike klienter r POP3 er tilstandsløs mellom sesjoner IMAP r Beholder meldinger på mail-serveren r Tillater brukeren å organisere meldinger i mapper r IMAP tar vare på tilstand mellom sesjoner: m navn på mapper og kobling mellom meldings-ID og mappenavn

66 Versjon 2.0 / Kap 2: Applikasjonslaget66 Kapittel 2 – hvor er vi? r 2.1 Principles of network applications r 2.2 Web and HTTP r 2.3 FTP r 2.4 Electronic Mail m SMTP, POP3, IMAP è 2.5 DNS r 2.6 P2P file sharing r 2.7 Socket programming with TCP r 2.8 Socket programming with UDP r 2.9 Building a Web server

67 Versjon 2.0 / Kap 2: Applikasjonslaget67 DNS: Domain Name System Mennesker har flere identifikatorer: m personnummer, navn, passnummer Maskiner på Internett: m IP-adresse (32 bit) – brukes for å adressere datagrammer m “navn” f.eks. odin.hiof.no – brukes av mennesker Q: kobling mellom IP-adresser og navn? Domain Name System: r distribuert database implementert i hierarki av mange navnetjenere (name servers) r applikasjonslagsprotokoll maskiner, rutere og navne- tjenere kommuniserer for å resolve navn (adresse/navn- oversettelse) m merk: dette er en kjernefunksjon i Internett implementert som en applikasjonslagsprotokoll m kompleksiteten er i nettverkets “kant”

68 Versjon 2.0 / Kap 2: Applikasjonslaget68 DNS Hvorfor ikke sentralisere DNS? r “single point of failure” r trafikkvolum r stor avstand til sentralisert database for mange r vedlikehold skalerer ikke! DNS tjenester r Maskinnavn til IP- adresse oversetting r Host aliasing m Kanoniske og alias navn r Mail server aliasing r Lastdeling m Replikerte webservere: sett av IP-adresser tilhørende ett kanonisk navn

69 Versjon 2.0 / Kap 2: Applikasjonslaget69 DNS navnetjenere r ingen server har alle navn-til-IP-adresse mappingene lokale navnetjenere: m hver ISP og bedrift har en lokal (default) navnetjener m DNS-forespørsler sendes først til lokal navnetjener autoritativ navnetjener: m lagrer en maskins IP-adresse knyttet til maskinens navn m kan utføre navn/adresse-oversettelse for maskinen

70 Versjon 2.0 / Kap 2: Applikasjonslaget70 TLD og autoritative servere r Top-level domain (TLD) servere: ansvarlige for com, org, net, edu osv., samt alle top-nivå landdomener som uk, fr, ca og no m Norid er ansvarlig for no-domenet (www.norid.no)www.norid.no r Autoritative DNS-servere: en organisasjons DNS-servere, gir autoritative maskinnavn til IP mappinger for organisasjonens servere (f.eks. web- og mail-server). m Kan vedlikeholdes av organisasjonen eller en tjenestetilbyder (“service provider”)

71 Versjon 2.0 / Kap 2: Applikasjonslaget71 Lokal navnetjener r Ikke noe strengt hierarki r Hver ISP (ISP-firma, bedrift, universitet) har en m kalles også “default navnetjener” r Når en maskin sender en DNS query, sendes den til dens lokale navnetjener (DNS server) m Fungerer som en proxy, videresender forespørsel inn i hierarkiet

72 Versjon 2.0 / Kap 2: Applikasjonslaget72 Rot DNS-Servere com DNS-servere org DNS-servereedu DNS-servere poly.edu DNS-servere umass.edu DNS-servere yahoo.com DNS-servere amazon.com DNS-servere ietf.org DNS-servere Distribuert, hierarkisk database Klient ønsker IP for r Klient spør en rot-tjener om DNS-server for “com” r Klient spør “com” DNS-server om amazon.com sin DNS-server r Klient spør amazon.com sin DNS-server om IP- adressen til

73 Versjon 2.0 / Kap 2: Applikasjonslaget73 DNS: Rot-navnetjener b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA i NORDUnet Stockholm k RIPE London m WIDE Tokyo a NSI Herndon, VA c PSInet Herndon, VA d U Maryland College Park, MD g DISA Vienna, VA h ARL Aberdeen, MD j NSI (TBD) Herndon, VA 13 rot-navne- tjenere i verden

74 Versjon 2.0 / Kap 2: Applikasjonslaget74 DNS - Domain Name System RFC1034RFC1034, RFC1035RFC1035 Top Level Domains (TLD) Second Level Domains Navnløs rot IN- ADDR YAHOO PEOPLE NO HIOF IT Generiske domenerLanddomener ARPA - spesielt domene for adresse-til-navn mapping COMEDUGOVMILNETORGARPAAENOZW

75 Versjon 2.0 / Kap 2: Applikasjonslaget75 spørrende maskin cis.poly.edu gaia.cs.umass.edu rot DNS-server lokal DNS-server dns.poly.edu autoritativ DNS-server dns.cs.umass.edu 7 8 TLD DNS-server 3 Eksempel r Maskin på cis.poly.edu ønsker IP-adressen til gaia.cs.umass.edu rekursiv forespørsel (query): r legger byrden med navneoppslag på kontaktet navnetjener r kan gi stor belastning

76 Versjon 2.0 / Kap 2: Applikasjonslaget76 spørrende maskin cis.poly.edu gaia.cs.umass.edu rot DNS-server lokal DNS-server dns.poly.edu autoritativ DNS-server dns.cs.umass.edu 7 8 TLD DNS-server Iterativ forespørsel iterativ forespørsel: r kontaktet navnetjener svarer med adressen til navnetjener som kan kontaktes

77 Versjon 2.0 / Kap 2: Applikasjonslaget77 DNS: caching og recordoppdatering r når en navnetjener får kjennskap til en “mapping”, vil den cache den m mappinger i cache vil fjernes etter en tid m TLD servere vil typisk caches i lokale navnetjenere Trenger derfor sjelden å kontakte rotnavnetjenere r “update/notify” mekanismer designes nå av IETF m RFC 2136, RFC 3007

78 Versjon 2.0 / Kap 2: Applikasjonslaget78 DNS records r Type=NS  navn er domene (f eks foo.com)  verdi er IP-adressen til autoritativ navnetjener for dette domenet RR format: (navn, verdi, type, ttl) r Type=A  navn er maskinnavn  verdi er IP-adresse r Type=CNAME  navn er alias-navn for et “kanonisk” (et virkelig) navn is really servereast.backup2.ibm.com  verdi er kanonisk navn r Type=MX  verdi er navn på mail- serveren assosiert med navn

79 Versjon 2.0 / Kap 2: Applikasjonslaget79 DNS-meldinger DNS protokollen : query (forespørsel) og reply (svar) meldinger har samme meldingsformat meldingsheader r identification: 16 bits id- nummer for forespørsel, svar på spørsmål benytter samme nummer r flagg: m query (0) eller reply (1) m rekursjon ønsket m rekursjon tilgjengelig m svar er autoritativt

80 Versjon 2.0 / Kap 2: Applikasjonslaget80 DNS-meldinger (forts) Navn- og type-felt for en query RR som svar på query records for andre autoritative tjenere tilleggsinfo som kan benyttes

81 Versjon 2.0 / Kap 2: Applikasjonslaget81 Innlegging av records i DNS r Eksempel: har laget “Network Utopia” r Registrerer navnet networkuptopia.com hos en registrar (liste hos Internic (.com) eller Norid (.no)) m Gir registraren navn og IP-adresser til dine autoritative navnetjenere (primær og sekundær) m Registrar legger inn to RRs i com TLD-server: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, , A) r Legger inn autoritativ server Type A record for og Type MX record for networkutopia.com

82 Versjon 2.0 / Kap 2: Applikasjonslaget82 Kapittel 2 – Hvor er vi? r 2.1 Principles of network applications m app architectures m app requirements r 2.2 Web and HTTP r 2.4 Electronic Mail m SMTP, POP3, IMAP r 2.5 DNS è 2.6 P2P file sharing r 2.7 Socket programming with TCP r 2.8 Socket programming with UDP r 2.9 Building a Web server

83 Versjon 2.0 / Kap 2: Applikasjonslaget83 P2P fildeling Eksempel r Alice kjører en P2P klient applikasjon på sin PC r Av og til knytter hun seg til Internett; får ny IP-adresse hver gang r Spør etter “Beautiful” r Applikasjonen viser andre peers som har en kopi av Beautiful r Alice velger en av dem, Bob r Filen kopieres fra Bobs PC til Alices PC v.hj.a HTTP r Men Alice laster ned sangen kan andre brukere hente filer fra Alice r Alices peer er både en web-klient og en midlertidig webserver Alle peers er servere = skalerer bra!

84 Versjon 2.0 / Kap 2: Applikasjonslaget84 P2P: sentralisert katalog det originale “Napster”- designet 1) når peer knytter seg opp, informerer den en sentral server om: m IP-adresse m innhold den vil dele 2) Alice spør serveren om “Beautiful” 3) Alice ber Bob om å overføre filen sentralisert katalogserver peers Alice Bob

85 Versjon 2.0 / Kap 2: Applikasjonslaget85 P2P: problemer med sentralisert katalog r “Single point of failure” r Flaskehals for ytelsen r Problemer med opphavsrett (copyright) Filoverføringen er desentralisert, men å finne innhold er sentralisert

86 Versjon 2.0 / Kap 2: Applikasjonslaget86 Query flooding: Gnutella r helt distribuert m ingen sentral server r offentlige (public domain) protokoller r many Gnutella clients implementing protocol “overlay network”: graf r kant mellom peer X og Y hvis det eksisterer en TCP-forbindelse r alle aktive peers og kanter utgjør “overlay nettet” r Kant er ikke en fysisk link r Hver peer vil typisk være knyttet til færre enn 10 naboer

87 Versjon 2.0 / Kap 2: Applikasjonslaget87 Gnutella: protokoll Query QueryHit Query QueryHit Query QueryHit Filoverføring: HTTP r Forespørsel sendes over eksisterende TCP-forbindelser r peers videresender forespørsler r QueryHit sendes over tilbake samme vei Skalerbarhet: begrense rekke- vidde på flooding

88 Versjon 2.0 / Kap 2: Applikasjonslaget88 Gnutella: Tilknytning av ny peer 1. Når peer X ønsker å knytte seg til, må den finne en annen peer i Gnutella nettet: bruker liste av mulige peers 2. X forsøker å etablere TCP-forbindelse etter tur med nodene på listen inntil den får kontakt med en node, Y 3. X sender ”ping”-melding til Y; Y videresender den 4. Alle peers som mottar ”ping”-melding svarer med en ”pong”-melding 5. X mottar mange ”pong”-meldinger og kan da sette opp flere TCP-forbindelser

89 Versjon 2.0 / Kap 2: Applikasjonslaget89 Utnyttelse av heterogenitet: KaZaA r Hver peer er enten en gruppeleder eller tilordnet et en gruppeleder m TCP-forbindelse mellom peer og dens gruppeleder m TCP-forbindelse mellom noen gruppeledere r Gruppeleder har info om innhold hos alle sine “barn”

90 Versjon 2.0 / Kap 2: Applikasjonslaget90 KaZaA: Forespørsel r Hver fil har en “hash” og en deskriptor r Klient sender nøkkelord-forespørsel til sin gruppeleder r Gruppeleder svarer med de treff den har funnet: m For hvert treff: metadata, hash og IP-adresse r Hvis gruppeleder videresender forespørsel til andre gruppeledere, vil de svare med sine treff r Klient velger de filer den ønsker å laste ned m HTTP-forespørsel med hash som identifikator sendes til de som har den ønskede filen

91 Versjon 2.0 / Kap 2: Applikasjonslaget91 KaZaA-teknikker r Begrensninger i samtidige opplastinger r Forespørselskø r Incentiv-prioriteringer r Parallell nedlasting

92 Versjon 2.0 / Kap 2: Applikasjonslaget92 Kapittel 2 – hvor er vi? r 2.1 Principles of network applications r 2.2 Web and HTTP r 2.3 FTP r 2.4 Electronic Mail m SMTP, POP3, IMAP r 2.5 DNS r 2.6 P2P file sharing è 2.7 Socket programming with TCP r 2.8 Socket programming with UDP r 2.9 Building a Web server

93 Versjon 2.0 / Kap 2: Applikasjonslaget93 Socketprogrammering Socket API r introdusert i BSD4.1 UNIX, 1981 r genereres, brukes og fjernes av applikasjoner r klient/tjener paradigme r to typer transport- tjenester via socket API: m upålitelig datagram m pålitelig, byte-strøm- orientert et maskin-lokalt, applikasjonsgenerert, OS-kontrollert grensesnitt (en “dør”) som applikasjonsprosesser kan sende og motta meldinger gjennom, meldinger til eller fra andre applikasjonsprosesser socket Mål: lære hvordan man lager klient/tjener- applikasjoner som kommuniserer via sockets

94 Versjon 2.0 / Kap 2: Applikasjonslaget94 Socketprogrammering med TCP Socket: en dør mellom applikasjonsprosess og ende- til-ende protokoll (UCP eller TCP) TCP tjeneste: pålitelig overføring av byte fra en prosess til en annen prosess TCP med buffere, variable socket styrt av applikasjons- utvikler styrt av operativ- systemet maskin eller tjener prosess TCP med buffere, variable socket styrt av applikasjons- utvikler styrt av operativ- systemet maskin eller tjener internett

95 Versjon 2.0 / Kap 2: Applikasjonslaget95 Socket programmering med TCP Klient må kontakte server r server prosess må være kjørende r server må ha etablert en velkomst-socket Klient kontakter server ved å: r lage en TCP socket hos seg selv r spesifisere IP-adresse og portnummer til server- prosessen r Når klienten etablerer socket: klient-TCP etablerer forbindelse til server-TCP r Når den kontaktes av en klienten, vil server TCP etablere en ny socket som kan brukes av serverprosessen for å kommunisere med klienten m tillater at server snakker med flere klienter m avsenders portnummer brukes for å skille klienter (mer om dette i kap 3) TCP gir pålitelig, rekkefølge- bevarende overføring av byte (“rør”) mellom klient og server applikasjonens ståsted

96 Versjon 2.0 / Kap 2: Applikasjonslaget96 Oppretting av forbindelse

97 Versjon 2.0 / Kap 2: Applikasjonslaget97 “Strøm”-terminologi r En strøm er en sekvens av tegn som flyter inn i eller ut av en prosess r En input strøm er knyttet til en input-kilde for prosessen, f eks tastatur eller socket r En output strøm er knyttet til en utgang, f eks skjerm eller socket

98 Versjon 2.0 / Kap 2: Applikasjonslaget98 Socket programmering med TCP Eksempel klient-server app: 1) klient leser linje fra standard input ( inFromUser strøm), sender denne til server via socket ( outToServer strøm) 2) server leser linje fra socket 3) server konverterer linja til versaler og sender den tilbake til klient 4) klient leser og skriver ut modifisert linje fra socket ( inFromServer strøm) Klient- prosess klient TCP socket

99 Versjon 2.0 / Kap 2: Applikasjonslaget99 Klient/tjener socket-interaksjon: TCP vent på innkommde foresp. om forbindelse connectionSocket = welcomeSocket.accept() generér socket, port = x, for innkommende forespørsel: welcomeSocket = ServerSocket() generér socket, etablér forbindelse til hostid, port x clientSocket = Socket() lukk connectionSocket les svar fra clientSocket lukk clientSocket Tjener (kjører på maskinen hostid ) Klient send foresp. clientSocket les foresp. fra connectionSocket skriv svar til connectionSocket TCP oppsetting av forbindelse

100 Versjon 2.0 / Kap 2: Applikasjonslaget100 Eksempel: Java-klient (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()); Lag input-strøm Generér klient-socket, kontakt tjener Lag output-strøm forbundet med socket

101 Versjon 2.0 / Kap 2: Applikasjonslaget101 Eksempel: Java-klient (TCP), forts. 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(); } Lag input- strøm forbundet med socket Send linje til tjener Les linje fra tjener

102 Versjon 2.0 / Kap 2: Applikasjonslaget102 Klientprosessen: socket og strømmer Client process outToServer til nettet fra nettet inFromServer inFromUser tastaturskjerm Klient- prosess input strøm input strøm output strøm TCP socket klient TCP- socket

103 Versjon 2.0 / Kap 2: Applikasjonslaget103 Eksempel: 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())); Generér velkomst-socket på port 6789 Vent ved velkomst- socket på å bli kontaktet av klient Lag input- strøm knyttet til socket

104 Versjon 2.0 / Kap 2: Applikasjonslaget104 Eksempel: Java-server (TCP), forts. DataOutputStream outToClient = new DataOutputStream (connectionSocket.getOutputStream()); clientSentence = inFromClient.readLine(); capitalizedSentence = clientSentence.toUpperCase() + '\n'; outToClient.writeBytes(capitalizedSentence); } Les inn linje fra socket Lag output- strøm knyttet til socket Skriv ut linje til socket enden av while-løkke, vent på neste kontakt (fra annen klient)

105 Versjon 2.0 / Kap 2: Applikasjonslaget105 Kapittel 2 – hvor er vi? r 2.1 Principles of network applications r 2.2 Web and HTTP r 2.3 FTP r 2.4 Electronic Mail m SMTP, POP3, IMAP r 2.5 DNS r 2.6 P2P file sharing r 2.7 Socket programming with TCP è 2.8 Socket programming with UDP r 2.9 Building a Web server

106 Versjon 2.0 / Kap 2: Applikasjonslaget106 Socket programmering med UDP UDP: ingen “forbindelse” mellom klient og server r ingen håndhilsing r sender må eksplisitt sette på mottagers IP-adresse og portnummer på hver pakke r server må ekstrahere senderens IP-adresse og portnummer fra den mottatte pakken UDP: data som sendes kan mottas i feil rekkefølge eller de kan gå tapt på veien applikasjonens ståsted UDP gir upålitelig overføring av pakker (“datagrams”) mellom klient og server

107 Versjon 2.0 / Kap 2: Applikasjonslaget107 Klient/tjener socket-interaksjon: UDP lukk clientSocket Tjener (kjører på hostid ) les svar fra clientSocket generér socket clientSocket = DatagramSocket() Klient Lag datagram med data og adresse ( hostid, port=x) og send datagram ved hjelp av clientSocket generér socket, port = x, for inn- kommende forespørsel: serverSocket = DatagramSocket() les foresp. fra serverSocket skriv svar til serverSocket med angivelse av klientens adresse og portnummer

108 Versjon 2.0 / Kap 2: Applikasjonslaget108 Eksempel: Java-klient (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(); Lag input-strøm Generér klient-socket Oversett maskin- navn til IP-adresse v.hj.a. DNS

109 Versjon 2.0 / Kap 2: Applikasjonslaget109 Eksempel: Java-klient (UDP), forts. 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(); } Lag datagram med data som skal sendes, lengde, IP-adr, port Send datagram til tjener Les datagram fra tjener

110 Versjon 2.0 / Kap 2: Applikasjonslaget110 Eksempel: Java-klient (UDP) sendPacket til nettetfra nettet receivePacket inFromUser tastaturskjerm UDP pakke input UDP pakke UDP socket klient UDP- socket Input: mottar pakke (TCP mottok “byte stream”) Output: sender pakke (TCP sendte “byte stream”) Klient prosess strøm

111 Versjon 2.0 / Kap 2: Applikasjonslaget111 Eksempel: Java-tjener (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); Generér datagram socket på port 9876 Lag plass for mottatt datagram Motta datagram

112 Versjon 2.0 / Kap 2: Applikasjonslaget112 Eksempel: Java-tjener (UDP), forts 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); } Få IP-adr og portnr fra avsender Skriv ut datagram til socket Enden av while-løkke, vent på neste datagram Lag datagram for sending til klient

113 Versjon 2.0 / Kap 2: Applikasjonslaget113 Kapittel 2 – Hvor er vi? r 2.1 Principles of network applications m app architectures m app requirements r 2.2 Web and HTTP r 2.4 Electronic Mail m SMTP, POP3, IMAP r 2.5 DNS r 2.6 P2P file sharing r 2.7 Socket programming with TCP r 2.8 Socket programming with UDP è 2.9 Building a Web server

114 Versjon 2.0 / Kap 2: Applikasjonslaget114 Bygge en enkel web-server r håndterer kun en HTTP-forespørsel av gangen r aksepterer forespørselen r parser headeren r finner ønsket fil i serverens filsystem r lager HTTP-respons-melding: m header-linjer + fil r sender responsen til klienten

115 Versjon 2.0 / Kap 2: Applikasjonslaget115 Kapittel 2: Oppsummering r Applikasjonsarkitekturer m klient-tjener m P2P m hybrid r tjenestekrav fra applikasjonene: m pålitelighet, båndbredde, forsinkelse r Internetts transport- tjenester m forbindelsesorientert, pålitelig: TCP m upålitelig, datagram: UDP Vårt studium av nettverksapplikasjoner er nå ferdig r protokoller vi har sett på: m HTTP m FTP m SMTP, POP, IMAP m DNS r socket programmering

116 Versjon 2.0 / Kap 2: Applikasjonslaget116 Kapittel 2: Oppsummering r typisk request/reply meldingsutveksling: m klient ber om info eller tjeneste m tjener (server) svarer med data og/eller statuskode r meldingsformater: m headere: felter med info om data m data: info som skal oversendes Viktigste: lært om protokoller r kontroll- vs. datameldinger m in-band, out-of-band r sentralisert vs. desentralisert r tilstandsløs vs. tilstandsorientert r pålitelig vs. upålitelig meldingsoverføring r “kompleksitet i kanten av nettet”


Laste ned ppt "Versjon 2.0 / 14.09.04 Kap 2: Applikasjonslaget1 Kapittel 2 Application Layer Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition."

Liknende presentasjoner


Annonser fra Google