tema 2. estructura de un protocolo - dte.us.es · estructura de un protocolo ... parte que es el...
TRANSCRIPT
Atribución-NoComercial-LicenciarIgual 2.5
Tu eres libre de:
copiar, distribuir, comunicar y ejecutar públicamente la obrahacer obras derivadas
Bajo las siguientes condiciones:
Atribución. Debes reconocer y citar la obra de la forma especificada porel 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 obraderivada, sólo puedes distribuir la obra generada bajo una licenciaidéntica a ésta.
Al reutilizar o distribuir la obra, tienes que dejar bien claro los términos de lalicencia 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 oexcepciones 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 workto make derivative works
Under the following conditions:
Attribution. You must attribute the work in the manner specified by theauthor or licensor.
Noncommercial. You may not use this work for commercial purposes.
Share Alike. If you alter, transform, or build upon this work, you maydistribute 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
2
Estructura de un protocolo
1. Introducción2. Los cinco elementos de un protocolo3. Servicio y entorno4. Vocabulario y formato de los mensajes5. Reglas de procedimiento6. Diseño de un protocolo estructurado7. Mecanismos básicos de los protocolos
3
d
A B
Introducción
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
4
señal eléctrica
bits
símbolos/caracteres
campos de mensaje
tramas/paquetes
IntroducciónNiveles de abstracción
5
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
6
Los cinco elementos de un protocolo
Especificación del servicioEl propósito del protocolo es transferir ficheros de texto como secuencias de caracteres a través de una línea de datos mientrasque 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.
7
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
8
Los cinco elementos de un protocolo
Vocabulario del protocolo- ack = mensaje + acuse de recibo positivo
- nack= mensaje + acuse de recibo negativo
- err = mensaje con distorsión
Formato del mensajeMensaje={etiqueta de control, dato}
enum control {ack, nack, err};struct message {
enum control etiqueta;unsigned char dato;
};
V={ack, nack, err}
9
ste:o
recibiendo
ack:inack:i err:i
ste:o
ack:o nack:oack:o
Inicio de la transmisióno: cola de mensajes a transmitiri: cola de mensajes a recibir
= Esperando
= Mensaje de entrada
= Mensaje de salida
= Evento interno
Leyenda
Los cinco elementos de un protocolo
1. Si la recepción anterior estuvo libre de errores, el siguiente mensaje por elcanal inverso debe llevar unreconocimiento positivo; en casocontrario, llevará un reconocimientonegativo.
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
Reglas de procedimiento
10
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
11
Comunicación sin errores
Aceptar ‘a’
A Berr ste
ste
ack ‘b’
Aceptar ‘z’
ack ‘a’
ack ‘y’
nack ‘z’
ack ‘x’
Aceptar ‘x’
steAceptar ‘y’
Aceptar ‘b’
ste
ste
ste
A Berr ste
ste
nack ‘a’
Aceptar ‘z’ ack ‘a’ err
nack ‘z’ err
nack ‘z’
Aceptar ‘a’ack ‘z’
Aceptar ‘z’ste
ack ‘b’
Comunicación con errores
Los cinco elementos de un protocolo
12
A Berr ste
ste
nack ‘a’
Aceptar ‘z’ ack ‘a’ err
nack ‘z’ err
nack ‘z’
Aceptar ‘a’ack ‘z’
Aceptar ‘z’ste
ack ‘b’
A envía su primer carácter ‘a’ + acuse de recibodel carácter ‘z’ recibido, pero se deteriora en el camino
B transmite su primer carácter ‘z’ + acuse de recibodel err recibido
Llega a B como err, luego B piensa que A ha iniciado una nueva TX
A inicia TX
B transmite su primer carácter ‘z’ + acuse de recibodel err recibido, pero se deteriora en el caminoA interpreta el err como que B
ha iniciado la TX
A transmite su primer carácter‘a’ +acuse de recibo del err recibido
B transmite su primer carácter ‘z’ +acuse de recibodel carácter ‘a’ recibidoA recibe y acepta
dos veces el carácter ‘z’
13
P2 P1 P1 P2
P2 P1 Po P1 P2Pn Pn
Servicio y entorno
Canal virtual
Envolturas de datos
P1: Testeador + generador de paridad (8 bits)P2: Codificador + decodificador (7 bits)
14
Servicio y entornoVentajas 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
A B
Nivel N+1
Nivel N-1
Nivel NProtocolo par Entidad par
Primitivas de servicio
Servicio
15
Usuario de servicio(Capa N)
Usuario de servicio(Capa N)
Suministrador del servicio (Capa N-1)
X.request
X.indication
X.responseX.confirm
Servicio y entorno
Usuario Usuario
E-DATA.request(DATO)
Enlace
F-DATA.ind(SEC,DATO)F-DATA.req(SEC, ACK)
Enlace
E-DATA.indication(DATO)
Medio físico
Transmisor Receptor
F-DATA.req(SEC, DATO)F-DATA.ind(SEC,ACK)
Primitivas:- De petición de servicio- De indicación de servicio- De respuesta (de entidad par)- De confirmación (del suministrador del servicio)
Diagrama decorrelación de
primitivas
16
Vocabulario y formato de mensajes
- Se define para cada nivel- Dos tipos de protocolos en cuanto formato de mensajes:
- protocolo orientado a bitTx datos como flujo de bits sin longitud definida (flagsde inicio y fin). Ej: HDLC
- protocolo orientado a carácterTx 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...STX c1 c2 DLE cn ETX...DLE DLEDLE
Character stuffing
17
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 }
18
Estado i
Estado i+1
evento1[condicion1]/accion1
evento2[condicion2]/accion2
evento0[condicion0]/accion0
Reglas de procedimiento- Procesos concurrentes- Necesitamos herramientas más formales: diagrama temporal, máquina de estados finitas, ESTELLE...
19
Diseño estructurado de protocolos1. Simplicidad2. Modularidad3. 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
20
Diseño estructurado de protocolosLas 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
21
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
22
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 conhardware y el resto por software (no se eliminan)
- El esquema de control de error debe ser adecuado a las característicasde la línea de comunicaciones:
. Si un canal sólo tiene inserciones, no sirve un protocolo queproteja contra eliminaciones
. Si un canal produce errores simples, puede ser más adecuadousar un protocolo más simple
. Si el error del canal es < que el de la circuitería, el mecanismode control sólo degrada rendimiento del sistema y disminuye fiabilidad del protocolo
23
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 mensajef ≡fracción de errores que capta el método de controlerror 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 solicitareTx de los mensajes alterados por errores menos frecuentes
24
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 mensajeprocesado, longitud de palabras suele ser constante
Se pueden clasificar en:Códigos lineales: combinación lineal de palabras válidasCódigos cíclicos: rotación cíclica de código válidoCódigos sistemáticos: mensaje original + bits de comprobación
Razón de código=d/(d+e)d ≡ nº de bits de informacióne ≡ nº de bits redundantes
A mejor calidad de código menor razón de código
25
Control de secuencia y de errores. Corrección de errores
• 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– una tasa de errores alta
Código válidoCódigo alterado
26
Control de secuencia y de errores. Código corrector basado en paridad
LRC= Longitudinal Redundancy CheckVRC= Vertical Redundancy Check
d=28 bitse=12 bitsRazón de código=28/(28+12)=0.7
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
27
Control de secuencia y de errores. Método Van Lint
- A tiradas de una moneda por segundo- canal de 2A bps- tasa de errores de 2·10-2
q=0.98p=0.02
cada par de tiradas se codifica con 4 bits
se logra la mitad de tasa de errores
P(no error)=q4+3·p·q3
P(error)= 1-P(no error)
12 de las 16 combinaciones se “desperdician”
Resultado Código
XX 0000
CX 1001
XC 0111
CC 1110
Códigos válidos Resultado
0000 1000 0100 0010 XX
1001 0001 1101 1011 CX
0111 1111 0011 0101 XC
1110 0110 1010 1100 CC
en tr
ansm
isor
en re
cept
or
El código resiste errores en 1 bit de los 3 primeros de la palabra
28
Control de secuencia y de errores. Distancia de Hamming
• Distancia de Hamming: diferencia de bits mínima entre dos palabras de un 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:
C BSNbps= +log ( )2 1
XOR(2 palabras de código)
29
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 111 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
28-2
30
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)
posición del error
XOR
1·20 +1·21+1·23 +0·24 = 7
31
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
• Se ha demostrado que en la mayoría de los casos es mejor el control por realimentación (↑aprovechamiento del canal y ↓error residual).
• 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, modemsde alta velocidad
32
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
– CRC-16: x16+x15+x2+1
– CRC-CCITT: x16+x12+x5+1
• 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
P·xr
GT=P·xr - R
Detecta ráfagas ≤ r
33
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
• 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 ISOunsigned 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);
}
Menor carga de procesamiento Menor latencia
34
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.
35
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
36
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
37
Tx Rx
E-DATOS.request /F-DATOS.request
F-DATOS.indication /E-DATOS.indication
Transmisor Receptor
Control de flujo. Protocolo simple sin control de flujo
38
Control de flujo. Protocolo Xon-Xoff
Esperando
Transmitiendodesencolar
F-DATOS.request
E-DATOS.request/encolar
XOFF/-
XOFF/-E-DATOS.request/encolar
XON/-
TransmisorTransmisor
39
Control de flujo. Protocolo Xon-Xoff
es una acción que inicia el proceso de formación de la primitiva de indicación que va hacia el nivel superior
ind_preparada[n<=min]/XON; desencolar; E-DATOS.indication
Procesando
Recibiendoy
Procesandoind_preparada/desencolar; E-DATOS.indication
F-DATOS.indication/encolar; preparar_ind
F-DATOS.indication[n>=max]/XOFF; desencolar; preparar_ind
ind_preparada[n>min]/desencolar; E-DATOS.indication
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
ReceptorReceptor
40
TransmisorTransmisor
Control de flujo. Protocolo Xon-Xoff
Esperando
E-DATOS.request [Xon] / F-DATOS.request
TxXon/-
Xoff/ -
E-DATOS.request [Xof] / -
41
Esperando
E-DATOS.request [puedo_Tx=Xon] / F-DATOS.request
TransmisorTransmisor
TxF-DATOS.indication(Xon)/-
F-DATOS.indication(Xoff)/-
E-DATOS.request [puedo_Tx=Xoff]/ -
Control de flujo. Protocolo Xon-Xoff
puedo_Tx: variable que almacena el último mensaje de control (Xon, Xoff) que recibió el transmisor
42
Control de flujo. Protocolo Xon-Xoff
ReceptorReceptorCola de mensajes por procesar en receptor:
principio cola fin colaMÁXIMO
principio cola fin cola
MÍNIMO
XOFF
XON
n
n: cantidad de mensajes que quedan por procesar en la cola del receptor
43
Sólo procesando
(Xoff)
F-DATOS.indication [n<max & n<min] / Xon; E-DATOS.indication; n--
Rx yprocesandomensajes
F-DATOS.indication [n<max & n>min] /E-DATOS.indication; n--
F-DATOS.indication [n>max] / Xoff; E-DATOS;n--
F-DATOS.indication [n>max] / E-DATOS.indication; n--
F-DATOS.indication [n<max] / Xon; E-DATOS.indication; n--
Control de flujo. Protocolo Xon-Xoff
ReceptorReceptor
44
ReceptorReceptor
Control de flujo. Protocolo Xon-Xoff
Sólo procesando
(Xoff)
F-DATOS.indication [n<min] / F-DATOS.request(Xon); E-DATOS.indication; n--
Rx yprocesandomensajes
F-DATOS.indication [n<max & n>min] /E-DATOS.indication; n--
F-DATOS.indication [n≥max] / F-DATOS.request(Xoff); E-DATOS.indication;n--
F-DATOS.indication [n≥max] /F-DATOS.request(Xoff); E-DATOS.indication; n--
F-DATOS.indication [n<max] / F-DATOS.request(Xon); E-DATOS.indication; n--
[n≥max] /E-DATOS.indication; n--
45
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
46
EsperandoTransmisor
Tx
F-DATOS.indication / -
E-DATOS.request /F-DATOS.request
Control de flujo. Protocolo parada y espera
Receptor
Rx F-DATOS.indication /E-DATOS.indication;F-DATOS.request
47
Esperando
Transmisor
Tx
F-DATOS.indication [CRC OK] / -
E-DATOS.request /F-DATOS.request
F-DATOS.indication [CRC no OK] / -
Timeout / F-DATOS.request
Control de flujo. Protocolo parada y espera contimeout y errores de canal
Rx
Receptor
F-DATOS.indication [CRC OK] / E-DATOS.indicationF-DATOS.request
F-DATOS.indication [CRC no OK] / -
48
Emisor Receptor
mensaje iste
ack i-1
Mensaje que se pierde
Timeout Timeoutmensaje i
steAcepta mensaje i
ack i
Acepta mensaje iste
Retransmite el último ack (del mensaje i-1)
Retransmite denuevo el mensaje
Cuando este ack llega al emisor, éste ya haretransmitido el
mensaje i, pero vuelvetransmitirlo
Se duplica el mensaje i en el receptor
Control de flujo. Protocolo parada y espera contimeout y errores de canal
Ejemplo: Duplicación de mensajes en el receptor
49
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
50
• 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
Control de flujo
51
B0B1
A1
A1A0
A0B0
B1
A1B1
B1
A0 A1
B0B0
A0
Listo
Esperaack0
Buscaste.
Esperaack1
ReTxdato1
ListoListo
Aceptadato1
ReTxack1
Esperadato1
Aceptadato0
ReTxack0
ReTxdato0
Transmisor Receptor
Control de flujo. Protocolo bit alternante
Origen del mensaje (A, B)
Número de secuencia (0,1)
transmisión
A y B son procesos
52
a(0)ack de a
b(1)
retrasoack de b
timeout
c(0)ack de b
c(0)
Transmisor Receptor
Control de flujo. Protocolo bit alternante
53
A0
TransmisorA
ReceptorB
Nº sec
0
1
2
3
Nº ack
3
3
3
3
A1
A2
A3
B0
B1
B2
B3
Nº sec
0
1
2
3
Nº ack
0
1
2
3A4
Nº sec
0
1
2
3
Nº ack
3
3
3
3
A5
A6
A7
Hasta que no llega el ack de A0, el emisorno puede seguir transmitiendo
Control de flujo. Protocolo de ventana
54
A0
TransmisorA
ReceptorB
Nº
sec
0
1
2
3
Nº
ack
3
3
3
3
A1
A2
A3
B0
B1
B2
B3
Nº
sec
0
1
2
3
Nº
ack
0
1
2
3A4
Nº
sec
0
1
2
3
Nº
ack
3
3
3
3
A5
A6
A7
timeout
B0
B1
B2
B3
Nº
sec
0
1
2
3
Nº
ack
0
1
2
3
Se retransmite
A los acepta y piensa que los datos de la
ventana anterior han llegado bien
Control de flujo. Protocolo de ventana
55
A0
TransmisorA
ReceptorB
Nº
sec
0
1
2
3
Nº
ack
3
3
3
3
A1
A2
A3
B0
B1
B2
B3
Nº
sec
0
1
2
3
Nº
ack
0
1
2
3
A0
Nº
sec
0
1
2
3
Nº
ack
3
3
3
3
A1
A2
A3
timeout
B0
B1
B2
B3
Nº
sec
0
1
2
3
Nº
ack
0
1
2
3
Se retransmite
B los acepta y piensa que son los datos de la
ventana siguiente , y sin embargo, están duplicados
Control de flujo. Protocolo de ventana
56
Transmitiendo
Esperaack
Límiteventana
1/12/1
3/14/5
5/4
6/5
1/1
-/3 3/2
2/1
4/5
5/4
Transmisor
Control de flujo. Protocolo de ventana con detección de errores
57
Control de flujo. Protocolo de ventana con detección de errores
v ≡ nº de mensajes pendientes de ackw ≡ tamaño de la ventana de Txs ≡ nº de secuencia del último mensaje enviadoa ≡ nº de secuencia del mensaje más antiguo enviado y sin confirmardato[x] ≡ almacena el dato que fue enviado con nº de secuencia xd ≡ dato que se quiere enviarp ≡ nº de secuencia recibido en ackM ≡ rango de números de secuencia disponible
Acciones:pendiente[i] ≡ el mensaje con nº de sec i se apunta como enviado y pendiente de ackpendiente[i] ≡ el mensaje con nº de sec i se apunta como confirmado
v+ ≡ se incrementa en uno el nº de mensajes pendientes de confirmaciónv- ≡ se decrementa en uno el nº de mensajes pendientes de confirmación
NotaciónNotación
58
Control de flujo. Protocolo de ventana con detección de errores
TransmisorTransmisor
Tx Límiteventana
1/1
Entradas1. 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)
Salidas1. 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. Nada5. para i desde a hasta s en módulo M hacer: F-DATOS.request(dato[i],i) (retransmite todos los datos desde el último que no fue confirmado)
3/2
4/3
5/4
6/5
2/1
6/5
5/4
4/3
3/2
59
Tx
Esperaack
Límiteventana
1/12/1
3/14/5
5/4
6/5
1/1
-/3 3/2
2/1
4/5
5/4
Transmisor
Entradas1. 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. timeout6. F-DATOS.indication (ack) [CRC & Nºsec & Nºack OK]
Salidas1. Toma 3-PDU, forma 2-PDU; F-DATOS.request2. Extrae 3-PDU; E-DATOS.indication3. Forma 2-PDU; F-DATOS.request
4. Forma 2-PDU; F-DATOS.request5. nada
Detección y corrección de errores
Control de flujo. Protocolo de ventana con detección de errores
60
A0
TransmisorA
ReceptorB
Nº sec
0
1
2
3
Nº ack
3
3
3
3
A1
A2
A3
B0
B1
B2
B3
Nº sec
0
1
2
3
Nº ack
0
1
2
3
A4
Nº sec
0
1
2
3
Nº ack
3
3
3
3
A5
A6
A7
Hasta que no llega el ack de A0, el emisorno puede seguir transmitiendo
Control de flujo. Protocolo de ventana con ackglobal