Ingeniería de protocolos

Ingeniería de protocolos
Tema 2. Estructura de un protocolo
Mª del Carmen Romero
[email protected]
1
Atribución-NoComercial-LicenciarIgual 2.5
Tu eres libre de:
copiar, distribuir, comunicar y ejecutar públicamente la obra
hacer obras derivadas
Bajo las siguientes condiciones:
Atribución. Debes reconocer y citar la obra de la forma especificada por
el autor o el licenciante.
No Comercial. No puedes utilizar esta obra para fines comerciales.
Licenciar Igual. Si alteras o transformas esta obra, o generas una obra
derivada, sólo puedes distribuir la obra generada bajo una licencia
idéntica a ésta.
Al reutilizar o distribuir la obra, tienes que dejar bien claro los términos de la
licencia de esta obra.
Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular
de los derechos de autor
Los derechos derivados del uso legítimo, del agotamiento u otras limitaciones o
excepciones reconocidas por la ley no se ven afectados por lo anterior.
Esto es un resumen simple del texto legal. La licencia completa está disponible en:
http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode
Attribution-NonCommercial-ShareAlike 2.5
You are free:
to copy, distribute, display, and perform the work
to make derivative works
Under the following conditions:
Attribution. You must attribute the work in the manner specified by the
author or licensor.
Noncommercial. You may not use this work for commercial purposes.
Share Alike. If you alter, transform, or build upon this work, you may
distribute the resulting work only under a license identical to this one.
For any reuse or distribution, you must make clear to others the license terms of
this work.
Any of these conditions can be waived if you get permission from the copyright
holder.
Your fair use and other rights are in no way affected by the above.
This is a human-readable summary of the Legal Code. Read the full license at:
http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode
Estructura de un protocolo
1. Introducción
2. Los cinco elementos de un protocolo
3. Servicio y entorno
4. Vocabulario y formato de los mensajes
5. Reglas de procedimiento
6. Diseño de un protocolo estructurado
7. Mecanismos básicos de los protocolos
2
Introducción
A
B
d
Acuerdos sobre:
- Inicio y final del intercambio de datos
- Sincronización de emisores y receptores
- Detección y corrección de errores de transmisión
- Formateo y codificación de los datos
3
Introducción
Niveles de abstracción
señal eléctrica
bits
símbolos/caracteres
campos de mensaje
tramas/paquetes
4
Los cinco elementos de un protocolo
1. Servicio que proporciona el protocolo
2. Suposiciones sobre el entorno donde se ejecuta el protocolo
3. Vocabulario de los mensajes utilizados en el protocolo
4. Formato de los mensajes del vocabulario del protocolo
5. Reglas de procedimiento que controlan la consistencia del
intercambio de mensajes
5
Los cinco elementos de un protocolo
Especificación del servicio
El propósito del protocolo es transferir ficheros de texto como
secuencias de caracteres a través de una línea de datos mientras
que en la protección frente a errores de transmisión, se asume que
todos los errores pueden ser detectados. El protocolo se define para
transferencias full-duplex, es decir, debería permitir transferir en
ambas direcciones simultáneamente. Los acuses de recibo positivos
y negativos para el tráfico desde A hasta B se envían por el canal
desde B hasta A y viceversa. Cada mensaje contiene dos partes: una
parte que es el mensaje en sí y una parte de control que se aplica al
tráfico del canal inverso.
6
Los cinco elementos de un protocolo
Suposiciones del entorno
- Dos usuarios como mínimo + un canal de transmisión
- Los usuarios envían una solicitud de transferencia de fichero y
esperan a que finalice
- Canal con distorsiones aleatorias, pero no se pierden, duplican,
insertan o desordenan mensajes
- Se pueden producir errores aleatorios
7
Los cinco elementos de un protocolo
Vocabulario del protocolo
- ack = mensaje + acuse de recibo positivo
- nack= mensaje + acuse de recibo negativo
V={ack, nack, err}
- err = mensaje con distorsión
Formato del mensaje
Mensaje={etiqueta de control, dato}
enum control {ack, nack, err};
struct message {
enum control etiqueta;
unsigned char dato;
};
8
Los cinco elementos de un protocolo
Leyenda
o: cola de mensajes a transmitir
i: cola de mensajes a recibir
Inicio de la transmisión
= Esperando
= Mensaje de entrada
Reglas de
procedimiento
ste:o
= Mensaje de salida
= Evento interno
1. Si la recepción anterior estuvo libre de
errores, el siguiente mensaje por el
canal inverso debe llevar un
reconocimiento positivo; en caso
contrario, llevará un reconocimiento
negativo.
2. Si la recepción anterior portaba un
reconocimiento negativo, o si fue
errónea, se retransmitirá el último
mensaje; en caso contrario se
transmitirá el mensaje siguiente
recibiendo
nack:i
ack:i
err:i
ste:o
ack:o
ack:o
nack:o
9
Los cinco elementos de un protocolo
Defectos de diseño
- No se puede transmitir en ambas direcciones simultáneamente
- No se ha definido procedimientos de inicio y finalización Ö¿err?
- Se aceptan todos los mensajes recibidos correctamente, incluyendo
los duplicados
- Si se aceptan los que llegan OK y no se aceptan los mensajes de
err Ö duplicación de mensajes cuando se producen dos errores
consecutivos
10
Los cinco elementos de un protocolo
Comunicación sin errores
A
Comunicación con errores
B
err
ste
A
ste
err
ste
nack ‘z’
Aceptar ‘z’
ste
B
ste
nack ‘z’
Aceptar ‘z’
ack ‘a’ Ö err
ack ‘a’
nack ‘z’ Ö err
ack ‘y’
Aceptar ‘a’
ste
nack ‘a’
Aceptar ‘y’
ste
Aceptar ‘a’
ack ‘b’
ack ‘x’
Aceptar ‘x’
ack ‘z’
Aceptar ‘b’
Aceptar ‘z’
ste
ste
ack ‘b’
11
A inicia TX
A
B
err
ste
nack ‘z’
Aceptar ‘z’
ack ‘a’ Ö err
nack ‘z’ Ö err
A interpreta el err como que B
ha iniciado la TX
A transmite su primer carácter
‘a’ +acuse de recibo del err recibido
A recibe y acepta
dos veces el
carácter ‘z’
nack ‘a’
ste
B transmite su primer carácter ‘z’ + acuse de recibo
del err recibido
A envía su primer carácter ‘a’ + acuse de recibo
del carácter ‘z’ recibido, pero se deteriora en el camino
Llega a B como err, luego B piensa que A ha
iniciado una nueva TX
B transmite su primer carácter ‘z’ + acuse de recibo
del err recibido, pero se deteriora en el camino
Aceptar ‘a’
ack ‘z’
B transmite su primer carácter ‘z’ +acuse de recibo
del carácter ‘a’ recibido
Aceptar ‘z’
ste
ack ‘b’
12
Servicio y entorno
P1: Testeador + generador de paridad (8 bits)
P2: Codificador + decodificador (7 bits)
Canal virtual
P2
P1
P1
P2
Envolturas de datos
Pn
P2 P1 Po P1 P2
Pn
13
Servicio y entorno
Ventajas del diseño por niveles:
- Ayuda a distinguir la estructura lógica del protocolo, al separar
tareas de alto nivel de las de bajo nivel
- Facilita la escalabilidad del protocolo
Actores del modelo de diseño:
- Un nivel o capa define un grado de abstracción de un protocolo,
agrupando funciones relacionadas y separando las independientes
- Un interfaz separa (y une) dos niveles distintos de abstracción
Nivel N+1
Nivel N
A
B
Protocolo par
Entidad par
Nivel N-1
Primitivas
de servicio
Servicio
14
Servicio y entorno
Primitivas:
Usuario de servicio
(Capa N)
- De petición de servicio
- De indicación de servicio
Suministrador
del servicio
(Capa N-1)
Usuario de servicio
(Capa N)
X.request
- De respuesta (de entidad par)
X.indication
- De confirmación (del suministrador
Diagrama de
correlación de
primitivas
X.response
X.confirm
del servicio)
Transmisor
Receptor
Usuario
Usuario
E-DATA.request(DATO)
E-DATA.indication(DATO)
Enlace
Enlace
F-DATA.ind(SEC,DATO)
F-DATA.req(SEC, DATO)
F-DATA.ind(SEC,ACK)
F-DATA.req(SEC, ACK)
Medio físico
15
Vocabulario y formato de mensajes
- Se define para cada nivel
- Dos tipos de protocolos en cuanto formato de mensajes:
- protocolo orientado a bit
Tx datos como flujo de bits sin longitud definida (flags
de inicio y fin). Ej: HDLC
- protocolo orientado a carácter
Tx datos en bloques de n bits (o múltiplos de n)
(caracteres marcadores de inicio y fin). Ej: Carácter
STX(Start of TeXt) y ETX (End of TeXt)
STX c1 c2 c3
...
cn ETX
Character stuffing
DLE STX c1 c2 DLE DLE
... cn
DLE ETX
16
Vocabulario y formato de mensajes
- Formato = { cabecera, datos, cola }
• cabecera = { tipo, destino, nº secuencia, longitud }
» tipo = { ack, nack, err }
• cola = { checksum, dirección de retorno }
17
Reglas de procedimiento
- Procesos concurrentes
- Necesitamos herramientas más formales: diagrama
temporal, máquina de estados finitas, ESTELLE...
evento0[condicion0]/accion0
evento1[condicion1]/accion1
Estado
i
Estado
i+1
evento2[condicion2]/accion2
18
Diseño estructurado de protocolos
1. Simplicidad
2. Modularidad
3. Protocolos bien formados
- NO sobre-especificado
- NO incompleto
- Acotado
- Autoestabilizado
- Autoadaptable
4. Robustez
- Evolución automática con la tecnología
5. Consistencia
- Bloqueos
- Bucles infinitos
- Terminaciones impropias
19
Diseño estructurado de protocolos
Las diez reglas de diseño:
1. Asegurarse de definir bien todos los aspectos del protocolo
2. Definir el servicio a realizar por cada nivel antes de elegir estructuras
3. Diseñar antes funcionalidad externa que la interna
4. Mantener el diseño simple
5. No conectar lo que es independiente
6. Obviar aquello que es innecesario
7. Validar el diseño antes de implementarlo
8. Implementar diseño, medir su rendimiento y optimizarlo
9. Comprobar que la versión final cumple los criterios de diseño
10. Nunca saltarse las 7 primeras reglas
20
Mecanismos básicos de los protocolos
1. Control de secuencia y control de errores
- Redundancia
- Tipos de códigos
- Códigos de paridad
- Corrección de errores (varios métodos)
2. Control de flujo
- protocolo simple sin control de flujo
- protocolo Xon-Xoff
- protocolo de parada y espera
- protocolo de parada y espera con timeout
- protocolo de bit alternante
- protocolos de ventana
21
Control de secuencia y de errores
- Mayor número de errores debido a la comunicación que al hardware
P(circuitería)<10-15
P(F.O.) ≈10-9 P(coax.) ≈10 -6
P(tlf.) ≈10 -4 ó 10 -5
- Causas principales de error:
- limitaciones en el ancho de banda del canal (distorsión lineal)
- eco, ruido blanco, impulsos electromagnéticos... (no lineal)
- El efecto de esos ruidos se puede paliar hasta cierto punto con
hardware y el resto por software (no se eliminan)
- El esquema de control de error debe ser adecuado a las características
de la línea de comunicaciones:
. Si un canal sólo tiene inserciones, no sirve un protocolo que
proteja contra eliminaciones
. Si un canal produce errores simples, puede ser más adecuado
usar un protocolo más simple
. Si el error del canal es < que el de la circuitería, el mecanismo
de control sólo degrada rendimiento del sistema y disminuye
22
fiabilidad del protocolo
Control de secuencia y de errores.
Redundancia
- Añadir información redundante a los mensajes
- Dos formas de gestionar los errores:
- Control de errores hacia delante Ö códigos correctores
- Control de errores por realimentación Ö códigos detectores
p≡probabilidad de error en la transmisión de un mensaje
f ≡fracción de errores que capta el método de control
error residual=p·(1-f)
- Si p↓ Ö no código corrector (ralentiza las comunicaciones)
Si p↑ Ö no código detector (las reTx también podrían ser erróneas)
- También depende del coste: si p↓ y coste de reTx↑ Ö código corrector
- Sistema mixto: el receptor corrige los errores más frecuentes y solicita
reTx de los mensajes alterados por errores menos frecuentes
23
Control de secuencia y de errores.
Tipos de códigos
• Códigos de bloque:
. palabras de código de misma longitud y codificación estática
• Códigos de convolución:
. palabras de código dependen del mensaje actual y de
anteriores, el codificador cambia su estado con cada mensaje
procesado, longitud de palabras suele ser constante
Se pueden clasificar en:
¾Códigos lineales: combinación lineal de palabras válidas
¾Códigos cíclicos: rotación cíclica de código válido
¾Códigos sistemáticos: mensaje original + bits de comprobación
Razón de código=d/(d+e)
d ≡ nº de bits de información
e ≡ nº de bits redundantes
)A mejor calidad de código Ö menor razón de código
24
Control de secuencia y de errores.
Corrección de errores
Código válido
Código alterado
• Los códigos se eligen de forma que haya varios bits de diferencia entre
dos palabras válidas
• Rxor reconstruye mensaje, asociándole la palabra de código más
cercana
• Razón de código de sistema corrector < razón de código de sistema
detector
• Se usa sistema corrector si hay:
– un retraso de transmisión alto
– ausencia de canal de retorno
25
– una tasa de errores alta
Control de secuencia y de errores.
Código corrector basado en paridad
LRC
D=
1 0 0 0 1 0 0
0
A=
1 0 0 0 0 0 1
0
T=
1 0 1 0 1 0 0
1
A=
1 0 0 0 0 0 1
0
VRC
0 0 1 0 0 0 0
1
Permite la corrección de 1 bit
LRC= Longitudinal Redundancy Check
VRC= Vertical Redundancy Check
d=28 bits
e=12 bits
Razón de código=28/(28+12)=0.7
26
Control de secuencia y de errores.
Método Van Lint
Código
XX
0000
CX
1001
XC
0111
CC
1110
en transmisor
Resultado
en receptor
Códigos válidos
- A tiradas de una moneda por segundo
- canal de 2A bps
- tasa de errores de 2·10-2
q=0.98
p=0.02
Ö cada par de tiradas se codifica con
4 bits
Ö se logra la mitad de tasa de errores
Resultado
0000
1000
0100
0010
XX
1001
0001
1101
1011
CX
0111
1111
0011
0101
XC
1110
0110
1010
1100
CC
P(no error)=q4+3·p·q3
P(error)= 1-P(no error)
12 de las 16
combinaciones se
“desperdician”
El código resiste errores en 1 bit de los 3 primeros de la palabra
27
Control de secuencia y de errores.
Distancia de Hamming
• Distancia de Hamming: diferencia de bits mínima entre
dos palabras de un código.
XOR(2 palabras de código)
• Si la distancia de Hamming de un código es n, se puede:
– Detectar errores de hasta n-1 bits
– Corregir errores de hasta (n-1)/2 bits
• ↑distancia de Hamming Ö ↑fiabilidad de protocolo
• Límite de Shannon:
S
C = B log 2 (1 + )bps
N
28
Control de secuencia y de errores.
Código de Hamming
• Para que un código de k bits de datos y r bits
redundantes sea capaz de corregir errores simples debe
cumplir: k+r+1≤ 2r
• Los códigos que verifican lo anterior con r mínimo se
denominan óptimos
• Ejemplo: k=7 (ASCII), r mínimo / k+r+1≤ 2r Ö r=4 Ö n=11
‘a’≡ 1 1 0 0 0 0 1
1 2 3 4 5 6 7 8 9 10 11
1
1 0 0
0 0 1
Los bits redundantes ocupan las posiciones potencia de 2
(1,2,4,8), el resto son los bits de datos
2928-2
Control de secuencia y de errores.
Código de Hamming (II)
C1=fp(b1,b3 ,b5 ,b7 ,b9,b11)
C2=fp(b2,b3 ,b6 ,b7 ,b10,b11)
C3=fp(b4,b5 ,b6 ,b7)
C4=fp(b8,b9 ,b10 ,b11)
XOR
1·20 +1·21 +1·23 +0·24 = 7 Ö posición del error
30
Control de secuencia y de errores.
Ráfagas
• La mayor parte de las veces los errores no se producen
de forma aislada.
• Mecanismos correctores tolerantes a ráfagas:
- Códigos de interlineado
- Reed-Solomon
• k datos de n bits Ö matriz kxn
• se Tx por columnas Ö corrige ráfagas ≤ k
• CDs, DVDs, códigos de barras, comunicaciones
inalámbricas, comunicaciones satélite, TV digital, modems
de alta velocidad
• Se ha demostrado que en la mayoría de los casos es
mejor el control por realimentación (↑aprovechamiento del
canal y ↓error residual).
31
Control de secuencia y de errores.
Código de redundancia cíclica (CRC)
• Mensajes de n bits se tratan como polinomios de grado n-1: 101 = x2 + 1.
• El código de comprobación se obtiene dividiendo el polinomio del mensaje
por un polinomio generador G => se halla el resto y se le añade al mensaje
• El mensaje recibido es correcto si el divisible por G. No se detecta el error
cuando es divisible por G.
• Ejemplos de polinomios:
– CRC-12: x12+x11+x3+x2+1
T=P·xr
-R
P·xr
G
– CRC-16: x16+x15+x2+1
– CRC-CCITT: x16+x12+x5+1
Detecta ráfagas ≤ r
• CRC-CCITT detecta:
– Cualquier número impar de errores simples
– Todos los errores dobles
– Todas las ráfagas de 16 o menos bits
– El 99’997% de las ráfagas de 17 bits
– El 99’998% de las ráfagas de 18 o más bits
32
Control de secuencia y de errores.
Checksum aritmético
• Método de Fletcher (1982)
• Sólo sumas y módulos, es simple, pero con buena detección de
errores
Menor carga de procesamiento
Menor latencia
• Inferior al CRC, detecta ráfagas de 1 a 14 bits (excepto de 8)
• Estandarizado como parte de protocolo estándar transporte (clase 4)
de ISO
unsigned short cksum (register unsigned char *s, register int n)
{
register int c0=0, c1=0;
do
{
c0 = (c0 + *s++) % 255;
c1 = (c0 + c1) % 255;
}while (--n>0);
return (unsigned short) (c1<<8+c0);
}
33
Control de flujo
• Objetivos:
– Asegurarse que no se transmiten los datos
más rápido de lo que se puede procesar.
– Optimizar el uso del canal.
– Evitar saturar el canal.
– Proteger la transmisión contra borrado,
inserción, duplicación y reordenamiento de
mensajes.
34
Control de flujo
•
•
•
•
Protocolo simple sin control de flujo
Protocolo Xon-Xoff
Protocolo de parada y espera
Protocolo de parada y espera con
timeout
• Protocolo de bit alternante
• Protocolo de ventana
35
Control de flujo
• Protocolo simple sin control de flujo
– OK si Rxor más rápido que Txor Ö se viola el principio “no
hacer suposiciones de la velocidad relativa de procesos
concurrentes”
– Rx es más costoso que Tx
• Protocolo Xon-Xoff
–
–
–
–
–
No requiere negociación previa
Dúplex
Si se pierde Xon Ö bloqueo de los cuatro procesos
No se protege contra la saturación de forma efectiva
No se protege contra la pérdida de mensajes
36
Control de flujo. Protocolo simple sin control de flujo
Transmisor
Receptor
Tx
Rx
E-DATOS.request /
F-DATOS.request
F-DATOS.indication /
E-DATOS.indication
37
Control de flujo. Protocolo Xon-Xoff
E-DATOS.request/encolar
XOFF/-
Transmisor
Esperando
XON/-
XOFF/-
Transmitiendo
desencolar
F-DATOS.request
38
E-DATOS.request/encolar
Control de flujo. Protocolo Xon-Xoff
F-DATOS.indication/
encolar; preparar_ind
ind_preparada[n>min]/
desencolar; E-DATOS.indication
Receptor
Procesando
ind_preparada[n<=min]/
XON; desencolar; E-DATOS.indication
F-DATOS.indication[n>=max]/
XOFF; desencolar; preparar_ind
Recibiendo
y
Procesando
F-DATOS.indication/encolar; preparar_ind
es un evento interno que indica que el
proceso de formación ha concluido y
se puede pasar hacia el nivel superior
ind_preparada/desencolar; E-DATOS.indication
es una acción que inicia el proceso de
formación de la primitiva de indicación
que va hacia el nivel superior
39
Control de flujo. Protocolo Xon-Xoff
Transmisor
Xoff/ -
Esperando
E-DATOS.request [Xof] / -
Xon/-
Tx
E-DATOS.request [Xon] / F-DATOS.request
40
Control de flujo. Protocolo Xon-Xoff
Transmisor
F-DATOS.indication(Xoff)/-
Esperando
E-DATOS.request [puedo_Tx=Xoff]/ -
F-DATOS.indication(Xon)/-
Tx
puedo_Tx: variable que almacena el
último mensaje de control (Xon,
Xoff) que recibió el transmisor
E-DATOS.request [puedo_Tx=Xon] / F-DATOS.request
41
Control de flujo. Protocolo Xon-Xoff
Receptor
Cola de mensajes por procesar en receptor:
principio cola
fin cola
fin cola
principio cola
MÍNIMO
XOFF
MÁXIMO
n
XON
n: cantidad de mensajes que quedan
por procesar en la cola del receptor
42
Control de flujo. Protocolo Xon-Xoff
F-DATOS.indication [n>max] /
E-DATOS.indication; n--
Receptor
Sólo
procesando
(Xoff)
F-DATOS.indication [n>max] /
Xoff; E-DATOS;n--
F-DATOS.indication [n<max] /
Xon; E-DATOS.indication; n--
Rx y
procesando
mensajes
F-DATOS.indication [n<max & n<min] /
Xon; E-DATOS.indication; n--
F-DATOS.indication [n<max & n>min] /
E-DATOS.indication; n-43
Control de flujo. Protocolo Xon-Xoff
F-DATOS.indication [n≥max] /
F-DATOS.request(Xoff);
E-DATOS.indication; n--
[n≥max] /
E-DATOS.indication; n--
Sólo
procesando
(Xoff)
F-DATOS.indication [n<max] /
F-DATOS.request(Xon);
E-DATOS.indication; n--
Receptor
F-DATOS.indication [n≥max] /
F-DATOS.request(Xoff);
E-DATOS.indication;n--
Rx y
procesando
mensajes
F-DATOS.indication [n<max & n>min] /
E-DATOS.indication; n--
F-DATOS.indication [n<min] /
F-DATOS.request(Xon); E-DATOS.indication; n--
44
Control de flujo
• Protocolo de parada y espera
–
–
–
–
Desaparece problema de saturación en Rxor
Si se pierde un mensaje, se bloquea
Se desaprovecha el canal
Retraso de 2·t+a-p por cada mensaje enviado
• t: tiempo de propagación
• a: tiempo que tarda el receptor en aceptar el mensaje
• p: tiempo que tarda el emisor en prepararlo
• Protocolo de parada y espera con timeout
– Protege contra la pérdida de tramas
– Si tanto Txor como Rxor pueden iniciar reTx, pueden
perderse ambas y asociar equivocadamente cada mensaje
con otro ack
– Una solución: numerar mensajes y ack’s
45
Control de flujo. Protocolo parada y espera
Transmisor
Esperando
E-DATOS.request /
F-DATOS.request
F-DATOS.indication / -
Tx
Receptor
Rx
F-DATOS.indication /
E-DATOS.indication;
F-DATOS.request
46
Control de flujo. Protocolo parada y espera con
timeout y errores de canal
F-DATOS.indication
[CRC no OK] / -
Transmisor
Timeout /
F-DATOS.request
Esperando
E-DATOS.request /
F-DATOS.request
F-DATOS.indication
[CRC OK] / -
Tx
Receptor
F-DATOS.indication
[CRC no OK] / -
Rx
F-DATOS.indication [CRC OK] /
E-DATOS.indication
F-DATOS.request
47
Control de flujo. Protocolo parada y espera con
timeout y errores de canal
Ejemplo: Duplicación de mensajes en el receptor
Receptor
Emisor
ste
Mensaje que se pierde
mensaje i
Retransmite de
nuevo el mensaje
Retransmite el último ack
(del mensaje i-1)
Timeout
Cuando este ack llega
al emisor, éste ya ha
retransmitido el
mensaje i, pero vuelve
transmitirlo
ste
ste
mensaje i
ack i-1
ack i
Timeout
Acepta mensaje i
Acepta mensaje i
Se duplica el
mensaje i en
el receptor
48
Control de flujo
• Protocolo de bit alternante
– Timeout + nº de secuencia de 1bit
– Puede fallar si se produce un retraso demasiado grande en
el envío del ack desde el Rxor
• Protocolo de ventana
– En la fase de establecimiento de conexión se negocia
tamaño de la ventana (W)
– El Txor puede enviar W mensajes sin esperar acuse de
recibo del Rxor
– Optimiza canal en los que el tiempo de tránsito es alto
– Control de error en ventana deslizante:
• Los reconocimientos tienen que numerarse
• ACK1 significa que se recibió correctamente la 0
• Si se pierde un mensaje y llega el siguiente:
– se rechaza: vuelta a atrás
– se acepta: reTx selectiva
• Reconocimientos globales: ACK4 implica Rx OK de 1..3
49
Control de flujo
• Protocolo de ventana (cont.)
– Ventana de Tx: mensajes enviados pendientes de ack (de
tamaño variable, pero limitada a W)
– Ventana de Rx: nºs de secuencia que Rxor espera Rx (de
tamaño fijo)
– Para el rango de los nºs de secuencia debe cumplirse:
• rango(nºs secuencia)<=K+N
• donde K es el tamaño de la ventana de Rx y N el tamaño
máximo de la ventana de Tx
• en caso contrario podrían darse duplicaciones
50
Control de flujo. Protocolo bit alternante
Transmisor
Número de secuencia (0,1)
Origen del mensaje (A, B)
Receptor
ReTx
dato1
ReTx
ack1
B0
Listo
B1
A1
B1
Espera
ack1
Acepta
dato1
A1
A0
Espera
ack0
B0
Busca
ste.
B1
Espera
dato1
A0
transmisión
A1
Listo
B0
B1
A0
A1
Acepta
Listo
dato0
A0
ReTx
dato0
B0
ReTx
ack0
A y B son procesos
51
Control de flujo. Protocolo bit alternante
Transmisor
Receptor
a(0)
ack de a
b(1)
timeout
retraso
ack de b
c(0)
ack de b
c(0)
52
Control de flujo. Protocolo de ventana
Transmisor
A
Nº sec Nº ack
Receptor
B
0
3
A0
1
3
A1
2
3
A2
B0
3
3
A3
Nº sec Nº ack
0
3
A4
1
3
A5
2
3
A6
3
3
A7
Nº sec Nº ack
0
0
B1
1
1
B2
2
2
B3
3
3
Hasta que no llega
el ack de A0, el emisor
no puede seguir
transmitiendo
53
Control de flujo. Protocolo de ventana
Transmisor
A
Nº
Nº
sec
ack
A0
0
3
A1
Receptor
B
Nº
Nº
sec
ack
1
3
A2
B0
2
3
0
3
Nº
B1
B2
0
3
Nº
A3
1
1
sec
ack
A4
B3
2
2
0
3
A5
3
3
1
3
A6
2
3
3
A7
3
timeout
Se retransmite
Nº
Nº
sec
ack
B1
B2
0
0
1
1
B3
2
2
3
3
B0
A los acepta y piensa
que los datos de la
ventana anterior han
llegado bien
54
Control de flujo. Protocolo de ventana
Nº
Nº
sec
ack
0
3
Transmisor
A
Receptor
B
A0
1
3
A1
A2
2
3
3
A3
3
B0
Nº
Nº
sec
ack
B1
0
0
B2
1
1
B3
2
2
3
3
Nº
Nº
sec
ack
B1
B2
0
0
1
1
B3
2
2
3
3
timeout
Se retransmite
Nº
Nº
sec
ack
A0
0
3
A1
1
3
A2
2
3
3
A3
3
B0
B los acepta y piensa
que son los datos de la
ventana siguiente , y sin
embargo, están duplicados
55
Control de flujo. Protocolo de ventana con
detección de errores
Transmisor
5/4
1/1
2/1
4/5
Transmitiendo
6/5
-/3
3/2
Límite
ventana
3/1
4/5
5/4
2/1
1/1
Espera
ack
56
Control de flujo. Protocolo de ventana con
detección de errores
Notación
v ≡ nº de mensajes pendientes de ack
w ≡ tamaño de la ventana de Tx
s ≡ nº de secuencia del último mensaje enviado
a ≡ nº de secuencia del mensaje más antiguo enviado y sin confirmar
dato[x] ≡ almacena el dato que fue enviado con nº de secuencia x
d ≡ dato que se quiere enviar
p ≡ nº de secuencia recibido en ack
M ≡ rango de números de secuencia disponible
Acciones:
pendiente[i] ≡ el mensaje con nº de sec i se apunta como enviado y pendiente de ack
pendiente[i] ≡ el mensaje con nº de sec i se apunta como confirmado
v+ ≡ se incrementa en uno el nº de mensajes pendientes de confirmación
v-
≡ se decrementa en uno el nº de mensajes pendientes de confirmación
57
Control de flujo. Protocolo de ventana con
detección de errores
1/1
Transmisor
2/1
3/2
4/3
Tx
Límite
ventana
4/3
6/5
3/2
5/4
Entradas
1. E-DATOS.request(d)[v< w-1]
(se quieren enviar datos y caben más mensajes en la ventana)
2. E-DATOS.request(d)[v= w-1]
(se quieren enviar datos y se llega al límite de la ventana)
3. F-DATOS.indication(ack,p)
(llega un acuse de recibo positivo del mensaje con nº sec p)
4. F-DATOS.indication(nack,p)
(llega un acuse de recibo negativo del mensaje con nº sec p)
5. F-DATOS.indication(-,p) no OK
(llega una indicación errónea)
6. Timeout
(expira el temporizador de retransmisión)
6/5
5/4
Salidas
1. F-DATOS.request(d,s); v+ ; pendiente[s]; dato[s]=d; s=(s+1)%M
(envía dato con nº de sec s, incrementa el nº de mensajes
pendientes de confirmación, apunta el nº de sec como pendiente,
almacena el dato enviado con ese nº de sec y se prepara el
nº de sec para el siguiente mensaje)
2. para i desde a hasta p en módulo M hacer:
v-; pendiente[i]
(decrementa el nº de mensajes pendiente de confirmación en
función de los que se hayan confirmado y los marca como
confirmados)
3. F-DATOS.request(dato[p],p)
(retransmite dato con sec=p)
4. Nada
5. para i desde a hasta s en módulo M hacer:
F-DATOS.request(dato[i],i)
58
(retransmite todos los datos desde el último que no fue
confirmado)
Control de flujo. Protocolo de ventana con
detección de errores
Transmisor
1/1
5/4
2/1
4/5
Tx
6/5
-/3
3/2
Límite
ventana
3/1
4/5
1/1
Espera
ack
Entradas
1. E-DATOS.request [n<W]
2. E-DATOS.request [n=W]
3. F-DATOS.indication (dato) [CRC & Nºsec & Nºack OK]
4. F-DATOS.indication [CRC || Nºsec || Nºack KO]
5. timeout
6. F-DATOS.indication (ack) [CRC & Nºsec & Nºack OK]
2/1
5/4
Salidas
1. Toma 3-PDU, forma 2-PDU; F-DATOS.request
2. Extrae 3-PDU; E-DATOS.indication
3. Forma 2-PDU; F-DATOS.request
4. Forma 2-PDU; F-DATOS.request
5. nada
Detección y corrección de errores
59
Control de flujo. Protocolo de ventana con ack
global
Transmisor
A
Nº sec Nº ack
Receptor
B
0
3
A0
1
3
A1
2
3
A2
B0
3
3
A3
Nº sec Nº ack
0
3
A4
1
3
A5
2
3
A6
3
3
A7
Nº sec Nº ack
0
0
B1
1
1
B2
2
2
B3
3
3
Hasta que no llega
el ack de A0, el emisor
no puede seguir
transmitiendo
60