PDF de programación - Transporte fiable

ARQUITECTURA DE REDES, SISTEMAS Y SERVICIOS
Área de Ingeniería Telemática

Transporte fiable

Area de Ingeniería Telemática

http://www.tlm.unavarra.es

Arquitectura de Redes, Sistemas y Servicios

3º Ingeniería de Telecomunicación

a
c
i
t

Temario

,

I

I



S
E
D
E
R
E
D
A
R
U
T
C
E
T
U
Q
R
A

S
O
C
V
R
E
S
Y
S
A
M
E
T
S
S

I

I



l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

• Introducción
• Arquitecturas, protocolos y estándares
• Conmutación de paquetes
• Conmutación de circuitos
• Tecnologías
• Control de acceso al medio en redes de área local
• Servicios de Internet

2

a
c
i
t

Temario

,

I

I



S
E
D
E
R
E
D
A
R
U
T
C
E
T
U
Q
R
A

S
O
C
V
R
E
S
Y
S
A
M
E
T
S
S

I

I



l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

Introducción

1.
2. Arquitecturas, protocolos y estándares
3. Conmutación de paquetes

•
•

Principios
Problemas básicos
•
•
•
•
•

Como funcionan los routers (Nivel de red)
Encaminamiento (Nivel de red)
Transporte fiable (Nivel de transporte en TCP/IP)
Control de flujo (Nivel de transporte en TCP/IP)
Control de congestión (Nivel de transoporte en TCP/IP)

4. Conmutación de circuitos
5. Tecnologías
6. Control de acceso al medio en redes de área local
7. Servicios de Internet

3

Material

Del Capitulo 3 de
Kurose & Ross,
“Computer Networking a top-down approach

featuring the Internet”

Addison Wesley

,

I

I



S
E
D
E
R
E
D
A
R
U
T
C
E
T
U
Q
R
A

S
O
C
V
R
E
S
Y
S
A
M
E
T
S
S

I

I



a
c
i
t

l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

4

El problema del transporte fiable
• Enviar datos y asegurarme de que llegan

,



I

I

S
E
D
E
R
E
D
A
R
U
T
C
E
T
U
Q
R
A

S
O
C
V
R
E
S
Y
S
A
M
E
T
S
S



I



I

a
c
i
t

l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

correctamente
– No se pierde ninguno
– No se cambia ninguno
– No se generan más (no hay duplicados)
– Llegan en el mismo orden

• ¿Qué velocidades se consiguen? ¿Qué

limitaciones tiene?

5

Red y transporte

‣ Nivel de red: Comunicación lógica entre hosts


Envía este paquete al nivel de transporte de la dirección IP a.b.c.d

He recibido este paquete de la dirección IP x.y.z.t

No garantiza que todos los paquetes acaben llegando

‣ Nivel de transporte: Comunicación lógica entre procesos

App 1

Transporte

App 1

Transporte

Red

Red

Red

Red

Red

Enlace

Enlace

Enlace

Enlace

Enlace

7 noviembre 2007

Transporte-1

6

Funciones del nivel de transporte

‣ Comunicación lógica entre

aplicaciones

‣ Puede haber más de una

aplicación en cada dirección IP
> multiplexar aplicaciones

Transporte

Red

Enlace

‣ Las aplicaciones quieren que todo

lo que envían llegue
> Transporte fiable

Red

Enlace

‣ Las aplicaciones ¿envían mensajes

o establecen llamadas?
> varios protocolos con interfaz

de conexiones o mensajes

Red

Enlace

‣ No queremos saturar al receptor

ni a la red
> control de flujo y control de

congestión

Canal lógico

Red

Enlace

Red

Enlace

Transporte

Red

Enlace

7 noviembre 2007

Transporte-1

7

Transporte fiable

a
c
i
t

,



I

I



S
E
D
E
R
E
D
A
R
U
T
C
E
T
U
Q
R
A

S
O
C
V
R
E
S
Y
S
A
M
E
T
S
S



I



I

l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

• Si hubiera un “Top ten” problemas de

redes el transporte fiable sería un buen
candidato para el primer puesto

Kurose

8

Transporte fiable

a
c
i
t

,

I

I



S
E
D
E
R
E
D
A
R
U
T
C
E
T
U
Q
R
A

S
O
C
V
R
E
S
Y
S
A
M
E
T
S
S

I



I

l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á



• ¿Se puede conseguir un transporte fiable sobre un

nivel de datagramas de entrega no fiable?

t_envia(datos)

Nivel de
Transporte

Protocolo de
transporte fiable

r_envia(datos)

Nivel de Red

t_recibe(datos)

Protocolo de
transporte fiable
r_recibe(datos)

Entrega no garantizada
se pueden perder datos

9

,



I

I

S
E
D
E
R
E
D
A
R
U
T
C
E
T
U
Q
R
A

S
O
C
V
R
E
S
Y
S
A
M
E
T
S
S

I



I

a
c
i
t

l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

Pensando en protocolos

• Descripción protocolo (=programa)


con máquinas de estados finitos
– Eventos que pueden ocurrir
– Acciones como resultado de esos eventos
– El protocolo son las funciones para responder a eventos

• Emisor y receptor son diferentes programas y están en general

en distinto estado (normalmente ni siquiera su conjunto de
estados es el mismo)

10

,

I



I



S
E
D
E
R
E
D
A
R
U
T
C
E
T
U
Q
R
A

S
O
C
V
R
E
S
Y
S
A
M
E
T
S
S



I



I

a
c
i
t

l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

Protocolo de transporte fiable
• Ejemplo: protocolo de transporte sobre un

nivel de red fiable

• Diagrama de estados de emisor y

receptor

Emisor

Receptor

red fiable:
r_envia(p) siempre causa un r_recibe(p)

11

,

I

I



S
E
D
E
R
E
D
A
R
U
T
C
E
T
U
Q
R
A

S
O
C
V
R
E
S
Y
S
A
M
E
T
S
S

I

I



a
c
i
t

l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

Ejemplo

• Todo lo que envío llega
• La red/el canal puede
retrasar los paquetes
pero acaba
entregándolos todos
• Si la red es compleja

puede que algunos
tarden más que otros
• Algún problema si los
entrega siempre pero
en desorden??
– Si queremos

entrega en orden el
protocolo debe
construirlo

Emisor

Receptor

r_send(paq0)

paq0

r_send(paq1)

r_send(paq2)
r_send(paq3)

paq1

paq2

paq3

r_recv(paq0)

r_recv(paq1)

r_recv(paq2)

r_recv(paq3)

Operación normal

12

a
c
i
t

Errores de bit

,

I

I



S
E
D
E
R
E
D
A
R
U
T
C
E
T
U
Q
R
A

S
O
C
V
R
E
S
Y
S
A
M
E
T
S
S

I

I



l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

• Pero... el nivel de red puede cambiar bits (probabilidad de error)
• Cambios necesarios en el protocolo de transporte

– Detección de errores

• Uso de checksum o CRC

información redundante que depende los datos (por ejemplo bits de paridad)
si cambian bits es improbable que se siga cumpliendo la condición
detecto en recepción que el paquete no es el mismo que se envió

– Comunicación de fallos al emisor

• ACK (acknowledgement): avisar al emisor de los paquetes que recibimos.
• NACK (negative acknowledgement): avisar al emisor de los paquetes que no

recibimos correctamente
– Reenvío de paquetes

• El protocolo de transporte fiable debe retransmitir

automaticamente los errores
Esto se conoce tipicamente como ARQ (Automatic Repeat
reQuest)

13

,

I

I



S
E
D
E
R
E
D
A
R
U
T
C
E
T
U
Q
R
A

S
O
C
V
R
E
S
Y
S
A
M
E
T
S
S

I

I



a
c
i
t

l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

Protocolo de transporte fiable
• Para un canal con errores de bits

– Usamos detección de errores con checksum/CRC
– Informamos al emisor de si llegan o no
– El emisor tiene dos estados: esta esperando datos de la

aplicación o bien está esperando una confirmación
• EL protocolo es conocido como Stop-and-Wait

Emisor

Receptor

a Stop-and-wait

,



I

I

S
E
D
E
R
E
D
A
R
U
T
C
E
T
U
Q
R
A

S
O
C
V
R
E
S
Y
S
A
M
E
T
S
S



I

I



c
i
t

l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

• El emisor controlado por el

receptor
– ACK (recibido OK manda

otro)

– NACK (recibido mal manda

otra vez el mismo)

– Mientras no me dice nada

no envío

• De hecho esto puede

considerarse también control
de flujo (el emisor envía
cuando el receptor le da
permiso) = regulación de
flujo por el receptor

Emisor

Receptor

r_send(paq0)

paq0

r_recv(ack)
r_send(paq1)

r_recv(nack)
r_send(paq1)

r_recv(nack)
r_send(paq1)

r_recv(nack)
r_send(paq2)

ack

r_recv(paq0)
r_send(ack)

paq1 corrompido

nack

r_recv(paq1 err)
r_send(nack)

paq1 corrompido

nack

paq1

ack

paq2

ack

r_recv(paq1 err)
r_send(nack)

r_recv(paq1)
r_send(ack)

r_recv(paq2)
r_send(ack)

15

a Problemas con stop-and-wait

,

I

I



S
E
D
E
R
E
D
A
R
U
T
C
E
T
U
Q
R
A

S
O
C
V
R
E
S
Y
S
A
M
E
T
S
S

I



I

c
i
t

l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

• ¿Qué pasa si hay un error en

la transmisión del ACK o
NACK?

• Soluciones complican el

protocolo
– Detección de errores para

ACK y NACK?

• y que pasa si se pierden

las confirmaciones del
ACK/NACK

– Checksums que permitan no

solo detectar sino corregir
errores?

• Mucha información

– Reenviar los datos si no

entiendo el ACK/NACK ??
• Nuevo problema: paquetes

duplicados

Emisor

Receptor

r_send(paq0)

paq0

r_recv(ack)
r_send(paq1)

r_recv(no se)
r_send(paq1)

r_recv(ack)
r_send(paq2)

r_recv(no se)
r_send(paq2)

Ok 0

ack

Paq1 corrompido

Mal 1

nack
nack corrompido

Ok 1

Ok 2

ack

paq2

ack

paq2

ack corrompido

ack

Paq 2
recibido 2 veces

16

a
c
i
t

Solución

,



I

I

S
E
D
E
R
E
D
A
R
U
T
C
E
T
U
Q
R
A

S
O
C
V
R
E
S
Y
S
A
M
E
T
S
S

I



I



l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

• Los protocolos más usados utilizan contra esto numeros de

secuencia del paquete

• El paquete va etiquetado con un numero de secuencia que

permite confirmarlo/rechazarlo indicando cual
estos datos tienen el
numero de secuencia 5
datos
seq=5

cab. red

eth

checksum

cabecera
transporte

• El numero de secuencia es un campo del paquete por lo que

podrá tener una serie finita de valores

• Aunque es fácil asignar bits para que el numero de secuencia

pueda crecer mucho antes de dar la vuelta, veamos primero las
bases con números de secuencia en rangos limitados

17

,



I

I

S
E
D
E
R
E
D
A
R
U
T
C
E
T
U
Q
R
A

S
O
C
V
R
E
S
Y
S
A
M
E
T
S
S

I



I

a
c
i
t

l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

Protocolo con número de secuencia
• 1 bit para número de secuencia
Cada paquete de datos es secuencia 0 o 1

– Si llega el que esperamos mandamos ACK y lo entregamos
– Si llega el que no esperamos?
mandamos ACK pero no son datos nuevos

18

,

I

I



S
E
D
E
R
E
D
A
R
U
T
C
E
T
U
Q
R
A

S
O
C
V
R
E
S
Y
S
A
M
E
T
S
S



I

I

a
c
i
t

l



á
m
e
e
T
a
í
r
e
n
e
g
n

i

I


e
d



a
e
r
Á

Protocolo con número de secuencia
• Estados del emisor

19

,



I