2. Concepto de protocolo
• Un protocolo es un acuerdo que se lleva a cabo
entre las partes que conformaran una
comunicación sobre como debe realizarse tal
comunicación para que funcione correctamente.
Violar el protocolo hará más difícil la comunicación, si
no es que imposible.
3. Elementos de un Protocolo
• Servicio que proporciona el protocolo
• Suposiciones sobre el entorno donde se ejecuta el
protocolo
• Vocabulario de los mensajes utilizados en el protocolo
• Formato de los mensajes del vocabulario del protocolo
• Reglas de procedimiento que controlan la consistencia
del intercambio de mensajes
4. 10 reglas del diseño de un protocolo
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
5. 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
6. Control de secuencia y de errores
• Redundancia
• Tipos de códigos
• Códigos de paridad
• Corrección de errores (varios métodos)
7. Redundancia
• Añadir información redundante a los mensajes
• Dos formas de gestionar los errores:
Control de errores hacia adelante códigos
correctores
Control de errores por realimentación códigos
detectores
8. 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.
9. Se pueden clasificar en:
Códigos lineales: combinación lineal de palabras validas.
Códigos cíclicos: rotación de código válido
Códigos sistemáticos: mensaje original + bits de comprobación.
10. 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 mas 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
11. Código corrector basado en paridad
• Permite la corrección de 1 bit
LRC = Longitudinal Redundancy Check
VRC = Vertical Redundancy Check
12. Método Van Lint
• A tiradas de una por segundo
• Canal de 2ª bps
• Tasa de error de 2-10-2
▫ q = 0.98
▫ P = 0.02
Cada par de tiradas se codofica con 4
bits
Se logra la mitad de tasa de errores
P(no error)=q4 + 3*p*q3
P(error) = 1-P(no error)
13. 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:
C =B log2 ( 1+ S/N)bps
14. 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
• Los bits redundantes ocupan las posiciones potencia de
2(1,2,4,8), el resto son los bits de datos
15. 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
- k datos de n bits matriz kxn
- se Tx por columnas corrige ráfagas ≤ k
- Reed-Solomon
- 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).
16. Checksum aritmético
• Método de Fletcher (1982)
• Sólo sumas y módulos, es simple, pero con buena detección de
errores
Menos 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);
}
17. 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.
18. 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
19. • 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
20. • 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