1

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

2

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

skrzynka pocztowa użytkownika

kolejka wiadomości do wysłania

serwer poczty

agent użytk.

agent użytk.

agent użytk.

serwer poczty

agent użytk.

agent użytk.

serwer poczty

agent użytk.

SMTP

SMTP

SMTP

2

3

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

agent użytk.

agent użytk.

agent użytk.

serwer poczty

agent użytk.

agent użytk.

serwer poczty

agent użytk.

SMTP

SMTP

SMTP

4

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

3

5

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

AU

serwer poczty

serwer poczty AU

1

2 3 4 5 6

6

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

4

7

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

8

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

5

9

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

10

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

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 base64 .....

.........................

......dane kodowane przez base64

typ oraz podtyp danych multimedialnych,

deklaracje parametrów

metoda kodowaniadanych

Wersja MIME

kodowane dane

6

11

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

12

Typ Multipart (załączniki poczty)

From: alice@nalesnik.pl

To: bob@hamburger.edu

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?

7

13

Protokoły dostępu do poczty

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.

AU

Serwer poczty nadawcy

AU

SMTP SMTP protokół dostępowy

Serwer poczty odbiorcy

14

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

C: list S: 1 498

S: 2 912

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

S: +OK POP3 server ready

C: user bob

S: +OK

C: pass glodny

S: +OK user successfully logged on

8

15

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

16

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

9

17

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., www.pjwstk.edu.pl – używana przez ludzi

Pytanie: jak tłumaczyć pomiędzy adresami IP i nazwami?

18

Serwery nazw DNS ż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

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

10

19

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

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 serwerów u korzenia na całym świecie

20

Prosty przykład działania DNS

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

pytający host surf.eurecom.fr

gaia.cs.umass.edu

serwer u korzenia

serwer autorytatywny dns.umass.edu

serwer lokalny dns.eurecom.fr

1

2 3

4

5

6

11

21

Przykład działania DNS

Serwer u korzenia:

może nie znać serwera autorytatywnego

może znać pośredni serwer nazw: kogo spytać o autorytatywny serwer pytający host

surf.eurecom.fr

gaia.cs.umass.edu

root name server

lokalny serwer nazw dns.eurecom.fr

1

2 3

4 5

6

serwer autorytatywny dns.cs.umass.edu

pośredni serwer nazw dns.umass.edu

7

8

22

DNS: iterowane pytania

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” pytający host

surf.eurecom.fr

gaia.cs.umass.edu

serwer u korzenia

lokalny serwer dns.eurecom.fr

1

2 3

4

5 6

serwer autorytatywny dns.cs.umass.edu

serwer pośredni dns.umass.edu

7

8

pytanie iterowane

12

23

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 2136 http://www.ietf.org/html.charters/dnsind-charter.html

24

Rekordy DNS DNS: rozproszona baza danych przechowująca rekordy

zasobów (RZ)

Typ=NS nazwa jest domeną

(n.p. edu.pl)

wartość jest adresem IP autorytatywnego serwera nazw dla tej domeny

format RZ: (nazwa, wartość, typ,czas życia)

Typ=A nazwa hosta

wartość jest adresem IP

Typ=CNAME nazwa jest aliasem dla pewnej

“kanonicznej” (prawdziwej) nazwy

www.ibm.com jest naprawdę servereast.backup2.ibm.com

wartość jest nazwą kanoniczną

Typ=MX wartość jest nazwą serwera

poczty związanego z nazwą

13

25

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 flagi

ilość pytań ilość rekordów

ilość autorytatywnych

rekordów

ilość dodatkowych rekordów

pytania (zmienna ilość)

odpowiedzi (zmienna ilość)

autorytatywne odpowiedzi (zmienna ilość rekordów)

dodatkowa informacja (zmienna ilość rekordów)

12 b

ajtów

26

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

14

27

FTP: file transfer protocol

transfer pliku z/na zdalny host model klient/serwer

klient: strona, która rozpoczyna transmisję serwer: zdalny host

ftp: RFC 959 serwer ftp: port 21

transfer plików Serwer

FTP

Interfejs użytk. FTP

Klient FTP

lokalny system plików

zdalny system plików

użytkownik pracujący na

hoście

28

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

Serwer FTP

Kontrolne połączenie TCP, port 21

Połączenie TCP dla danych, port 20

Dla przesłania drugiego pliku, serwer otwiera drugie połączenie.

Połączenie kontrolne: “poza pasmem”

Serwer FTP utrzymuje “stan”: aktualny katalog, wcześniejszą autoryzację

15

29

30

16

31

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

3-

32

Warstwa transportu

17

3-

33

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

3-

34

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

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

18

3-

35

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

3-

36

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

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

19

3-

37

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

3-

38

Multipleksacja/demultipleksacja

aplikacji

transportu

sieci

łącza

fizyczna

P1 aplikacji

transportu

sieci

łącza

fizyczna

aplikacji

transportu

sieci

łącza

fizyczna

P2 P3 P4 P1

host 1 host 2 host 3

= proces = gniazdo

przekazywanie otrzymanych segmentów do właściwych gniazd

Demultipleksacja u odbiorcy zbieranie danych z wielu gniazd,

dodanie nagłówka (używanego później przy demultipleksacji)

Multipleksacja u nadawcy

20

3-

39

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

port nadawcy port odbiorcy

32 bity

dane aplikacji (komunikat)

inne pola nagłówka

format segmentu TCP/UDP

3-

40

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

21

3-

41

Demultipleksacja bezpołączeniowa (c.d.)

DatagramSocket gniazdoSerwera = new DatagramSocket(6428);

klient IP:B

P2

klient

IP: A

P1 P1 P3

serwer

IP: C

PN: 6428

PO: 9157

PN: 9157

PO: 6428

PN: 6428

PO: 5775

PN: 5775

PO: 6428

Port nadawcy (PN) jest „adresem zwrotnym”.

3-

42

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

22

3-

43

Demultipleksacja połączeniowa (c.d)

klient IP: B

P1

klient

IP: A

P1 P2 P4

serwer

IP: C

PN: 9157

PO: 80

PN: 9157

PO: 80

P5 P6 P3

IP-O: C

IP-N: A

IP-O: C

IP-N: B

PN: 5775

PO: 80

IP-O: C

IP-N: B

3-

44

Demultipleksacja połączeniowa i serwer wielowątkowy

klient IP: B

P1

klient

IP: A

P1 P2

serwer

IP: C

PN: 9157

PO: 80

PN: 9157

PO: 80

P4 P3

IP-O: C

IP-N: A

IP-O: C

IP-N: B

PN: 5775

PO: 80

IP-O:C

IP-N: B

23

3-

45

Porty komunikacyjne

Numer przydzielony przez system: 0 po wywołaniu bind system wybiera numer portu 1024-

5000 (znaleźć go można po wywołaniu getsockname())

Porty zarezerwowane: 1-1023 Porty dobrze znane: 1-255 (/etc/services)

Porty zwyczajowo zarezerwowane dla Unixa BSD: 256-511

Przydzielane przez rresvport: 512-1023

Porty wolne 1024-65535

3-

46

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

24

3-

47

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

3-

48

Więcej o UDP

Często używane do 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 port odbiorcy

32 bity

Dane aplikacji (komunikat)

Format segmentu UDP

długość suma kontrolna

Długość segmentu UDP w bajtach (z nagłówkiem)

25

3-

49

Suma kontrolna UDP

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 ….

Cel: odkrycie „błędów” (n.p., odwróconych bitów) w przesłanym segmencie

3-

50

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

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0

1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0

1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

zawinięcie

suma

suma kontrolna

26

3-

51

… na chwilę wracamy do

Warstwy aplikacji

52

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

27

53

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

54

Interakcja klient/serwer: UDP

zamyka

clientSocket

Serwer (działa na hostid)

czyta odpowiedź z

clientSocket

tworzy gniazdo,

clientSocket =

DatagramSocket()

Klient

Tworzy, adresuje (hostid, port=x),

wysyła datagram z komunikatem

przez clientSocket

tworzy gniazdo, port=x,

dla nadchodzących

połączeń : serverSocket =

DatagramSocket()

czyta komunikat z

serverSocket

wysyła odpowiedź

serverSocket

podając adres i port

klienta

28

55

Przykład: Klient w Javie (UDP)

sen

dP

ack

et

do sieci z sieci

rece

iveP

ack

et

inF

rom

Use

r

klawiatura monitor

clientSocket

pakiet

UDP

strumien

wejsciowy

pakiet

UDP

gniazdo

UDP

Wyjście: wysyła pakiet (przez TCP, wysyłał “strumień bajtów”)

Wejście: odbiera pakiet (przez TCP odbierał “strumień bajtów”)

Proces

klienta

gniazdo UDP klienta

56

Przykład: klient w Javie (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();

Tworzy strumień wejściowy

Tworzy gniazdo klienta

Tłumaczy nazwę na adres IP

używając DNS

29

57

Przykład: klient w Javie (UDP), c.d.

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();

}

}

Tworzy datagram z danymi do wysłania, długością, adresem

IP, portem Wysyła datagram

do serwera

Czyta datagram z serwera

58

Przykład: serwer w Javie (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);

Tworzy gniazdo UDP na porcie 9876

Tworzy miejsce na otrzymany datagram

Odbiera datagram

30

59

Przykład: serwer w Javie (UDP), c.d.

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);

}

}

}

Pobiera adres IP, numer portu,

nadawcy pakietu

Wysyła datagram przez gniazdo

Koniec pętli "while", powrót i oczekiwanie na następny datagram

Tworzy datagram do wysłania do

klienta

3-

60

… wracamy do Warstwy transportu

31

3-

61

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

3-

62

Zasady niezawodnej komunikacji danych Ważne w warstwie aplikacji, transportu i łącza

Jeden z najważniejszych tematów w dziedzinie sieci!

charakterystyka zawodnego kanału określa złożoność niezawodnego protokołu komunikacji (npk)

warstwa wyższa

warstwa niższa

warstwa niezawodna

Proces nadawcy

Proces odbiorcy

kanał niezawodny

dane dane

kanał zawodny

pakiet pakiet

Niezawodny protokół

transportowy (nadawca)

npk_send()

zpk_send() npk_recv()

Niezawodny protokół

transportowy (odbiorca)

deliver_data() dane dane

a) udostępniana usługa

b) implementacja usługi

32

3-

63

Niezawodna komunikacja (npk)

warstwa niższa

warstwa niezawodna

kanał zawodny

pakiet pakiet

npk_send

()

zpk_send

()

npk_recv

()

Niezawodny

protokół transportowy (odbiorca)

deliver_data

()

dane dane

Niezawodny

protokół transportowy (nadawca)

nadawca odbiorca

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

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

3-

64

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

stan

1 stan

2

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

zdarzenie (lub brak: )

czynności (lub brak: )

33

3-

65

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

Czekaj na

wywołanie

z góry packet = make_pkt(data)

zpk_send(packet)

npk_send(data)

extract (packet,data)

deliver_data(data)

npk_rcv(packet)

nadawca odbiorca

Czekaj na

wywołanie

z dołu

3-

66

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

34

3-

67

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

3-

68

npk2.0: specyfikacja AS

snkpkt = make_pkt(data, checksum)

zpk_send(sndpkt)

extract(rcvpkt,data)

deliver_data(data)

zpk_send(ACK)

npk_rcv(rcvpkt) &&

notcorrupt(rcvpkt)

npk_rcv(rcvpkt) && isACK(rcvpkt)

zpk_send(sndpkt

)

npk_rcv(rcvpkt) &&

isNAK(rcvpkt)

zpk_send(NAK)

npk_rcv(rcvpkt) &&

corrupt(rcvpkt)

Czekaj na

ACK lub

NAK

Czekaj na

wywołanie

z dołu nadawca

odbiorca npk_send(data)

Czekaj na

wywołanie

z góry

35

3-

69

npk2.0: działanie bez błędów

Czekaj na

wywołanie

z góry

snkpkt = make_pkt(data, checksum)

zpk_send(sndpkt)

extract(rcvpkt,data)

deliver_data(data)

zpk_send(ACK)

npk_rcv(rcvpkt) &&

notcorrupt(rcvpkt)

npk_rcv(rcvpkt) && isACK(rcvpkt)

zpk_send(sndpkt

)

npk_rcv(rcvpkt) &&

isNAK(rcvpkt)

zpk_send(NAK)

npk_rcv(rcvpkt) &&

corrupt(rcvpkt)

Czekaj na

ACK lub

NAK

Czekaj na

wywołanie

z dołu

npk_send(data)

3-

70

npk2.0: działanie z błędami

Czekaj na

wywołanie

z góry

snkpkt = make_pkt(data, checksum)

zpk_send(sndpkt)

extract(rcvpkt,data)

deliver_data(data)

zpk_send(ACK)

npk_rcv(rcvpkt) &&

notcorrupt(rcvpkt)

npk_rcv(rcvpkt) && isACK(rcvpkt)

zpk_send(sndpkt

)

npk_rcv(rcvpkt) &&

isNAK(rcvpkt)

zpk_send(NAK)

npk_rcv(rcvpkt) &&

corrupt(rcvpkt)

Czekaj na

ACK lub

NAK

Czekaj na

wywołanie

z dołu

npk_send(data)

36

3-

71

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

Nadawca wysyła jeden pakiet, potem czeka na odpowiedź

odbiorcy

wstrzymaj i czekaj

3-

72

npk2.1: nadawca, obsługuje błędne ACK/NAK

Czekaj na

wywołanie

z góry

sndpkt = make_pkt(0, data, checksum)

zpk_send(sndpkt)

npk_send(data)

Czekaj na

ACK lub

NAK zpk_send(sndpkt)

npk_rcv(rcvpkt) &&

( corrupt(rcvpkt) ||

isNAK(rcvpkt) )

sndpkt = make_pkt(1, data, checksum)

zpk_send(sndpkt)

npk_send(data)

npk_rcv(rcvpkt)

&& notcorrupt(rcvpkt)

&& isACK(rcvpkt)

zpk_send(sndpkt)

npk_rcv(rcvpkt) &&

( corrupt(rcvpkt) ||

isNAK(rcvpkt) )

npk_rcv(rcvpkt)

&& notcorrupt(rcvpkt)

&& isACK(rcvpkt)

Czekaj na

wywołanie

z góry

Czekaj na

ACK lub

NAK

numer=0 numer=0

numer=1 numer=1

37

3-

73

npk2.1: odbiorca, obsługuje błędne ACK/NAK

Czekaj

na wyw.

z dołu

sndpkt = make_pkt(NAK, chksum)

zpk_send(sndpkt)

npk_rcv(rcvpkt) &&

not corrupt(rcvpkt) &&

has_seq0(rcvpkt)

npk_rcv(rcvpkt) && notcorrupt(rcvpkt)

&& has_seq1(rcvpkt)

extract(rcvpkt,data)

deliver_data(data)

sndpkt = make_pkt(ACK, chksum)

zpk_send(sndpkt)

npk_rcv(rcvpkt) && notcorrupt(rcvpkt)

&& has_seq0(rcvpkt)

extract(rcvpkt,data)

deliver_data(data)

sndpkt = make_pkt(ACK, chksum)

zpk_send(sndpkt) npk_rcv(rcvpkt) &&

(corrupt(rcvpkt)

sndpkt = make_pkt(ACK, chksum)

zpk_send(sndpkt)

npk_rcv(rcvpkt) &&

not corrupt(rcvpkt) &&

has_seq1(rcvpkt)

npk_rcv(rcvpkt) &&

(corrupt(rcvpkt)

sndpkt = make_pkt(ACK, chksum)

zpk_send(sndpkt)

sndpkt = make_pkt(NAK, chksum)

zpk_send(sndpkt)

numer=0

Czekaj

na wyw.

z dołu

numer=1

3-

74

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ę

38

3-

75

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

3-

76

npk2.2: fragmenty nadawcy, odbiorcy

Czekaj na

wywołanie

z góry

sndpkt = make_pkt(0, data, checksum)

zpk_send(sndpkt)

npk_send(data)

zpk_send(sndpkt)

npk_rcv(rcvpkt) &&

( corrupt(rcvpkt) ||

isACK(rcvpkt,1) )

npk_rcv(rcvpkt)

&& notcorrupt(rcvpkt)

&& isACK(rcvpkt,0)

Czekaj na

ACK

fragment AS nadawcy

Czekaj na

wywołanie

z dołu

npk_rcv(rcvpkt) && notcorrupt(rcvpkt)

&& has_seq1(rcvpkt)

extract(rcvpkt,data)

deliver_data(data)

sndpkt = make_pkt(ACK1, chksum)

zpk_send(sndpkt)

npk_rcv(rcvpkt) &&

(corrupt(rcvpkt) ||

has_seq1(rcvpkt))

zpk_send(sndpkt)

fragment AS odbiorcy

numer=0 numer=0

numer=0

39

3-

77

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

3-

78

npk3.0 nadawca

sndpkt = make_pkt(0, data, checksum)

zpk_send(sndpkt)

start_timer

npk_send(data)

Czekaj

na ACK

npk_rcv(rcvpkt) &&

( corrupt(rcvpkt) ||

isACK(rcvpkt,1) )

Czekaj na

wywołanie

z góry

sndpkt = make_pkt(1, data, checksum)

zpk_send(sndpkt)

start_timer

npk_send(data)

npk_rcv(rcvpkt)

&& notcorrupt(rcvpkt)

&& isACK(rcvpkt,0)

npk_rcv(rcvpkt)

&&

( corrupt(rcvpkt) ||

isACK(rcvpkt,0) )

npk_rcv(rcvpkt)

&& notcorrupt(rcvpkt)

&& isACK(rcvpkt,1)

stop_timer

stop_timer

zpk_send(sndpkt)

start_timer

timeout

zpk_send(sndpkt)

start_timer

timeout

npk_rcv(rcvpkt) Czekaj na

wywołanie

z góry

npk_rcv(rcvpkt)

numer=0 numer=0

numer=1 numer=1

Czekaj

na ACK