La Capa de Transporte (Pt. 1) - cs.uns.edu.arags/RC/downloads/Handouts... · Por un lado, la capa de red brinda una conexión lógica punta a punta entre computadoras. Pero por otro

Redes de ComputadorasRedes de ComputadorasDepto. de Cs. e Ing. de la Comp.Depto. de Cs. e Ing. de la Comp.Universidad Nacional del SurUniversidad Nacional del Sur

Módulo 03Módulo 03La Capa de TransporteLa Capa de Transporte

(Pt. 1)(Pt. 1)

Redes de Computadoras - Mg. A. G. StankeviciusRedes de Computadoras - Mg. A. G. Stankevicius 22

CopyrightCopyrightCopyright © 2010-2018 A. G. Stankevicius

Se asegura la libertad para copiar, distribuir y modificar este documento de acuerdo a los términos de la GNU Free Documentation License, versión 1.2 o cualquiera posterior publicada por la Free Software Foundation,sin secciones invariantes ni textos de cubierta delantera o trasera.

Una copia de esta licencia está siempre disponibleen la página http://www.gnu.org/copyleft/fdl.html.

La versión transparente de este documento puedeser obtenida de la siguiente dirección:

http://cs.uns.edu.ar/~ags/teaching

http://www.gnu.org/copyleft/fdl.html

http://cs.uns.edu.ar/~ags/teaching


ContenidosContenidosServicios y protocolos de la capa de transporte.

Multiplexado y demultiplexado de segmentos.

Transporte no orientado a la conexión (UDP).

Teoría de transporte confiable de datos.

Transporte orientado a la conexión (TCP).

Establecimiento y cierre de conexiones.

Teoría de control de congestión.

Control de congestión en TCP.


ISO/OSI - TCP/IPISO/OSI - TCP/IP

7

6

5

4

3

2

1 físicaenlace

redtransporte

sesiónpresentación

aplicación

Usted está aquí

5

4

3

2

1

transporte


Servicios de transporteServicios de transporteLa capa de transporte provee la comunicación lógica entre las diversasaplicaciones de red.

El servicio brindado seimplementa a travésde los protocolos dela capa de transporte.

Por caso en internet secuenta con TCP y UDP.

aplicacióntransporte

redenlacefísica

aplicacióntransporte

redenlacefísica


Protocolos de transporteProtocolos de transporteLos protocolos de la capa de transporte corren en las computadoras de la frontera de la red.

Cabe enfatizar que los routers en el núcleo de la red usualmente sólo implementan hasta la capa de red.

El lado emisor de una comunicación corta los mensajes de las aplicaciones en segmentos,los que son pasados a la capa de red.

El lado receptor rearma los mensajes a partirde los segmentos recibidos, que son luego pasados a la capa de aplicaciones.


Transporte vs. RedTransporte vs. RedLa capa de red y la de transporte parecen ser similares, pero en realidad brindan serviciosun tanto diferentes:

Por un lado, la capa de red brinda una conexión lógica punta a punta entre computadoras.

Pero por otro lado, la capa de transporte brinda una conexión lógica punta a punta entre procesos.

La capa de transporte no sólo hace uso de los servicios provistos por la capa de red sino que además los perfecciona y extiende.


Transporte en internetTransporte en internetInternet cuenta con dos servicios de transporte.

TCP, orientado a la conexión, que brinda un envío confiable y ordenado de datos e implementa control de flujo y de congestión.

UDP, no orientado a la conexión, que brinda un envío de datos no confiable ni ordenado y tampoco implementa control de flujo ni de congestión.

El servicio de transporte de internet no tiene forma de asegurar ni un ancho de banda mínimo ni un retardo máximo.


Multiplexado y demultiplexadoMultiplexado y demultiplexadoLa capa de transporte es la encargada de generalizar el servicio de conexión entre computadoras provisto por la capa de red.

Para la capa de transporte no basta con identificar a una computadora en particular, debe poder identificar a un dado proceso.

El mecanismo que lleva a cabo esta generalización se denomina multiplexadodel lado del emisor y demultiplexadodel lado del receptor.


aplicaciónaplicación

transportetransporte

redred

enlaceenlace

físicafísica

Multiplexado y demultiplexadoMultiplexado y demultiplexado

Bruno



redred

enlaceenlace

físicafísica



redred

enlaceenlace

físicafísica

Alicia Carlos

socket socket socketP3 P4 P5

Multiplexado: se realiza en el emisor al juntar mensajes de los sockets con un encabezado adicional, el cual contiene información extraque será usada luego para demultiplexar.

socket socketP1 P2


Multiplexado y demultiplexadoMultiplexado y demultiplexadoDemultiplexado: tiene a lugar en el receptor al determinar a qué socket corresponde entregar cada uno de los datos recibidos.



redred

enlaceenlace

físicafísica

Bruno



redred

enlaceenlace

físicafísica



redred

enlaceenlace

físicafísica

Alicia Carlos

socket socket socketP3 P4 P5

socket socketP1 P2


DemultiplexadoDemultiplexadoEl proceso de demultiplexado comienzaal recibir un datagrama IP:

Cada datagrama tiene un IPde origen y de destino.

Contiene exactamenteun segmento de la capade transporte.

Cada segmento especificaun puerto origen y destino.

El IP y puerto destino identificaunívocamente a un socket.

formato de un segmentoTCP/UDP

puerto origen puerto dest.

otros campos del encabezado

cuerpo delmensaje

32 bits


Demultiplexado UDPDemultiplexado UDPCada sockets UDP se asocia a un númerode puerto local determinado.

Para identificar un socket UDP arbitrario sólohace falta una dirección IP y un puerto.

Al recibir un segmento UDP se verifica el puerto destino indicado en el segmento y se entrega su contenido al socket asociado a ese puerto.

Segmentos originados en máquinas con diversas direcciones IP o bien distintos puertos de origen pueden ser entregados al mismo socket UDP.


Demultiplexado UDPDemultiplexado UDPSupongamos que el proceso P2 crea un socket UDP en el puerto 6428:

servidor(IP: B)

socketP2

cliente(IP: A)

socketP1

cliente(IP: C)

socketP3

SP: 9157DP: 6428

SIP: ADIP: B

SP: 5775DP: 6428

SIP: CDIP: B

SP: 6428DP: 5775

DIP: CSIP: B

SP: 6428DP: 9157

DIP: ASIP: B


Demultiplexado TCPDemultiplexado TCPCada socket TCP se asocia a cuatro valores,la dirección IP y puerto de origen por un ladoy la dirección IP y puerto destino por el otro.

La computadora que recibe un segmento TCP hace uso de esos cuatro valores para determinar cuálde los sockets TCP debe recibirlo.

Los servidores hacen uso de múltiples sockets, uno para cada uno de los clientes conectados.

La dirección IP y puerto de origen distinguea los distintos clientes entre sí.


Demultiplexado TCPDemultiplexado TCPEl proceso P2 ahora necesita un socket TCP independiente para cada cliente:

servidor(IP: B)

cliente(IP: A)

socketP1

cliente(IP: C)

socketP3

socketsocketP2

SP: 9157DP: 80SIP: ADIP: B

SP: 5775DP: 80SIP: CDIP: B

SP: 51112DP: 5775

DIP: CSIP: B

SP: 51211DP: 9157

DIP: ASIP: B


Protocolo UDPProtocolo UDPEl protocolo UDP representa el servicio de transporte más elemental que brinda internet.

Se define formalmente en el RFC 768.

Se basa en el principio “best effort”,propio del protocolo IP de la capa de red.

Se trata de un protocolo no orientadoa la conexión:

Cada segmento UDP se puede manipularde manera independiente del resto.


Protocolo UDPProtocolo UDP¿Habiendo TCP, hace falta UDP?

UDP no necesita establecer una conexión antesde comenzar a enviar información.

Es extremadamente simple, no necesita almacenar información acerca del intercambio en curso.

Su encabezado es mucho más sencillo y ocupa menor cantidad de bytes que un encabezado TCP.

No implementa control de flujo ni de congestión,el emisor puede enviar la información al ritmoque le plazca, sin limitaciones de ningún tipo.


Protocolo UDPProtocolo UDPEl protocolo se suele utilizar para hacer streaming de audio y video.

El streaming es tolerantea pérdidas pero requiereretardos acotados.

Otros usos:

DNS.

SMNP.

Juegos en línea. formato deun segmento UDP

puerto origen puerto dest.

cuerpo delmensaje

32 bits

longitud checksum

largo en bytesdel segmento UDP,incluyendo encabezado


Checksum UDPChecksum UDPEl propósito del campo checksum es detectarla aparición de bits en error.

El emisor calcula el checksum correcto:

Considera el contenido del segmento comouna secuencia de enteros de 16 bits.

El checksum consiste de la suma en 1-complemento de esta secuencia de enteros.

Una vez obtenido el checksum correcto lo escribeen el campo correspondiente del encabezado UDP.


Checksum UDPChecksum UDPEl receptor debe verificar el checksum:

Recomputa el checksum del segmentoque acaba de recibir.

Compara el valor obtenido con el checksumregistrado en el campo del encabezado.

Si difieren se detectó uno o más erroresen la transmisión.

En contraste, si son iguales no se han detectados errores en la transmisión (¡lo cual no significaque no se hayan producido uno o más errores!).


Comunicación confiableComunicación confiable

Aplicación

Transporte

Red

P2

canal confiable

servicio provisto implementación

canal no confiable

P1

datos datos datos datos

paquete paquete

envio_rdt() entregar()

protocolo rdt(emisor)

protocolo rdt(receptor)

envio_udt() recep_rdt()

P2P1


Comunicación confiableComunicación confiable

canal no confiable

envio_rdt() entregar()datos datos

protocolo rdt(emisor)

protocolo rdt(receptor)

paquete paqueteenvio_udt() recep_rdt()

envio_rdt(): invocado desdearriba, suministra los datosa ser enviados

envio_rdt(): invocado desdearriba, suministra los datosa ser enviados

entregar(): invocado porel protocolo para entregarlos datos recibidos

entregar(): invocado porel protocolo para entregarlos datos recibidos

envio_udt(): invocado porel protocolo para transferirun paquete a través del canalno confiable

envio_udt(): invocado porel protocolo para transferirun paquete a través del canalno confiable

recep_rdt(): invocado porel protocolo cuando llegaun nuevo paquete al receptor

recep_rdt(): invocado porel protocolo cuando llegaun nuevo paquete al receptor

P2P1


Protocolo RDTProtocolo RDTA continuación analizaremos cómo se debería definir el protocolo RDT para poder brindarun servicio de transferencia confiable de datos.

La idea es comenzar con un protocolo básico para luego ir considerando un escenario más realista.

Emisor y receptor tienen responsabilidades diferentes.

Sólo consideraremos una comunicación unidireccional.

Las distintas iteraciones del protocolo RDT serán definidas a través de autómatas finitos.


RDT/1.0RDT/1.0El protocolo RDT/1.0 permite el envío confiable de datos a través de un canal confiable.

El canal no pierde información ni introduce errores.

Un autómata para el emisor y otro para el receptor.

paqenv = empaq(datos)envio_udt(paqenv)

envio_rdt(datos)esperarllamada

de arriba datos = desempaq(paqrec)entregar(datos)

recep_rdt(paqrec)esperarllamadade abajo

emisor receptor


RDT/2.0RDT/2.0El protocolo RDT/2.0 permite envío confiablede datos a través de un canal que puede causar errores a nivel de los bits.

El canal sigue sin perder información, sólo introduce errores a nivel de bit.

Los errores pueden ser detectados por el campo checksum del encabezado UDP.

No obstante, con detectar el error no basta,se debe incorporara al protocolo algún mecanismode recuperación ante la detección de un error.

¿Qué hacen los humanos ante este tipo de error?


RDT/2.0RDT/2.0La nueva versión del protocolo hará usode confirmaciones de recepción (ACK) paraindicar que el paquete fue recibido sin errores.

Si el paquete llega con errores, se solicitala retransmisión del mismo haciendo usode un mensaje específico (NAK).

El emisor reenvía el último paquete enviadoal recibir un NAK en vez de un ACK.

¿Existe alguna situación involucrando humanos enla que se haga uso de mensajes de ACK y/o NAK?


Emisor RDT/2.0Emisor RDT/2.0

envio_udt(paqenv)

recep_rdt(paqrec) &&esNAK(paqrec)

esperarllamada

de arriba

esperar porACK/NAK

recep_rdt(paqrec) &&esACK(paqrec)

envio_rdt(datos)

paqenv = empaq(datos,checksum)envio_udt(paqenv)


Receptor RDT/2.0Receptor RDT/2.0

esperarllamadade abajo

paqenv = crearpaqNAK()envio_udt(paqenv)

recep_rdt(paqrec) &&corrupto(paqrec)

paqenv = crearpaqACK()envio_udt(paqenv)datos = desempaq(paqrec)entregar(datos)

recep_rdt(paqrec) &&!corrupto(paqrec)


RDT/2.0 envío sin erroresRDT/2.0 envío sin errores

envio_udt(paqenv)


esperarllamada

de arriba

esperar porACK/NAK

envio_rdt(datos)









RDT/2.0 envío con erroresRDT/2.0 envío con errores

envio_udt(paqenv)


esperarllamada

de arriba

esperar porACK/NAK


envio_rdt(datos)








Análisis de RDT/2.0Análisis de RDT/2.0RDT/2.0 es un protocolo tipo “stop and wait”.

El emisor envía un paquete y queda a la esperade que le confirmen su correcta recepción.

No obstante, RDT/2.0 tiene un defecto fatal:

¿Qué sucede si el canal corrompe el paquete enviado por el receptor conteniendo un ACK o un NAK?

El problema es que el receptor desconoce qué está pasando con el emisor.

Asumir que se trataba de un NAK no es suficiente, puede causar que el receptor acepte un duplicado.


Posibles solucionesPosibles solucionesUna posibilidad consiste en enviar un ACK oun NAK adicional para que el receptor sepasi el emisor recibió correctamente el mensaje.

¿Qué pasa si se corrompe el ACK/NAK del ACK/NAK?

Otra posibilidad es agregar suficientes bits de código como para poder corregir estos errores.

Podría funcionar, pero no se puede aplicar a canales que pierdan paquetes.

La única solución viable parece ser numerarlos paquetes.


Paquetes duplicadosPaquetes duplicadosIncorporar un esquema de numeración delos paquetes implica que el emisor marque cada paquete que envía con un cierto número.

En el escenario que se corrompía el ACK/NAKenviado por el receptor, el emisor simplementeasume que se trataba de un NAK y reenvíael último paquete (usando el mismo númerode paquete que la vez anterior).

El receptor en caso de recibir por segunda vezel mismo paquete simplemente lo descarta.



envio_udt(paqenv)

recep_rdt(paqrec) &&(corrupto(paqrec) || esNAK(paqrec))

paqenv = empaq(0,datos,checksum)envio_udt(paqenv)

envio_rdt(datos)

recep_rdt(paqrec) &&!corrupto(paqrec) &&

esACK(paqrec))

esperarllamada 0de arriba

esperar porACK/NAK 0

esperar porACK/NAK 1



envio_rdt(datos)


esACK(paqrec))

envio_udt(paqenv)

recep_rdt(paqrec) &&(corrupto(paqrec) ||

esNAK(paqrec))



esperarllamada 0de abajo


paqenv = empaq(NAK,checksum)envio_udt(paqenv)


paqenv = empaq(ACK,checksum)envio_udt(paqenv)


nrosec0(paqrec)

datos = desempaq(paqrec)entregar(datos)paqenv = empaq(ACK,checksum)envio_udt(paqenv)


nrosec0(paqrec)

datos = desempaq(paqrec)entregar(datos)paqenv = empaq(ACK,checksum)envio_udt(paqenv)


nrosec1(paqrec)paqenv = empaq(NAK,checksum)envio_udt(paqenv)


paqenv = empaq(ACK,checksum)envio_udt(paqenv)


nrosec1(paqrec)


Análisis de RDT/2.1Análisis de RDT/2.1RDT/2.1 incorpora números de secuenciaen los paquetes enviados por el emisor.

Con sólo dos números de paquete es suficiente.

El emisor verifica la correcta recepción delos mensajes de ACK/NAK.

Los autómatas finitos que definen el protocolo requieren el doble de estados que en RDT/2.0.

Los estados distinguen el número de secuenciadel próximo paquete a ser enviado o recibido.


Análisis de RDT/2.1Análisis de RDT/2.1El receptor debe verificar que los paquetes recibidos tengan el número de secuencia esperado.

Caso contrario, se trata de un paquete duplicado,el cual debe ser descartado.

El receptor no tiene forma de saber si el emisor recibió correctamente el último ACK/NAK.

Se dará cuenta implícitamente que el emisor recibió correctamente el ACK cuando vea un paquete numerado con el próximo valor de la secuencia.


RDT/2.2RDT/2.2El protocolo RDT/2.1 admite ser optimizado evitando tener que hacer uso de los mensajes NAK de reconocimiento negativo.

La idea es que el receptor indique qué paquete está reconociendo al enviar un ACK.

Debemos incorporar el número de secuenciaen los mensajes enviados por el receptor.

La recepción por parte del emisor deun segundo ACK hace las veces de NAK.

En ambos casos se debe reenviar el último paquete.



envio_udt(paqenv)

recep_rdt(paqrec) &&(corrupto(paqrec) || esACK1(paqrec))


envio_rdt(datos)


esACK0(paqrec)


esperar porACK 0

esperar porACK 1



envio_rdt(datos)


esACK1(paqrec))

envio_udt(paqenv)

recep_rdt(paqrec) &&(corrupto(paqrec) ||

esACK0(paqrec))





paqenv = empaq(0,ACK,checksum)envio_udt(paqenv)

recep_rdt(paqrec) &&(corrupto(paqrec) || nrosec0(paqrec)

datos = desempaq(paqrec)entregar(datos)paqenv = empaq(0,ACK,checksum)envio_udt(paqenv)almenosunoenv = false

recep_rdt(paqrec) &&!corrupto(paqrec) && nrosec0(paqrec)

datos = desempaq(paqrec)entregar(datos)paqenv = empaq(1,ACK,checksum)envio_udt(paqenv)

recep_rdt(paqrec) &&!corrupto(paqrec) && nrosec1(paqrec)if(!almenosunoenv)

paqenv = empaq(1,ACK,checksum) envio_udt(paqenv)

recep_rdt(paqrec) &&(corrupto(paqrec) || nrosec1(paqrec))

almenosunoenv = true


RDT/3.0RDT/3.0El protocolo RDT/3.0 permite envío confiable de datos a través de un canal que puede causar errores a nivel de los bits y/o perder en su totalidad alguno de los mensajes enviados.

El protocolo debe contemplar que se pierdaun paquete o un mensaje de ACK.

Se deben resolver dos problemas: cómo detectarlas pérdidas y qué hacer cuando se produzca una.

Los mecanismos presentes en RDT/2.2 no permiten detectar que se produjo una pérdida.


RDT/3.0RDT/3.0Un posible solución es quedar a la espera deun paquete o un mensaje ACK y cuando se tenga la certeza de que se perdió reenviarlo.

¿Cuánto hay que esperar para tener la certezaque se perdió el último mensaje enviado?

Esta alternativa funciona, pero implica pagar un costo muy alto en eficiencia al perderse un mensaje.

Una mejor opción es quedar a la espera de una respuesta por un tiempo razonable y si no llega asumir que se perdió y reenviarlo.


RDT/3.0RDT/3.0¿Qué sucede si en realidad el paquete estaba retrasado, pero no se había perdido?

El reenvió generará un mensaje duplicado, peroel protocolo ya maneja correctamente esa situación.

Emisor y receptor deben indicar el númerode secuencia en sus mensajes.

Para implementar esta política hace falta contar con un temporizador programable.


Emisor RDT/3.0Emisor RDT/3.0paqenv = empaq(0,datos,checksum)envio_udt(paqenv)poner(alarma)

envio_rdt(datos)

recep_rdt(paqrec) &&(corrupto(paqrec) ||nrosec1(paqrec))



esperar porACK 0

esperar porACK 1

disparo(alarma)

envio_udt(paqenv)poner(alarma)

sacar(alarma)


nrosec0(paqrec)

recep_rdt(paqrec)

recep_rdt(paqrec)

paqenv = empaq(1,datos,checksum)envio_udt(paqenv)poner(alarma)

envio_rdt(datos)

recep_rdt(paqrec) &&(corrupto(paqrec) ||nrosec0(paqrec))

disparo(alarma)

envio_udt(paqenv)poner(alarma)

sacar(alarma)


nrosec1(paqrec)


RDT/3.0 idealRDT/3.0 ideal

envío paq. 0recep. paq. 0envío ACK 0

recep. ACK 0envío paq. 1 recep. paq. 1

envío ACK 1recep. ACK 1envío paq. 0 recep. paq. 0

envío ACK 0recep. ACK 0

emisor receptor


Pérdida de un paquetePérdida de un paquete

envío paq. 0recep. paq. 0envío ACK 0

recep. ACK 0envío paq. 1

disparo de alarmareenvío paq. 1 recep. paq. 1


emisor receptor

paquetepérdido


Pérdida de un ACKPérdida de un ACK

recep. paq. 1envío ACK 1

disparo de alarmareenvío paq. 1 recep. paq. 1 (duplicado detec.)

reenvío ACK 1recep. ACK 1

emisor receptor

ACKpérdido


recep. ACK 0envío paq. 1

envío paq. 0


Reenvío prematuroReenvío prematuro

disparo de alarmareenvío paq. 0 recep. paq. 0 (duplicado detec.)

reenvío ACK 0recep. ACK 0

(duplicado detec.)

emisor receptor


envío paq. 0

recep. ACK 0envío paq. 1 recep. paq. 1



Análisis de RDT/3.0Análisis de RDT/3.0El protocolo RDT/3.0 cumple con el objetivo propuesto, esto es, permite la transmisión confiable de datos sobre un canal no confiable.

No obstante, este protocolo presenta un desempeño bastante pobre, lo que lo torna poco aplicable a escenarios del mundo real.

Esta es una característica propia de los protocolosde la familia “stop-and-wait”.


Desempeño de RDT/3.0Desempeño de RDT/3.0Consideremos la siguiente situación:

Se dispone de una línea dedicada de 1 Gb/s queune dos de las oficinas de una cierta compañía.

Se intercambian paquetes de 1 KB y el RTT entreestas oficinas es de 30 ms.

uenlace

= L/R

RTT + L/R= .008 ms

30.008 ms= 0.027%

dtrans

= L (cantidad de bits)

R (ancho de banda) = 8000 b

10^9 b/s= 8 microseg.

1 paq. / 30 ms = 1 Gb/s x 0.027% = 33.3 KB/s


Operatoria stop-and-waitOperatoria stop-and-wait

recep. del primer bit

recep. del ACK (t = L/R + RTT)comienza el envío del sig. paq.

envío del primer bit (t = 0)

envío del último bit (t = L/R)

recep. del último bitenvío del ACKRTT

uenlace

= L/R

RTT + L/R= .008 ms

30.008 ms= 0.027%


Operatoria en pipelineOperatoria en pipelineEl factor de utilización obtenido de apenas 0.027% es evidentemente inaceptable.

Habría que permitir una operatoria en pipelinea fin de elevar el factor de ocupación.

La idea básica es permitir que varios paquetesestén en camino al mismo tiempo.

A tal efecto hace falta incrementar los númerosde secuencia disponibles.

También hace falta alguna forma de almacenamiento intermedio tanto en emisor como receptor.


Operatoria en pipelineOperatoria en pipeline

recep. del primer bit

recep. del ACK, comienza el envíodel sig. paq. (t = L/R + RTT)

envío del primer bit (t = 0)

envío del último bit (t = L/R)

último bit 1er. paq. / envío ACKRTT

uenlace

= 3 x L/R

RTT + L/R= .024 ms

30.008 ms= 0.08%

último bit 2do. paq. / envío ACK

último bit 3er. paq. / envío ACK

¡mejora la utilizaciónpor un factor de 3!


Operatoria en pipelineOperatoria en pipelineGo-Back N (GBN)

El emisor puede tener hasta n paquetes aun sin confirmar.

El receptor sólo envía ACKs acumulativos(¡no tolera huecos!).

El emisor sólo requiere un temporizador para el paquete más antiguo sin reconocer.

Selective Repeat (SR)

El emisor puede tener hasta n paquetes aun sin confirmar.

El receptor envía ACKs individuales para cada paquete.

El emisor mantieneun temporizador para paquete aun no reconocido.


Protocolo Go-Back-NProtocolo Go-Back-NEl protocolo GBN es una de las formasde implementar la operatorio en pipeline.

Se reservan k bits del encabezado para los números de secuencia de los paquetes.

Se permiten hasta una ventana deslizante de n paquetes en tránsito, esto es, aquellos cuales cuya confirmación de recepción aún no ha sido recibida.

ACK yarecibido

enviadosesperando ACK

a ser enviados todavíano usables

ventana deslizantede tamaño N


Emisor GBNEmisor GBN

esperarllamada

de arriba

base = 1proxnum = 1

envio_rdt(datos)

if(proxnum < base + N) { paqenv[proxnum] = empaq(proxnum, datos, checksum) envio_udt(paqenv[proxnum]) if (proxnum == base) poner(alarma) proxnum++} else rechazar(datos)

disparo(alarma)

poner(alarma)envio_udt(paqenv[base])envio_udt(paqenv[base + 1])¼

envio_udt(paqenv[proxnum - 1])


base = nrosec(paqrec) + 1if (proxnum == base) sacar(alarma)else poner(alarma)



Receptor GBNReceptor GBN


recep_rdt(paqrec) && !corrupto(paqrec) &&(nrosec(paqrec) == proxnumreq)

datos = desempaq(paqrec)entregar(datos)paqenv = empaq(proxnumreq, ACK, checksum)envio_udt(paqenv)proxnumreq++

recep_rdt(paqrec) &&(corrupto(paqrec) || (nrosec(paqrec) != proxnumreq)))

envio_udt(paqenv)

proxnumreq = 1paqenv = empaq(0,ACK,checksum)


Análisis GBNAnálisis GBNEl receptor sólo envía un mensaje de ACK para el paquete correctamente recibido con mayor número de secuencia.

Esta política puede generar mensajes de ACK duplicados.

El receptor sólo necesita recordar el númerode secuencia del próximo paquete que desea.

Los paquetes recibidos fuera de ordenson descartados.

El receptor no requiere almacenamiento intermedio.


GBN en acciónGBN en acción

envío paq. 0

recep. paq. 0, envío ACK 0envío paq. 2

rec. ACK 1, env. paq. 4

reenvío paq. 2

envío paq. 1

envío paq. 3 recep. paq. 1, envío ACK 1

recep. paq. 3 (se descarta)reenvío ACK 1

rec. ACK 2, env. paq. 5 recep. paq. 4 (se descarta)reenvío ACK 1recep. paq. 5 (se descarta)reenvío ACK 1recep. paq. 2, envío ACK 2

reenvío paq. 3

reenvío paq. 5reenvío paq. 4

recep. paq. 3, envío ACK 3recep. paq. 4, envío ACK 4recep. paq. 5, envío ACK 5

1 2 3 4 5 60 71 2 3 4 5 60 71 2 3 4 5 60 71 2 3 4 5 60 7

1 2 3 4 5 60 71 2 3 4 5 60 7

1 2 3 4 5 60 71 2 3 4 5 60 71 2 3 4 5 60 71 2 3 4 5 60 7


Repetición SelectivaRepetición SelectivaEl protocolo Repetición Selectiva (SR) es otra implementación de la operatoria en pipeline.

La idea central es disminuir el número de paquetesa ser reenviados al recuperarse de una pérdida.

A diferencia de GBN, el receptor reconocepor separado a cada uno de los paquetes correctamente recibidos.

El receptor debe contar con un almacenamiento intermedio para alojar los paquetes recibidos correctamente pero fuera de orden.


Repetición SelectivaRepetición SelectivaEl emisor sólo debe reenviar aquellos paquetes para los que aún no se haya recibido el mensaje de ACK correspondiente

Esto implica que debemos contar con un temporizador independiente para cada paquete enviado cuyo ACK asociado aún no haya sido recibido.

El emisor cuenta con una ventana deslizantede n números consecutivos de secuencia.

La ventana representa el conjunto de paquetes que tiene permitido tener en tránsito al mismo tiempo.


Visión del emisor y receptorVisión del emisor y receptor

ventana deslizante

enviados, ACK ya recibidoenviados, esperando ACKusables, a ser enviadosno usables

ventana deslizante

emisor SR

receptor SR

recibidos fuera de orden, ACK ya enviadoa la espera, aún no recibidos

aceptablesno usables


Emisor SREmisor SREl emisor SR debe reaccionar ante los eventos que se presenten de la siguiente manera:

Al recibir un nuevo paquete a ser enviado debe verificar si el siguiente número de secuenciase encuentra dentro de la ventana.

Al dispararse la alarma de un paquete debe reenviar sólo ese paquete y debe reiniciar el temporizador.

Al recibir un ACK debe marcar ese paquete como recibido y en caso de ser el menor número de paquete no reconocido, debe avanzar la ventana hasta el próximo paquete aún sin reconocer.


Receptor SRReceptor SREl receptor SR debe reaccionar ante los eventos que se presenten de la siguiente manera:

Al recibir un paquete con número de secuencia basese envía su ACK y se avanza la ventana hastael próximo paquete esperado pero aún no recibido.

Al recibir un paquete con número de secuencia entre base+1 y base+n-1 se envía su ACK y se guarda provisoriamente en el almacenamiento intermedio.

Al recibir un paquete con número de secuencia entre base-n y base-1 sólo se envía su respectivo ACK.

En cualquier otro caso, no se toma acción alguna.


Protocolo SR en acciónProtocolo SR en acción

1 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 90

1 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 90

1 2 3 4 5 6 7 8 90

enviados conf. enviados no conf.usables no usables

fuera de ordena la espera

1 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 90

1 2 3 4 5 6 7 8 90

alarmapaq. 2

1 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 90

1 2 3 4 5 6 7 8 901 2 3 4 5 6 7 8 90


El dilema del receptor SREl dilema del receptor SR

1 2 3 0 1 20

1 2 3 0 1 20



1 2 3 0 1 201 2 3 0 1 20

1 2 3 0 1 201 2 3 0 1 20

1 2 3 0 1 20

1 2 3 0 1 201 2 3 0 1 201 2 3 0 1 20

1 2 3 0 1 201 2 3 0 1 20


El dilema del receptor SREl dilema del receptor SR

1 2 3 0 1 20

1 2 3 0 1 20



1 2 3 0 1 201 2 3 0 1 20alarma

paq. 0 1 2 3 0 1 201 2 3 0 1 20

1 2 3 0 1 20

1 2 3 0 1 20

¡SR entrega un paquetefuera de orden!


Análisis SRAnálisis SREl receptor SR no tiene forma de distinguir entre estos dos escenarios.

En el primer caso el funcionamiento es el esperado, pero en el segundo caso, SR termina entregandoun paquete fuera de orden.

¿Qué relación tiene que cumplirse entreel tamaño de ventana y el conjuntode números de secuencia disponibles?

El tamaño de ventana debe ser menor o igual ala mitad de la cantidad de números de secuencia.


¿¿Preguntas?Preguntas?

Documents

La Capa de Transporte (Pt. 1) - cs.uns.edu.arags/RC/downloads/Handouts... · Por un lado, la capa de red brinda una conexión lógica punta a punta entre computadoras. Pero por otro