Este artículo lo lleva a ver la relación principal entre las tres versiones del protocolo confiable de transmisión de datos RDT y la explicación de la máquina de estados finitos

Serie de redes informáticas de autoaprendizaje, si hay un error, corríjame.

Escriba al frente: aquí está el registro de crecimiento de Xiao Wang, un estudiante universitario ordinario que quiere compartir sus notas de estudio después de aprender, registrar su trayectoria de crecimiento y ayudar a quienes lo necesiten. Por lo general, el contenido del blog es principalmente algunos sistemas Notas de estudio, notas prácticas de proyectos, algunas exploraciones técnicas y algunas de mis propias ideas. Todos son bienvenidos a prestar atención, leeré cuidadosamente cada comentario que desee y siga. Si tiene alguna pregunta, hágamelo saber. Haré todo lo posible para ayudar a todos y crear un entorno hermoso para CSDN.

---

0. Introducir

• El problema de la transmisión confiable de datos no solo aparece en la capa de transporte, sino también en la capa de enlace y la capa de aplicación. Muchos "problemas generales" aparecerán en la red, pero la transmisión confiable de datos es particularmente importante.
• Servicios proporcionados por transmisión confiable de datos: los datos pueden transmitirse a través de un canal confiable . Por medio de un canal fiable, de transmisión de bits de datos no puede ser dañado (de 0 a 1, o viceversa) o pérdida , y y todos los datos son en función de su transmisión entrega de la orden en línea .
• La siguiente hipótesis a lo largo de nuestra discusión es que los paquetes se entregarán en el orden en que fueron enviados , y algunos paquetes pueden perderse; esto significa que el canal subyacente no reordenará los paquetes.
• La definición es clara: la
  máquina de estados finitos (máquina de estados finitos, FSM), también conocida como autómata de estados finitos, denominada máquina de estados, es un modelo matemático que representa un número finito de estados y el comportamiento de las transiciones y acciones entre estos estados. A continuación, continuaremos discutiendo la máquina de estado finito del remitente y el receptor para lograr una transmisión de datos confiable.

1. Transmisión de datos confiable a través de un canal completamente confiable: rdt 1.0

1.1) La suposición en rdt1.0 y la leyenda de dos máquinas de estados finitos

Primero suponga que el canal subyacente es completamente confiable, el protocolo en este caso es muy simple, directamente arriba

• La figura anterior muestra la definición de Máquina de estado finito (FSM) para rdt 1. 0 emisor y receptor.
• El remitente de rdt solo acepta los datos de las capas superiores a través del evento rdt_send (datos) , genera un paquete que contiene los datos (a través de la acción make_pkt (datos)) y envía el paquete al canal .
• En el extremo receptor , rdt recibe un paquete del canal subyacente a través del evento rdt_rcv (paquete) , extrae datos del paquete (a través de la acción de extracción (paquete, datos)) y carga los datos a una capa superior (a través de la acción de entrega de datos (datos)).

1.2) Resumen

En este protocolo simple, una unidad de datos no es diferente de un paquete. Además, todos los paquetes fluyen del remitente al receptor; con un canal completamente confiable, el receptor no necesita proporcionar ninguna información de retroalimentación al remitente , ¡porque no hay necesidad de preocuparse por los errores! Tenga en cuenta que también hemos asumido que el receptor recibe datos La velocidad puede ser tan rápida como la velocidad a la que el remitente envía los datos. ¡Por lo tanto, el receptor no necesita solicitarle al remitente que disminuya la velocidad!

2. Transmisión de datos confiable a través del canal de error de bit: rdt 2.0

2.1) Suposiciones en rdt2.0

En rdt 2.0, suponemos que los bits en el paquete pueden estar dañados (esto es normal y generalmente aparece en la parte física de la red), y seguimos asumiendo que todos los paquetes enviados (aunque posiblemente dañados) todavía se reciben en su orden.

Entonces, para los paquetes dañados, tenemos que retransmitir. Este es un protocolo muy importante en el entorno de red de computadoras: protocolo de solicitud de repetición automática (ARQ) (protocolo de transmisión de datos confiable basado en un mecanismo de retransmisión)

Para cooperar con ARQ para lidiar con errores de bit, necesitamos otras tres funciones de protocolo:

• 1. Detección de errores:
     permite al receptor detectar y posiblemente corregir errores de bits en el paquete.
     -Las técnicas de detección y corrección de errores típicos tienen suma de comprobación UDP. La sección de suma de comprobación se puede encontrar al final de mi otro blog , presentando el método de cálculo y la razón de su aparición.
• 2. Comentarios del receptor
     • Nuestro protocolo rdt 2.0 enviará paquetes ACK y NAK desde el receptor al remitente. Y en teoría, estos paquetes solo necesitan un bit de largo; por ejemplo, use 0 para NAK y 1 para ACK.
• 3. Retransmisión
     • Cuando el receptor recibe un paquete erróneo, el emisor retransmitirá el paquete.

Dos máquinas de estados finitos en rdt2.0

El remitente tiene dos estados.

• Izquierda: cuando se genera un evento rdt_send (datos), el remitente generará un paquete (sndpkt) que contiene los datos que se enviarán, con una suma de verificación, y luego enviará el paquete a través de la operación udt_send (sndpkt).

• Derecha: el protocolo del remitente espera los paquetes ACK o AK del receptor.

  • Si se recibe un paquete ACK (el símbolo rdt_rcv (rcvpkt) && IsACK (rcvpkt) corresponde al evento en la figura), el remitente sabe que el paquete enviado más recientemente se ha recibido correctamente, por lo que el protocolo vuelve al estado de espera para la capa superior de datos.
  • Si se recibe un paquete NAK, el protocolo retransmite el último paquete y espera el ACK y NAK devueltos por la parte receptora en respuesta al paquete retransmitido.

• Debemos tener en cuenta que el remitente no puede obtener más datos de la capa superior mientras espera el paquete de respuesta ACK o NAK

El extremo receptor todavía solo tiene un estado

• Cuando llega el paquete, el receptor responde un ACK o un NAK, dependiendo de si el paquete recibido está dañado nuevamente

  • ¡Esto conduce a una falla fatal de paquetes ACK o NAK!

• Método de procesamiento de pérdida de paquetes ACK o NAK

  • Posible solución

    • El remitente envía una consulta.

      • Necesita una nueva agrupación

    • Agregue suficientes bits de suma de verificación para que el remitente no solo pueda detectar errores sino también recuperarlos.

      • Para los canales que generarán errores pero no pierden paquetes, esto puede resolver el problema directamente.

    • En caso de no aceptación o pérdida de los bits del paquete ACK / NAK, el remitente retransmite directamente el paquete de datos actual

      • Causa paquete duplicado
      • El receptor no sabe si el remitente recibió correctamente el ACK o el NAK que envió la última vez. Por lo tanto, no puede saber de antemano si el paquete recibido es nuevo o una retransmisión.

  • Solución práctica

    • Para confirmar el paquete (ACK / NAK), agregue un nuevo campo, numere, remitente (reciba ACK / NAK) para verificar el número de secuencia
    • Entonces tenemos una versión revisada de rdt2.1

Dos máquinas de estados finitos en rdt2.1

Remitente

• El número de estados es el doble que el de 2.0

  • Porque debe reflejar si el número de secuencia del paquete que se está enviando actualmente (por el remitente) o el paquete (en el receptor) que desea recibir es 0 o 1.
  • La acción en el estado de enviar o esperar recibir el número de paquete 0 es similar a la acción en el estado de enviar o esperar recibir el número de paquete 1 ; la única diferencia es el método de procesamiento del número de secuencia.

• Utilice la confirmación positiva y negativa del receptor al remitente.

  • Enviar NAK correspondiente al número de serie o ACK (ACK redundante) del número de serie anterior puede desempeñar el mismo papel

• Sutil diferencia de 2.0

  • El receptor debe incluir el número de secuencia de paquete confirmado por un mensaje ACK (esto puede lograrse incluyendo el parámetro ACK 0 o ACK 1 en make_pkt () en el FSM del receptor)
  • El remitente debe verificar el número de secuencia de paquete reconocido en el mensaje ACK recibido (esto se puede lograr incluyendo el parámetro 0 o 1 en el isACKO en el FSM del remitente).

• Leyenda del emisor rdt2.2
  

3. Transmisión de datos confiable a través de un canal de pérdida de paquetes con errores de bit: rdt 3.0 (protocolo alternativo de bit)

Suposiciones en rdt3.0

En 3.0, no solo asumimos que el bit se dañará , sino que también asumimos que el canal subyacente también perderá paquetes (esto es normal) , por lo que en 3.0 debemos resolver la detección y el procesamiento de
la pérdida de paquetes. Para la detección de la pérdida de paquetes y la acción después de la pérdida de paquetes Consideramos lo siguiente:

• Método 1: retransmita el paquete después de esperar un tiempo determinado sin recibir una respuesta

  • De hecho funciona

  • El tiempo de espera debe ser al menos un retraso de ida y vuelta entre el emisor y el receptor (que puede incluirse en el retraso de la memoria intermedia del enrutador intermedio) más el tiempo requerido para que el receptor procese un paquete.

  • Pero este tipo de espera durante cierto tiempo para retransmitir también puede causar problemas:

    • 1. La demora máxima en el peor de los casos es difícil de determinar, y hay pocos factores para determinar
    • 2. Puede llevar mucho tiempo
    • 3. Genere un paquete de datos redundantes (paquete de datos duplicados): el número de serie que mencionamos anteriormente puede solucionar este problema

• Método 2: temporizador de cuenta regresiva

  • Después de que una cantidad de tiempo expire, el remitente puede ser interrumpido.
  • Por lo tanto, el remitente debe poder:
    • ① Cada vez que se envía un paquete (incluido el primer paquete y el paquete de retransmisión), se inicia un temporizador.
    • ② Responda a la interrupción del temporizador (tome las medidas apropiadas).
    • ③ Temporizador de terminación
  • Esta es también la forma real de "detectar" la pérdida de paquetes en rdt3.0, y nuestras medidas para lidiar con la pérdida de paquetes son obviamente la retransmisión.

Leyenda de la máquina de estados finitos en rdt3.0

Problemas en rdt3.0

El protocolo rdt que estamos discutiendo todavía tiene un problema más serio y la eficiencia no es suficiente, es decir, tenemos que esperar hasta que se complete el informe anterior y se confirme que el estado se recibe antes de transmitir el siguiente paquete, lo que causará mucho desperdicio. ! En este modo, enviaremos múltiples paquetes a la vez, y luego enviaremos los siguientes paquetes cuando se confirmen múltiples paquetes. Estén atentos para más detalles.

4. Recomendación de artículo relevante:

¿No ha descubierto el protocolo UDP de la capa de transporte? -Oh, ¿por qué no vienes aquí para verlo? Este

artículo te mostrará cómo multiplexar y demultiplexar.

---

He visto aquí, mis hermanos, hermanas, tíos y tías dan un comentario a Xiao Wang y dejan un comentario, crecen con Xiao Wang, su atención es mi mayor apoyo.
Ven a ver si tienes algo que hacer: índice del directorio de blogs de Xiao Wang

---

Si hay imprecisiones u omisiones en el contenido anterior, o si tiene una mejor opinión, deje un comentario a continuación para informarme, haré todo lo posible para responder.