protocolos de comunicación de datos1
DESCRIPTION
protocolos de comunicacion de datos.TRANSCRIPT
Protocolos de Comunicación de Datos Ingeniero en Computación
8° Semestre
Contenido Unidades
I. Introducción a los protocolos de comunicación…..........( 03)
II. Estructura de los protocolos……………………………………….(17)
III. Control de error………………………………………………………….(42)
IV. Control de flujo………………………………...........................…(55)
V. Modelos de Validación……………………......................…....(65)
VI. Criterios de corrección…………………………………………..…..(95)
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
2
Unidad I Introducción a los protocolos de comunicación
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
3
Regresar a Contenido
¿Protocolo? • Conjunto de reglas o convenios que gobiernan el formato y el
control de la información transmitida a través de una red.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
4
Protocolos como Lenguajes La definición completa de un protocolo se parece mucho a la definición de un lenguaje:
Define el formato preciso de mensajes válidos (sintaxis)
Define las reglas para el intercambio de datos (gramática)
Define un vocabulario de mensajes válidos que pueden ser intercambiados, con su significado (semántica).
La gramática del protocolo debe ser consistente y completa: bajo cualquier circunstancia las reglas deben dictar de manera no ambigua lo que está prohibido y lo que está permitido.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
5
Estandarización de Protocolos La normalización o estandarización es la redacción y aprobación de normas que se establecen para garantizar el acoplamiento de elementos construidos independientemente, así como garantizar el repuesto en caso de ser necesario, garantizar la calidad de los elementos fabricados, la seguridad de funcionamiento y trabajar con responsabilidad social.
La normalización es el proceso de elaborar, aplicar y mejorar las normas que se aplican a distintas actividades científicas, industriales o económicas con el fin de ordenarlas y mejorarlas. La asociación estadounidense para pruebas de materiales (ASTM) define la normalización como el proceso de formular y aplicar reglas para una aproximación ordenada a una actividad específica para el beneficio y con la cooperación de todos los involucrados.
Según la ISO (International Organization for Standarization) la normalización es la actividad que tiene por objeto establecer, ante problemas reales o potenciales, disposiciones destinadas a usos comunes y repetidos, con el fin de obtener un nivel de ordenamiento óptimo en un contexto dado, que puede ser tecnológico, político o económico.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
6
Objetivos fundamentales de la normalización
• Simplificación: se trata de reducir los modelos para quedarse únicamente con los más necesarios.
• Unificación: para permitir el intercambio a nivel internacional.
• Especificación: se persigue evitar errores de identificación creando un lenguaje claro y preciso.
• Las elevadas sumas de dinero que los países desarrollados invierten en los organismos normalizadores, tanto nacionales como internacionales, es una prueba de la importancia que se da a la normalización.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
7
Organismos Internacionales de Normalización • ITU - Unión Internacional de Telecomunicaciones (engloba CCITT y CCIR).
• ISO - La Organización Internacional de Normalización o ISO.
• ANSI - Instituto Nacional Estadounidense de Estándares.
• IETF -Internet Engineering Task Force.
• IEEE corresponde a las siglas de (Institute of Electrical and Electronics
Engineers) en español Instituto de Ingenieros Eléctricos y Electrónicos. Algunos estándares son:
• VHDL • POSIX • IEEE 1394 • IEEE 488 • IEEE 802 • IEEE 802.11 • IEEE 754
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
8
Estandarización de Protocolos
Se requiere de métodos convincentes y efectivos para:
• Diseñar y describir protocolos.
• Verificar que el protocolo es correcto.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
9
FDT (Técnicas de Descripción Formal)
Se han desarrollado tres lenguajes para la especificación de protocolos:
SDL
Lotos
Estelle
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
10
FDT
• SDL (Specification and Description Language). Desarrollado por el CCITT (1987). Inicialmente creado para la especificación y el diseño de sistemas de telecomunicaciones.
• Lotos (Language of Temporal Ordering Specifications). Desarrollado por ISO (1989). Especificación formal del comportamiento de los procesos desde un alto nivel de abstracción.
• Estelle. Desarrollado por ISO (1989). Basado en una extensión de concepto de máquina de estado finito.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
11
Identificación del problema
¿Cómo diseñar un conjunto de reglas para el intercambio de información que sean mínimas,
consistentes, completas e implementadas de manera eficiente?
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
12
Disciplina de diseño
Durante el diseño del protocolo se seguirá un conjunto de reglas autoimpuestas que ayudarán a evitar posteriores problemas. Además, se seguirá la siguiente política:
• Todo protocolo debe ser considerado como incorrecto, hasta que se demuestre lo contrario.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
13
Herramientas de diseño
Los métodos de diseño que se usarán están basados en el modelo de validación.
Un modelo de validación:
• Expresa las características esenciales del protocolo.
• No entra en detalles de implementación.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
14
Herramientas automatizadas interpretan estos modelos de validación y reportan deficiencias de diseño
PROMELA (Protocol Meta Language).
Desarrollado por AT&T Bell Labs. Gerard Holzmann.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
15
Ejercicios:
• ¿Cuál es el propósito del diseño de protocolos?
• Escriba el nombre de cinco protocolos de comunicación.
• Describa las principales características del TCP/IP.
• En qué consisten las Técnicas de Descripción Formal?
• Cuáles organizaciones definen la estandarización de protocolos?
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
16
Unidad II Estructura de Protocolos
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
17
Regresar a Contenido
Introducción
Durante el diseño de protocolos, dos tipos de errores son difíciles de evitar:
• Diseño de un conjunto incompleto de reglas.
• Diseño de reglas contradictorias.
La ambición de idea es hacer que el conjunto de reglas sea tanto completo como consistente.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
18
Los Cinco Elementos de un Protocolo
La especificación de un protocolo, consiste de las siguientes partes:
• El servicio provisto por el protocolo.
• Las suposiciones hechas acerca del medio ambiente en el cual el protocolo será ejecutado.
• El vocabulario de mensajes usados para implementar el protocolo.
• La codificación (formato) de cada mensaje del vocabulario.
• Las reglas de intercambio de mensajes.
El último elemento es el más difícil de diseñar y de verificar; nos dedicaremos principalmente al diseño y validación del conjunto de reglas no ambiguas.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
19
Ejemplo de la especificación de un Protocolo
Especificación del Servicio
El objetivo del protocolo es la transferencia de archivos texto como consecuencia de caracteres a través de una línea telefónica, con detección y corrección de errores.
• Transferencia full-duplex.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
20
Ejemplo de la especificación de un Protocolo
Reconocimientos positivos y negativos para el tráfico de A a B son enviados por el canal de B a A y viceversa.
Cada mensaje contiene dos partes:
1. Información
2. Control aplicado al tráfico en el canal inverso.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
21
Supuestos acerca del Medio Ambiente
• Por lo menos dos usuarios del servicio de transferencia de archivos y un canal de transmisión.
• Los usuarios simplemente realizan una petición para la transferencia de archivo y esperan su terminación.
• El canal de transmisión puede distorsionar los mensajes de manera arbitraria.
• El canal de transmisión no pierde, duplica, inserta o reordena mensajes.
• Se asume que un módulo de nivel inferior es el encargado de detectar mensajes alterados y reemplazarlos por mensajes no alterados de tipo err.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
22
Vocabulario del Protocolo
Define tres tipos de mensajes:
• ack. Mensaje combinado con un reconocimiento positivo.
• nack. Mensaje combinado con un reconocimiento negativo.
• err. Mensaje con error de transmisión.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
23
De manera breve, el vocabulario puede ser expresado como un conjunto:
V = {ack, err, nak}
Vocabulario del Protocolo
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
24
Formato de los Mensajes
Cada mensaje consiste de dos campos de tamaño fijo:
• Campo de control que identifica el tipo de mensaje.
• Campo de datos conteniendo el carácter.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
25
La forma general de cada mensaje puede ser representada de manera simbólica como una simple estructura de dos campos:
{control tag, data}
Formato de los Mensajes
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
26
En lenguaje C, de manera más detallada, se tendría:
enum control {ack, nak, err} struct message{ enum control tag; unsigned char data; };
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
27
Conjunto de Reglas
De manera informal, las reglas del protocolo son:
• Si el mensaje recibido no contiene errores, el siguiente mensaje que será enviado por el canal en sentido inverso, contendrá un reconocimiento positivo; si el mensaje recibido tuvo error, entonces contendrá un reconocimiento negativo.
• Si el mensaje recibido contiene un reconocimiento negativo o es un error, entonces retransmitir el mensaje viejo; en otro caso, generar un nuevo mensaje para ser transmitido.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
28
Para formalizar estas reglas, se puede hacer uso de las siguientes técnicas:
• Diagramas de transición de estados.
• Diagramas de flujo.
• Expresiones algebraicas, etc.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
29
Servicio y Medio Ambiente
• Modelo OSI de ISO (Introducción)
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
30
Servicio y Medio Ambiente
La necesidad de intercambiar información entre sistemas heterogéneos, es decir, entre sistemas cuyas tecnologías son muy diferentes entre sí, llevó a la ISO (International Standard Organization) a buscar la manera de regular dicho intercambio de información.
El modelo de referencia OSI (Open Systems Interconnection) surgió en el año de 1983 y fue el resultado del trabajo de la ISO para la estandarización internacional de los protocolos de comunicación.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
31
Modelo OSI
El modelo OSI consta de siete capas o niveles.
Las características generales de las capas son las siguientes:
Cada una de las capas desempeña funciones bien definidas.
Los servicios proporcionados por cada nivel son utilizados por el
nivel superior.
Existe una comunicación virtual entre dos mismas capas, de
manera horizontal.
Existe una comunicación vertical entre una capa de nivel N y la
capa de nivel N + 1.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
32
Arquitectura de red basada en el modelo OSI
N7 Aplicación Provee servicios generales relacionados con
aplicaciones (transferencia de archivos)
N6 Presentación Formato de datos (ASCII)
N5 Sesión Coordina la interacción en la sesión de usuarios
N4 Transporte Provee una transmisión de datos confiable punto a
punto
N3 Red Enruta unidades de información
N2 Enlace de datos Provee intercambio de datos entre dispositivos en el
mismo medio
N1 Físico Transmite un flujo de bits a través del medio físico
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
33
Comparativo entre el Modelo OSI y el Modelo TCP/IP
OSI TCP/IP PROTOCOLOS
Aplicación
Presentación
Sesión
Aplicación
HTTP, Telnet, FTP,
LPD, SNMP, TFTP,
SMTP, NFS, X
Windows, JPEG,
MPEG
Transporte Transporte TCP, UDP
Red Internet ICMP, BOOTP, ARP,
RARP, IP, IPX
Enlace de Datos
Física
Red
Ethernet, Fast-
Ethernet, Token Ring,
FDDI, HDLC, Frame-
Relay
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
34
Vocabulario y formato de protocolos
A nivel más bajo, se tienen los siguientes
formatos:
Orientado a bit.
Orientado a caracteres.
Orientado a un número total de bytes.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
35
- Orientado a bit
El protocolo transmite los datos como una
secuencia de bits crudos.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
36
- Orientado a carácter
El número de bits por carácter es fijado a n bits
(normalmente 7 u 8).
La transmisión se lleva a cabo en grupos de n bits.
Por ejemplo, código ASCII.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
37
- Orientado a un número total de bytes
En algún lugar predefinido después del carácter de control, se incluye el número total de bytes que el mensaje contiene.
No se necesitaría una bandera de inicio ni una bandera de fin.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
38
Encabezados y colas (headers and trailers)
• format = {header, data, trailer} • header = {type, destination, sequence number, count} • trailer = {checksum, return address}
STX header user data trailer ETX
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
39
Trama Ethernet
Preámbulo Dir. destino Dir. fuente Tipo trama Datos CRC
8 bytes 6 bytes 6 bytes 2 bytes 46-1500 bytes 4 bytes
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
40
Ejercicios: 1. Escriba su ejemplo de especificación de un protocolo.
2. Describa las capas del Modelo OSI y sus principales funciones. 3. Escriba un ejemplo de protocolo de Enlace y de Red. 4. Mencione tres protocolos de la capa de Aplicación. 5. ¿En qué consiste la técnica de piggybacking?. 6. ¿Cuál es el enfoque de formato que utiliza la mayoría de protocolos actuales? 7. Explique las Diez Reglas de Diseño de Protocolos.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
41
Unidad III Control de Error
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
42
Regresar a Contenido
Control de Error
Existen diferentes probabilidades de error en los medios de transmisión guiados o no guiados.
• Enlace fibra óptica: 10-9. En promedio 1 en 109 bits transmitidos.
• Cable coaxial: 10-6.
• Línea telefónica: 10-4... 10-5.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
43
Control de Error
Vel. Transmisión Prob. de error Tipo de enlace 1 error cada:
9600 bps 10-4 Línea telefónica 1.04 segs
9600 bps 10-6 Coaxial 104 segs
9600 bps 10-9 Fibra óptica 3303 años
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
44
Tipos de Errores de Transmisión
• Inserción
• Pérdida
• Duplicación
• Distorsión
• Reordenamiento
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
45
Cyclic Redundancy Check (CRC)
• Al mensaje original (palabra código) se le agrega una secuencia de bits.
• Si no hay error, el método garantiza que la palabra código junto con la secuencia de bits agregada, es divisible por un factor dado.
• El factor utilizado determina el rango de errores de transmisión que pueden ser detectados.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
46
Cyclic Redundancy Check (CRC) El método está basado en asimilar las secuencias de bit con polinomios de coeficientes 0 o 1.
0 1 1 0 1 1 0
0 x6 + 1 x5 + 1 x4 + 0 x3 + 1 x2 + 1 x + 0
x5 + x4 + x2 + x
Para usar este método emisor y receptor acuerdan utilizar un polinomio G(x), que es el polinomio generador. La información redundante generada por este polinomio se denomina checksum.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
47
Cyclic Redundancy Check (CRC)
• El cálculo del checksum se lleva a cabo de forma que el polinomio que representa la trama de datos + checksum sea divisible por G(x).
• M(x) = polinomio que representa los bits de datos.
• T(x) = trama de datos + checksum.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
48
Algoritmo para el cálculo del checksum:
1.- Añadir r bits 0 al final de los datos xr M(x)
r = grado (G(x))
Ejemplo: G(x) = x5 + x4 + x2 + 1 r = 5
M(x) = x9 + x7 + x3 + x2 + 1 101000110100000
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
49
Algoritmo para el cálculo del checksum:
2.- Dividir xr M(x) entre G(x) utilizando aritmética en módulo 2. 101000110100000 |110101 110101 1101010110 0111011 110101 00111010 110101 00111110 110101 00101100 cociente Q(x) y resto R(x) 110101 0110010 110101 0001110
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
50
Algoritmo para el cálculo del checksum:
3.- Restar xr M(x) - R(x) = T(x) que es lo que se transmite
101000110100000
1110
101000110101110
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
51
Algoritmo para el cálculo del checksum:
4.- Receptor: T’(x) / G(x) Þ R’(x)
Si R’(x) = 0 la trama de datos recibida se da como buena
Si R’(x) ¹ 0 la trama de datos tendrá errores
Aunque si R’(x) = 0 no se puede asegurar que no tenga errores ya que pueden haberse producido muchos errores en T(x) y que al dividirlo por G(x) de 0.
Condiciones que debe cumplir G(x) para detectar errores de 1 bit:
T’(x) / G(x) = T(x) + E(x) / G(x) = T(x) / G(x) + E(x) / G(x)
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
52
Algoritmo para el cálculo del checksum:
• Si sólo se ha producido un error en la transmisión: E(x) = xi i = posición del error.
• Para detectar errores de un bit, G(x) deberá tener más de un término.
• ¿Qué debe cumplir G(x) para detectar un número impar de errores?
• Si E(x) tiene un número impar de términos, no tiene (x+1) como factor entonces, si G(x) tiene a (x+1) como factor, E(x) no es divisible por G(x)
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
53
Polinomios más utilizados:
• CRC-12 G(x) = x12 + x11 + x3 + x2 + x + 1
• CRC-16 G(x) = x16 + x15 + x2 + 1
• CRC-CCITT G(x) = x16 + x12 + x5 + 1
Los polinomios de grado 16 son capaces de detectar ráfagas de error de hasta 16 bits.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
54
Unidad IV Control de Flujo
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
55
Regresar a Contenido
Control de Flujo
El Control de flujo consiste en ajustar la tasa a la cual el transmisor envía datos con la tasa a la cual el receptor puede procesar.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
56
Protocolo x-on / x-off
• El funcionamiento correcto del protocolo, depende de las propiedades de transmisión del canal.
• Mensaje suspend perdido => overflow.
• Mensaje resume perdido => procesos bloqueados.
• Se requiere solucionar los siguientes problemas:
• Proteger contra problemas de overflow
• Proteger contra la pérdida de mensajes
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
57
Protocolo de Reconocimiento Positivo con Retransmisión
• El emisor envía un paquete y espera un mensaje de reconocimiento de parte del receptor, antes de enviar el siguiente paquete.
• El emisor, después de enviar un paquete, activa un temporizador: si éste expira antes de la llegada del reconocimiento, el emisor retransmite el paquete.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
58
Protocolos de Ventana Deslizante
• Más eficiente
• Aprovechamiento del ancho de banda de la red.
• El emisor transmite un número determinado de paquetes antes de esperar el reconocimiento.
• Este número está limitado por el tamaño de la ventana.
• Un tamaño de ventana igual a 1 corresponde al protocolo de reconocimiento positivo.
• Conforme el tamaño de ventana aumenta es posible eliminar el tiempo de ocio de la red completamente. En el estado de equilibrio, el emisor transmite paquetes a la misma tasa con la que la red los puede procesar, lo que implica que se obtiene un máximo desempeño de la red.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
59
Otras consideraciones:
• La transmisión ya no es simplex sino que se transmite información en ambos sentidos (duplex o semi-duplex).
• Van a haber tramas de datos y reconocimiento mezcladas en el canal, para diferenciarlas se usará el campo clase.
• Se usará una técnica de reconocimiento llamada PIGGIBACKING, consiste en enviar el reconocimiento junto a la trama de datos.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
60
Problema:
Si no hay tráfico de sentido inverso. Se deberá habilitar un temporizador para esperar un cierto tiempo si hay datos para enviar, en caso contrario se enviará una trama de reconocimiento.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
61
Ventajas: al haber menos tramas se realizará un mejor uso del canal.
• Todas las tramas están identificadas por un número de secuencia entre 0 y 2n-1.
• Permiten el envío de varias tramas antes de que las estaciones se queden bloqueadas esperando el reconocimiento.
• Las estaciones que utilizan estos protocolos mantienen una ventana de emisión (lista con los números de tramas enviadas por esa estación y que están pendientes de reconocimiento) y una de recepción.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
62
Ventajas
• El hecho de enviar varias tramas antes de que se bloquee la estación implica el tener unos buffers con las tramas enviadas por si se deben volver a enviar, esto añade cierta complejidad a los protocolos.
• La ventana de recepción contiene una lista con los números de secuencia de las tramas que puede aceptar la máquina receptora.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
63
Ejercicios:
• ¿Cómo determinar cada cuánto tiempo ocurre un error en los medios de transmisión?
• ¿Cuáles son los diferentes tipos de errores de transmisión?
• ¿Cómo se detectan errores de transmisión conociendo los datos recibidos y el polinomio CRC utilizado?
• ¿Cómo evitar o reducir la congestión en un canal de comunicación?
• ¿En qué casos se deben utilizar protocolos de ventana deslizante?
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
64
Unidad V Modelos de Validación
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
65
Regresar a Contenido
Modelos de Validación
Un modelo de validación define las interacciones de procesos en un sistema distribuido.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
66
Se definen los modelos de validación en términos de tres tipos de objetos:
• Procesos
• Canales
• Variables
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
67
PROMELA (Protocol Meta Language).
Es un lenguaje usado para describir modelos de validación. PROMELA fue creado en 1980 y es un subconjunto de C y OCAN.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
68
Enunciados Ejecutables
• En PROMELA no hay diferencias entre condiciones y enunciados.
• Los enunciados son ejecutables o bloqueantes.
• El estado ejecutable de un enunciado representa el medio principal de sincronización.
• Un proceso puede esperar a que un evento suceda hasta que un enunciado se vuelva ejecutable.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
69
Por ejemplo:
• En lugar de escribir:
while (a != b) skip /* wait for == b */
• En PROMELA se tiene el mismo efecto con el siguiente enunciado:
(a == b)
• La condición es ejecutada sólo si es verdadera.
• Si la condición es falsa, la ejecución es bloqueada hasta que la condición sea verdadera.
• La asignación a variables siempre es ejecutable.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
70
Variables y Tipos de Datos
• Las variables pueden ser globales o locales a un proceso.
• Una variable puede ser de alguno de los siguientes tipos predefinidos: bit, bool, byte, short, int, chan.
• Un canal es un objeto que puede almacenar un conjunto de valores agrupados en estructuras definidas por el usuario.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
71
Arreglos
byte state [N]
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
72
Procesos
proctype A() {
byte state;
state = 3
}
** ';' y '->' son separadores equivalentes de enunciados.
Ejemplo:
byte state = 2;
proctype A () { (state == 1) -> state = 3 }
proctype B () { state = state - 1 }
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
73
Proceso init
• Equivalente a la función main( ) de lenguaje C.
• La especificación más pequeña posible en PROMELA es:
init { skip }
• Otros ejemplos,
init { printf ( "Hola, crayolas! \n" ) }
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
74
Para instanciar los procesos A y B:
init { run A (); run B () }
• El proceso init lanza dos procesos, que serán ejecutados de manera concurrente.
• En éste caso, el proceso init termina después de haber lanzado el segundo proceso.
• run instancia una copia del proceso dado como operando, no espera a que el proceso termine.
• run es un enunciado ejecutable y regresa un número positivo (pid) sólo si el proceso pudo ser instanciado.
• Es no ejecutable y regresa 0 si el proceso no pudo ser instanciado.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
75
Paso de Parámetros a un Nuevo Proceso
proctype A (byte state; short set) {
( state == 1) -> state = set }
init { run A (1, 3) }
• Sólo valores de cualquiera de los tipos base, pueden ser pasados como parámetros.
• No es posible pasar arreglos ni procesos.
• run puede ser usado en cualquier proceso para crear nuevos procesos.
• Un proceso muere cuando termina, es decir, cuando alcanza el final de su cuerpo, siempre y cuando todos sus procesos hijos hayan terminado.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
76
Canales de comunicación
• Usados para modelar la transferencia de información entre procesos.
• Pueden ser locales o globales.
chan a, b; chan c [3]
• Define a y b como identificadores de canal; c como arreglo de identificadores de canal.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
77
Declaración de un canal con un inicializador
1. chan a = [16] of { short }
El canal puede almacenar hasta 16 mensajes de tipo short.
2. chan c [3] = [4] of { byte }
3. chan qname = [2] of { byte, int, chan }
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
78
Envío de Mensajes
qname ! expr
Envía el valor de la expresión expr a través del canal qname; lo coloca en el buffer asociado al canal qname (política FIFO).
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
79
Recepción de Mensajes
• qname ? msg
byte int chan byte int chan
Recupera el primer mensaje en el buffer asociado al canal qname y almacena su valor en la variable msg.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
80
Envío y Recepción de Mensajes estructurados
qname ! expr1, expr2, expr3
qname ? var1, var2, var3
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
81
Comunicación Síncrona (Rendezvous)
chan port = [0] of { byte }
• Estamos definiendo un tamaño de buffer para el canal port igual a 0, por lo que no es posible almacenar mensajes.
• La comunicación es síncrona y binaria; sólo dos procesos, un transmisor y otro receptor son sincronizados.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
82
Control de Flujo
• Selección case.
• Repetición.
• Jumps incondicionales.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
83
Selección Case if :: (a != b) -> opcion1 :: (a == b) -> opcion2 fi 1
8/0
1/2
01
4
Pro
toco
los
de
Co
mu
nic
ació
n d
e D
ato
s/C
AR
R/8
° Se
mes
tre
84
• Sólo una secuencia de enunciados (opción1 u opción2) es ejecutada.
• Una secuencia es seleccionada sólo si su primer enunciado es ejecutable.
• El primer enunciado es llamado guardia.
• Si más de un guardia es ejecutable, una sola secuencia de las asociadas a dichos guardias, es seleccionada de manera aleatoria.
• Si ningún guardia es ejecutable, el proceso se bloquea hasta que por lo menos uno de ellos pueda ser seleccionado.
Ejemplo 1: #define a 1 #define b 2 chan ch = [1] of { byte } proctype A () { ch ! a } proctype B () { ch ! b } proctype C () { if :: ch ? a :: ch ? b fi } init { atomic { run A(); run B(); run C () }
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
85
Ejemplo 2:
byte count; proctype counter() { if :: count = count + 1 :: count = count - 1 fi }
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
86
Repetición • El siguiente ciclo incrementa o decrementa la variable de manera
aleatoria: byte count; proctype counter() { do :: count = count + 1 :: count = count - 1 :: (count == 0) -> break od }
• El ciclo puede ser roto con el enunciado break cuando count es igual
a 0.
• Puede no terminar ya que las otras dos opciones son seleccionables.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
87
Repetición
proctype counter() { do :: (count != 0) -> if :: count = count + 1 :: count = count - 1 fi :: (count == 0) -> break od }
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
88
Saltos incondicionales (jumps)
proctype Euclid (int x, y) { do :: (x > y) -> x = x - y :: (x < y) -> x = y - x :: (x == y) -> goto done od done: skip }
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
89
Funciones, procedimientos y recursión
proctype fact (int n; chan p) { int result; if :: (n <= 1) p ! 1 :: (n >= 2) -> chan child = [1] of { int }; run fact (n - 1, child); child ? result; p ! n * result fi } init { int result; chan child = [1] of { int }; run fact (3, child); child ? result; printf ("Resultado: %d \n", result) }
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
90
Definición de los Tipos de Mensaje
mtype = {ack, nak, err, next, accept} Equivalente a: #define ack 1 #define nack 2 #define err 3 #define next 4 #define accept 5
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
91
Temporizadores
proctype watchdog () { do :: timeout -> guard ! reset od }
• timeout es una condición predefinida que se vuelve verdadera sólo cuando ningún otro enunciado en el sistema distribuido es ejecutable.
• No modela errores causados por la expiración prematura del temporizador en un sistema real.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
92
Tipos de Enunciados
• Asignación y condición.
• Selección y repetición.
• send y receive.
• goto y break.
• timeout.
• run y len no son enunciados, sino operadores unarios que pueden ser usados en asignaciones y condiciones.
• skip es un seudo enunciado.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
93
Ejercicios:
• ¿Cuáles son los tres tipos de objetos que definen los modelos de validación?
• ¿Cuál es el equivalente a la función main() de C en el lenguaje PROMELA?
• ¿A qué se refiere el término Rendezvous?
• ¿Cómo realiza PROMELA el control de flujo?
• ¿Cómo implementa un temporizador?
• ¿Cómo se definen en PROMELA los tipos de mensaje?
• ¿Cuáles son los tipos básicos de enunciados definidos en PROMELA?
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
94
Unidad VI Criterios de corrección
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
95
Regresar a Contenido
Criterios de Corrección El objetivo principal del lenguaje PROMELA es validar, y no implementar.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
96
Validación • Para validar un diseño, es necesario especificar de manera clara y
precisa lo que entendemos por un diseño correcto.
• Un diseño puede ser considerado correcto sólo para un conjunto específico de criterios de corrección.
• Necesitamos de un formalismo para especificar los criterios de corrección.
• Entre más expresiva sea nuestra notación, menos útil será en la práctica.
• Por lo tanto, los criterios de corrección que pueden ser especificados en PROMELA han sido escogidos cuidadosamente.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
97
Razonamiento sobre el comportamiento
• Formalizamos los criterios de corrección como afirmaciones sobre el comportamiento de un modelo de validación en PROMELA.
• Un comportamiento es: Inevitable o imposible.
• Los criterios de corrección que pueden ser expresados en PROMELA definen comportamientos considerados como imposibles.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
98
Justificación
Para afirmar que un comportamiento es inevitable, por ejemplo, podemos estipular que todos los comportamientos posibles que nos alejan de él, son imposibles.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
99
Definiciones en PROMELA
• El comportamiento de un modelo de validación se define como el conjunto de todas las secuencias de ejecución posibles.
• Una secuencia de ejecución es simplemente un conjunto finito de estados ordenados.
• Un estado está dado por el valor de todas las variables locales y globales, puntos de control de flujo de los procesos en ejecución y por el contenido de todos los mensajes de comunicación.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
100
Conjunto finito de estados
• Un conjunto finito de estados ordenados, es considerado válido para un modelo M dado si satisface los siguientes criterios:
• El estado inicial de la secuencia, por ejemplo, el estado 1, es el estado inicial de M, con todas las variables inicializadas en 0, todos los canales de comunicación vacíos y sólo con el proceso init activo.
• Si M es colocado en el estado i, existe por lo menos un enunciado ejecutable que lo llevará al estado i + 1.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
101
Secuencias Especiales: Terminales y Cíclicas
• Una secuencia es terminal si ningún estado aparece más de una vez
en la secuencia y el modelo M no contiene enunciados ejecutables una vez alcanzado el último estado de la secuencia.
• Una secuencia es cíclica si todos los estados menos el último son diferentes, y este último es igual a alguno de los estados precedentes.
• Secuencias cíclicas definen ejecuciones potencialmente infinitas.
• Las secuencias terminales y cíclicas que pueden ser generadas al ejecutar un modelo en PROMELA, definen juntas el comportamiento del sistema para ese modelo.
• La unión de todos los estados incluidos en el comportamiento del sistema, define el conjunto de estados alcanzables del modelo.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
102
Criterios de validación
• Aserciones: • assert ( condición)
• Invariantes del sistema: • proctype monitor () { assert (invariante) }
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
103
Ejemplo: Semáforos Dijkstra #define p 0 #define v 1 chan semaf = [0] of { bit } proctype dijkstra () { do :: semaf ! p -> semaf ? v od } proctype user () { semaf ? p; /* Sección crítica */ semaf ! v /* Sección no crítica */ } init { atomic { run dijkstra(); run user(); run user(); run user(); } }
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
104
Ejemplo: Semáforos Dijkstra
• El semáforo garantiza acceso exclusivo a la región crítica de cada proceso user.
• Se puede modificar el proceso user de tal manera que la variable global count contenga el número de procesos que se encuentran en su sección crítica como se muestra a continuación.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
105
Ejemplo: Semáforos Dijkstra (sesión crítica)
byte count; proctype user() { semaf ? p count = count + 1; /* Sección crítica */ count = count - 1; semaf ! v /* Sección no crítica */ }
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
106
Verificación del funcionamiento del semáforo
La siguiente invariante del sistema puede ser utilizada para verificar el funcionamiento correcto del semáforo:
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
107
proctype monitor () { assert ( count == 0 || count == 1 ) } init { atomic { run dijkstra(); run monitor(); run user(); run user(); run user(); } }
Deadlocks:
proctype dijkstra () { end: do :: semaf ! p -> semaf ? v od }
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
108
Ciclos erróneos:
• Existen dos propiedades sobre las secuencias cíclicas correspondientes a dos tipos estándares de criterios de corrección.
• Las dos propiedades se basan en el marcado explícito de estados en el modelo de validación.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
109
Ciclos sin progresión:
proctype dijkstra () { end : do :: semaf ! p -> progress : semaf ? v od }
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
110
Livelocks:
proctype dijkstra () { end : do :: semaf ! p -> accept : semaf ? v od }
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
111
Exigencias temporales
never { do :: skip od -> P -> ! Q }
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
112
Conclusiones
• Se ha introducido el resto de las directivas de validación PROMELA.
• Estas directivas están relacionadas con la especificación de los criterior de corrección para un modelo: Enunciados de aserción, Etiquetas end, progress y accept, Exigencia temporal never.
• Es prácticamente imposible verificar manualmente requerimientos de corrección.
• El comportamiento de inclusive protocolos simples es bastante complejo.
• Herramientas automatizadas como PROMELA son imprescindibles, no sólo para expresar los requerimientos de corrección del diseño de un protocolo, sino también para validarlos de manera confiable.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
113
Ejercicios:
• Explique los principales criterios de validación.
• ¿Explique los ejemplos de Deadlocks y Livelocks?
• ¿Cuáles son las dos propiedades sobre las secuencias cíclicas correspondientes a los dos tipos estándares de criterios de corrección?
• ¿Cómo se hace referencia a instancias de procesos en PROMELA?
• ¿Cómo se hace referencia a las variables locales de procesos?
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
114
Validación de Protocolos
Se necesita verificar la consistencia lógica de una especificación formal. La especificación es formalizada como un modelo de validación en PROMELA, por ejemplo.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
115
Método Manual de Prueba
• Considere un sistema simple de transmisión con un transmisor S y un receptor R.
• El proceso S envía mensajes al proceso R a través de un medio no confiable de transmisión.
• Cada mensaje transmitido lleva un número de secuencia, incialmente igual a 1 e incrementado en 1 después de cada transmisión.
• El receptor reconoce el mensaje recibido mediante la transmisión del número de secuencia a través de un canal similar.
• El receptor almacena el número de secuencia más grande que ha recibido correctamente en su variable local B.
• El emisor guarda en la variable A el número de secuencia más grande que R ha recibido correctamente.
• Inicialmente, A = B = 0.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
116
En PROMELA: #define W cte_positiva chan R = [W] of { int } chan S = [W] of { bit } mtype = { mesg, ack } proctype S () { int A = 0; do :: R ! mesg (A + rand () % W) /* S1 */ :: S ? ack(A) /* S2 */ od } proctype R () { int B = 0, b; do :: S ! ack (B) /* R1 */ :: atomic { /* R2 */ R ? mesg (b); B = fct (b, B); } od }
fct (b, B) memoriza la recepción del mensaje con número de secuencia igual a b y regresa un valor X ≥ B para el cual garantiza que todos los mensajes con número de secuencia menor o igual a X fueron grabados previamente por fct ().
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
117
Discusión sobre los Métodos Manuales
• Basados en la noción de estados invariantes.
• Contrariamente a los métodos usados en sistemas de validación automatizados, el método manual no se basa en la inspección de estados del sistema alcanzables, sino en la inspección de transmisiones de estado.
• Normalmente hay menos transiciones de estado que estados del sistema alcanzables.
• Sin embargo, puede requerir demasiado esfuerzo verificar que una transición no puede invalidar ninguna de las invariantes del sistema.
• Lo anterior implica que es un método ineficiente para sistemas grandes, por lo cual se requieren herramientas automatizadas para la construcción de pruebas.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
118
Métodos de Validación Automatizados
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
119
Algoritmos de Análisis de Estados Alcanzables
• Este tipo de algoritmos trata de generar e inspeccionar todos los estados de un sistema distribuido que son alcanzables a partir de un estado inicial.
• Existen tres tipos: Búsqueda completa (sistemas con hasta 105 estados), Búsqueda parcial controlada (sistemas con hasta 108 estados), Simulación aleatoria(sistemas aún más grandes).
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
120
Algoritmos de Análisis de Estados Alcanzables
El intérprete SPIN puede ser utilizado en las tres modalidades: Simulaciones aleatorias, Búsqueda parcial y Búsqueda exhaustiva.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
121
Método 1: Búsqueda completa o exhaustiva del espacio de estados
• Se lleva a cabo un análisis de todos los estados alcanzables y los no alcanzables.
• Se separan los estados alcanzables y los no alcanzables.
• Cada estado alcanzable y toda secuencia de estados alcanzables pueden ser verificados por un conjunto de criterios de corrección.
• Ejemplos de criterios de corrección: Ausencia de deadlocks, saturación de buffers, requerimientos temporales, invariantes del sistema, etc.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
122
ALGORITMO DE BÚSQUEDA COMPLETA DEL ESPACIO DE ESTADOS:
start(){ W = { initial_state }; /* estados por analizar */ A = { }; /* estados previamente analizados */ analyze(); } analyze() { /* Búsqueda exhaustiva */ if ( W is empty ) return; q = last element from W; add q to A; if (q == error_state) report_error(); else { for each succesor state s of q if (s is not in A or W){ add s to W; analyze(); } } delete q from W; }
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
123
Discusión sobre el Método de Búsqueda Exhaustiva
• El problema principal consiste en la capacidad de memoria disponible así como en la velocidad de procesamiento.
• Considere un protocolo con dos procesos, cada uno con 100 posibles estados, un canal de comunicación y 5 variables locales. Ambos canales están limitados a 5 entradas cada uno, en donde el número de mensajes diferentes a intercambiar es 10. Los valores distintos para las variables locales está limitada a 10.
• Búsqueda exhaustiva: sistemas con hasta 105 estados alcanzables.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
124
Método 2: Búsqueda Parcial Controlada
Basada en la premisa de que en la mayoría de los casos prácticos, el número máximo de estados que pueden ser analizados, A, es sólo una fracción del número total de los estados alcanzables R.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
125
Una búsqueda parcial controlada tiene los siguientes objetivos:
1. Analizar exactamente A estados.
2. Seleccionar los A estados del conjunto completo de estados alcanzables R, de tal manera que la mayoría de las funcionalidades del protocolo sean probadas.
3. Seleccionar los A estados de manera que la calidad de búsqueda, como la probabilidad de encontrar algún error dado, sea mejor que la cobertura A/R.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
126
Algoritmo de búsqueda parcial controlada
analyze() { /* Búsqueda parcial controlada */ if ( W is empty ) return; q = last element from W; add q to A; if (q == error_state) report_error(); else
{ for some succesor state s of q if (s is not in A or W){ add s to W; analyze(); } } delete q from W; }
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
127
Métodos para establecer criterios de selección
La selección de los estados sucesores puede ser hecha basada en una heurística para favorecer ejecuciones que revelen, con una probabilidad alta, errores de diseño.
• Límite de profundidad, • Búsqueda dispersa, • Búsqueda probabilística, • Orden parcial, • Selección aleatoria.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
128
Métodos para establecer criterios de selección
- Límite de profundidad: Se establece un límite en la longitud de las secuencias que serán analizadas. Limita la búsqueda a un subconjunto representativo de comportamientos.
- Búsqueda probabilística: Los estados son analizados, según su probabilidad de ocurrencia, en orden decreciente. Las transiciones del sistema son etiquetadas con una alta o baja probabilidad de ocurrencia, lo cual sirve como criterio de selección.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
129
Métodos usados para establecer los criterios de selección:
- Orden parcial: Los procesos son clasificados en procesos de alta y baja prioridad. Una transición perteneciente a un proceso de alta prioridad es favorecida a una transición de un proceso de baja prioridad.
- Selección aleatoria: No se realiza ningún esfuerzo para predecir los estados del sistema en los cuales se encontrarán los errores más probables. Este método es el más sencillo de implementar y el que produce una búsqueda con la más alta calidad.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
130
Discusión sobre los Métodos de Búsqueda Parcial Controlada
• Las primeras tres técnicas para controlar la búsqueda parcial tienen el siguiente problema en común: tratan de predecir dónde pueden ser encontrados los errores del protocolo.
• A pesar de que estos métodos reducen el número de estados del sistema analizados, estos están limitados ya en la práctica a sistemas con hasta 108 estados.
• Corolario de la Ley de Murphy:
• Los errores se esconden muy probablemente en donde el diseñador o el validador han decidido no buscar.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
131
Método 3: Simulaciones Aleatorias
• Utilizado para sistemas con más de 108 estados.
• El algoritmo descarta los conjuntos A y W y explora el espacio de estados usando la técnica de "Baco".
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
132
Algoritmo de Simulación aleatoria
analyze() { /* Simulación aleatoria */ q = initial state; while (1){ if (q is error_state){ report_error(); q = initial state;
{ else q = a succesor state of q; } }
El algoritmo funciona de manera independiente al tamaño y complejidad del sistema modelado (inclusive sistemas de tamaño infinito).
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
133
Algoritmo Supertrace:
• La implementación en C del algoritmo forma parte del intérprete Spin.
• Recuérdese que Spin ofrece las tres modalidades: Búsqueda exhaustiva, Búsqueda parcial controlada y Simulación aleatoria.
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
134
Ejercicios:
• Mencione cuatro ejemplos de criterios de corrección.
• ¿Cuáles son los métodos usados para establecer los criterios de selección?
• ¿Qué es una búsqueda dispersa?
• ¿Para qué se utiliza el spin en PROMELA?
• ¿Qué técnica de búsqueda utiliza el algoritmo Supertrace?
18
/01
/20
14
P
roto
colo
s d
e C
om
un
icac
ión
de
Dat
os/
CA
RR
/8°
Sem
estr
e
135