Control de flujo
| ||||||
Control de Flujo es una técnica para sincronizar el envío de paquetes entre dos máquinas, las que eventualmente procesarán esta información a velocidades irregulares por lo que se hace necesario un control de flujo entre los datos transmitidos. El protocolo TCP proporciona el servicio de Control de Flujo a sus aplicaciones para eliminar la posibilidad de que el emisor desborde el buffer del receptor.
Sumario
Parada y espera
Control de flujo es la forma más simple de control de flujo. En este método, el receptor indica su disposición a recibir los datos para cada trama, el mensaje se divide en múltiples marcos. Los emisor espera para un ACK (reconocimiento) después de cada cuadro por el tiempo especificado (llamado tiempo de espera). Se envía a asegurar que el receptor ha recibido la trama correctamente. A continuación, enviar el siguiente fotograma sólo después de que se haya recibido el ACK. Operaciones
- Remitente: Transmite un solo cuadro a la vez.
- Receptor: Transmite acuse de recibo (ACK), ya que recibe una trama.
- Remitente recibe ACK dentro de tiempo de espera.
- Vaya al paso 1.
Si se pierde un marco o ACK durante la transmisión, entonces tiene que ser transmitidos de nuevo por el remitente. Este proceso se conoce como retransmisión ARQ (petición de repetición automática). El problema con Stop-and espera es que sólo un fotograma se puede transmitir a la vez, y que a menudo conduce a la transmisión ineficiente, ya que hasta el remitente recibe el ACK no puede transmitir cualquier nuevo paquete. Durante este tiempo tanto el emisor y el canal son no utilizado.
Ejemplo Introductorio
Pongámonos en la situación en que tenemos un servidor gigante, que envía una cantidad "monstruosa", de alta magnitud, de datos y a una tasa muy veloz. Ahora bien, tenemos un PC común y corriente, no muy veloz, que recibirá estos datos, por lo tanto es necesario hacer un control de el flujo de esos datos enviados. El servidor comenzará a mandar datos hasta que el PC pueda recibirlos, pero llegará un momento en que nuestro computador cliente (receptor) estará al borde del colapso, o colapsará, y debe "decirle" al servidor de alguna manera que detenga el envío de paquetes. Cuando nuestro PC tenga algún espacio en el buffer para recibir otro paquete de datos, éste le avisará al servidor que puede recibir más datos y que cantidad, a lo que el Servidor responderá enviando la data solicitada o disminuyendo la tasa de transferencia, si es que el cliente no llenó su capacidad, pero lo hubiera hecho eventualmente.
Eso es a grandes rasgos, ahora entremos en la parte técnica del asunto.
¿Qué se utiliza para controlar dicho flujo?
El protocolo TCP utiliza un mecanismo llamado Ventana Deslizante que es del tipo "Stop and Wait", esto quiere decir que el emisor deja de enviar paquetes hasta que reciba un mensaje de reconocimiento que le llegaron los datos por parte del receptor. Podemos deducir a partir de esto que es una comunicación poco eficiente, ya que si el receptor no envia el reconocimiento no se puede seguir transmitiendo.
¿Cómo funciona la Ventana Deslizante?
Le Ventana Deslizante está compuesta por dos "Ventanas", la primera es la Ventana de recepción, ubicada en el receptor, valga la redundancia, y que indica cuantos bytes caben aún en el buffer que se utilice en el receptor. La segunda "ventana" es la Ventana de envío, la que indica Qué bytes del buffer de envío se pueden envíar sin tener que esperar una confirmación. Como observación podemos decir que la Ventana de envío NO, puede ser mayor que la ventana de recepción.
Ahora explicaremos la Figura 2, que es un ejemplo de ventana deslizante:
Tenemos la ventana de envío de nuestro servidor que tiene tamaño 6, y está ubicada al comienzo del buffer de envío.
Como se ve en el diagrama central, se envía el paquete 1, al recibirlo nuestro receptor envía una confirmación ACK1, que quiere decir que recibió satisfactoriamente el paquete 1. El emisor al recibir este ACK1 sabe que recibió con éxito el primero, por lo que desliza la ventana el espacio correspondiente al tamaño del paquete número 1 o sea 1. Luego hace envío de los paquetes 2 y 3. Como el cliente los pudo recibir, envía ACK2 y ACK3, lo que hace que el servidor de envío deslice la ventana 1 espacio por el ACK2 y otro espacio por el ACK3.
Se muestra también que el servidor envía el paquete 4, 5 y 6 (indicadas por las 3 flechas que van desde el emisor al receptor que no tienen etiqueta), pero no se ha recibido confirmación por parte del cliente.
En ese instante, se observa la Ventana actualmente, que tiene la ventana deslizada 3 espacios (por los 3 paquetes enviados y recibidos satisfactoriamente). Viendola, podemos hacer el siguiente análisis:
- Los paquetes 1, 2 y 3 han sido enviados y reconocidos
- Los paquetes 4, 5 y 6 han sido enviados, pero no han sido reconocidos, es decir no se ha recibido por parte del emisor el ACK4, ACK5 y ACK6 respectivamente. Se puede ver, que al no ser reconocidos aun, la ventana no ha sido deslizada.
- Como la ventana tiene tamaño 6, y se han enviado 3 paquetes sin reconocer, aun el emisor puede mandar 3 paquetes más sin recibir reconocimiento.
- Si llegase a envíar el paquete 10 sin haber reconocido ninguno de los 6 anteriores, éste último no se podrá mandar y el receptor le dirá que no puede recibirlo, por lo que el emisor debe quedarse en "stand by" hasta que reciba un reconocimiento de alguno de los paquetes anteriores.
- Cualquier paquete que esté después de la ventana, en este caso el 10 y 11 no se podrán envíar hasta que queden dentro de la Ventana.
El control de flujo se puede realizar
• ya sea por la señal de control de líneas en una interfaz de comunicación de datos (véase el puerto serie y RS 232), • o mediante la reserva de los caracteres de control dentro de la banda de la señal de inicio de flujo y dejar (como los ASCII códigos para XON / XOFF).
Control de flujo de hardware
En común RS 232 hay pares de líneas de control que se hace referencia generalmente como el control de flujo de hardware: RTS (Request To Send) y CTS (Clear To Send), utilizado en el control de flujo RTS DTR (Data Terminal Ready) y DSR (Data Set Ready), control de flujo DTR Control de flujo de hardware suele ser manejado por el DTE o el "fin principal", ya que es primera cría o la afirmación de su línea para comandar el otro lado: En el caso de flujo de control RTS, DTE establece sus RTS, que señala el extremo opuesto (el extremo esclavo tal como un DCE) para comenzar el seguimiento de su línea de entrada de datos. Cuando esté listo para los datos, el fin de esclavos elevará su línea complementaria, CTS en este ejemplo, que señala el maestro para iniciar el envío de datos, y para el maestro para comenzar a supervisar la línea de salida de datos del esclavo. Si cualquiera de los extremos tiene que dejar de los datos, que disminuye su respectiva línea "readyness de datos". Para PC-to-módem y enlaces similares, en el caso de control de flujo DTR, DTR / DSR se crían para la sesión entera módem (por ejemplo una llamada de Internet de acceso telefónico) y RTS / CTS se plantean para cada bloque de datos.
Control de flujo de software
Por el contrario, XON / XOFF que normalmente se conoce como control de flujo por software.
