Número máximo de secuencia de cuadros en protocolos deslizantes

Creo que te refieres a de \ $ 0 \ $ a un máximo de \ $ 2 ^ n - 1 \ $.

Esto se debe a que desde \ $ 0 \ $ hasta un máximo de \ $ 2 ^ n \ $ necesitarías otro bit extra en binario.

Por ejemplo, si \ $ n = 8 \ $ entonces tiene valores de 0 a 256 (\ $ 2 ^ 8 \ $). Eso es 257 valores (¡cero conteos!) Que requiere 9 bits, pero de 0 a 255 (\ $ 2 ^ 8 - 1 \ $) es el rango completo de 8 bits o 256 valores.

Si tiene Windows 7, puede jugar con el modo "Programador" en la calculadora. Ayuda a visualizar algunos de estos conceptos. Lo uso todo el tiempo, especialmente cuando escribo ensamblado.

Interpreté tu pregunta como una que es un caso muy famoso en TCP por no usar el doble de números de secuencia que pareces necesitar. La regla es que solo puede tener números de secuencia en vuelo (un tamaño máximo de ventana) que sea a lo sumo la mitad del número de números de secuencia posibles, dados los bits que reserva para ellos. Un ejemplo: si tiene 11 bits reservados para los números de secuencia en su encabezado, puede generar 2048 enteros diferentes. Solo puede enviar un máximo de 1024 bytes en los datos de una sola ventana.

Al generar paquetes en TCP, por ejemplo, indicará el número del primer byte en secuencia en el campo del número de secuencia. Una vez que llegue al último número, volverá a 0. Estos son números de byte y no de paquete. Entonces, ¿por qué esta regla? Debido a que es posible tener un receptor que malinterprete un número de secuencia para aplicar al byte incorrecto en una secuencia.

Un ejemplo: elige un esquema con 4 números de secuencia, 2 bits. Se van numerando bytes a medida que los envía, 0, 1, 2, 3, 0, 1, 2, 3. El receptor espera 0, 1, 2, 3 y, a medida que llegan, los pone a disposición de la aplicación que espera. y envía un acuse de recibo. Pero considere lo que sucede cuando sus cuatro bytes se envían y llegan con éxito, pero los reconocimientos se pierden: el receptor ha avanzado su ventana esperando la segunda ronda de bytes numerados 0, 1, 2, 3, que han recibido la serie anterior. El remitente, sin embargo, eventualmente reenvía el original 0, 1, 2, 3 ya que nunca fueron reconocidos. Está reenviando su primer 0, pero el receptor lo interpretará como el segundo 0 y lo pondrá a disposición de la aplicación en espera. Desastre. La única forma de evitar esto es tener siempre el doble de números de secuencia de los que puede tener bytes en vuelo, enviados pero en espera de confirmación.

Los protocolos de comunicación usualmente usan formatos de mensajes rígidos que se definen hasta el nivel de octetos o bits individuales. Los "encabezados" de los mensajes de protocolo utilizan tipos de datos simples de ancho fijo, como números de 8, 16 o 32 bits.

Cuando un tipo de datos de este tipo representa un número de secuencia de mensaje, tiene sentido tratar ese tipo de datos como si se tratara de una representación binaria pura.

El valor máximo de un número binario de N bits es \ $ 2 ^ {N} - 1 \ $.

El ancho particular N se elige en función de varios criterios, como la profundidad de la ventana deslizante del protocolo y también la probabilidad de problemas causados por números de secuencia reproducidos, y si existe la necesidad de minimizar el tamaño del encabezado del protocolo (porque los sistemas que usan el protocolo son muy pequeños y la red tiene un ancho de banda muy bajo o lo que sea). Además, la consideración de si el número de secuencia enumera paquetes, o si también da una posición en un flujo de bytes (al igual que los números de secuencia TCP).

En algunas situaciones, puede ser aceptable usar un número de secuencia que solo tenga 8 bits de ancho, o incluso más estrecho.

Un número de secuencia de 3 bits no es posible si puede haber más de ocho paquetes no reconocidos en la ventana deslizante. Los primeros 7 paquetes pueden transmitirse con los números de secuencia del 0 al 7. Luego, el siguiente número de secuencia se ajusta a 0. Si el paquete 0 aún no se ha reconocido como recibido, el número de secuencia 0 no se puede reutilizar. Debido a que el paquete 0 podría haber sido eliminado por la red, y el paquete 0 recién transmitido (que en realidad es el paquete # 8) será confundido por el extremo remoto como el primer paquete, corrompiendo el flujo transmitido.

Tenga en cuenta que el rango de 0 a 7 no es necesariamente suficiente. Supongamos que el otro extremo no está reconociendo el primer paquete, por lo que tiene que ser retransmitido varias veces. Supongamos que luego reconoce el paquete, y así el protocolo avanza al paquete 8, que reutiliza la secuencia 0. pero suponga que todavía hay copias del paquete original 0 en tránsito. Estos paquetes son ambiguos contra el nuevo 0. Por esta razón, los protocolos deben tener en cuenta la red. ¿La red tiene enrutadores que almacenan y reenvían muchos paquetes? Si es así, necesita un rango de números de secuencia muy superior al tamaño de la ventana deslizante, de modo que cuando se reciclen los números de secuencia, no haya ninguna posibilidad de tal ambigüedad, o al menos la posibilidad es muy pequeña.

  

Una discusión sobre el diseño de protocolos y formatos de paquetes de protocolos es "demasiado amplia"; además, este sitio podría no ser el mejor ajuste, a menos que se trate de un protocolo específico utilizado en sistemas integrados.

"2n-1" probablemente debería escribirse "2 ⁿ -1", donde los números de secuencia aparecen n bits. Si el número de secuencia ocupa 3 bits, el valor posible es 0 - 7, porque 2 ³ es 8