INGENIERÍA DE PROTOCOLOS DE COMUNICACIONES (MÓDULO...

INGENIERÍA DE PROTOCOLOS DE COMUNICACIONES - IMPLEMENTACIÓN DE PROTOCOLOS

INGENIERÍA DE PROTOCOLOS DE COMUNICACIONES

(MÓDULO 1)

INGENIERÍA DE PROTOCOLOS DE COMUNICACIONES - IMPLEMENTACIÓN DE PROTOCOLOSF. I. M.

L.S.I.I.S

F. I. M.

L.S.I.I.S

LUIS MENGUAL GALÁN

LSIIS

FIM

TELEMÁTICA

INGENIERÍA DE PROTOCOLOS(MÓDULO 1)

http://pegaso.ls.fi.upm.es/~lmengual/inicio_IP.html


OBJETIVOS

Describir las técnicas de descripción formal utilizadas para especificar formalmente protocolos de comunicaciones y presentar sus ventajas en la ingeniería de protocolos

Analizar las interfaces de programación más utilizadas en el entorno corporativo: Sockets de Berkeley, Windows Sockets, Sockets en Java.

Comprender las técnicas de implementación de aplicaciones distribuidas utilizando las diferentes interfaces de programación y el modelo cliente-servidor.

Estudiar el rendimiento de las implementaciones de software cliente y servidor.


ÍNDICE1. ESPECIFICACIÓN, DISEÑO Y VERIFICACIÓN DE PROTOCOLOS

1.1 Niveles de descripción de una arquitectura estructurada1.1.1 Definición de la Arquitectura1.1.2 Especificación de servicios1.1.3 Especificación formal de protocolos

1.2 Desarrollo de Protocolos 1.2.1 Especificación Formal

1.2.1.1 Validación1.2.1.2 Verificación1.2.1.3 Análisis de Prestaciones

1.2.2 Implementación1.2.3 Conformidad

1.3 Metodologías de Especificación1.3.1 Lenguaje Natural1.3.2 Grafos de Control de Comunicaciones1.3.3 Máquinas de Estados Finitos Extendidas1.3.4 Redes de Petri1.3.5 SDL1.3.6 Estelle1.3.7 Lotos1.3.8 Prolog


ÍNDICE1

2. IMPLEMENTACIÓN DE PROTOCOLOS (I)

2.1 Modelo cliente-servidor2.1.1 Terminología y conceptos2.1.2 Comparación con otros modelos

2.1.2.1 Aplicaciones peer to peer,2.1.2.2 Teoría de Agentes

2.2 Modelo Unix2.2.1 Comunicación entre procesos2.2.2 Procesos Concurrentes2.2.3 E/S asíncronas

2.3 Interfaces de Programación de Aplicaciones (API, AplicationProgramming Interface)

2.3.1 Funcionalidad y especificación de las Interfaces deProgramación2.3.2 Interfaces existentes


ÍNDICE1

2. IMPLEMENTACIÓN DE PROTOCOLOS (II)

2.4 Interfaz Sockets de Berkeley2.4.1 Algoritmos de diseño Software Cliente

2.4.1.1 Arquitectura del cliente2.4.1.2 Tipos de clientes (TCP/UDP)

2.4.2 Implementación Software Cliente2.4.2.1 Ejemplos clientes TCP/UDP

2.4.3 Algoritmos de diseño Software Servidor2.4.3.1 Arquitectura del servidor2.4.3.2 Tipos de servidores (TCP/UDP, concurrentes, iterativos)

2.4.4 Implementación Software Servidor2.4.4.1 Servidores Iterativos no Orientados a Conexión (UDP)2.4.4.2 Servidores Iterativos Orientados a Conexión (TCP)2.4.4.3 Servidores Concurrentes orientados a conexión (TCP)2.4.4.4 Servidores Concurrentes. Un solo proceso TCP2.4.4.5 Servidores Multiprotocolo (TCP, UDP)2.4.4.6 Servidores Multiservicio (TCP, UDP)


1

2. IMPLEMENTACIÓN DE PROTOCOLOS (III)2.4.5 Eficiencia y gestión de la concurrencia en servidores

2.4.5.1 Elección entre un modelo iterativo y concurrente2.4.5.2 Nivel de concurrencia2.4.5.3 Concurrencia en función de la demanda2.4.5.4 Coste de la concurrencia

2.4.6 Concurrencia en clientes2.4.6.1 Ventajas de la concurrencia2.4.6.2 Implementaciones con varios procesos2.4.6.3 Implementación con un solo proceso

2.4.7 Procedimientos Remotos2.4.7.1 Servicios Básicos sobre RPC2.4.7.2 Construcción de aplicaciones

ÍNDICE


ÍNDICE

2. IMPLEMENTACIÓN DE PROTOCOLOS (IV)2.5 Interfaz Windows Sockets

2.5.1 Comparación sockets de Berkeley2.5.2 Desarrollo de aplicaciones

2.6 Interfaz sockets en Java2.6.1. Introducción2.6.2. Direcciones de Internet2.6.3. Sockets TCP

2.6.3.1 Sockets para clientes 2.6.3.2 Sockets para servidores 2.6.3.3 Servidores multiusuario 2.6.3.4 Sockets seguros

2.6.4. Datagramas y sockets UDP2.6.5. Sockets multicast2.6.6. Conexiones a URLs2.6.7. Otras alternativas (Java RMI, Java IDL)


BIBLIOGRAFÍA

“USING FORMAL DESCRIPTION TECHIQUES” An Introduction to Estelle, Lotos and SDL. Edited by K.J. Turner. John Wiley &Sons 1993

“INTERNETWORKING WITH TCP/IP. CLIENT-SERVER PROGRAMMING AND APLICATIONS BSD SOCKETS” VERSION VOLUME III. D. Comer, R. Stevens. Prentice Hall. 1993

“UNIX NETWORK PROGRAMMING”. R. Stevens, Prentice Hall. 1998 “INTERNETWORKING WITH TCP/IP VOLUME III: CLIENT-SERVER

PROGRAMMING AND APPLICATIONS”. Window Sockets Version. D. Comer, R. Stevens. Prentice Hall. 1997

NETWORK PROGRAMMING FOR MICROSOFT WINDOWS. Second Edition. Anthony Jones, Jim Ohlund. Microsoft Press

“WINDOWS SOCKETS NETWORK PROGRAMMING”. B. Quin, D. Shute. Addison-Wesley Publishing Company. 1995

“JAVA NETWORK PROGRAMMING”. E. R. Harold. O’Reilly 2000, 2ª Edition

“JAVA SECURITY”. S. Oaks. O’Reilly 2001, 2ª Edition


Especificación sistemas:– Definir un sistema dinámico de forma univoca

Especificar un protocolo de comunicaciones consiste en:

– Especificar un algoritmo distribuido de tiempo real que se desarrolla en un entorno compuesto por varios usuarios que quieren comunicarse entre sí y por unas conexiones a través de las cuales deben de comunicarse las distintas entidades del protocolo.

ESPECIFICACIÓN DE PROTOCOLOS (I)

- ESPECIFICACIÓN FORMAL DE PROTOCOLOS


ESPECIFICACIÓN Y DISEÑO DE PROTOCOLOS (I)

La creciente utilización de sistemas distribuidos hace cada vez más complejos los protocolos de comunicaciones

– Esto plantea nuevas problemas de diseño detrás de los cuales, está casi siempre la necesidad de una especificación precisa del protocolo

Las primeras descripciones de protocolos eran narrativas llevando fácilmente a ambigüedades

Inicialmente no se disponía de herramientas formales de validación, verificación y comprobación de los protocolos especificados y sus implementaciones



ESPECIFICACIÓN Y DISEÑO DE PROTOCOLOS (II)


Hoy en día se entiende que una especificación precisa debe de permitir:

– Verificar si un protocolo cumple el servicio para el que ha sido diseñado

– Validar el funcionamiento del sistema (estados alcanzables, no bloqueos, etc)

– Facilitar al máximo la realización del protocolo de forma ejecutable, para la ó las máquinas en cuestión


Beneficios– Se pueden derivar muchas implementaciones cambiando

pocas líneas en la especificación– Se puede asegurar previamente un comportamiento

correcto del protocolo de acuerdo a las exigencias del cliente.

– Se ahorra tiempo y dinero en la contratación de personal encargado de implementar en lenguaje de alto nivel (pascal, C, etc) si se dispone de una herramienta que me permita la generación de manera automática o semiautomática de código.

– Permite fácilmente generar un nuevo código del protocolo adaptado a los nuevos cambios tecnológicos.

ESPECIFICACIÓN DE PROTOCOLOS (II)



NIVELES DE DESCRIPCIÓNARQUITECTURAS DE COMUNICACIONES (I)

DEFINICIÓN DE LA ARQUITECTURA DEFINICIÓN DE LOS SERVICIOS ESPECIFICACIÓN DE LOS PROTOCOLOS


SERVICIOS SERVICIOS

PROTOCOLOMECANISMOSFUNCIONES

MECANISMOSFUNCIONESA

RQ

UIT

ECTU

RA


RED

TRANSPORTE

FISICO

ENLACE

APLICACIÓN

RED

TRANSPORTE

FISICO

ENLACE

APLICACIÓN

ESPECIFICACIÓN SERVICIOS

ESPECIFICACIÓN PROTOCOLO

DEFINICIÓN ARQUITECTURA

NIVELES DE DESCRIPCIÓNARQUITECTURAS DE COMUNICACIONES (II)


FASES DEL DESARROLLO DE PROTOCOLOS

ESPECIFICACIÓN FORMAL– VALIDACIÓN

» Especificación Completa, Ausencia de Bloqueos, Ausencia de lazos improductivos, Terminación, Todos los estados alcanzables

– VERIFICACIÓN– ANÁLISIS DE PRESTACIONES

IMPLEMENTACIÓN CONFORMIDAD



METODOLOGÍAS DEESPECIFICACIÓN DE PROTOCOLOS

AUTÓMATAS MÁQUINAS DE ESTADOS EXTENDIDAS REDES DE PETRI SDL

– CCITT Recommendation Z.100, Specification and Description Language SDL, AP IX-35 1988

ESTELLE– ISO/DP 9074. A formal Description technique based on an Extended

State Transition model, 1985 LOTOS

– A Formal Description Technique based on the Temporal Ordering of Observational Behaviour. ISO 8807, 1988. Language Of Temporal Ordering Specification

PROLOG


AUTÓMATAS

Un autómata es una quíntupla A = < E,S,Q,f,g > :

QQE:f ×

g E Q S: × →

E : CONJUNTO FINITO DE ENTRADAS

S : CONJUNTO FINITO DE SALIDAS

f : FUNCION DE TRANSICION

Q : CONJUNTO DE ESTADOS

g : FUNCION DE SALIDA


→


DIAGRAMA DE TRANSICIONES(DIAGRAMA DE MOORE)

q1 q2

q3

a / 0

b / 1

b / 0

a / 0

a / 1

b / 0



TABLA DE TRANSICIONES

E a b= ,

Q q q q= 1 2 3, ,

S= 0 1,

a bEQ

q1

q2

q3

q1 / 0 q2 / 1

q3 / 0

q3 / 1 q1 / 0

q2 / 0


{

{

{

}

}

}


PROTOCOLO PARADA-ESPERA

I(0)

I(1)

ACK1

ACK0

V(S) V(R)

0

0

1

0

1

0

I(0)

I(0)

T

x

V(S) V(R)



MÁQUINA DE ESTADOS EXTENDIDA:PROTOCOLO PARADA-ESPERA

DESOCUPADO

ESPERANDOACK

TRAMA I LISTA PARA ENVIAR / ENVIO TRAMA

TRAMA ACKRECIBIDA /PROCESO ACK

EXPIRA T / RETRANS.

TRAMA ACKRECIBIDA /

ERROR

DESOCUPADO

TRAMA I RECIBIDA / MANDAR ACK

EMISOR

RECEPTOR



EXPIRATEMP.

TRAMA ILISTA

TRAMA ACKRECIBIDA

DESOCUPADO

EVENTOESTADO

ACTUALNA TRANS.

TRAMAERROR

0 1 0(0)

ESPERANDOACK

(1)

RETRANS.TRAMA RETARDO PROC. ACK ACCION

ACCION

NUEVO ESTADO

NUEVO ESTADO

EVENTOESTADO

ACTUAL

TRAMA IRECIBIDA

ACCION

NUEVO ESTADO

DESOCUPADO(0)

MANDARACK

1 1 0

0


MÁQUINA DE ESTADOS EXTENDIDA:PROTOCOLO PARADA-ESPERA


REDES DE PETRI (I)

∏ = p p p p Conjunto LUGARESr1 2 3, , , . .∑ = t t t t Conjunto TRANSICIONESs1 2 3, , , . .

F N Función incidencia PROGRESIVA: *∏ × ∑ →

B N Función incidencia REGRESIVA: *∏ × ∑ →

M N MARCAJE INICIAL: *∏ →

LUGARES

TRANSICIONES

FUNCIONES DE INCIDENCIA

REPRESENTACIÓNGRAFICA


{ }

{ }


REDES DE PETRI (II)

.. ..p1 p

2

p3

t 1

t 4

t 2

t 3


∏ = p p p1 2 3, , M p p p0 1 2 33 1 0= ( ), ( ), ( )∑ = t t t t1 2 3 4, , ,

{{

{}}

}


REDES DE PETRI (III)

t 3t 2t 1 t 4

p1

p2

p3

1 0 0 0

0 1 0 0

0 0 1 1

F t 3t 2t 1 t 4

p1

p2

p3

0 0 1 0

2 1 0 0

0 2 0 0

B

p ti i→ t pi i→



REDES DE PETRI: PROTOCOLO PARADA-ESPERA

p3

p2

p1

p 4

p5

1T (ENVIO TRAMA)

T 2 (RECEP.ACK)

3T (REENVIO TRAMA)

EMISOR

p 2 : DATOS NIVEL SUPERIOR

3 : ESPERANDO ACKp

4 : ACK RECIBIDOpp 1 : DESOCUPADO

p 5 :TEMPORIZADOR EXPIRADO



ESTELLE es una técnica de descripción formal para la especificación de sistemas concurrentes distribuidos

Una especificación ESTELLE está orientada a la descripción de un conjunto de máquinas de estado finito que se comunican entre sí y cuyas acciones internar están definidas por sentencias Pascal (con algunas restricciones y extensiones)

ESTELLE:PROTOCOLO PARADA-ESPERA



Módulos o procesos– El comportamiento interno de un módulo está descrito

como una máquina de estados finíta extendida no determinística

– Las transiciones se expresan en forma de sentencias Pascal (con restricciones y extensiones)

– Cada módulo tiene un conjunto de puntos de acceso de entrada/salida llamados puntos de interacción. Estos puntos de interacción se utilizarán para la comunicación entre procesos de distintos módulos

ESTELLE:Elementos de la especificación



Transiciones– La ejecución de una acción está relacionada con el

estado de control del proceso, los valores actuales de las variables de contexto, los mensajes recibidos y encolados de otros procesos y la prioridad asociada a cada transición

– Las transiciones no son determinísticas en el sentido de que en cualquier instante dado puede haber más de una acción que un módulo puede ejecutar

– Cuando se ejecuta una transición un módulo pasa a un nuevo estado se actualizan ciertas variables e incluso se pueden enviar ciertos mensajes por los puntos de interacción definidos




Comunicación entre procesos– Los módulos o procesos definidos en ESTELLE se

comunican intercambiando mensajes o interacciones a través de canales lógicos

– Un proceso puede enviar un mensaje a otro proceso a través de un canal lógico establecido entre dos puntos de interacción.

– Un proceso siempre puede mandar un mensaje o interacción

– Un mensaje recibido por un proceso en un punto de interacción se introducirá en una cola FIFO asociada con ese punto de interacción




Paralelismo y no Determinismo:– La comunicación entre procesos es asíncrona. – Los módulos operan independientemente y se

comunican asíncronamente a través de los canales.– Cada proceso definido en un módulo seleccionará el

conjunto de transiciones o acciones listas para ser ejecutadas.

– Aunque los procesos pueden intercambiar mensajes entre ellos, éstos se ejecutan de manera asíncrona, de modo que sus pasos son completamente independientes uno de otros.





USUARIO_E(UE)

USUARIO_R(UR)

EMISOR(E)

RECEPTOR(R)

MEDIO (M)

U

U

MT

MT

U

U

MR

MR

C1

C2 C4

C3envia(datos)

envia(n,datos)

recibe(datos)

recibe(n,datos)ack(n) ack(n)



CHANNEL C1 (usuario, proveedor);by usuario :

envia (datos:tipo_datos);

CHANNEL C2 (usuario, proveedor);by usuario :

envia (n:sec;datos tipo_datos);by proveedor:

ack (n : sec);

CHANNEL C3 (usuario, proveedor);by proveedor:

recibe (datos : tipo_datos);

CHANNEL C4 (usuario, proveedor);by usuario: ack (n :sec);

by proveedor:recibe (n:sec;:datos : tipo_datos);




MODULE USUARIO_E;ip U : C1(usuario);

MODULE USUARIO_R;ip U : C3(usuario);

MODULE EMISOR;ip U : C1(proveedor);

MT: C2(usuario);

MODULE MEDIO;ip MT: C2(proveedor);

MR: C4(proveedor);

MODULE RECEPTOR;ip U : C3(proveedor);

MR: C4(usuario);

BODY USUARIO_E_BODY FOR USUARIO_E; EXTERNAL;BODY USUARIO_R_BODY FOR USUARIO_R; EXTERNAL;BODY EMISOR_BODY FOR EMISOR; EXTERNAL;BODY RECEPTOR_BODY FOR RECEPTOR; EXTERNAL;BODY MEDIO_BODY FOR MEDIO; EXTERNAL;




MODVAR

E : EMISOR;R : RECEPTOR;UE: USUARIO_E;UR: USUARIO_R;M: MEDIO;

INITIALIZE BEGIN

INIT UE WITH USUARIO_E_BODY;INIT E WITH EMISOR_BODY;INIT M WITH MEDIO_BODY;INIT UR WITH USUARIO_R_BODY;INIT R WITH RECEPTOR_BODY;

CONNECT UE.U TO E.U;CONNECT E.MT TO M.MT;CONNECT UR.U TO R.U;CONNECT R.MR TO M.MR;

END;




CONDICION DE DISPARO– ESTADO ORIGEN (FROM)– ENTRADA (WHEN)– PREDICADO (PROVIDED)– PRIORIDAD (PRIORITY)

ACCIONES– ESTADO DESTINO (TO)– SALIDAS (OUTPUT)

TRANSICIONES ESPONTANEAS– NO TIENEN ENTRADA (WHEN)– PUEDEN TENER LA CLAUSULA DELAY

ESTELLETRANSICIONES



EMISOR_BODY FOR EMISORSTATE desocupado, esperando_ack

INITIALIZE BEGINSTATE TO desocupado;nsec : 0;

END

TRANS WHEN U.envia(datos)FROM desocupado TO esperando_ackBEGIN

buffer :=datos;OUTPUT MT.envia(nsec,buffer);

END




TRANS WHEN MT.ack(n)FROM esperando_ack TO desocupadoPROVIDED n=nsec+1; (MOD2)BEGIN

nsec := nsec+1; (MOD2)END

TRANS FROM esperando_ack TO sameDELAY (timeout)BEGIN

OUTPUT MT.envia(nsec,buffer);END



INGENIERÍA DE PROTOCOLOS DE COMUNICACIONES - IMPLEMENTACIÓN DE PROTOCOLOS- ESPECIFICACIÓN FORMAL DE PROTOCOLOS


RECEPTOR_BODY FOR RECEPTORINITIALIZE BEGIN

nesp=o;ENDWHEN MR.recibe(n,datos)

BEGINIF n<>nesp THEN BEGINOUTPUT MR.ack(nesp+1);ENDIF n=nesp THEN BEGINOUTPUT U.recibe(datos);nesp=nesp+1;OUTPUT MR.ack(nesp);END

END END


ESTELLE:Asentimientos Selectivos

U

U

N

N

USER

RECEIVER

NETWORK

SEND_AK(ak_no) DATA_INDICATION

DATA_INDICATION



RECEIVER_BODY FOR RECEIVERSTATE IDLE, ACK_SENT INITIALIZE BEGIN (* initialization part *)

STATE TO IDLEmin:=1;max:=20;inactive_period:=60;ak_no:=0;

ENDTRANS (* transition part *)

FROM IDLE TO IDLEPRYORITY MEDIUMWHEN N.DATA_INDICATION;{T1} begin

output U. DATA_INDICATION;ak_no:=ak_no+1;

end




TO ACK_SENTPROVIDED (ak_no>0) and (ak_no<=4)

PRYORITY LOWDELAY (min,max){T2} begin

output N. SEND_AK(ak_no);end

PROVIDED (ak_no>4) and (ak_no<7) PRYORITY highDELAY (min){T3} begin


PROVIDED (ak_no=7) PRYORITY high

{T4} beginoutput N. SEND_AK(ak_no);

endPROVIDED (ak_no=0)

PRYORITY lowDELAY (inactive_period){T5} begin





FROM AK_SENT TO IDLE

{T6} beginak_no:=0;

end

end; (* transsition part *)




Inmediatamente después de la inicialización, arranca el temporizador cláusula delay de la transición T5

– Si pasan 60s y no llega ningún mensaje entrante se dispara la transición T5 mandándose un ack artificial para evitar la desconexión

– Si llega un mensaje antes de 60s se dispara la transición T1 y se cancela el temporizador de la transición T5.

» El valor de ack_no = 1» El estado final es IDLE


60s

T5Inicio



Después de llegar el primer mensaje arranca el temporizador de la cláusula delay de la transición t2

– Si los mensajes llegan en cantidades de 1-4 cada 20s. ellos pueden ser reconocidos uno por uno o en bloques de 2-4 mensajes dependiendo de la distribución de mensajes en el tiempo


T1

1s 20s

M1

Inicio Tem. Delay T2




1s 20s

T2M1


M2

T2

1s 20s

M1


M3M2

T2

1s 20s

M1


M4M3M2




T2

1s 20s

M1


M4

T2

1s 20s

M1


M3

M2 M3

M2 M4



Después de llegar el quinto mensaje y no haber sido asentidos los cuatro anteriores

– Se cancela el temporizador asociado al delay de la T2– Arranca arranca el temporizador de la cláusula delay de

la transición T3– Después de 1s se disparará la T3 si no se recibe el

mensaje 7


T3

1s

M5


M1 M2 M3 M4

T3

1s

M5


M1 M2 M3 M4 M6



Después de llegar el séptimo mensaje y no haber sido asentidos los mensaje anteriores

– Se cancela el temporizador asociado al delay de la T3– Se dispara la T4 inmediatamente


Disparo T4

1s

M5M1 M2 M3 M4 M6 M7



Cancela Temp T3



Conclusiones:– Alta carga:

» Llegada de 7 mensajes en menos de 1s: Los asentimientos son enviados en bloques de 7 mensajes

– Carga Media:» Cuando se reciben más de cuatro mensajes en menos de

20s: Se manda un asentimiento conjunto después de un retardo de 1s. desde el quinto mensaje.

– Esto ocurre si no se recibe antes el mensaje 7, en cuyo caso el asentimiento es inmediato

– Carga Baja:» Cuando solo se reciben de 1 a 4 mensajes en 20s se manda

un asentimiento al final de este tiempo (de 1, 2, 3 o 4)– Sin tráfico

» Si no se envía ningún mensaje en el periodo de 60s se envía un ack de mantenimiento de la línea




SDL (Specification and Description Language)introducción

SDL : Leguaje de Especificación y Descripción Basado en autómatas extendidos y comunicación

asíncrona de procesos Normalizado por el CCITT: SDL-72, SDL76, ..SDL-88 /

ITU: SDL-92 Notación textual (SDL/PR) y gráfica (SDL/GR) Aplicación: sistemas distribuidos, de tiempo real,

interactivos, protocolos de comunicaciones– Ejemplo: Estándar IEEE 802.11

Herramientas: Telelogic Tau


SDL: Estructura de una Especificación


System S

Block B2

Process P11 Process P12 Process P13 Process P21 Process P22

Block B1


SDL: Estructura de un Sistema


Block

Block

Channel

Channel Channel

SystemEnviroment


SDL: Estructura del Bloque


Process

Process

Cha

nnel

Signalroute

Block

Cha

nnel

Signalroute

Signalroute


SDL:Proceso: Modelo Básico



SDL: Constructores para la descripción de un Proceso


START STATE INPUT OUTPUT NEXSTATE

S1 S2A B


SDL:Proceso: Estados y Transiciones II



SDL:PROTOCOLO PARADA-ESPERA

TRAMADATOS

DESOCUPADO

TRAMAACK

DESOCUPADO

DATOS NIVELSUPERIOR

ESPERANDOACK

TRAMADATOS

ESPERANDOACK

ESPERANDOACK

ACK(n)

TRAMADATOS

DESOCUPADO

DESOCUPADO

EMISOR RECEPTOR

SET(NOW+13,T)

ESPERANDOACK

nn<>nsec n=nsec

T

SET(NOW+13,T)



TELELOGIC SDL


SDL PROTOCOLO PARADA-ESPERA Descripción Sistema


SDL PROTOCOLO PARADA-ESPERA Descripción Bloques I


SDL PROTOCOLO PARADA-ESPERA Descripción Bloques II


SDL PROTOCOLO PARADA-ESPERA Descripción Procesos I


SDL PROTOCOLO PARADA-ESPERA Descripción Procedimientos


SDL PROTOCOLO PARADA-ESPERA Descripción Procesos II


(o)

(1)

(1)

(o)


En LOTOS Se hace una descripción dinámica del sistema basado en una ordenación de eventos

Los eventos ocurren en puntos de interacción de procesos denominados puertas

Un evento corresponde a la activación de una puerta

El proceso de modelado consiste en:– Seleccionar los aspectos más relevantes del sistema

decidir como trasladarlos a puertas– El comportamiento del sistema es especificado

describiendo todas las posibles secuencias de eventos que el sistema puede ofrecer al entorno

LOTOSINTRODUCCIÓN



LOTOSREPRESENTACIÓN DE EVENTOS Y PUERTAS

a: ?x1:int, ?x2:int, !(3+5), !true, ?x3:bool;

a b

c d

estados

puertas



LOTOSOPERADOR DE ELECCIÓN (CHOICE [ ])

( Net1_in? Datagrama: ip_dtgrm;encamina(Datagrama);.............................

)

[ ]

( Net2_in? Datagrama: ip_dtgrm;encamina(Datagrama);.............................

)

Operador Choice [ ]:



LOTOSSELECCIÓN DE EVENTOS Y OPERADORES DE GUARDA

a ? x:int [x<0];a: ? x:int, !y [x>y]

Net1_in? Datagrama: ip_dtgrm;( ( [ruta(datagrama)=2] ->

Net2_out ! Datagrama;.........)

[ ]( [ruta(datagrama)=3] ->

Net3_out ! Datagrama;..........)

)

Selección de Eventos:

Operadores de Guarda:



LOTOSENTRELAZADO DE PROCESOS

a1 b1 a2 b2| | |

a1b1

a2 b2 a2 b2

a2b2

a1 b1 a1 b1



a b

c d

a f

d| [ a, d ] |

a

c d

f

b

b

f

LOTOSSINCRONIZACIÓN PARCIAL



Las puertas tienen el mismo nombre y e es un valor de tipo t

Las puertas tienen el mismo nombre y los valores s1 y s2 coinciden

Los valores ofrecidos en la puerta son del mismo tipo (t1=t2), pero no están definidos

(En este caso el valor del evento que ocurrirá en el modelo no está definido)

a ? x : t y a ! e

a ! s1 y a ! s2

a ? x : t1 y a ? y : t2

LOTOSSINCRONIZACIÓN DE PUERTAS (I)



Ejemplos:

a: ?x1:int, ?x2:int, !(3+5), !true, ?x3:bool

a: !7, !9, ?y1:int, !true, ?y2:bool

a: !7, !9, ?y1:bool, !true, ?y2:bool

a: !7, !9

LOTOSSINCRONIZACIÓN DE PUERTAS (I)



LOTOSPROTOCOLO PARADA-ESPERA

SPECIFICACION BIT ALTERNANTEbehaviour

( EMISOR [get, tout, send, receive ] (0)| | |RECEPTOR [ give, send, receive] (0)

)

| [ tout, send, receive] |

LINEA [tout, send, receive]

whereprocess EMISOR [get, tout, send, receive ] (0) ( ........... )process RECEPTOR [ give, send, receive] (0) ( ........... )process LINEA [tout, send, receive] ( ........... )

endspec



LOTOSPROTOCOLO PARADA-ESPERA


send !info !seq !data

receive !ack !inc(seq) !empty

exit

tout

receive !info ?rec:SNum?data:BitString

rec<>nesprec=nespsend !ack !inc(nesp)!emptygive !data

send !ack !inc(nesp)!empty

i

send ?f:trame ?seq:SNum ?data:BitString

receive !f !seq!data

tout

EMISORRECEPTOR

LINEA

RECEPTOR (inc(nesp))


EJEMPLO ESPECIFICACIÓN PROTOCOLO RDSI Q.931

RTC

RED DE CONMUTACION DE PAQUETES

TELEX

RED BANDA ANCHA

USUARIOUSUARIO

RDSI USUARIOUSUARIO RDSI



CENTRALLOCALRDSITR 1

TERMINALNO RDSI

AT

....TERMINALRDSI

US/T

RACCESO BÁSICO 2B+D

CENTRALLOCALRDSI

US

TERMINALNO RDSI

AT

....TERMINALRDSI

R...

T

CENTRALITADIGITAL

MULTISERVICIO(NT2)

TR 1

ACCESO PRIMARIO 30B+D

RED DIGITAL SERVICIOS INTEGRADOS



MULTIPLEXACION A NIVEL FISICO:– ACCESO BASICO

» 2B (64Kbps) + D (16Kbps)– ACCESO PRIMARIO

» 30B (64Kbps) + D (64Kbps)

PLANO DE CONTROL: – CANAL D

PLANO DE USUARIO: – CANAL B Y D

El PLANO DE CONTROL estructurado en 3 niveles (alineado con el modelo OSI)

El plano de usuario depende de las aplicaciones




CONTROL DE LLAMADAS POR CANAL COMUN




FISICO

ENLACE

RED

TRANSPORTE

SESION

PRESENTACION

APLICACION

CANAL D CANAL B

CONMUTACIONCIRCUITOS

CONMUTACIONPAQUETES

LINEADEDICADASEÑALIZACION PAQUETES TELEMETRIA

NIVEL 1 (I.430, I.431)

LAP- D LAP-B

X.25NIVEL PAQUETE

X.25NIVEL PAQUETE

SEÑALIZACIONCONTROL(I.451)

SEÑALIZACIONUSUARIOEXT-EXT

ARQUITECTURA DE PROTOCOLOS EN EL INTERFAZ USUARIO-RDSI

FRAME-RELAY




ARQUITECTURA DE COMUNICACIONES RDSI

I.451/ Q.931

LAP-D(I.441)

INTERFAZBASICO(I.430)

INTERFAZPRIMARIO

(I.431)

MENSAJE I.451 / Q.931

MENSAJE I.451 / Q.931CABECERALAPD FIN LAPD



FORMATO DE LOS MENSAJES Q.931

DISCRIMINADOR PROTOCOLO

LONGITUD DELV.R.Ll.

VALOR DE REFERENCIADE LLAMADA

TIPO DE MENSAJE

I

0

0 0 0 0

CONTENIDOSE.I.

IDENTIFICADORE.I.1

IDENTIFICADOR E.I.1

0 IDENTIFICADOR E.I.

LONGITUD E.I.

CONTENIDOS E.I.

ELEMENTOS DE INFORMACION OBLIGATORIOS Y ADICIONALES

R.LLFormato E.I. tipo 1

Formato E.I. tipo 2

Formato E.I. tipo 3



MENSAJES Q.931

ESTABLECIMIENTO, ACUSE ESTABLECIMIENTO, LLAMADA EN CURSO, AVISO, PROGRESO, CONEXION, ACUSE CONEXION

SUSPENSION, ACUSE SUSPENSION, RECHAZO SUSPENSION, REANUDACION, ACUSE REANUDACION, RECHAZO, REANUDACIONINFORMACION USUARIO

DESCONEXION, LIBERACION, LIBERACION COMPLETADA

INFORMACION, ESTADO, CONSULTA DE ESTADO, NOTIFICACION, CONTROL DE LA CONGESTION

MENSAJESESTABLECIMIENTO

MENSAJESLIBERACION

MENSAJESFASE

INFORMACION

MENSAJESDIVERSOS



PROCEDIMIENTOSLLAMADA Q.931

DATOS

ESTABLECIMIENTO

LLAMADA EN CURSO

AVISO

CONEXION

ACUSE CONEXION

DESCONEXIONDESCONEXION

ESTABLECIMIENTO

AVISO

CONEXIONACUSE CONEXION

LIBERACION COMPLETA

LIBERACIONLIBERACION

LIBERACION COMPLETA



Diagrama de transición de estadospara el establecimiento de la llamadaQ.931 por Conmutación de Circuitos



Diagrama de transición de estadospara la finalización de la llamada

Q.931 por Conmutación de Circuitos



EJEMPLO ESPECIFICACIÓN PROTOCOLORDSI Q.931 CON SERVICIOS DE SEGURIDAD

USUARIO A

USUARIO B

AUTORIDADCERTIFICACIÓN

M. INFORMACIÓN USUARIO (Mensaje 1)

M. INFORMACIÓN USUARIO (Mensaje 2)

M. ESTABLECIMIENTO (Mensaje 3)

M. AVISO (Mensaje 4)




[ ]( );,,(,,,,Re::1 1NAKencryptKencryptBAqCA SAPC→

[ ]( ) [ ]( ) ( );,,,,,,,,,::2 2NKencryptTKBKencryptTKAKencryptAC PAPBSCPASC→

[ ]( ) [ ]( );,,,(,,,,,::3 3NTSKKencryptKencryptTKAKencryptBA SAPBPASC→

( );,::4 4NSKencryptAB →

INTERCAMBIOS DEL PROTOCOLO DE SEGURIDADINCORPORADO EN EL CANAL D DE LA RDSI




behaviour

(ISDN_USER[isdn, user, scontrol_call,choice_random,timeout] (userA)|||ISDN_USER[isdn, user, scontrol_call,choice_random,timeout] (userB)|||CERTIFICATION_AUTHORITY[isdn, user,t imeout](guide) )

|[isdn, timeout]|

NETWORKING_SERVICE[isdn, control_isdn, timeout]

where

...........................................



EJEMPLO ESPECIFICACIÓN LOTOS PROTOCOLORDSI Q.931 CON SERVICIOS DE SEGURIDAD

isdn ! setup_security_message ! own_name ? call_refd : call_reference_value ? one_setup: setup_security;

.user ! initiate ! own_name ? tpname, peer_name :

user_name;

SECURITY_SERVICE_PHASE_1[isdn, user,scontrol_call,choice_random, timeout ] (own_name, tpname, peer_name)

SECURITY_SERVICE_RESPOND[isdn, user] (own_name, call_refd,one_setup)

ISDN_USER [isdn,user,scontrol_call,choice_random,timeout] (own_name : user_name) : noexit :=



SECURITY_SERVICE_PHASE_1 [isdn,user,scontrol_call,timeout](own_name, guide, peer_name : user_name): exit :=.scontrol_call ? call_refs: -

isdn !setup !m_setup(----)

isdn !call_proc !own_name !call_refs ?one-call_proc

isdn ! alerting !own_name !call_refs ?one_alerting

isdn ! connect!own_name !call_refs ?one_connect

isdn ! ui ! m_ui(----)

.

.

..

..

isdn ! ui !own_name !call_refs ?one_ui

SECURITY_SERVICE_PHASE_2[isdn,user,scontrol_call](own_name, peer_name, cp) ) ) ))

i

i

timeout

CLEAR_USER1[isdn] (own_name, call_refs)

isdn !release_complete !own_name !call_refs ?one_release_complete;

exit

.exit

user ! guide_service_down; exit

M1->

<-M2



SECURITY_SERVICE_PHASE_2 [ isdn, user, scontrol_call,timeout] (own_name, peer_name : user_name, cp: public_key) : exit :=

scontrol_call ? call_refs: -

isdn ! setup_security !m_setup(----)

isdn !call_proc !own_name !call_refs ?one-call_proc

isdn ! alerting_security !own_name !call_refs ?one_alerting

user ! authentication _service_comptete !own_name ;exit

.

.

.isdn !release_complete !own_name !call_refs ?one_release_complete;

exit

.

.

user !authentication_service_rejected !own_name ;exit

timeout

M3->

<-M4



CERTIFICATION_AUTHORITY [isdn,user,timeout] (own_name : user_name) : exit :=

isdn ! setup !own_name ? call_refd ?one_setup

isdn ! alerting !m_alerting(---)

isdn ! connect !m_conect(---)

..

isdn !release_complete !m_release_complete(---)

.

isdn ! ui !own_name ! call_refd ?one_ui

.isdn ! ui !m_ui(---) .

CLEAR_USER2[isdn] (own_name, call_refs)

exit

(guide_service_accepted/guide_service_rejected)

exit

M1->

<-M2



SECURITY_SERVICES_RESPOND [isdn, user] (own_name : user_name,call_refd : call_reference_value, one_setup : setup_security) : exit :=

isdn ! setup_security !own_name ? call_refd ?one_setup

isdn ! alerting_security !m_alerting(---)

..

isdn !release_complete !m_release_complete(---)

..

.

* setup_acepted

user ! authentication _service_accepted!own_name

exit

user ! authentication _service_rejected!own_name

isdn ! alerting !m_alerting(---)

.exit exit



1

NETWORKING_SERVICE[isdn, scontrol_call] : noexit :=

isdn ! setup ?one_setup: setup

.

.

.scontrol_call ? call_refd

.isdn ! setup !destination !call_refd !one_setup

isdn ! call_proc !source !call_refs ! m_call_proc(---)

isdn ! alerting ? one_alerting[ call_refd == get_cr(one_alerting)]

i

CLEAR_1[isdn] (source, call_refs, destination, call_refd)

(I)

isdn ! setup_security ?one_setup: setup_security

scontrol_call ? call_refd

isdn ! setup_security !destination !call_refd !one_setup_security

isdn ! call_proc !source !call_refs ! m_call_proc(---)

..

..

.exit

.isdn ! alerting_security ? one_alerting

[call_refd == get_cr (one_alerting)]

isdn ! alerting _security !source !call_refs ! one_alerting_security

timeout timeout



1

isdn ! alerting !source !call_refs ! one_alerting.

isdn ! connect ! source !call_refs !one_connect

isdn ! connect ? one_connect[call_refd == get_call_ref(one_connect)]

i

(II)

NETWORK_SERVICE[isdn] (user)..

DATA_TRANSMISION[isdn] (source, call_refs, destination, call_refd)

NETWORKING_SERVICE[isdn, scontrol_call] : noexit :=



PROLOG:Introducción

PROLOG es un lenguaje de programación desarrollado para representar y utilizar el conocimiento que se tiene sobre un determinado dominio.

Un dominio es un conjunto de objetos y el conocimiento sobre ese dominio se representa por un conjunto de relaciones o reglas que describen las propiedades de los objetos y sus interacciones.

Un programa PROLOG no es más que un conjunto de reglas que describen las propiedades e interacciones entre los objetos.

Un programa PROLOG consta de tres elementos básicos:

• Declaración de hechos (“facts”) acerca de los objetos y sus relaciones.

• Definición de reglas (“rules”) hechos que dependen de otros hechos

• Preguntas (“questions”) acerca de hechos



PROLOG:Hechos “facts”

Los “hechos” no es más que el conocimiento que se tiene de los objetos y sus relaciones.

En PROLOG una colección de “hechos” que son utilizadas para resolver un problema particular se denomina “Base de Conocimiento”.

conoce(juan, parís).

Predicado(nombre de la relación)

Argumentos (nombres de los objetos)

Hecho: “Juan conoce París”



PROLOG:Consultas, Objetivos

Una vez que tenemos algunos hechos, podemos formular algunas preguntas acerca de ellos

Cuando se hace una pregunta el intérprete PROLOGbuscará si dicho hecho coincide con alguno otro existente en su Base de Conocimiento.

Estos dos hechos coincidirán si sus predicados son los mismos y los argumentos coinciden y están en la misma posición.

Para el intérprete PROLOG una consulta implica satisfacer el objetivo expresado.

Si el intérprete PROLOG encuentra un hecho que coincide con el hecho definido en la interrogación responderá afirmativamente.

?- conoce(juan, parís).



PROLOG:Variables

En PROLOG no sólo se pueden utilizar nombres para denominar a objetos concretos sino que también se puede utilizar nombres para denominar a objetos todavía no determinados. Los nombres de este segundo tipo se denominan variables

Cuando PROLOG utiliza una variable, dicha variable puede estar o no instanciada:

– Una variable está instanciada cuando hay un valor particular asociado a dicha variable.

– Una variable no está instanciada cuando todavía no hay un valor particular asociado a dicha variable.

PROLOG distingue las variables de los nombres de objetos concretos debido a que las variables comienzan con una letra mayúscula

Cuando se realiza una pregunta a un intérprete PROLOGconteniendo una variable, éste explora todos los hechos de su Base de Conocimiento con el fin de encontrar un objeto para el que se pueda asociar a dicha variable.



PROLOG:Variables

X=paris;X=estocolmo;X=oslo;

?- conoce(juan, X).

conoce(juan, parís).conoce(juan, estocolmo).conoce(juan, oslo).

Base de Conocimiento

Consulta

Resultado



?-conoce(juan,X) , conoce(maria,X).

conoce(juan,oslo).conoce(juan,paris).conoce(juan,londres).conoce(maria,paris).

?-conoce(juan,X) , conoce(maria,X).


•Primer objetivo satisfecho. Se asigna “X”=oslo.•Prolog marca el punto de la BD en el que se satisface el objetivo.•Se intenta satisfacer el segundo objetivo para ese valor de “X”.

• El segundo objetivo falla• Se intenta re-satisfacer el primer objetivo asignando un nuevo

valor a “X” a partir del punto marcado en la exploración anterior.

PROLOG:Conjunciones (mecanismo de Backtracking)



PROLOG:Conjunciones (mecanismo de Backtracking)

?-conoce(juan,X), conoce(maria,X).


?-conoce(juan,X), conoce(maria,X).


Primer objetivo satisfecho de nuevo. Se asigna “X”=paris Prolog marca el punto de la B.D. en el que se satisface el objetivoSe intenta satisfacer el segundo objetivo para ese valor de “X”.

El segundo objetivo tiene éxito.El intérprete Prolog informa de ello, y queda a la espera de realizar una nueva exploración



PROLOG:Reglas

En PROLOG se utilizan reglas cuando es necesario expresar hechos que dependen de uno u otros hechos.

En PROLOG una regla consta de una cabeceray un cuerpo. La cabecera y el cuerpo están conectadas por el símbolo “:-”.

– La cabecera de la regla define el hecho que dicha regla intenta definir.

– El cuerpo define una conjunción de objetivos que deben de ser satisfechos uno por uno para que la cabecera tenga éxito.

hermana_de(X,Y):=mujer(X), padres(X,P,M), padres(Y,P,M).

Hecho: “X es hermana de Y si X es mujer y X e Y tienen los mismos padres”



PROLOG:Análisis de la vulnerabilidad de Protocolos de Seguridad

Se puede utilizar PROLOG para analizar la vulnerabilidad de un protocolo de seguridad

– A partir de la definición (o especificación) de un protocolo de seguridad se puede representar su comportamiento con un conjunto de reglas PROLOG

– A partir del conocimiento de alguna información relativa a los contenidos del P.S. (grabada por un intruso) y de las reglas que definen el comportamiento del protocolo se puede analizar su vulnerabilidad



[ ]{ }[ ][ ]datEAB

AKEBA

AKEKEAC

BECA

s

b

ba

a

K

SK

SKSK

K

::4

::3

,::2

);(::1

→

→

→

→

C

A B

(2)

(3)

(4)

(1)

•C y A comparte una clave Ka•C y B comparte una clave Kb

* Protocolo de Needham Schroeder

EJEMPLO ESPECIFICACIÓN PROTOCOLO- ESPECIFICACIÓN FORMAL DE PROTOCOLOS


PROTOCOL SPECIFICATIONCONSTANTSa,b,x,c:address;dat,req,ok:data;ksa,ksb,kx,ks:key;n1,n2:int;t1,t2:ctime.MESSAGES1:a->c:encrypt(KSA,B);2:C->A:encrypt(KSA,[KS,encrypt(KSB,[KS,A])]);3:A->b:encrypt(KSB,[KS,a]);4:B->A:encrypt(KS,dat).RELATIONS1:secret_key(a,KSA:a);2:secret_key(B,KSB:C),secret_key(A,KSA:C),sesion_key(KS:C).RULESsecret_key(a,ksa:a,c),secret_key(b,ksb:b,c),secret_key(x,kx:x,c);sesion_key(ks:c).KNOWSkx,encrypt(ksa,x).

PROLOG:Especificación Protocolos de Seguridad (P.S.)



sent([a,c,encrypt(KSA,B)],[],1):-secret_key(a,KSA,a).

derives([a,c,encrypt(KSA,B)],[C,A,encrypt(KSA,[KS,encrypt(KSB,[KS,A])])],2,MH):-secret_key(B,KSB,C),secret_key(A,KSA,C),sesion_key(KS,C).

derives([C,A,encrypt(KSA,[KS,encrypt(KSB,[KS,A])])],[A,b,encrypt(KSB,[KS,a])],3,MH).

derives([A,b,encrypt(KSB,[KS,a])],[B,A,encrypt(KS,dat)],4,MH).

PROLOG:Traducción P.S. a un conjunto de reglas Prolog

REGLAS DE DERIVACIÓN DE MENSAJES



sent(Ms,[Mr|H],N):- R is N-1,R>0,received(Mr,H,R),derives(Mr,Ms,N,H).

received(Mr,[Ms|PH],N):-sent(Ms,PH,N),p_modified(Mr,Ms,PH,N).

p_modified([],[],_,_).p_modified([X|Mr],[Y|Ms],H,N):- isomorphic(X,Y),

p_knows_initially(X), p_modified(Mr,Ms,H,N).

p_modified([Y|Mr],[Y|Ms],H,N):- p_modified(Mr,Ms,H,N).

p_knows_initially(kx).p_knows_initially(encrypt(ksa,x)).

PROLOG:Traducción P.S a un conjunto de reglas Prolog

REGLAS ASOCIADAS A LA EMISIÓN / RECEPCIÓN DE MENSAJES Y A LAMODIFICACIÓN DE LOS MISMOS



p_knows(X,H,0):-p_knows_initially(X).

p_knows(X,H,N):- N>0,R is N-1, p_knows(X,H,R).

p_knows(X,[M|PH],N):- N>0, sent(M,PH,N), p_gets(X,M,PH,PH,N).


REGLAS ASOCIADAS AL ESTUDIO DE LA VULNERABILIDAD DE UN PROTOCOLO DE SEGURIDAD (I)



p_gets(X,M,PH,H,N):-member(X,M).

p_gets(X,M,PH,H,N):-encrypt_field0(encrypt(K0,W)),member(encrypt(K0,W),M),p_knows_ph1(K0,PH,H,N),member(X,W).

p_gets(X,M,PH,H,N):-encrypt_field1(encrypt(K0,[V,encrypt(K1,W)])),member(encrypt(K0,[V,encrypt(K1,W)]),M),p_knows_ph1(K0,PH,H,N),p_knows_ph1(K1,PH,H,N),member(X,W).

member(X,X).member(X,[X|_]).member(X,[_|Y]):-member(X,Y).


REGLAS ASOCIADAS AL ESTUDIO DE LA VULNERABILIDAD DE UN PROTOCOLO DE SEGURIDAD (II)



PROLOG:Análisis vulnerabilidad del P.S.

?- sent(M,H,1).

M = [a,c,encrypt(ksa,b)] H = [] ->

?- sent(M,H,2).

M = [c,a,encrypt(ksa,encrypt(kx,[ks,a]))] H = [[a,c,encrypt(ksa,x)],[a,c,encrypt(ksa,b)]] ->;

M = [c,a,encrypt(ksa,encrypt(ksb,[ks,a]))] H = [[a,c,encrypt(ksa,b)],[a,c,encrypt(ksa,b)]] ->;

?- sent(M,H,3).

M = [a,b,encrypt(kx,[ks,a])] H = [[c,a,encrypt(ksa,encrypt(kx,[ks,a]))],[c,a,encrypt(ksa,encrypt(kx,[ks,a]) )],[a,c,encrypt(ksa,x)],[a,c,encrypt(ksa,b)]] ->;

M = [a,b,encrypt(ksb,[ks,a])] H = [[c,a,encrypt(ksa,encrypt(ksb,[ks,a]))],[c,a,encrypt(ksa,encrypt(ksb,[ks,a]))],[a,c,encrypt(ksa,b)],[a,c,encrypt(ksa,b)]] ->;

Reconsulting ... ?- p_knows(ks,H,3).

H= [[a,b,encrypt(kx,[ks,a])],[c,a,encrypt(ksa,encrypt(kx,[ks,a]))],[c,a,encrypt(ksa,encrypt(kx,[ks,a]))],[a,c,encrypt(ksa,x)],[a,c,encrypt(ksa,b)]] ->



PROGRAM emisor

TYPEeventos=(trama_i_lista, trama_ack_recibida, expira_tem)estados=(desocupado, esperando_ack) acciones=(na, trans_trama, error, retrans_trama, retardo, proc_ack)

VARtabla_eventos_estados=array[estados,eventos] of

recordaccion: accionesnuevoestado: estados

endestado_actual: estadostipo_evento: eventosNseq: Numsecuencia

IMPLEMENTACIÓNPROTOCOLO PARADA-ESPERA



PROCEDURE inicializar{ Inicializa las variables de estado y los conteniods de la tabla_eventos_estados}

PROCEDURE transmitir_trama{Construcción de la trama (inserción de número de secuencia y datosde nivel superior). Pone la trama en linea. Salva la trama en un buffer.Activa el temporizador.}

PROCEDURE retransmitir_trama{Recupera trama de buffer. Pone la trama en línea. Activa temporizador}

PROCEDURE proceso_ack{Si ack es correcto : Borrar trama del buffer. Incrementar nº de secuencia}

PROCEDURE retardo{Retarda un corto intervalo de tiempo}




PROCEDURE Error { Situación error}

BEGINInicializar;REPEAT esperar a que se produzca un evento

tipo_evento:= eventoWITH tabla_estados_eventos[estado_actual, tipo_evento] DOBEGIN

CASE accion of ¨{acciones}trans_trama: transmitir_tramaretrans_trama: retransmitir_tramapro_ack: proceso_ackretardo: retardoerrror: error

ENDestado actual: nuevo

ENDUNTIL foreverEND




PROCEDURE receptorVAR

nesp

BEGIN Inicializar nespREPEAT esperar a una trama I

IF nseq de la trama= nesp THENBEGIN

incrementar nespmandar ack(nesp)

ENDif nseq de la trama<>nesp THEN

mandar ack(nesp)UNTIL forever

END



INGENIERÍA DE PROTOCOLOS DE COMUNICACIONES (MÓDULO...

Documents

Transcript of INGENIERÍA DE PROTOCOLOS DE COMUNICACIONES (MÓDULO...