This page was exported from Administración y Diseño de Redes Departamentales [ https://redes.noralemilenio.com ]
Export date: Thu Oct 21 5:27:33 2021 / +0000 GMT

Control de Flujo



El segundo aspecto que se necesita controlar en la gestión de un enlace de comunicación es el control de flujo, el cual es necesario para poder adaptar la velocidad de envío de datos con la velocidad de procesamiento de los datos en el receptor. El control de flujo es un conjunto de mecanismos que permiten saber al emisor cuándo puede transmitir.

Hay que tener en cuenta que, en muchas ocasiones, la velocidad de transmisión no está determinada por el ancho de banda de la línea de transmisión, es decir, la velocidad a la que el medio puede transmitir datos, sino que depende de la velocidad a la que los datos pueden ser procesados por el receptor. De esta forma, si los datos le llegan al receptor más rápido de lo que puede procesarlos, inevitablemente los datos se perderán. Podría pensarse en una solución basada en un buffer o memoria intermedia donde almacenar los datos hasta que el receptor los puede procesar. Pero esta solución solo retrasaría el problema de la pérdida de información, ya que los buffers tienen una capacidad limitada. Por ello se debe establecer un mecanismo para que el receptor pueda notificar al emisor cuándo puede enviar datos.

Existen básicamente dos métodos:

Parada y espera

En este método de control de flujo, el emisor envía una trama y espera el reconocimiento de la misma antes de enviar la siguiente, dicho reconocimiento se envía mediante una trama ACK. Este proceso se repite hasta que el emisor no tiene más datos y envía una trama EOT para indicar el final de la transmisión. Debido a que el método lleva implícita una alternancia en el flujo de los datos, se puede utilizar tanto en transmisiones half-dúplex como full-dúplex.

Este método tiene como principal ventaja su extremada sencillez, pero tiene un gran inconveniente, que es su lentitud.

parada-espera

Para mejorar este método que no es eficiente, se crea una solución que es enviar varios segmentos sin esperar a recibir los reconocimientos asociados, en este caso los paquetes que hay en tránsito entre el emisor y el receptor pueden verse como llenando una tubería lo que se conoce como Entubado o Pipilining.

Se utilizan varios segmentos por RTT (pipelining o procesamiento en cadena).

El entubado tiene las siguientes consecuencias para los protocolos fiables:

Emisor:

Ventana Deslizante

En el método de ventana deslizante, a diferencia del de parada y espera, el emisor puede enviar varias tramas consecutivas antes de esperar por la confirmación de las mismas. así mismo, el receptor puede enviar una sola confirmación para varias tramas de datos. Para implementar esta técnica es necesaria la existencia de buffers tanto en el emisor como en el receptor. Cada trama se numera con un número de secuencia.

El nombre completo de esta técnica sería “ventana deslizante de módulo n”. El valor de n está directamente relacionado con el tamaño máximo de las ventanas de transmisión. Por ejemplo, la más común es la técnica de ventana deslizante de módulo 8. Las tramas se numeran de 0 a n-1, y el tamaño máximo de la ventana es n-1. Para el ejemplo de ventana deslizante módulo 8, las tramas se numerarían de 0 a 7 y el tamaño máximo de la ventana es de siete tramas, uno menos del módulo. Esto es debido a que se pueden producir situaciones de ambigüedades que se resuelven reduciendo el tamaño máximo de la ventana.

ventana-deslizante

Funcionamiento en el emisor:

Funcionamiento en el receptor:

Ventana de recepción: grupo de tramas que el receptor tiene permitido aceptar. Toda trama que se reciba con un número de secuencia fuera de la ventana será descartada.

Cuando se recibe una trama, se reduce “por la izquierda” una posición la ventana del receptor.

Cuando se envía una confirmación, se expande “por la derecha” la ventana del receptor tantas posiciones como tramas se confirmen.

Las confirmaciones (ACK) se envían numeradas con la siguiente trama que se desea recibir. Un solo ACK puede confirmar varias tramas simultáneamente. Por ejemplo, si se envía una trama ACK 3, significa que el receptor confirma la recepción correcta de todas las tramas hasta la 2 inclusive.

Importante! Cuidado, la ventana del receptor no representa el número de tramas recibidas, sino las que todavía se pueden recibir antes de enviar una confirmación.

ventana-deslizante1

El método de ventana deslizante es útil sobre todo para transmisiones full-dúplex en las que las tramas de confirmación se pueden enviar junto con los datos que se envían en el otro sentido de la transmisión, lo cual es más eficiente que enviar tramas separadas de control. Efectivamente, al llegar una trama de datos, en lugar de enviar inmediatamente una trama de confirmación, el receptor espera a que se tengan datos que transmitir. Cuando esto ocurre, aprovecha la trama de datos para incluir en su cabecera la confirmación a la trama recibida. La mayor parte de las veces es mucho más eficiente enviar las confirmaciones dentro de una trama de datos (en la cabecera de la trama) que utilizar una trama específica solo para enviar la confirmación, ya que ésta debe incluir una cabecera propia y un campo de comprobación de errores.

Por ejemplo, en el protocolo HDLC se utiliza un solo bit para enviar una confirmación dentro de una trama de datos. Está claro que esta opción es mucho más eficiente. Esta técnica de retardar el envío de la confirmación para poder anexarlo a la siguiente trama de datos de salida se conoce como piggybacking (incorporación). (En pocas palabras es un retraso de ACK para convertirlo en trama de datos+ACK)

incorporacion

La técnica de ventana deslizante es especialmente útil en transmisiones full-dúplex, ya que se pueden aprovechar las tramas de datos para enviar confirmaciones.

Hay algunas implementaciones de ventana deslizante donde la ventana del transmisor y receptor no tienen el mismo tamaño. En algunos protocolos las ventanas pueden disminuir y aumentar a medida que se envían y reciben tramas.

Más información: tecnicas_control_flujo

Ejemplo: en este caso el emisor trabaja con una venta de valor máximo 8; por lo tanto en este momento no puede transmitir más segmentos hasta que reciba el ACK del primer segmento que ha enviado.

Seguimos el criterio habitual de protocolos reales del que el reconocimiento indica el número de secuencia siguiente al segmento que reconoce.

El ACK2 reconocerá el segmento de datos 1. También están en tránsito los ACK3, ACK4 y ACK5.

ejemplo-ventana-deslizante

Al recibir el reconocimiento (ACK)2 indicando la recepción correcta del segmento 1, el emisor a eliminado dicho segmento de la ventana y ha transmitido un nuevo segmento, el número 9, en el otro extremo el receptor ha procesado el segmento 4 y ha enviado su reconocimiento, ha si mismo suponemos que ha recibido el número 5 pero que todavía no ha enviado el reconocimiento.

ejemplo-ventana-deslizante-1

ejemplo-ventana-deslizante-2

En esta imagen el emisor a recibido el reconocimiento del segmento 2 y lo ha eliminado de la venta de transmisión, pero no ha envido nuevos datos porque de momento, la aplicación no los ha generado, en este momento el tamaño de la ventana es 7, inferior al máximo permitido.

Resumen:

 CONTROL DE FLUJO

–Requiere un canal semi-duplex o full-duplex

–No se utiliza en emisiones multicast/broadcast

Consiste en no saturar al receptor con más información de la que es capaz de gestionar

El receptor ha de usar una memoria temporal donde alojar la información antes de enviarla a las capas superiores

Conceptos fundamentales:

-Fija: inherente al medio físico

-Variable: consecuencia de los problemas de la transmisión

Mecanismos de Control de Flujo:

 

 


Post date: 2015-03-04 13:36:50
Post date GMT: 2015-03-04 13:36:50
Post modified date: 2015-03-17 15:53:46
Post modified date GMT: 2015-03-17 15:53:46

Powered by [ Universal Post Manager ] plugin. MS Word saving format developed by gVectors Team www.gVectors.com