Mapa wykładu. Poczta elektroniczna

Transkrypt

1 Mapa wykładu 2.1 Zasady budowy protokołów w. aplikacji 2.2 WWW i HTTP 2.3 DNS 2.4 Programowanie przy użyciu gniazd TCP 2.5 Programowanie przy użyciu gniazd UDP 2.6 Poczta elektroniczna SMTP, POP3, IMAP 2.7 FTP 2.8 Dystrybucja zawartości Schowki Internetowe Sieci dystrybucji zawartości 2.9 Dzielenie plików P2P 1 Poczta elektroniczna Trzy główne składniki: agenci użytkownika serwery poczty simple mail transfer protocol: SMTP Agent użytkownika (AU) czyli przeglądarka poczty kompozycja, edycja, czytanie poczty elektronicznej n.p., Eudora, Outlook, elm, Netscape Messenger wychodzące i przychodzące wiadomości zachowywane są na serwerze serwer poczty SMTP serwer poczty agent użytk. agent użytk. SMTP SMTP agent użytk. kolejka wiadomości do wysłania skrzynka pocztowa użytkownika serwer poczty agent użytk. agent użytk. agent użytk. 2 1

2 Poczta elektroniczna: serwery poczty Serwery poczty skrzynka zawiera wiadomości przychodzące od użytkowników kolejka wiadomości zawiera wiadomości do wysłania protokół SMTP wysyła pocztę pomiędzy serwerami poczty tak naprawdę, jest to protokół w modelu partnerskim (ang. peer-to-peer) serwer poczty SMTP serwer poczty agent użytk. agent użytk. SMTP SMTP agent użytk. serwer poczty agent użytk. agent użytk. agent użytk. 3 Poczta elektroniczna: SMTP [RFC 2821] używa TCP do niezawodnej komunikacji poczty pomiędzy serwerami, port 25 bezpośrednia komunikacja: serwer nadawcy do serwera odbiorcy trzy etapy komunikacji: inicjalizacja (powitanie) wymiana komunikatów zakończenie interakcja typu "polecenie/odpowiedź" polecenia: tekst ASCII odpowiedź: kod i fraza statusu komunikaty muszą być kodowane 7-bitowym ASCII 4 2

3 Scenariusz: Alicja wysyła pocztę do Boba 1) Alicja używa AU do skomponowania listu i wysyła go do: bob@szkola.edu.pl 2) AU alicji wysyła komunikat do jej serwera poczty; komunikat jest umieszczany w kolejce 3) Serwer SMTP otwiera połączenie TCP z serwerem poczty Boba 4) Serwer SMTP Alicji wysyła komunikat przez połączenie TCP 5) Serwer SMTP Boba umieszcza list w skrzynce Boba 6) Bob używa AU do przeczytania wiadomości 1 AU serwer poczty serwer poczty 5 6 AU 5 Przykładowa interakcja SMTP S: 220 hamburger.edu C: HELO nalesnik.pl S: 250 Hello nalesnik.pl, pleased to meet you C: MAIL FROM: <alice@nalesnik.pl> S: 250 alice@nalesnik.pl... 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: Czy lubisz ketchup? C: A moze ogoreczka? C:. S: 250 Message accepted for delivery C: QUIT S: 221 hamburger.edu closing connection 6 3

4 Spróbuj sam porozmawiać w SMTP: telnet nazwaserwera 25 obejrzyj odpowiedź 220 serwera wpisz polecenia HELO, MAIL FROM, RCPT TO, DATA, QUIT W ten sposób można wysyłać pocztę bez przeglądarki poczty 7 Podsumowanie o SMTP SMTP używa trwałych połączeń SMTP wymaga, żeby komunikat (nagłówek i dane) były kodowane w 7-bitowym ASCII Serwer SMTP używa CRLF.CRLF do rozpoznania końca danych Porównania z HTTP: HTTP: pull (pobieranie) SMTP: push (wypychanie) Oba mają komunikaty żądań/odpowiedzi w ASCII, kody wynikowe HTTP: każdy obiekt zawarty w swoim własnym komunikacie odpowiedzi SMTP: wiele obiektów może być wysłane w wieloczęściowym komunikacie 8 4

5 Format komunikatu poczty SMTP: protokół dla poczty elektronicznej RFC 822: standard opisujący format komunikatów tekstowych: linie nagłówków, n.p., To: From: Subject: różne od poleceń SMTP! dane list, tylko znaki ASCII nagłówki dane pusta linia 9 Format komunikatu poczty: rozszerzenia dla multimediów MIME: multimedia mail extension, RFC 2045, 2056 dodatkowe linie nagłówka określają typ MIME dla zawartości listu Wersja MIME metoda kodowaniadanych typ oraz podtyp danych multimedialnych, deklaracje parametrów kodowane dane From: alice@nalesnik.pl To: bob@hamburger.edu Subject: Zdjecie pysznych nalesnikow MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg dane kodowane przez base dane kodowane przez base

6 Typy MIME Content-Type: typ/podtyp; parametery Tekst przykładowe podtypy: plain, html Obraz przykładowe podtypy: jpeg, gif Dźwięk przykładowe podtypy: basic (kodowanie 8-bit mu-law), 32kadpcm (kodowanie 32 kbps) Wideo przykładowe podtypy: mpeg, quicktime Dane aplikacji dane, które muszą zostać przetworzone przez aplikacje, zanim można je pokazać przykładowe podtypy: msword, octet-stream 11 Typ Multipart (załączniki poczty) From: To: Subject: Zdjecie pysznych nalesnikow MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=zalacznik --Zalacznik Kochany Bobie, oto zdjecie nalesnika. --Zalacznik Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data base64 encoded data --Zalacznik Czy chcesz przepis? 12 6

7 Protokoły dostępu do poczty AU SMTP SMTP protokół dostępowy AU Serwer poczty nadawcy Serwer poczty odbiorcy SMTP: dostarczanie poczty do serwera odbiorcy Protokół dostępowy: odbieranie poczty z serwera i zarządzanie skrzynką pocztową POP: Post Office Protocol [RFC 1939] uwierzytelnienie (agent <--> serwer) o pobranie poczty IMAP: Internet Mail Access Protocol [RFC 1730] więcej funkcji (bardziej złożony) synchronizacja lokalnej skrzynki oraz skrzynki na serwerze HTTP: Hotmail, Yahoo! Mail, itd. 13 Protokół POP3 etap uwierzytelnienia polecenia klienta: user: podaję login pass: podaję hasło odpowiedzi serwera +OK -ERR etap transakcji, klient: list: podaj numery listów retr: pobierz list o numerze dele: usuń quit: zakończ S: +OK POP3 server ready C: user bob S: +OK C: pass glodny S: +OK user successfully logged on C: list S: S: S:. C: retr 1 S: <message 1 contents> S:. C: dele 1 C: retr 2 S: <message 1 contents> S:. C: dele 2 C: quit S: +OK POP3 server signing off 14 7

8 Protokół POP3 (cd) oraz IMAP Więcej o POP3 Poprzedni przykład używał tryby pobierz i usuń. Bob nie może przeczytać listu ponownie, jeśli zmieni przeglądarkę Pobierz i zostaw : kopie listów w wielu przeglądarkach POP3 jest bezstanowy pomiędzy sesjami IMAP Wszystkie listy są w jednym miejscu: na serwerze Użytkownik może organizować pocztę w foldery IMAP zachowuje stan użytkownika pomiędzy sesjami: nazwy folderów oraz przyporządkowanie listów do folderów 15 Mapa wykładu 2.1 Zasady budowy protokołów w. aplikacji 2.2 WWW i HTTP 2.3 DNS 2.4 Programowanie przy użyciu gniazd TCP 2.5 Programowanie przy użyciu gniazd UDP 2.6 Poczta elektroniczna SMTP, POP3, IMAP 2.7 FTP 2.8 Dystrybucja zawartości Schowki Internetowe Sieci dystrybucji zawartości 2.9 Dzielenie plików P2P 16 8

9 DNS: Domain Name System Ludzie: wiele identyfikatorów: PESEL, nazwisko, numer paszportu Hosty, rutery Internetu: adres IP (32 bity) używany do adresowania pakietów Czy to wystarczy? Co zrobić, jeśli adres IP musi ulec zmianie? Jak określać usługi, które są realizowane przez wiele serwerów? Jak odróżniać różne usługi, które są realizowane przez jeden serwer? Domain Name System: rozproszona baza danych implementowana przez hierarchię wielu serwerów nazw protokół warstwy aplikacji hosty, rutery, serwery nazw komunikują się, żeby tłumaczyć nazwy uwaga: jedna z głównych funkcji Internetu, implementowana jako protokół w warstwie aplikacji złożoność na "brzegu" sieci Rozwiązanie: nazwa, n.p., używana przez ludzi Pytanie: jak tłumaczyć pomiędzy adresami IP i nazwami? 17 Serwery nazw DNS Czemu nie scentralizować DNS? zagrożenie pojedynczą awarią ilość ruchu odległość od scentralizowanej bazy aktualizacje taki projekt nie jest skalowalny! Zasada delegacji organizacja zarządza strefą nazw w obrębie strefy, może wydzielać mniejsze strefy organizacja przekazuje zarządzanie za strefę innym organizacjom żaden serwer nie zna wszystkich odwzorowań adresów IP i nazw DNS lokalne serwery nazw: każdy DI, organizacja ma lokalny (domyślny) serwer nazw pytanie DNS z hosta jest kierowane najpierw do lokalnego serwera nazw autorytatywny serwer nazw: dla hosta: przechowuje adres IP i nazwę DNS hosta może dokonać odwzorowania pomiędzy nazwą i adresem dla tego hosta 18 9

10 DNS: serwery u korzenia lokalny serwer nazw pyta serwer u korzenia, gdy nie może przetłumaczyć nazwy serwer u korzenia: kontaktuje się z serwerem autorytatywnym, jeśli nie zna odwzorowania nazwy otrzymuje odwzorowanie przekazuje odwzorowanie do lokalnego serwera nazw e NASA Mt View, CA f Internet Software C. Palo Alto, CA b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA 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 k RIPE London i NORDUnet Stockholm m WIDE Tokyo 13 serwerów u korzenia na całym świecie 19 Prosty przykład działania DNS serwer u korzenia host surf.eurecom.fr potrzebuje adresu IP gaia.cs.umass.edu 1. pyta swój lokalny serwer DNS, dns.eurecom.fr 2. dns.eurecom.fr pyta serwer u korzenia, jeśli to konieczne 3. serwer u korzenia pyta serwer autorytatywny, dns.umass.edu, jeśli to konieczne serwer lokalny dns.eurecom.fr pytający host surf.eurecom.fr serwer autorytatywny dns.umass.edu gaia.cs.umass.edu 20 10

11 Przykład działania DNS root name server Serwer u korzenia: może nie znać serwera autorytatywnego może znać pośredni serwer nazw: kogo spytać o autorytatywny serwer lokalny serwer nazw dns.eurecom.fr pytający host surf.eurecom.fr pośredni serwer nazw dns.umass.edu 4 5 serwer autorytatywny dns.cs.umass.edu gaia.cs.umass.edu 21 DNS: iterowane pytania serwer u korzenia pytanie rekurencyjne: obciąża pytany serwer zadaniem zdobycia odpowiedzi duże obciążenie? pytanie iterowane: pytany serwer odpowiada adresem serwera, który należy pytać dalej Nie znam tej nazwy, ale spytaj ten serwer lokalny serwer dns.eurecom.fr pytający host surf.eurecom.fr pytanie iterowane serwer pośredni dns.umass.edu 5 6 serwer autorytatywny dns.cs.umass.edu gaia.cs.umass.edu 22 11

12 DNS: schowki i aktualizacja rekordów gdy (dowolny) serwer nazw pozna odwzorowanie, zachowuje je w schowku pozycje w schowku ulegają dezaktualizacji (znikają) po pewnym czasie mechanizmy aktualizacji (powiadamiania) są projektowane przez IETF RFC Rekordy DNS DNS: rozproszona baza danych przechowująca rekordy zasobów (RZ) Typ=A Typ=NS format RZ: (nazwa, wartość, typ,czas życia) nazwa hosta wartość jest adresem IP nazwa jest domeną (n.p. edu.pl) wartość jest adresem IP autorytatywnego serwera nazw dla tej domeny Typ=CNAME nazwa jest aliasem dla pewnej kanonicznej (prawdziwej) nazwy jest naprawdę servereast.backup2.ibm.com wartość jest nazwą kanoniczną Typ=MX wartość jest nazwą serwera poczty związanego z nazwą 24 12

13 Protokół, komunikaty DNS Protokół DNS : komunikaty pytania i odpowiedzi, oba z tym samym formatem komunikatu nagłówek komunikatu identyfikacja: 16 bitów na numer pytanie, odpowiedź używa tego samego numeru flagi: pytanie lub odpowiedź żądana rekurencja rekurencja dostępna odpowiedź jest autorytatywna identyfikator ilość pytań ilość autorytatywnych rekordów pytania (zmienna ilość) odpowiedzi (zmienna ilość) flagi ilość rekordów ilość dodatkowych rekordów autorytatywne odpowiedzi (zmienna ilość rekordów) dodatkowa informacja (zmienna ilość rekordów) 12 bajtów 25 Mapa wykładu 2.1 Zasady budowy protokołów w. aplikacji 2.2 WWW i HTTP 2.3 DNS 2.4 Programowanie przy użyciu gniazd TCP 2.5 Programowanie przy użyciu gniazd UDP 2.6 Poczta elektroniczna SMTP, POP3, IMAP 2.7 FTP 2.8 Dystrybucja zawartości Schowki Internetowe Sieci dystrybucji zawartości 2.9 Dzielenie plików P2P 26 13

14 FTP: file transfer protocol użytkownik pracujący na hoście Interfejs użytk. FTP Klient FTP lokalny system plików transfer plików Serwer FTP zdalny system plików transfer pliku z/na zdalny host model klient/serwer klient: strona, która rozpoczyna transmisję serwer: zdalny host ftp: RFC 959 serwer ftp: port FTP: oddzielne połączenie kontrolne i transferu plików Klient FTP kontaktuje się z serwerem na porcie 21 (TCP) Przez połączenie kontrolne, klient uzyskuje autoryzację Klient przegląda zdalny system plików przesyłając polecenia FTP przez połączenie kontrolne. Gdy serwer otrzymuje polecenie transferu pliku, otwiera połączenie TCP do klienta Po przesłaniu pliku, serwer zamyka nowe połączenie. Klient FTP Kontrolne połączenie TCP, port 21 Połączenie TCP dla danych, port 20 Serwer FTP Dla przesłania drugiego pliku, serwer otwiera drugie połączenie. Połączenie kontrolne: poza pasmem Serwer FTP utrzymuje stan : aktualny katalog, wcześniejszą autoryzację 28 14

15

16 Polecenia i odpowiedzi FTP Przykładowe polecenia: posyłane jako tekst ASCII przez połączenie kontrolne USER login PASS password LIST zwraca listę plików w aktualnym katalogu RETR nazwapliku pobiera plik STOR nazwapliku zapisuje plik na zdalnym hoście Przykładowe odpowiedzi FTP kod i opis wyniku (jak w HTTP) 331 Username OK, password required 125 data connection already open; transfer starting 425 Can t open data connection 452 Error writing file 31 Warstwa transportu 32 16

17 Mapa wykładu Usługi warstwy transportu Multipleksacja i demultipleksacja Transport bezpołączeniowy: UDP Zasady niezawodnej komunikacji danych Transport połączeniowy: TCP struktura segmentu niezawodna komunikacja kontrola przepływu zarządzanie połączeniem Mechanizmy kontroli przeciążenia Kontrola przeciążenia w TCP 33 Usługi i protokoły warstwy transportu logiczna komunikacja pomiędzy procesami aplikacji działającymi na różnych hostach protokoły transportowe działają na systemach końcowych nadawca: dzieli komunikat aplikacji na segmenty, przekazuje segmenty do warstwy sieci odbiorca: łączy segmenty w komunikat, który przekazuje do warstwy aplikacji więcej niż jeden protokół transportowy Internet: TCP oraz UDP ale może też być SAP (NetWare) application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical application transport network data link physical 34 17

18 Warstwy transportu i sieci warstwa sieci: logiczna komunikacja pomiędzy hostami warstwa transportu: logiczna komunikacja pomiędzy procesami korzysta z oraz uzupełnia usługi warstwy sieci Analogia: pracownicy firmy zamawiają pizzę procesy = pracownicy komunikaty = pizze hosty = firma i pizzeria protokół transportowy = zamawiający pracownik protokół sieci = doręczyciel pizzy 35 Protokoły transportowe Internetu niezawodna, uporządkowana komunikacja (TCP) kontrola przeciążenia kontrola przepływu tworzenie połączenia zawodna, nieuporządkowana komunikacja (UDP) proste rozszerzenie usługi best-effort IP niedostępne usługi: gwarancje maksymalnego opóźnienia gwarancje minimalnej przepustowości application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical application transport network data link physical 36 18

19 Mapa wykładu Usługi warstwy transportu Multipleksacja i demultipleksacja Transport bezpołączeniowy: UDP Zasady niezawodnej komunikacji danych Transport połączeniowy: TCP struktura segmentu niezawodna komunikacja kontrola przepływu zarządzanie połączeniem Mechanizmy kontroli przeciążenia Kontrola przeciążenia w TCP 37 Multipleksacja/demultipleksacja Demultipleksacja u odbiorcy przekazywanie otrzymanych segmentów do właściwych gniazd Multipleksacja u nadawcy zbieranie danych z wielu gniazd, dodanie nagłówka (używanego później przy demultipleksacji) = gniazdo = proces aplikacji P3 P1 P1 aplikacji P2 P4 aplikacji transportu sieci łącza transportu sieci łącza transportu sieci łącza fizyczna fizyczna host 1 host 2 host 3 fizyczna 38 19

20 Jak działa demultipleksacja host otrzymuje pakiety IP każdy pakiet ma adres IP nadawcy, adres IP odbiorcy każdy pakiet zawiera jeden segment warstwy transportu każdy segment ma port nadawcy i odbiorcy (pamiętać: powszechnie znane numery portów dla określonych aplikacji) host używa adresu IP i portu żeby skierować segment do odpowiedniego gniazda 32 bity port nadawcy port odbiorcy inne pola nagłówka dane aplikacji (komunikat) format segmentu TCP/UDP 39 Demultipleksacja bezpołączeniowa Gniazda są tworzone przez podanie numeru portu: DatagramSocket mojegniazdo1 = new DatagramSocket(99111); DatagramSocket mojegniazdo2 = new DatagramSocket(99222); Gniazdo UDP jest identyfikowane przez parę: (adres IP odbiorcy, port odbiorcy) Kiedy host otrzymuje segment UDP: sprawdza port odbiorcy w segmencie kieruje segment UDP do gniazda z odpowiednim numerem portu Datagramy IP z różnymi adresami IP lub portami nadawcy są kierowane do tego samego gniazda 40 20

21 Demultipleksacja bezpołączeniowa (c.d.) DatagramSocket gniazdoserwera = new DatagramSocket(6428); P2 P3 P1 P1 PN: 6428 PO: 9157 PN: 6428 PO: 5775 PN: 9157 PN: 5775 klient IP: A PO: 6428 serwer IP: C PO: 6428 klient IP:B Port nadawcy (PN) jest adresem zwrotnym. 41 Demultipleksacja połączeniowa Gniazdo TCP jest określane przez cztery wartości: adres IP nadawcy port nadawcy adres IP odbiorcy port odbiorcy Host odbierający używa wszystkich 4 wartości, żeby skierować segment do właściwego gniazda Uwaga: host sprawdza także 5 wartość: protokół Host serwera może obsługiwać wiele gniazd TCP jednocześnie: każde gniazdo ma inne 4 wartości Serwery WWW mają oddzielne gniazda dla każdego klienta HTTP z nietrwałymi połączeniami wymaga oddzielnego gniazda dla każdego żądania 42 21

22 Demultipleksacja połączeniowa (c.d) P1 P4 P5 P6 P2 P1 P3 PN: 5775 PO: 80 IP-N: B IP-O: C PN: 9157 PN: 9157 klient IP: A PO: 80 IP-N: A IP-O: C serwer IP: C PO: 80 IP-N: B IP-O: C klient IP: B 43 Demultipleksacja połączeniowa i serwer wielowątkowy P1 P4 P2 P1 P3 PN: 5775 PO: 80 IP-N: B IP-O:C PN: 9157 PN: 9157 klient IP: A PO: 80 IP-N: A IP-O: C serwer IP: C PO: 80 IP-N: B IP-O: C klient IP: B 44 22

23 Porty komunikacyjne Numer przydzielony przez system: 0 po wywołaniu bind system wybiera numer portu (znaleźć go można po wywołaniu getsockname()) Porty zarezerwowane: Porty dobrze znane: (/etc/services) Porty zwyczajowo zarezerwowane dla Unixa BSD: Przydzielane przez rresvport: Porty wolne Mapa wykładu Usługi warstwy transportu Multipleksacja i demultipleksacja Transport bezpołączeniowy: UDP Zasady niezawodnej komunikacji danych Transport połączeniowy: TCP struktura segmentu niezawodna komunikacja kontrola przepływu zarządzanie połączeniem Mechanizmy kontroli przeciążenia Kontrola przeciążenia w TCP 46 23

24 UDP: User Datagram Protocol [RFC 768] bez bajerów, odchudzony protokół transportowy Internetu usługa typu best effort, segmenty UDP mogą zostać: zgubione dostarczone do aplikacji w zmienionej kolejności bezpołączeniowy: nie ma inicjalizacji między nadawcą i odbiorcą UDP każdy segment UDP jest obsługiwany niezależnie od innych Czemu istnieje UDP? nie ma inicjalizacji połączenia (co może zwiększać opóźnienie) prosty: nie ma stanu połączenia u nadawcy ani odbiorcy mały nagłówek segmentu nie ma kontroli przeciążenia: UDP może słać dane tak szybko, jak chce 47 Więcej o UDP Długość segmentu UDP w bajtach Często używane do (z nagłówkiem) komunikacji strumieniowej tolerującej straty wrażliwej na opóźnienia Inne zastosowania UDP DNS SNMP niezawodna komunikacja po UDP: dodać niezawodność w warstwie aplikacji Praca domowa port nadawcy długość 32 bity Dane aplikacji (komunikat) port odbiorcy suma kontrolna Format segmentu UDP 48 24

25 Suma kontrolna UDP Cel: odkrycie błędów (n.p., odwróconych bitów) w przesłanym segmencie Nadawca: traktuje zawartość segmentu jako ciąg 16- bitowych liczb całkowitych suma kontrolna: dodawanie (i potem negacja sumy) zawartości segmentu nadawca wpisuje wartość sumy kontrolnej do odpowiedniego pola nagłówka UDP Odbiorca: oblicza sumę kontrolną odebranego segmentu sprawdza, czy obliczona suma kontrolna jest równa tej, która jest w nagłówku: NIE wykryto błąd TAK Nie wykryto błędu. Ale może błąd jest i tak? Wrócimy do tego. 49 Przykład sumy kontrolnej Uwaga Dodając liczby, reszta z dodawania najbardziej znaczących bitów musi zostać dodana do wyniku (zawinięta, przeniesiona na początek) Przykład: suma kontrolna dwóch liczb 16-bitowych zawinięcie suma suma kontrolna

26 na chwilę wracamy do Warstwy aplikacji 51 Mapa wykładu 2.1 Zasady budowy protokołów w. aplikacji 2.2 WWW i HTTP 2.3 DNS 2.4 Programowanie przy użyciu gniazd TCP 2.5 Programowanie przy użyciu gniazd UDP 2.6 Poczta elektroniczna SMTP, POP3, IMAP 2.7 FTP 2.8 Dystrybucja zawartości Schowki Internetowe Sieci dystrybucji zawartości 2.9 Dzielenie plików P2P 52 26

27 Programowanie gniazd UDP UDP: brak połączenia pomiędzy klientem i serwerem brak inicjalizacji połączenia nadawca nadaje każdemu pakietowi adres IP i port odbiorcy serwer musi pobrać adres IP, port nadawcy z otrzymanego pakietu UDP: wysyłane informacje mogą być gubione lub otrzymywane w innym porządku punkt widzenia programisty UDP udostępnia zawodną komunikację ciągów bajtów ( datagramów ) pomiędzy klientem i serwerem 53 Interakcja klient/serwer: UDP Serwer (działa na hostid) Klient tworzy gniazdo, port=x, dla nadchodzących połączeń : serversocket = DatagramSocket() czyta komunikat z serversocket tworzy gniazdo, clientsocket = DatagramSocket() Tworzy, adresuje (hostid, port=x), wysyła datagram z komunikatem przez clientsocket wysyła odpowiedź serversocket podając adres i port klienta czyta odpowiedź z clientsocket zamyka clientsocket 54 27

28 sendpacket receivepacket infromuser Przykład: Klient w Javie (UDP) klawiatura monitor Proces klienta Wyjście: wysyła pakiet (przez TCP, wysyłał strumień bajtów ) strumien wejsciowy pakiet UDP pakiet UDP Wejście: odbiera pakiet (przez TCP odbierał strumień bajtów ) gniazdo clientsocket UDP klienta gniazdo UDP do sieci z sieci 55 Przykład: klient w Javie (UDP) Tworzy strumień wejściowy Tworzy gniazdo klienta Tłumaczy nazwę na adres IP używając DNS 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(); 56 28

29 Przykład: klient w Javie (UDP), c.d. Tworzy datagram z danymi do wysłania, długością, adresem IP, portem Wysyła datagram do serwera Czyta datagram z serwera } 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(); } 57 Przykład: serwer w Javie (UDP) import java.io.*; import java.net.*; Tworzy gniazdo UDP na porcie 9876 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]; Tworzy miejsce na otrzymany datagram Odbiera datagram while(true) { DatagramPacket receivepacket = new DatagramPacket(receiveData, receivedata.length); serversocket.receive(receivepacket); 58 29

30 Przykład: serwer w Javie (UDP), c.d. Pobiera adres IP, numer portu, nadawcy pakietu String sentence = new String(receivePacket.getData()); InetAddress IPAddress = receivepacket.getaddress(); int port = receivepacket.getport(); String capitalizedsentence = sentence.touppercase(); Tworzy datagram do wysłania do klienta Wysyła datagram przez gniazdo } } senddata = capitalizedsentence.getbytes(); DatagramPacket sendpacket = new DatagramPacket(sendData, senddata.length, IPAddress, port); serversocket.send(sendpacket); } Koniec pętli "while", powrót i oczekiwanie na następny datagram 59 wracamy do Warstwy transportu 60 30

31 Mapa wykładu Usługi warstwy transportu Multipleksacja i demultipleksacja Transport bezpołączeniowy: UDP Zasady niezawodnej komunikacji danych Transport połączeniowy: TCP struktura segmentu niezawodna komunikacja kontrola przepływu zarządzanie połączeniem Mechanizmy kontroli przeciążenia Kontrola przeciążenia w TCP 61 Zasady niezawodnej komunikacji danych Ważne w warstwie aplikacji, transportu i łącza Jeden z najważniejszych tematów w dziedzinie sieci! warstwa wyższa Proces nadawcy dane Proces odbiorcy dane warstwa niezawodna kanał niezawodny npk_send() dane deliver_data() dane Niezawodny protokół transportowy (nadawca) zpk_send() pakiet Niezawodny protokół transportowy (odbiorca) npk_recv() pakiet warstwa niższa a) udostępniana usługa kanał zawodny b) implementacja usługi charakterystyka zawodnego kanału określa złożoność niezawodnego protokołu komunikacji (npk) 62 31

32 Niezawodna komunikacja (npk) npk_send(): wywoływany przez wyższą warstwę. Przekazuje dane do przesłania do odbiorcy deliver_data(): wywoływany przez npk. Przekazuje dane do wyższej warstwy npk_send dane dane deliver_data warstwa niezawodna Niezawodny protokół transportowy (nadawca) Niezawodny protokół transportowy (odbiorca) zpk_send pakiet pakiet npk_recv warstwa niższa nadawca kanał zawodny odbiorca zpk_send(): wywoływany przez npk. Wysyła pakiet przez zawodny kanał do odbiorcy npk_rcv(): wywoływany przez niższą warstwę, gdy pakiet zostanie odebrany po stronie odbiorcy 63 Niezawodna komunikacja: początki Co zrobimy: stopniowo zaprojektujemy nadawcę i odbiorcę niezawodnego protokołu komunikacji (npk) komunikacja danych tylko w jedną stronę ale dane kontrolne w obie strony! użyjemy automatów skończonych (AS) do specyfikacji nadawcy, odbiorcy zdarzenie powodujące zmianę stanu czynności wykonywane przy zmianie stanu stan: w określonym stanie, następny stan jest jednoznacznie określony przez następne zdarzenie stan 1 zdarzenie (lub brak: ) czynności (lub brak: ) stan

33 Npk1.0: niezawodna komunikacja przez niezawodny kanał używany kanał jest w pełni niezawodny nie ma błędów bitowych pakiety nie są tracone oddzielne AS dla nadawcy, odbiorcy: nadawca wysyła dane przez kanał odbiorca odbiera dane z kanału wywołanie z góry npk_send(data) packet = make_pkt(data) zpk_send(packet) wywołanie z dołu npk_rcv(packet) extract (packet,data) deliver_data(data) nadawca odbiorca 65 Npk2.0: kanał z błędami bitowymi kanał może zmieniać bity w pakiecie suma kontrolna pozwala rozpoznać błędy bitowe pytanie: jak naprawić błąd: potwierdzenia (ang. acknowledgement, ACKs): odbiorca zawiadamia nadawcę, że pakiet jest dotarł bez błędu negatywne potwierdzenia (NAKs): odbiorca zawiadamia nadawcę, że pakiet ma błędy nadawca retransmituje pakiet po otrzymaniu NAK nowe mechanizmy w npk2.0: rozpoznawanie błędów informacja zwrotna od odbiorcy: komunikaty kontrolne (ACK,NAK) odbiorca->nadawca 66 33

34 Mapa wykładu Usługi warstwy transportu Multipleksacja i demultipleksacja Transport bezpołączeniowy: UDP Zasady niezawodnej komunikacji danych Transport połączeniowy: TCP struktura segmentu niezawodna komunikacja kontrola przepływu zarządzanie połączeniem Mechanizmy kontroli przeciążenia Kontrola przeciążenia w TCP 67 npk2.0: specyfikacja AS npk_send(data) snkpkt = make_pkt(data, checksum) wywołanie z góry npk_rcv(rcvpkt) && isack(rcvpkt) nadawca ACK lub NAK npk_rcv(rcvpkt) && isnak(rcvpkt) zpk_send(sndpkt ) odbiorca npk_rcv(rcvpkt) && corrupt(rcvpkt) zpk_send(nak) wywołanie z dołu npk_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) zpk_send(ack) 68 34

35 npk2.0: działanie bez błędów npk_send(data) snkpkt = make_pkt(data, checksum) wywołanie z góry npk_rcv(rcvpkt) && isack(rcvpkt) ACK lub NAK npk_rcv(rcvpkt) && isnak(rcvpkt) zpk_send(sndpkt ) npk_rcv(rcvpkt) && corrupt(rcvpkt) zpk_send(nak) wywołanie z dołu npk_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) zpk_send(ack) 69 npk2.0: działanie z błędami npk_send(data) snkpkt = make_pkt(data, checksum) wywołanie z góry npk_rcv(rcvpkt) && isack(rcvpkt) ACK lub NAK npk_rcv(rcvpkt) && isnak(rcvpkt) zpk_send(sndpkt ) npk_rcv(rcvpkt) && corrupt(rcvpkt) zpk_send(nak) wywołanie z dołu npk_rcv(rcvpkt) && notcorrupt(rcvpkt) extract(rcvpkt,data) deliver_data(data) zpk_send(ack) 70 35

36 npk2.0 ma fatalny błąd! Co się stanie, gdy ACK/NAK będzie miał błąd? nadawca nie wie, co się stało u odbiorcy! nie można po prostu zawsze retransmitować: możliwe jest wysłanie pakietu podwójnie (duplikatu). Obsługa duplikatów: nadawca dodaje numer sekwencyjny do każdego pakietu nadawca retransmituje aktualny pakiet, jeśli ACK/NAK ma błąd odbiorca wyrzuca (nie przekazuje wyżej) zduplikowane pakiety wstrzymaj i czekaj Nadawca wysyła jeden pakiet, potem czeka na odpowiedź odbiorcy 71 npk2.1: nadawca, obsługuje błędne ACK/NAK npk_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) npk_rcv(rcvpkt) && ( corrupt(rcvpkt) isnak(rcvpkt) ) sndpkt = make_pkt(0, data, checksum) wywołanie z góry numer=0 ACK lub NAK numer=1 npk_send(data) ACK lub NAK numer=0 wywołanie z góry numer=1 npk_send(data) sndpkt = make_pkt(1, data, checksum) npk_rcv(rcvpkt) && ( corrupt(rcvpkt) isnak(rcvpkt) ) npk_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt) 72 36

37 npk2.1: odbiorca, obsługuje błędne ACK/NAK npk_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) npk_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq1(rcvpkt) sndpkt = make_pkt(ack, chksum) npk_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, chksum) Czekaj na wyw. z dołu numer=0 Czekaj na wyw. z dołu numer=1 npk_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack, chksum) npk_rcv(rcvpkt) && (corrupt(rcvpkt) sndpkt = make_pkt(nak, chksum) npk_rcv(rcvpkt) && not corrupt(rcvpkt) && has_seq0(rcvpkt) sndpkt = make_pkt(ack, chksum) 73 npk2.1: dyskusja Nadawca: Dodaje numer sekwencyjny do pakietu Dwa numery (0,1) wystarczą. Dlaczego? musi sprawdzać, czy ACK/NAK jest poprawny dwa razy więcej stanów (niż w npk2.0) stan musi pamiętać aktualny numer sekwencyjny (0 lub 1) Odbiorca: musi sprawdzać, czy odebrany pakiet jest duplikatem stan wskazuje, czy oczekuje numeru sekwencyjnego 0, czy 1 uwaga: odbiorca może nie wiedzieć czy ostatni ACK/NAK został poprawnie odebrany przez nadawcę 74 37

38 npk2.2: protokół bez negatywnych potwierdzeń (NAK) ta sama funkcjonalność co w npk2.1, używając tylko zwykłych potwierdzeń (ACK) zamiast NAK, odbiorca wysyła ACK za ostatni poprawnie odebrany pakiet odbiorca musi dodać numer sekwencyjny pakietu, który jest potwierdzany powtórne ACK u nadawcy powoduje tę samą czynność co NAK: retransmisję ostatnio wysłanego pakietu 75 npk2.2: fragmenty nadawcy, odbiorcy npk_rcv(rcvpkt) && (corrupt(rcvpkt) has_seq1(rcvpkt)) npk_send(data) sndpkt = make_pkt(0, data, checksum) wywołanie z góry numer=0 wywołanie z dołu fragment AS nadawcy fragment AS odbiorcy ACK numer=0 numer=0 npk_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) extract(rcvpkt,data) deliver_data(data) sndpkt = make_pkt(ack1, chksum) npk_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,1) ) npk_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) 76 38

39 npk3.0: kanał z błędami oraz stratami Nowe założenie: używany kanał może gubić pakiety (z danymi lub ACK) suma kontrolna, numery sekwencyjne, potwierdzenia, retransmisje będą pomocne, ale nie wystarczą Podejście: nadawca czeka przez rozsądny czas na potwierdzenie ACK retransmituje, jeśli nie otrzyma ACK w tym czasie jeśli pakiet (lub ACK) jest tylko opóźniony, ale nie stracony: retransmisja będzie duplikatem, ale za pomocą numerów sekwencyjnych już to obsługujemy odbiorca musi określić numer sekwencyjny pakietu, który jest potwierdzany wymagany jest licznik czasu 77 npk3.0 nadawca npk_rcv(rcvpkt) npk_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,1) stop_timer timeout start_timer npk_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,0) ) wywołanie z góry numer=0 Czekaj na ACK numer=1 npk_send(data) sndpkt = make_pkt(0, data, checksum) start_timer npk_send(data) Czekaj na ACK numer=0 wywołanie z góry numer=1 sndpkt = make_pkt(1, data, checksum) start_timer npk_rcv(rcvpkt) && ( corrupt(rcvpkt) isack(rcvpkt,1) ) timeout start_timer npk_rcv(rcvpkt) && notcorrupt(rcvpkt) && isack(rcvpkt,0) stop_timer npk_rcv(rcvpkt) 78 39