Transferencia de datos confiable (RDT) 2.0

El protocolo de transferencia de datos confiable (RDT) 2.0 funciona en una transferencia de datos confiable a través de un canal de error de bits. Es un modelo más realista para verificar errores de bit que están presentes en un canal mientras se transfiere, es posible que los bits en el paquete estén dañados. Dichos errores de bit ocurren en los componentes físicos de una red cuando un paquete se transmite, propaga o almacena en búfer. En esto, supondremos que todos los paquetes transmitidos se reciben en el orden en que se enviaron (si están dañados). 

En esta condición le pedimos al usuario que envíe ACK (reconocimiento, es decir, el paquete que recibió es correcto y no está dañado) o NAK (reconocimiento negativo, es decir, el paquete recibido está dañado). En este protocolo detectamos el error usando Checksum Field , checksum es un valor que representa el número de bits en un mensaje de transmisión. Para verificar que el valor de la suma de verificación calculado por el usuario final es incluso ligeramente diferente del valor de la suma de verificación original, esto significa que el paquete está dañado, el mecanismo que se necesita para permitir que el receptor detecte errores de bit en un paquete usando la suma de verificación se llama Detección de errores . 

Estas técnicas permiten que el receptor detecte y posiblemente corrija los errores de bits del paquete. En esto, solo necesitamos saber que esta técnica requiere que se envíen bits adicionales (más allá de los bits de datos originales que se transferirán) del remitente al receptor; estos bits se reunirán en el campo de suma de verificación del paquete del paquete de datos RDT 2.0. 

Otra técnica es la retroalimentación del receptor , ya que el remitente y el receptor se ejecutan en diferentes sistemas finales, la única forma de que el remitente conozca el escenario del receptor, es decir, si un paquete se recibió correctamente o no, es que el receptor proporcione retroalimentación explícita a el remitente. Las respuestas de acuse de recibo positivo (ACK) y negativo (NAK) en el escenario de dictado de mensaje son un ejemplo de dicha retroalimentación. Un valor cero indica un NAK y un valor de 1 indica un ACK. 

 
Lado de envío: 

El lado de envío de RDT 2.0 tiene dos estados. En un estado, el protocolo del lado de envío está esperando que los datos pasen de la capa superior a la capa inferior. En el otro estado, el protocolo del remitente está esperando un paquete ACK o NAK del receptor (una retroalimentación). Si se recibe un paquete ACK, es decir, rdt_rcv(rcvpkt) && es ACK(rcvpkt), el remitente sabe que el paquete transmitido más recientemente se ha recibido correctamente y, por lo tanto, el protocolo vuelve al estado de espera de datos de la capa superior. 

Si se recibe un NAK, el protocolo retransmite el último paquete y espera a que el receptor devuelva un ACK o NAK en respuesta al paquete de datos retransmitido. Es importante tener en cuenta que cuando el receptor está en el estado de espera de ACK o NAK, no puede obtener más datos de la capa superior, eso solo sucederá después de que el remitente reciba un ACK y abandone este estado. Por lo tanto, el remitente no enviará un nuevo dato hasta que esté seguro de que el receptor ha recibido correctamente el paquete actual, debido a este comportamiento del protocolo, este protocolo también se conoce como Stop and Wait Protocol . 

 
Lado receptor: 

El sitio del receptor tiene un solo estado, tan pronto como llega el paquete, el receptor responde con un ACK o un NAK, dependiendo de si el paquete recibido está dañado o no, es decir, usando rdt_rcv (rcvpkt) && corrupt (rcvpkt) donde se recibe un paquete y se encuentra que tiene un error o rdt_rcv(rcvpkt) && no corrupto(rcvpkt) donde un paquete recibido es correcto. 

RDT 2.0 puede parecer que funciona, pero tiene algunos defectos. Es difícil entender si los bits de los paquetes ACK/NAK están dañados o no, si el paquete está dañado, cómo se recuperará el protocolo de estos errores en los paquetes ACK o NAK. La dificultad aquí es que si un ACK o NAK está dañado, el remitente no tiene forma de saber si el receptor ha recibido correctamente o no la última parte de los datos transmitidos.