Desarrollo Protocolos

Joaqun Luque Rodrguez
Ana Vernica Medina Rodrguez
DESARROLLO DE
PROTOCOLOS
UNIVERSIDAD DE SEVILLA
DEPARTAMENTO DE TECNOLOGA ELECTRNICA
Joaqun Luque Rodrguez

Ana Vernica Medina Rodrguez
DESARROLLO DE
PROTOCOLOS
Universidad de Sevilla
Departamento de Tecnologa Electrnica
Servicio de Publicaciones
Sevilla, 1994
* Facultad de Informtica y Estadstica
Avenida Reina Mercedes s/n
41012-Sevilla. SPAIN.
( 455 27 86
DESARROLLO DE PROTOCOLOS
Pgina 1
1.- Conceptos de Ingeniera de Protocolos.
Se
denomina
actividades
Ingeniera
que,
de
partiendo
Protocolos
al
de
requisitos
unos
conjunto
de
de
comunicacin de un sistema informtico, es capaz de generar

un
protocolo
de
comunicaciones
requisitos
establecidos
(fig.
1).
Las
lugar
dentro
ejecutable
que
de
una
manera
actividades
ms
significativas
de
la
Ingeniera
de
fiable
cumple
y
eficiente
que
Protocolos
los
tienen
son
las
siguientes (fig. 2):
Figura 1.- Contexto de la Ingeniera de Protocolos
a) Sntesis. Partiendo de la descripcin informal de

los
requisitos
de
comunicaciones
genera
una
especificacin del protocolo. La especificacin de un

protocolo comprende 5 partes distintas:
- Los servicios proporcionados por el protocolo;
- Las suposiciones sobre el entorno en el cual se
va a ejecutar el protocolo;
Pgina 2
Figura 2.- La Ingeniera de Protocolos
El
vocabulario
de
mensajes
usados
por
el
mensajes
del
protocolo;
-
El
formato
de
cada
uno
de
los
vocabulario;
- Las reglas de procedimiento que garantizan la
consistencia del intercambio de mensajes; y
Pgina 3
Cada una de estas partes de la especificacin debe ser

descrita con la menor ambigedad posible, recurriendo,
cuando sea posible, a tcnicas de descripcin formal de
protocolos (FDTs: Formal Description Techniques), entre
las que se pueden destacar:
- Mquinas de estados finitos (FSM: Finite State
Machines).
- Mquinas de estados finitos extendidas (EFSM:
Extended Finite State Machines).
- Redes de Petri.
- Lgica temporal.
- Lenguajes de programacin.
-
Lenguajes
de
especificacin.
Entre
estos
destacan los siguientes lenguajes normalizados:

- Estelle (ISO), basado en EFSM.
- LOTOS (ISO), basado en lgica temporal.
- SDL (CCITT), basado en EFSM.
-
ASN.1
(ISO
CCITT)
para
descripcin
de
PDUs.
b) Validacin. Esta actividad se propone descubrir los
errores de autoconsistencia lgica que pudiese tener la
especificacin, en un esfuerzo por encontrar aquellos
errores que pueden existir en cualquier protocolo, con
independencia
de
la
funcin
especfica
que
realice.
Entre estos errores destacan:

- Bloqueos (deadlocks): el protocolo llega a un
estado del que no puede salir.
-
Crculos
ejecuta
Pgina 4
viciosos
(livelocks):
indefinidamente
una
el
protocolo
secuencia
de
pasos
repetitiva sin realizar ningn progreso efectivo.

- Diseo incompleto: no se especifican respuestas
para todos los sucesos posibles en cada estado.
c)
Verificacin.
protocolo
Es
la
especificado
tarea
de
comprobar
realiza
que
correctamente
el
las
funciones para las que fue diseado, y esto no slo en

condiciones normales, sino tambin ante la presencia de
cualquier
combinacin
de
fallos.
En
la
prctica
la
diferencia entre la validacin y la verificacin no es

siempre clara, por lo que a veces se engloban como una
sola actividad.
d)
Anlisis
de
prestaciones.
El
objetivo
de
la
Ingeniera de Protocolos no es slo obtener protocolos,

sino hacer que stos sean los ms eficientes que sea
posible. Para ello la especificacin es analizada desde
este
punto
de
vista,
midiendo
parmetros
tales
como
eficiencia, retardo, longitud de colas y otros, para

sugerir
modificaciones
en
la
especificacin
que
optimicen las prestaciones.

e) Implementacin. Una vez obtenida una especificacin
fiable y eficaz del protocolo, y a partir de ella, se
procede a la construccin de un protocolo ejecutable.
Son numerosas las cuestiones y criterios que habr que
tener en cuenta en esta fase, las cuales sern objeto
de desarrollo en posteriores apartados.
Pgina 5
f) Generacin de pruebas. Aunque la especificacin haya

sido depurada y sea fiable y eficiente, el complejo
problema de la implementacin puede introducir de nuevo
errores
ineficacias
en
el
producto
final.
Esta
actividad se encarga de generar la batera de pruebas a

las
que
Existen
deber
someterse
diversas
tcnicas
el
protocolo
para
ello
ejecutable.
incluso
un
lenguaje de especificacin de las pruebas normalizado

por
ISO
con
el
nombre
de
TTCN
(Tree
and
Tabular
Combined Notation).
g)
Pruebas.
El
protocolo
ejecutable,
antes
de
su
aprobacin definitiva, debe ser probado con respecto a

dos criterios:
- Pruebas de homologacin (conformance testing):
el protocolo ejecutable es una implementacin fiel
de la especificacin y cumple las funciones que en
ella se expresan.
- Pruebas de prestaciones: el protocolo ejecutable
tiene
unas
prestaciones
adecuadas
(tiempos
de
respuesta, capacidad de trfico, etc.).
Los
principios
discutidos
anteriormente
pueden
formularse en las siguientes diez reglas bsicas para el

desarrollo de protocolos [HOL 91]:
1.-
Asegrese de que el problema est bien definido. Todos

los criterios de diseo, requisitos y restricciones,
deben ser formulados antes de comenzar el desarrollo.
2.-
Pgina 6
Defina los servicios que deben realizarse en cada nivel

o
mdulo
de
estructuras
abstraccin
se
usarn
antes
para
de
llevar
decidir
a
cabo
que
estos
servicios (el qu viene antes que el cmo).

3.-
Disee la funcionalidad externa de cada nivel o mdulo

antes que el comportamiento interno. Considere primero
la solucin cmo una caja negra y decida como debe
interaccionar con su entorno. Una vez hecho esto puede
ya
decidir
negra.
como
se
Probablemente
organiza
internamente
consistir
en
cada
cajas
negras
caja
ms
pequeas que pueden ser tratadas de forma similar.

4.-
Mantenga la simplicidad. Los protocolos rebuscados son

ms propensos a contener errores que los simples; son
ms
difciles
de
implementar,
ms
difciles
de
verificar, y normalmente menos eficientes. Existen muy

pocos problemas realmente complejos en el desarrollo de
protocolos. Los problemas que parecen complejos son con
frecuencia problemas simples entrelazados. La tarea del
ingeniero
problemas
de
protocolos
ms
simples,
consiste
en
separarlos,
identificar
y
los
resolverlos
individualmente.
5.-
No mezcle cuestiones que son independientes.
6.-
No
introduzca
desarrollo
debe
restricciones
ser
innecesarias.
fcilmente
extensible.
Un
buen
Un
buen
desarrollo resuelve una clase de problemas y no tan

slo un problema aislado.
7.-
Antes de implementar el protocolo, valide y verifique
Pgina 7
el protocolo, y analice sus prestaciones, comprobando

que se cumplen los requisitos impuestos.
8.-
Implemente el protocolo.
9.-
Realice las pruebas de homologacin y prestaciones de

la implementacin obtenida.
10.- No se salte las reglas 1 a 7.

La regla que se incumple con ms frecuencia es claramente la
regla nmero 10.
2.- El problema de la implementacin.
El
problema
de
la
implementacin
de
un
protocolo,
superada ya la fase de especificacin del mismo, presenta

interesantes
cuestiones
principalmente
ejecutable
tres
que
vas
partir
de
conviene
para
una
abordar.
obtener
un
especificacin:
Existen
protocolo
automtica,
semiautomtica o manual (fig. 3). Por la va automtica la

especificacin, que debe haber sido descrita completamente
mediante FDTs, se somete a un compilador del lenguaje en el
que
est
descrita
la
especificacin,
el
cual
genera
el
protocolo ejecutable requerido. En el procedimiento manual

existen tres fases:
a)
En
primer
estrategias
lugar
para
se
establecen
implementar
los
criterios
correctamente
los
protocolos.
b)
continuacin
se
realiza
un
diseo
informtico
fruto del cual se obtiene un documento de diseo.
Pgina 8
c) Por ltimo se procede a codificar el diseo anterior

en algn lenguaje de programacin convencional del que
se deriva el protocolo ejecutable.
Figura 3.- La implementacin de protocolos
El procedimiento semiautomtico es una mezcla de los

dos anteriores. En efecto, parte de una especificacin del
protocolo descrita mediante una FDT para la cual se dispone
de un compilador adecuado. Sin embargo, si la especificacin
original no es completa (por ejemplo no incluye la gestin
de memoria, la interfaz con mdulos externos, etc.) ser
necesario completarla de forma manual, siguiendo para ello
los tres pasos anteriores: definicin de criterios, diseo
Pgina 9
informtico y codificacin. El resultado puede ser bien una

modificacin de la especificacin original para completarla,
o bien la elaboracin de mdulos ejecutables que en unin de
los
obtenidos
automticamente
forman
el
conjunto
del
protocolo ejecutable.
Cualquiera que sea el mtodo empleado la construccin

de
un
protocolo
pasa
necesariamente
por
una
fase
de
definicin de criterios de implementacin, aunque segn el

grado de automatizacin del proceso, estos criterios estarn
subsumidos en mayor o menor medida dentro de la herramienta
de generacin. Conviene pues centrarse en tales criterios,
entre los cuales destacan los siguientes (fig. 4):
- Representacin de arquitecturas multicapa.
- Representacin de mquinas de estados.
- Representacin de multiplicidad de mquinas iguales
del mismo nivel.
- Tratamiento de cabeceras y colas.
- Relacin entre SDUs y PDUs.
- Gestin de memoria.
- Manejo del hardware de comunicaciones.
- Interfaz con mdulos externos.
Cada uno de estos aspectos merece un estudio detenido

que se aborda en los prximos apartados.
Pgina 10
Figura 4.- Definicin de criterios de implementacin
Representacin de
capas
Una capa por

proceso
Pgina 11
Claridad conceptual
Fcil mantenimiento/sustitucin
Facilidad de pruebas
Varias capas
en un proceso
nico
Utilizacin de cdigo comn
Ocupa menos espacio

Ms rpido
Mayor transparencia
Representacin de
procesos
Tareas
Mayor claridad conceptual

Fcil mantenimiento/sustitucin
Facilidad de prueba
Inconvenientes
Sistema Operativo multitarea obligatorio

Mayor espacio
Elevado nmero de cambios de contexto
Prdida de control de ejecucin
Mdulos
Obligatoria en Sistemas Operativos monotarea

Necesita sistema de gestin de mdulos
Mayor rapidez (no hay cambios de contexto)
Menor espacio
Mejor control de ejecucin
Comunicacin entre
capas
Asncrona
Monocola
Ahorra espacio
Centraliza funciones de gestin de colas
Lgica de gestin ms compleja
Multicola
Dificultades
Control de flujo.
Soluciones:
Colas de tamao fijo

Primitivas de control de
flujo
Asig. de memor.
controlada
Ejec. atmica.
Solucin:
Asig. de prioridades a
los eventos
Transferencia de control con el IDU

Sncrona
Ventajas
Elimina el problema del control de flujo

Elimina el problema de la ejecucin atmica
Inconvenientes
Dificultades de coordinacin
Limita el paralelismo
Eleva el nmero de cambios de contexto.
Tabla 1.- Representacin de arquitecturas multicapa
Pgina 12
2.1.- Representacin de arquitecturas multicapa.
Cuando se aborda el problema de implementar protocolos

que
comprenden
ms
de
una
capa
del
modelo
OSI
hay
que
fijarse principalmente en 3 aspectos (tabla 1): a) forma de

representacin de las capas; b) forma de representacin de
los procesos; y c) forma de comunicacin entre capas.
a) Representacin de las capas. A este respecto caben dos

soluciones. La primera de ellas propugna que cada capa sea
representada mediante un proceso (fig. 5a), tenga ste la
forma informtica que tenga (mdulo, tarea). Este enfoque
proporciona
una
gran
claridad
conceptual,
facilita
el
mantenimiento y/o la sustitucin de la capa y se adapta

perfectamente a las tcnicas de prueba de la capa. Por otra
parte,
cabe
que
varias
capas
sean
agrupadas
en
un
slo
proceso (fig. 5b), optimizando espacio, tiempo de ejecucin,

posibilitando la utilizacin de cdigo comn, y haciendo ms
transparente
al
usuario
la
constitucin
interna
del
protocolo. Sin embargo con esta solucin es ms difcil la

sustitucin y la prueba de una capa aislada.
Pgina 13
Figura 5.a.- Una capa por proceso
b)
Representacin
de
los
Figura
proceso
5.b.-
procesos.
El
Varias
trmino
capas
por
proceso
utilizado hasta ahora para representar una o varias capas es

deliberadamente
ambiguo.
Su
concrecin
informtica
puede
tomar dos formas: tarea o mdulo. Entendemos por tarea una

unidad de programacin que el sistema operativo considera
como un ente autnomo para la ejecucin y que, por tanto,
constituye
la
unidad
elemental
en
la
planificacin
de
actividades del sistema. Un mdulo es un subconjunto de una

tarea y no puede ser ejecutado autnomamente por el sistema
operativo. Si se opta por representar cada proceso mediante
una
tarea
(fig.
6a)
se
obtienen
unos
lmites
claros
definidos, con lo que ello repercute en cuanto a claridad

conceptual, facilidad de mantenimiento y/o sustitucin, y
posibilidades de prueba. Sin embargo esta solucin presenta
algunos inconvenientes entre los que cabe destacar:
Figura 6.a.- Un proceso por tarea
Figura 6.b.- Varios procesos por tarea
Pgina 14
Pgina 15
- Slo puede utilizarse cuando el sistema operativo es

multitarea.
- Mayor ocupacin en memoria debido a que normalmente
cada tarea incorpora una determinada cantidad de cdigo
de tamao ms o menos fijo para su interfaz con el
exterior.
- Fuerte sobrecarga del sistema ya que en un protocolo
es corriente que el control de la ejecucin tenga que
estar
contnuamente
transfirindose
de
un
proceso
otro, por lo que, en esta solucin, se transferira el

control de una tarea a otra. El proceso de cambio de
tarea,
denominado
contexto),
"context
switching"
una
de
involucra
serie
(cambio
operaciones
de
del
sistema operativo que consumen considerables recursos

del sistema si se realizan con frecuencia.
- Hay una cierta prdida de control de la ejecucin de
los procesos. En efecto, los criterios por los cuales
el
sistema
operativo
transfiere
control
una
tarea
(proceso) est normalmente marcado por rgidas normas

que, en el mejor de los casos, permiten algn tipo de
parametrizacin (prioridad, porcin de tiempo de CPU,
etc.). Sin embargo, la eleccin de un adecuado conjunto
de parmetros de ejecucin es una tarea delicada que
adems slo permite un control muy reducido sobre los
procesos.
Pgina 16
La otra posibilidad consiste en identificar cada uno de

los procesos con un mdulo, constituyendo todos ellos una
tarea nica (fig. 6b). Esta solucin es obligatoria cuando
no se dispone de un sistema operativo multitarea por lo que
el
diseador
debe
proporcionar
un
sistema
de
gestin
de
mdulos de acuerdo con las facilidades que le proporcione el

sistema operativo y el lenguaje de programacin que utilice
(algunos lenguajes como el ADA facilitan en gran medida la
gestin de mdulos). En general esta solucin ocupa menos
espacio,
es
ms
rpida
(al
eliminar
los
"context
switchings") y permite un mejor control de la ejecucin de

los procesos.
c) Comunicacin entre capas. La comunicacin de informacin

entre dos capas adyacentes puede ser de dos tipos: sncrona
o
asncrona.
La
comunicacin
asncrona
se
basa
en
la
utilizacin de una o varias colas donde se introducen las

IDUs
(Interface
Data
Units:
Unidades
de
Datos
de
la
Interfaz). Dependiendo de los recursos de comunicacin entre

procesos
(tareas/mdulos)
que
proporcionen
el
sistema
operativo y el lenguaje de programacin, puede implementarse

con una cola (fig. 7a) o par de colas (fig. 7b) para el
conjunto
de
todas
las
conexiones
entre
las
dos
capas
(sistema monocola) o como un par de colas (fig. 7c) para

cada
una
sistema
de
dichas
monocola
almacenamiento
en
conexiones
general
centraliza
(sistema
tiende
las
multicola).
ahorrar
funciones
de
El
espacio
de
gestin
de
Pgina 17
colas, pero por el contrario necesita una lgica algo ms

compleja que permita determinar a qu conexin entre capas
corresponde cada IDU.
Figura 7.a.- Comunicacin con una cola
Figura 7.b.- Comunicacin con un par de colas
Figura 7.c.- Comunicacin multicola
La
comunicacin
asncrona
entre
capas
presenta
dos
dificultades. La primera de ellas es el control de flujo

entre capas, es decir, cmo hacer que una capa no genere, en
Pgina 18
promedio, ms informacin de la que la otra capa es capaz de

digerir.
Existen
tres
formas
posible
de
abordar
esta
cuestin:
- Si se utiliza una tcnica multicola (cada conexin
emplea un par de colas), puede asignarse a estas colas
un tamao fijo por lo que si una capa las encuentra
llenas
deber
esperarse,
adecuando
de
esta
forma
su
ritmo al del otro nivel.

- Si se utilizan colas ilimitadas, o bien la tcnica
monocola,
es
necesario
que
existan
primitivas
especficas de control de flujo entre capas deteniendo

o reanudando el flujo de informacin a travs de la
interfaz para cada conexin concreta.
-
Por
ltimo,
una
solucin
alternativa
consiste
en
hacer que la asignacin de memoria para una IDU se

realice de alguna forma controlada por la capa que lo
va a recibir. De esta forma si dicha capa no se halla
preparada
para
procesarlo
simplemente
no
concede
la
memoria necesaria para almacenar el IDU, con lo que el

proceso en la capa de origen se detiene.
La
segunda
de
las
dificultades
que
surgen
como
consecuencia de la comunicacin asncrona entre capas es el

denominado "ejecucin atmica de eventos". Consiste en el
hecho de que una peticin de servicios de una capa a otra,
realizada mediante la intercomunicacin de una IDU, no se
realiza en el mismo momento que se introduce en la cola
Pgina 19
correspondiente, pues puede haber otras IDU en la cola que

se procesen con anterioridad. Para determinados servicios de
una capa este hecho puede ser significativo. Por ejemplo, de
acuerdo con muchas especificaciones, cuando una capa lanza
una solicitud de desconexin, la conexin deja de existir
inmediatamente, no envindose ninguna PDU ms. Sin embargo,
si la cola contiene alguna solicitud previa de envo de
PDUs, la solicitud de desconexin no se tendr en cuenta, en
general, hasta despus de haber enviado todas las PDUs de la
cola. La implementacin no concuerda con la especificacin.
Una posible solucin a este problema est en la asignacin
de prioridades en la cola de IDUs, con lo cual una solicitud
de desconexin de alta prioridad se atender antes que una
solicitud de envo de PDUs.
La comunicacin sncrona entre capas es aquella que se

realiza sin el uso de colas de almacenamiento. Cuando una
capa desea pasar una informacin a otra capa detiene su
ejecucin y le pasa el control junto con la IDU. El control
slo
le
es
informacin.
control
existan
de
en
devuelto
Aunque
flujo
la
una
este
vez
procesada
enfoque
ejecucin
comunicacin
evita
atmica
asncrona,
completamente
los
problemas
de
eventos,
introduce
la
de
que
serias
dificultades de coordinacin entre procesos, limitando el

grado
de
elevando
paralelismo
el
nmero
en
de
la
ejecucin
"context
de
los
switchings"
procesos se representan mediante tareas.
mismos
cuando
los
Tratamiento
de eventos
Orden de tratamiento
Pgina 20
FIFO
Simple
Con prioridades
Aleatorio
Simple
Con prioridades
Efecto de la lectura
Permanece en la cola.
Requiere:
Orden explcita de extraccin

Lectura ms compleja
Especificacin de eventos a
descartar
Desaparece de la cola.
Requiere:
Almacenamiento interno de
eventos
Especificacin de eventos
almacenados
Representac
in de
esperas
En tareas independientes: utiliza recursos del Sistema Operativo
En rutinas: necesita
gestor de mdulos
Simple
Transferencia cuando debe actuar
Transferencia de orden aleatorio
En corrutinas
Necesita gestor de mdulos
Simple
Transferencia cuando debe actuar
Transferencia en orden aleatorio
No soportado en todos los lenguajes

Descripcin
de
transicione
s
En tablas (estado,
evento, condicin)
Ms lento
Fcil generacin automtica

En cdigo
Selecciones (estado, evento, condicin)

Selecciones (evento, estado, condicin)
Representac
in de
temporizado
res
En proceso externo
Con comprobacin peridica
Con llamada al Sistema Operativo

En proceso interno
Tabla 2.- Representacin de mquinas de estados
Pgina 21
2.2.- Representacin de mquinas de estados.
Una vez analizados los problemas de la representacin

de arquitecturas multicapas, donde pueden existir mltiples
tipos de mquinas de estados, es el momento de estudiar la
forma de representacin de una mquina de estados. A este
respecto son 4 las cuestiones en las que conviene fijarse
(tabla 2): a) tratamiento de los eventos; b) representacin
de las esperas; c) descripcin de las transiciones; y d)
representacin de los temporizadores (timers).
a) Tratamiento de los eventos. Los eventos de entrada a una

mquina provienen de otras mquinas o de la interfaz con el
exterior. En general estos eventos son almacenados en una
cola con disciplina de FIFO (First-In, First-Out: el primer
evento que entra es el primer evento que sale). De esta
forma al acceder a la cola se extrae siempre el ms antiguo
(fig. 8a). Este criterio puede ser matizado, si el protocolo
lo requiere, por la existencia de un parmetro de prioridad,
de tal forma que se tome siempre en consideracin el evento
ms
prioritario,
sea
no
el
ms
antiguo
(fig.
8b).
cualquiera de los dos mecanismos anteriores puede aadirse

un factor de "no determinismo". Esto consiste en extraer de
la cola un evento por criterio aleatorio de entre los de
mayor prioridad (fig. 8c). El acceder aleatoriamente a la
cola tiene sobre todo inters en procesos de validacin,
verificacin,
anlisis
de
prestaciones
pruebas,
ya
que
Pgina 22
permite explorar combinaciones de eventos muy diversos.
Figura 8.a.- Tratamiento de eventos con FIFO
Figura 8.b.- Tratamiento de eventos con FIFO priorizado
Figura 8.c.- Tratamiento de eventos no determinista
Otro
aspecto
considerar
en
el
tratamiento
de
los
eventos es el efecto que tiene sobre la cola el proceso de

lectura. Una solucin consiste en considerar que la lectura
de la cola da informacin del evento que hay que procesar
pero deja inalterada la cola (fig. 9a). De esta forma si la
mquina,
por
consideracin
encontrarse
el
evento,
en
el
debe
estado
adecuado,
realizarse
una
toma
en
operacin
explcita de extraccin del evento de la cola. Si por el
Pgina 23
contrario la mquina no pudiese procesar el evento, ste

seguira estando en la cola. La mquina debe entonces leer
de nuevo la cola para ver si existe algn otro evento que s
pueda ser procesado. Por tanto, los eventos no tratados en
un estado son conservados. Este sistema requiere:
- una orden explcita de extraccin de eventos de la
cola.
- un mecanismo ms complejo de lectura de la cola.
- una especificacin de los eventos que, por carecer de
sentido, deban ser descartados (borrados de la cola) en
cada uno de los estados.
Figura 9.a.- Lectura de eventos sin extraccin
Figura 9.b.- Lectura de eventos con extraccin
Pgina 24
La alternativa es que la lectura de la cola suponga

automticamente la extraccin del evento (fig. 9b). Si la
mquina no lo puede procesar en ese estado pero el evento no
debe
ser
rechazado
es
necesario
que
se
proceda
un
almacenamiento temporal interno al mdulo y a una posterior

consideracin
eventos
no
de
los
tratados
eventos
en
un
almacenados.
estado
son
Por
tanto,
descartados.
los
Este
sistema requiere:
- un mecanismo de gestin del almacenamiento interno de
eventos.
- una especificacin de los eventos que, por no poder
ser
tratados
en
un
estado,
deban
ser
las
esperas.
Existen
almacenados
internamente.
b)
Representacin
de
principalmente
tres mtodos de representar las situaciones de espera de las

mquinas de estados y el correspondiente control del ciclo
de ejecucin de las mismas. La primera de estas formas es la
que se utiliza cuando cada mquina de estados se representa
mediante
una
operativo
el
tarea
que
independiente,
controla
la
siendo
ejecucin
de
el
las
sistema
distintas
tareas (fig. 6a). En este caso la espera se ejecuta haciendo

uso de las facilidades del sistema operativo para suspender
la ejecucin de tareas y reanudarlas cuando se produce algn
suceso predeterminado (expiracin de un timer, activacin de
un semforo, etc.). En este caso la estructura, para un
ejemplo con dos mquinas, sera la siguiente:
main() /* Mquina A */
Pgina 25
{
for (;;)
{
espera_a();
lee_evento_a();
procesa_evento_a();
}
}
main() /* Mquina B */
{
for (;;)
{
espera_b();
lee_evento_b();
procesa_evento_b();
}
}
Cuando las mquinas se representan mediante rutinas de

una misma tarea (fig. 6b), y por tanto se necesita un gestor
de
mdulos
especfico,
representarse
de
dos
la
espera
formas.
En
de
una
mquina
puede
primer
lugar,
puede
utilizarse una salida de la rutina que codifica el mdulo y

la devolucin del control al gestor de mdulos. En este caso
la estructura sera esquemticamente la siguiente:
main() /* Gestor de mdulos */
{
for (;;)
{
maquina_a();
maquina_b();
}
}
maquina_a() /* Mquina A */
{
lee_evento_a();
procesa_evento_a();
}
maquina_b() /* Mquina B */
{
lee_evento_b();
procesa_evento_b();
Pgina 26
La versin aqu expuesta presenta un gestor de mdulos

bastante simple. Algunas modificaciones comunes al gestor
incluyen:
- la transferencia de control a las mquinas nicamente
cuando tienen algn evento que tratar, y
- la activacin de las mquinas
en
orden
aleatorio,
principalmente en simulacin.
Por
ltimo,
representan
mediante
tambin
mdulos
cuando
de
una
las
tarea
mquinas
nica,
se
pueden
representarse las esperas mediante transferencias de control

entre corrutinas. Para ello, en primer lugar, el gestor de
mdulos arranca todas y cada una de las mquinas de estados.
Este proceso es similar a la activacin de una tarea desde
el sistema operativo. Para arrancar un mdulo se reserva un
espacio en la pila (moviendo el Stack Pointer SP) y se llama
a la rutina que representa la mquina. Dicha rutina, al
igual que una tarea del sistema operativo, no debe finalizar
(devolver el control con un "return") sino que cuando quiera
realizar una espera, deber transferir el control al gestor
de
mdulos
mediante
la
tcnica
de
corrutinas.
Una
vez
arrancadas todas las mquinas, el gestor de mdulos les va

transfiriendo
control
tambin
segn
la
tcnica
corrutinas. La estructura genrica es la siguiente:

main() /* Gestor de mdulos */
{
de
Pgina 27
arranca_maquina_a();
arranca_maquina_b();
for (;;)
{
corrutina_maquina_a();
corrutina_maquina_b();
}
}
maquina_a() /* Mquina A */
{
for (;;)
{
espera_a();
lee_evento_a();
procesa_evento_a();
}
}
maquina_b() /* Mquina B */
{
for (;;)
{
espera_b();
lee_evento_b();
procesa_evento_b();
}
}
arranca_maquina_a()
{
reserva_espacio_pila();
valor=setjmp(punto_salto_gestor_modulos);
if (valor==0) maquina_a();
}
arranca_maquina_b()
{
reserva_espacio_pila();
if (valor==0) maquina_b();
}
corrutina_maquina_a()
{
if (valor==0) longjmp(punto_salto_maquina_a,1);
}
corrutina_maquina_b()
{
if (valor==0) longjmp(punto_salto_maquina_b,1);
}
Pgina 28
espera_maquina_a()
{
valor=setjmp(punto_salto_maquina_a);
if (valor==0) longjmp(punto_salto_gestor_modulos,1);
}
espera_maquina_b()
{
valor=setjmp(punto_salto_maquina_b);
}
La
reserva
de
espacio
en
la
pila
es
una
condicin
intrnseca al uso de corrutinas. En efecto, en la figura 10

puede observarse la distribucin de la pila sin reserva de
espacio (fig. 10a), con los conflictos que acarrea, y con
reserva de espacio (fig. 10b). Es de notar tambin que las
funciones
"setjmp"
"longjmp"
con
las
que
se
han
implementado en C la tcnica de corrutinas son estndares en

ANSI C y en UNIX, por los que pueden encontrarse en gran
nmero de plataformas y sistemas operativos. Otros lenguajes
proporcionan mecanismos similares. En algunos, sin embargo,
no es posible utilizar este recurso.
Figura 10.a.- Pila con corutinas si reserva de espacio
Pgina 29
Figura 10.b.- Pila con corrutina y reserva de espacio
c) Descripcin de las transiciones. Las transiciones pueden

ser expresadas de dos formas diferentes: mediante tablas o
mediante cdigo. En muchos documentos de especificacin de
protocolos
tablas
se
expresan
(estado,
combinacin
adicional
de
que
las
evento,
estado
se
mquinas
de
condicin).
evento,
imponga,
se
estados
Para
para
expresan
cada
cada
mediante
posible
condicin
tabularmente
las
acciones a realizar y el prximo estado. La otra forma de

representar las transiciones es expresarlas directamente en
el cdigo usando sentencias anidadas de seleccin ("switch"
en
similares).
estructura
de
Estas
(estado,
sentencias
evento,
pueden
condicin),
tomar
o
bien
una
de
(evento, estado, condicin). Con este sistema el protocolo

se
ejecuta
mayor
velocidad,
ya
que
no
hay
que
ir
interpretando las tablas de transiciones. Por el contrario

el mtodo de tablas es muy adecuado cuando se realiza una
generacin automtica de cdigo.
Pgina 30
Una cuestin que debe tenerse en cuenta, sea cual sea el

mtodo
de
representacin
de
transiciones
elegido,
es
la
necesidad de representar tambin el proceso o la transicin

de inicializacin de la mquina de estados.
La mejor forma de entender cada una de estas opciones

es mediante un ejemplo simple. Supongamos para ello que se
desea construir un juego que dispone de dos luces, roja y
verde, y dos pulsadores, tambin rojo y verde. Cada segundo,
se
enciende
aleatoriamente
una
de
las
lmparas.
Si
el
jugador pulsa el botn del mismo color que la lmpara, sta

se
apaga.
Transcurrido
un
segundo
se
vuelve
encender
aleatoriamente otra (o la misma) lmpara. El juego termina

cuando,
por
descuido
del
jugador,
se
encienden
las
dos
lmparas, momento en el cual una nueva pulsacin no apaga

ninguna
lmpara.
Este
sencillo
juego
puede
modelarse
de
acuerdo con la mquina de estados de la figura 11. La misma

mquina se expresa de forma tabular en la figura 12. Los
programas
anexos
presentan
las
"maqsimp1",
tres
"maqsimp2"
alternativas
de
"maqsimp3"
representacin
de
transiciones aplicados a ese ejemplo. Por ltimo el programa

anexo "maqsimp" es una simulacin ejecutable del mencionado
juego.
Figura 11.- Mquina de estados de un juego simple
Pgina 31
Pgina 32
Figura 12.- Tablas de estado de un juego simple
d) Representacin de los temporizadores (timers). Uno de los

elementos presentes con gran frecuencia en las mquinas de
estados que describen protocolos de comunicaciones es el de
los temporizadores o timers. Si bien son similares a otros
eventos, su tratamiento presenta algunas singularidades que
conviene
sealar.
Fundamentalmente
son
dos
las
formas
de
13a)
la
abordar la representacin de los temporizadores:

- mediante proceso externo al mdulo, o
- mediante proceso interno al mdulo.
En
el
primero
de
estos
activacin o cancelacin de un
enfoques
timer
se
(fig.
traducen
en
una
actuacin de la mquina de estados hacia un proceso externo.

En este proceso externo el temporizador puede ser tratado de
dos formas:
Pgina 33
1) Una posibilidad consiste en almacenar el instante en

el que expira el timer e irlo comparando peridicamente
(en cada activacin del proceso de gestin de timers)
con
el
valor
del
reloj
(real
simulado).
Una
vez
superado el plazo impuesto por el timer se genera el

evento correspondiente en la mquina original.
2) La segunda posibilidad de tratamiento del timer en

el proceso externo es solicitar al sistema operativo
que
avise
(active
el
proceso
de
gestin
de
timers)
cuando expire el evento. Una vez que esto ocurre se

genera
el
evento
correspondiente
en
original.
Figura 13.a.- Gestin externa de timers
la
mquina
Pgina 34
Figura 13.b.- Gestin interna de timers
La
representacin
de
los
temporizadores
mediante
proceso interno al mdulo (fig. 13b) supone que la cola (o

colas) de entrada de eventos a la mquina tiene un parmetro
que indica la "hora de entrada en vigor" de cada evento. De
esta forma un evento normal tendr hora de entrada en vigor
igual a cero o igual a la hora en la que se gener, con lo
cual puede ser procesado inmediatamente. Por el contrario la
activacin de un timer supone la inclusin en la cola de un
evento de expiracin del
timer con una hora de entrada en
vigor igual a la hora actual ms la duracin del
timer.
Hasta que el reloj (real o simulado) no supera la hora de

entrada
en
vigor
consideracin.
El
de
un
proceso
evento,
de
la
ste
no
cancelacin
supone la extraccin del evento de la cola.
es
de
tomado
un
en
timer
Pgina 35
2.3.- Representacin de mquinas mltiples.
Una
cuestin
que
se
plantea
frecuentemente
en
el
desarrollo de protocolos es que, si bien el funcionamiento

de
una
determinada
capa
es
descrita
mediante
una
nica
mquina de estados, dicha mquina se halla mltiples veces,

en
estados
con
valores
de
variables
distintas,
correspondiendo con la existencia de mltiples usuarios. Por

ejemplo un protocolo de transferencia de ficheros puede ser
descrito por una mquina nica, tambin denominada mquinatipo.
Pero
intentan
si
varios
utilizar
programas
de
un
sistema
simultneamente
las
multitarea
facilidades
proporcionadas por el protocolo, cada uno de ellos necesita

para
una
individual,
copia
que
se
de
la
mquina
encuentra
en
de
un
estado,
estado
la
mquina-
absolutamente
independiente del estado de las dems mquinas-individuales.

La
representacin
de
estas
mquinas
mltiples
puede
realizarse recurriendo, principalmente, a dos mtodos (tabla

3):
- mediante procesos independientes.

- mediante un proceso nico.
En el primero de estos enfoques (fig. 14) cada una de

las
mquinas
individuales
se
plasma
mediante
un
proceso
(tarea independiente o mdulo de un programa). La variable

que representa el estado de la mquina, as como el resto de
Pgina 36
las variables usadas por la maquina deben ser locales al

proceso, mientras que el cdigo es repetido tantas veces
como
mquinas-individuales
existan.
Esta
solucin
implica
una ocupacin de espacio relativamente alta.

Procesos independientes
Ocupacin de memoria alta

Fcil codificacin (no hay ndices)
Alta velocidad (no hay ndices)
Proceso nico
Variables indexadas
Ocupacin baja de memoria

Menor velocidad (manejo de ndices)
Codificacin engorrosa (ndices)
Corrutinas
Ocupacin baja de memoria

Fcil codificacin (no hay ndices)
Alta velocidad (no hay ndices)
Tabla 3.- Representacin mquinas mltiples
Si
iguales
se
opta
mediante
por
un
representar
nico
las
proceso
mltiples
(fig.
15)
mquinas
todas
las
mquinas individuales comparten el mismo cdigo, aunque sus

variables
son
independientes.
Esto
se
traduce
en
una
importante reduccin de espacio. El aspecto ms conflictivo

radica en que un cdigo nico maneje variables diferentes.
Para ello caben fundamentalmente dos soluciones:
- el uso de variables indexadas, o
- el uso de corrutinas.
La primera de estas alternativas implica que todas las
variables de la mquina sean indexadas, tanto si se definen
como variables globales o como variables locales al proceso.
El ndice de las variables hace referencia a la mquina
individual
la
que
corresponde.
Cuando
se
transfiere
Pgina 37
control a la mquina-tipo se hace con la indicacin de la

mquina individual que se desea ejecutar, lo que se traduce
en el uso de un determinado ndice para las variables. Esta
tcnica hace la codificacin de la mquina ms engorrosa y
su ejecucin algo ms lenta.
Figura 14.a.- Una mquina individual por tarea
Figura 14.b.- Una mquina individual por mdulo
Pgina 38
Figura 15.a.- Varias mquinas individuales por tarea
Figura 15.b.- Varias mquinas individuales por mdulo
La
segunda
alternativa
implica
el
uso
de
corrutinas
para la codificacin de las mquinas-tipo. Si las variables

usadas por la corrutina son de tipo local, stas estarn
Pgina 39
ubicadas en la pila.
Figura 16.- Pila con corutinas y maquinas mltiples
Si se reservan espacios de pila diferentes para las

variables de cada una de las mquinas individuales de una
mquina-tipo
individual
(fig.
se
correspondiente
16),
puede
a
la
la
efectuar
ejecucin
de
una
utilizando
un
nico
mquina-tipo,
el
cual
mquina
cdigo
utiliza
las
Pgina 40
variables de la mquina individual pertinente mediante el

uso
de
tanto,
la
zona
adecuada
no
tienen
que
de
la
estar
pila.
Las
indexadas
variables,
con
lo
que
por
se
simplifica el cdigo, se aumenta la velocidad de ejecucin y

se
facilita
la
generacin
"gestor" realiza una
automtica.
implementacin
de
El
programa
mquinas
anexo
mltiples
mediante corrutinas, con pequeas variantes de tipo prctico

con
respecto
lo
mencionado
comentarios del propio programa).
en
estas
lneas
(ver
Pgina 41
2.4.- Tratamiento de cabeceras y colas.
En
un
informacin
determinado
que
nivel,
circula,
digamos
denominada
nivel
N,
(N)-PDU,
la
est
constituida, en general, por datos del nivel (N+1) y por una

informacin de control denominada tcnicamente (N)-PCI, y en
forma ms coloquial cabeceras y/o colas. El tratamiento de
estas cabeceras y colas supone, en general, un esfuerzo de
clculo
bastante
considerable,
principalmente
para
el
receptor, por lo que habr de estudiarse y optimizarse al

mximo. Entre estas tcnicas de optimizacin destacan:
- El uso de cabeceras y colas precalculadas, de forma
que el cmputo efectivo se reduce al mnimo.
- La anticipacin y prediccin de los posibles valores
de la cabecera y la cola de la prxima PDU, lo que
permite menores tiempos de respuesta y mayor velocidad
de proceso.
-
La
comprobacin
temprana
de
la
consistencia
contenido de la cabecera y la cola de una PDU, evitando

desperdiciar tiempo de CPU en procesar una PDU que ser
descartado ms adelante.
-
El
uso
de
hardware
especfico
para
tratamiento
(construccin y deconstruccin) de cabeceras y colas.
Pgina 42
2.5.- Relacin entre SDUs y PDUs.
Las relaciones entre las unidades de datos del servicio

(SDUs) y las unidades de datos del protocolo (PDUs) para
cada una de las capas, pueden ser de tipo simple como las
recogidas en la figura 17. Sin embargo existen tambin tres
tipos de relacin compleja entre SDUs y PDUs, que son los
siguientes (fig. 18):
Figura 17.- Relaciones simples entre SDUs y PDUs
Pgina 43
Figura 18.- Relaciones complejas entre SDUs y PDUs
- Concatenacin/separacin en la que varias (N)-PDUs

constituyen una nica (N-1)-SDU.
-
Empaquetamiento/desempaquetamiento,
situacin
en
la
que varias (N)-SDUs constituyen una nica (N)-PDU.

- Segmentacin/reunificacin en la que un nico (N)-SDU
es enviado utilizando varios (N)-PDUs.
En
mejoran
general
las
la
concatenacin
prestaciones
(la
el
empaquetamiento
eficiencia)
aunque,
en
determinadas circunstancias pueden aumentar en alguna medida

el
retardo.
Sin
embargo
la
segmentacin
puede
reducir
significativamente la eficiencia sin mejorar para nada el

retardo.
Adicionalmente
la
segmentacin
complica
considerablemente la gestin de la memoria (buffers). Por

ello la segmentacin debe reducirse al mnimo indispensable.
Pgina 44
Una solucin obvia es prohibirla, reduciendo con ello los

servicios suministrados por el protocolo. Una alternativa
mucho menos drstica es limitar el uso de la segmentacin a
una nica capa, con lo cual se limitan los inconvenientes
que plantea.
2.6.- Gestin de memoria.
El
produce
flujo
en
de
todo
informacin
protocolo
de
de
una
capa
otra
comunicaciones,
que
supone
se
una
importante actividad de gestin de memoria en la que SDUs,

PDUs, IDUs, colas entre capas, variables locales y un largo
etctera de
unidades de informacin deben ser almacenadas
temporalmente en alguna parte de la memoria. Ello implica la

reserva
de
coordinacin
una
zona
con
de
el
memoria
resto
de
del
tamao
zonas
de
adecuado,
la
memoria,
la
transferencia de informacin entre esta zona y el exterior o

entre dos zona distintas y, por ltimo, la liberacin de las
zonas una vez que su uso ya no es necesario. Esta gestin de
la memoria de almacenamiento temporal implica pues algunas
cuestiones interesantes, entre las que cabe destacar las 5
siguientes
(tabla
4):
a)
ubicacin
de
las
zonas
de
almacenamiento; b) gestor de la memoria; c) paso de PDU's

entre capas; d) almacenamiento de PDU's; y e) liberacin de
la memoria.
a)
Ubicacin
de
las
Pgina 45
zonas
de
almacenamiento.
Para
esta
cuestin se cuenta principalmente con dos alternativas: una

nica zona global o una zona diferente para cada capa. El
uso de una nica zona de memoria en la cual se almacena la
informacin
de
todas
las
capas
del
protocolo
presenta
algunas peculiaridades. En primer lugar su uso slo puede

realizarse,
obviamente,
cuando
la
estructura
dada
las
capas (procesos, tareas, mdulos, ...) y el contexto en el

que
se
enmarca
(lenguaje,
sistema
operativo,
plataforma,
...) permiten la definicin de zonas comunes de memoria.

Cuando
se
utiliza
esta
tcnica,
en
general
se
aprovecha
mejor el espacio, pues el tamao de la zona manejada tiene

las
reservas
propias
de
la
situacin
global
ms
desfavorable, mientras que si el almacenamiento es local en

cada capa las reservas deben ser dimensionadas al caso ms
desfavorable de dicha capa, lo cual en conjunto suele ser
mayor que una reserva global. Por ltimo, si se usa una zona
global
debe
solicitudes
ponerse
de
una
especial
capa
cuidado
capas
en
agoten
evitar
que
rapidamente
las
la
capacidad de almacenamiento, dejando sin servicio a otras

capas con poca informacin almacenada. Esto podra incluso
ocasionar un bloqueo del protocolo, al impedir que acten
por
saturacin
de
la
memoria
las
capas
encargadas
precisamente de liberar esa memoria.
Si por el contrario se usan zonas locales en cada capa

se evitan los posibles problemas de bloqueo y se consigue
Pgina 46
una mayor independencia entre capas. El precio a pagar es la

necesidad de reservar mayores espacios para almacenamiento y
la prdida de la gestin centralizada de la memoria.
Ubicacin zonas de
almacenamiento
Una zona global
Necesita acceso a zona comn

Optimiza espacio (menores reservas)
Gestin centralizada
Cuidar asignacin equitativa entre capas
Posibles bloqueos
Una zona por capa
Mayor independencia entre capas

Evita problemas de asignacin y bloqueos
Gestor de memoria
Sistema Operativo
Codificacin ms simple
Cuidado con asignacin dinmica
Proceso especfico: Mayor control

Pase de PDUs entre capas
Por copia
Simplicidad
Fuerte sobrecarga de proceso
Por referencia
Tcnica del impreso

Tcnica de dispersin-recopilacin
Caractersticas
Gestin ms compleja
Mayor velocidad
Almacenamiento de PDUs
Contiguas
Simplicidad del gestor

Poco aprovechamiento de la memoria
Eventual necesidad de compactacin
No contiguas
Gestor ms complejo
Buen aprovechamiento de la memoria
Liberacin de la memoria
Donde
Con paso de PDUs por copia: En la capa que recibe

la PDU
Con paso de PDUs por
referencia
En la capa ms baja
(transmisin)
En la capa ms alta
(recepcin)
Peligros
Aspecto siempre delicado

Retransmisin de PDUs
Fallos que descartan PDUs
Tabla 4.- Gestin de memoria
b) Gestor de la memoria. Se pueden plantear fundamentalmente

dos alternativas en cuanto al encargado de gestionar la zona
Pgina 47
o zonas de almacenamiento: el sistema operativo o un proceso

especfico. El uso de las facilidades de gestin de memoria
que
proporcionan
programacin
que
el
sistema
operativo
se
use
traduce
se
el
lenguaje
normalmente
en
de
una
codificacin ms simple, pues delega este tipo de funciones,

pero
por
el
contrario
redunda
en
una
cierta
prdida
de
control. Habr que tener especial cuidado si adems, como

suele ocurrir, estas zonas no tienen reservado un tamao
fijo, sino que el sistema operativo las toma de las zonas
libres que dinmicamente vaya dejando el propio programa.
Esto en ocasiones puede provocar saturaciones prematuras si
la zona dinmica se ha quedado muy pequea por el uso que de
ellan
han
hecho
necesariamente
de
otros
mdulos
comunicaciones.
del
Si
programa,
por
el
no
contrario
se
decide usar un proceso (tarea o mdulo) especfico para la

gestin de la memoria mejoramos el control de la misma y
evitamos los problemas de la gestin dinmica.
c)
Paso
de
PDU's
entre
capas.
Tres
son
las
formas
de
realizar la transferencia de una PDU de una capa a otra: por

copia,
mediante
la
tcnica
de
"impreso"
mediante
la
tcnica de "dispersin-recopilacin". Evidentemente la forma

ms directa de realizarlo es mediante copia, es decir, el
nivel N copia en un almacenamiento propio la PDU ofrecida
por
el
nivel
(N+1),
aadindole
la
cabecera
cola
correspondiente (fig. 19). Sin embargo esta continua copia

de datos supone, en general, una fuerte sobrecarga que est
enrgicamente
Pgina 48
desaconsejada,
slo
se
justifica
por
la
sencillez de la implementacin. En la tcnica del impreso

(fig. 20), el nivel ms alto que genera una PDU (normalmente
el
de
aplicacin,
excepcin
de
las
PDUs
de
control)
reserva un espacio suficientemente amplio como para albergar

a la SDU y al conjunto de las cabeceras y colas de los
niveles
inferiores.
De
esta
forma
un
nivel
le
pasa
al
siguiente la PDU como un puntero a la zona del impreso donde

comienza
la
informacin
pertinente
dicho
nivel.
Por
ltimo, la tcnica de dispersin-recopilacin utiliza zonas

de
memoria
distintas
punteros
no
contigua
partes
de
unas
de
para
una
zonas
almacenar
cada
PDU,
utilizando
otras
(fig.
una
para
21a)
de
las
unirlas
una
lista
externa de punteros (fig. 21b). Para poder reconstruir la

PDU original a partir de las diferentes porciones es a veces
conveniente incluir junto al puntero la longitud de la zona
referenciada. Las tcnicas de paso de PDUs por referencia
proporcionan una mayor velocidad de ejecucin al precio de
una gestin ms compleja del paso de PDUs entre capas.
d)
Almacenamiento
almacenar
los
de
PDUs
PDU's.
La
consiste
en
tcnica
ms
ubicarlas,
simple
sin
para
ninguna
transformacin, en la zona de memoria correspondiente. Sin

embargo
si,
como
es
frecuente,
tamaos
muy
diferentes,
la
las
gestin
PDUs
del
pueden
ser
de
almacenamiento
se
hace compleja si no se quieren desaprovechar los huecos que

dejan
vacantes
las
PDUs
despus
de
ser
extraidas
de
la
Pgina 49
memoria. Este problema, similar al que se produce en la

gestin del espacio de un disco magntico donde se almacenan
y
borran
ficheros,
puede
solucionarse
bien
con
una
compactacin peridica de la memoria, con la consiguiente

sobrecarga de proceso, o bien mediante la divisin de la PDU
en
trozos
de
tamao
fijo
(relativamente
pequeos)
el
almacenamiento de dichos trozos en zonas no contiguas de

memoria. Esta solucin, si bien supone un gestor de memoria
ms elaborado, optimiza el uso del almacenamiento disponible
con escaso consumo de CPU.
Figura 21.a.- Paso de PDUs por punteros
Pgina 50
Figura 21.b.- Paso de PDUs por lista de punteros
e) Liberacin de memoria. Tan importante como la reserva de

la memoria para el almacenamiento de PDUs es la liberacin
de
la
misma
cuando
ya
no
resulta
necesario
su
uso.
Una
fuente de errores frecuente en el desarrollo de protocolos

radica en una inadecuada liberacin de la memoria ocupada.
Por
tanto
esta
cuestin
debe
dedicrsele
un
especial
cuidado. Si el paso de PDUs entre capas se realiza mediante

copia
la
liberacin
de
la
memoria
correspondiente
debe
realizarse, en general, en la capa que recibe el PDU. Si por

el contrario, el paso de
(tcnicas
de
impreso
PDUs
de
se
realiza
por
referencia
dispersin-recopilacin),
la
memoria deber ser liberada normalmente en la capa ms alta

a la que vaya destinado la PDU (en recepcin) o a la capa
inferior del protocolo (en transmisin). No obstante deben
considerarse con precaucin dos situaciones especiales. La
Pgina 51
primera es aquella situacin que se presenta cuando, por

haber ocurrido algn error, un mensaje debe ser transmitido
de nuevo. Un segundo caso, tambin en presencia de fallos de
comunicacin, es la necesidad de descartar una PDU. En estas
situaciones
capas
deber
encargadas
estudiarse
del
con
cautela
almacenamiento
cuales
temporal
son
las
de
la
liberacin de PDUs que pueden ser retransmitidas, tanto en

caso de fallo como en la ausencia del mismo. Igualmente
deber
considerarse
con
cuidado
la
capa
capas
que
liberarn las PDUs que han sido descartadas por fallo de

transmisin.
Pgina 52
2.7.- Manejo del hardware de comunicaciones.
Toda implementacin de un protocolo tiene que afrontar,

antes
despus,
comunicaciones.
el
problema
Ms
an,
del
hardware
cuando
se
especfico
habla
de
de
estos
dispositivos no debe pensarse tan slo en un hardware que se

limite a cumplir las funciones del nivel fsico, sino que,
cada vez con ms frecuencia, puede encontrarse hardware de
comunicaciones desempeando tareas correspondientes a capas
intermedias del modelo OSI (tpicamente niveles de enlace de
datos y de red).
El
manejo
del
hardware
de
comunicaciones
puede
abordarse principalmente desde dos perspectivas (tabla 5):

mediante
gestin
directa
sistema
operativo.
La
comunicaciones
puede
usando
gestin
las
directa
realizarse,
facilidades
del
hardware
suponiendo
que
del
de
el
dispositivo lo permita, mediante alguna de las siguientes

tres tcnicas: por exploracin, por interrupcin o por DMA.
La
tcnica
de
exploracin
consiste
en
la
comprobacin
cclica del estado en el que se encuentran las etapas de

transmisin y recepcin del dispositivo. Cuando el estado es
el adecuado se le inyecta una informacin a transmitir o se
le retira una informacin recibida. Aunque es un sistema muy
sencillo es ineficaz, supone una fuerte carga de proceso y
requiere una atencin continua, so pena de desbordamiento de
las colas internas del dispositivo.
Gestin directa
Pgina 53
Exploracin
Ineficaz
Fuerte sobrecarga
Posible prdida de informacin
Interrupciones
Sistema eficaz
Codificacin compleja
DMA
Sin interrupciones
Con interrupciones
Usando sistema operativo
Sin activacin asncrona

Con activacin asncrona
Caractersticas
Codificacin simple
Mayor coordinacin con otras
tareas
Mayores tiempos de respuesta
Sobrecarga
Tabla 5.- Manejo del hardware de comunicaciones
Usando
avisa
la
cuando
tcnica
est
de
interrupciones
listo
para
el
transmitir
dispositivo
una
nueva
informacin o cuando se ha recibido por la lnea algn dato.

Este
sistema
es
en
general
mucho
ms
adecuado
pues
no
sobrecarga la CPU y garantiza que no se pierde informacin,

siempre que la interrupcin sea atendida con prontitud. Sin
embargo
hay
que
interrupciones
considerar
es,
tambin
normalmente,
una
que
el
tarea
de
manejo
una
de
cierta
complejidad.
Por ltimo, si el dispositivo est preparado para ello,

se
puede
memoria
realizar
(DMA).
En
la
gestin
esta
mediante
alternativa
acceso
la
directo
transmisin
a
o
recepcin de informacin se realiza sin el concurso de la

CPU principal, cuyo nico cometido est en la iniciacin del
proceso y en la recogida de resultados. La finalizacin del
Pgina 54
DMA puede detectarse por exploracin cclica o, lo que es

ms
frecuente,
por
interrupciones.
Cuando
el
dispositivo
proporciona esta posibilidad, el DMA con interrupciones es,

sin duda, el ms eficiente de los sistemas de manejo del
hardware.
Como contrapunto al manejo directo de los dispositivos

de comunicaciones, se puede considerar el uso del sistema
operativo para estas funciones. Una de las tareas tpicas de
los sistemas operativos ha sido siempre la gestin de los
dispositivos perifricos para facilitar y coordinar el uso
que de los mismos realizan las distintas tareas. Normalmente
la parte del sistema operativo que realiza la gestin de un
dispositivo
concreto
(driver).
ellos
recibe
se
el
accede
nombre
mediante
de
la
manipulador
invocacin
de
primitivas especficas del sistema operativo que permiten la

transmisin
recepcin
de
informacin.
Algunas
de
estas
primitivas permiten una activacin asncrona de alguno de

los mdulos de la tarea que los invoc, permitiendo de esta
forma
una
ms
eficaz
gestin
de
las
transferencias
de
informacin. El uso del sistema operativo para el manejo de

los dispositivos de comunicaciones supone por un lado una
mayor simplicidad de cdigo y una mejor coordinacin con el
resto
de
prdida
tareas,
de
pero
control,
por
los
el
contrario
tiempos
de
hay
una
respuesta
cierta
son
ms
elevados y hay una cierta sobrecarga debido a la gestin

introducida por el sistema operativo.
Pgina 55
2.8.- Interfaz con el exterior.
El protocolo de comunicaciones no slo debe comunicarse

con otros computadores a travs de los canales adecuados,
sino que tambin deber interrelacionarse con otros procesos
(tareas o mdulos) que hagan uso de sus servicios. La forma
que adopte esta interfaz con el exterior depender en gran
medida
de
dnde
se
ubique
el
protocolo,
pudiendo
distinguirse principalmente dos alternativas (tabla 6): en

un frontal de comunicaciones o en el mismo procesador que el
resto
de
los
procesos.
comunicaciones
(o
Si
se
utiliza
"front-end")
la
un
frontal
relacin
con
de
otros
procesos ser mediante los mecanismos de comunicacin que se

establezcan
entre
comunicacin
estar
los
procesadores
normalmente
respectivos.
basada
en
un
Dicha
protocolo
simple para canales punto a punto, con pocos errores y alta

velocidad. La tarea del frontal ser, en este caso, la de
preprocesar
la
informacin
complejos
que
procesador
principal
comunicacin.
La
puedan
de
manejar
estar
las
los
protocolos
ms
presentes,
liberando
al
tareas
intercomunicacin
procesador
principal
siguientes
mtodos:
suele
por
entre
realizarse
BUS
(fig.
ms
pesadas
el
por
22a),
de
la
el
frontal
alguno
de
los
normalmente
con
acceso directo a memoria (DMA); por red local y procesador

especfico en BUS con DMA (fig. 22b); y por lnea de alta
velocidad, con o sin procesador especfico (fig. 22c).
Ubicacin
En un front-end
Pgina 56
Por BUS (DMA)

Por red local
Por lnea de alta velocidad
En el mismo procesador
En el sistema operativo: por

directivas del Sistema Operativo
y zonas globales de memoria
En tareas independientes.:
Mediante comunicacin entre
tareas del Sistema Operativo y
zonas globales de memoria
En la misma tarea (librera):
Mediante llamadas a mdulos y
zonas comunes de memoria
Tabla 6.- Interfaz con el exterior
Figura 22.a.- Frontal conectado al BUS
Figura 22.b.- Frontal conectado en red local
Pgina 57
Figura 22.c.- Frontal conectado por lnea de alta velocidad
Si se ubica en el mismo procesador que el resto de los

procesos se plantean, a su vez, tres posibles ubicaciones.
En primer lugar cabe que el protocolo se desarrollo como una
parte del sistema operativo, bien porque el desarrolle lo
realice el propio fabricante, o bien porque nos encontremos
ante sistemas operativos que pueden ser ampliados por el
usuario. En este caso el interfaz entre el protocolo y los
dems
procesos
se
realizar
mediante
el
manejo
de
las
primitivas del propio sistema operativo y, eventualmente, el

uso de zonas globales de memoria. Una segunda alternativa,
en sistemas multitarea, consiste en desarrollar el protocolo
como una o varias tareas autnomas, realizndose en este
caso la interfaz mediante las facilidades de comunicacin
entre
tareas
que
proporcione
el
sistema
operativo
y,
eventualmente
tambin,
Pgina 58
a
travs
de
zonas
globales
de
memoria. Por ltimo el protocolo puede tomar la forma de una

librera de mdulos que se integran en una tarea mediante
llamada siguiendo las reglas del lenguaje de programacin
elegido y utilizando zonas de memoria internas a la propia
tarea
(aunque
puedan
estar
compartidas
entre
varios
mdulos). La decisin de usar una u otra alternativa depende

en
general
de
consideraciones
de
diseo
globales
de
la
aplicacin y no, tan slo, del protocolo de comunicaciones.
ANEXOS
Pgina 60
ANEXOS
Programa GESCOR.C.
Programa ejemplo de gestin de mquinas con corrutinas.
#include <stdio.h>/* Estos include son necesarios para los */

#include <setjmp.h>/* procesos de gestin de corrutinas */
main() /* El main tan slo sirve para dar soporte a la rutina gestor */
{
printf("\n\n\n");
gestor_modulos();
}
jmp_buf punto_salto_maquina_a;
jmp_buf punto_salto_maquina_b;
jmp_buf punto_salto_gestor_modulos;
gestor_modulos()
{
arranca_maquina_a(100);
arranca_maquina_b(100);
for (;;)
{
corrutina_maquina_a();
corrutina_maquina_b();
}
}
maquina_a()
{
int valor,paso;
printf("Activada mquina A\n");
paso=0;
for (;;)
{
valor=setjmp(punto_salto_maquina_a);
printf("Mquina A. Paso %d\n",++paso);
} /* Fin del bucle infinito */
} /* Fin del mdulo A */
arranca_maquina_a(reserva)
int reserva;
{
int valor;
reserva--;
if (reserva<=0)
{
if (valor==0) maquina_a();
}
else arranca_maquina_a(reserva);
return;
}
corrutina_maquina_a()
{
int valor;
if (valor==0) longjmp(punto_salto_maquina_a,1);
return;
}
maquina_b()
{
int valor,paso;
printf("Activada mquina B\n");
paso=0;
for (;;)
{
valor=setjmp(punto_salto_maquina_b);
printf("Mquina B. Paso %d\n",++paso);
} /* Fin del mdulo B */
arranca_maquina_b(reserva)
int reserva;
{
int valor;
reserva--;
if (reserva<=0)
{
if (valor==0) maquina_b();
}
else arranca_maquina_b(reserva);
return;
}
corrutina_maquina_b()
{
int valor;
if (valor==0) longjmp(punto_salto_maquina_b,1);
return;
}
Programa GESTOR.
Pgina 61
Pgina 62
Programa ejemplo de gestin de corrutinas recursivas.
#include <stdio.h> /* Estos include son necesarios para los */

#include <setjmp.h> /* procesos de gestin de corrutinas */
#include <stdlib.h> /* Estos include son necesarios */
#include <time.h> /* para los procesos de aleatorizacin */
{
randomize();
printf("\n\n\n");
gestor();
}
#define n_tareas_modulo_A 3 /* Estos define deben ser generados de forma
*/
#define n_tareas_modulo_B 2 /*automtica por el generador de cdigo C */
#define n_total_tareas 5
/*y coinciden con el nmero de mquinas
individuales de cada mdulo y con el
nmero total de ellas */
#define RESERVA_STACK
100
/* Este define marca el nmero de veces
que se activa recursivamente la rutina de
llamada de mdulos antes de llamar
definitavemente al mdulo. Es una medida
indirecta de la cantidad de espacio
reservado en el stack para la llamada a
subrutinas de cada mquina individual */
/* Cada mdulo genera un conjunto de instruciones como las siguientes.

Su objetivo es establecer los puntos de ida y vuelta para
cada una de las mquinas individuales del mdulo */
/***** Variables correspondientes al mdulo A ******/
jmp_buf salto_ida_modulo_A [n_tareas_modulo_A];
jmp_buf salto_vuelta_modulo_A;
int arrancando_modulo_A=1;
/* Utilizado en el proceso de arranque
del mdulo */
/**** Variables correspondientes al mdulo B *****/
jmp_buf salto_ida_modulo_B [n_tareas_modulo_B];
jmp_buf salto_vuelta_modulo_B;
int arrancando_modulo_B=1;
/**** Variables correspondientes al mmi *****/
jmp_buf salto_ida_mmi;
jmp_buf salto_vuelta_mmi;
/****************************************************************
*
*
Rutina que realiza la gestin de todas las tareas.
*
*
En una primera fase inicializa todas las tareas
Pgina 63
*
reservando espacio de stack para ellas y esbleciendo
*
los puntos de salto a las mismas. La activacin de
*
estas rutinas se hace en forma de corrutinas que,
*
por tanto, estn siempre activas. La llamada a cada
*
una de las tareas de cada uno de los mdulos se hace
*
recursivamente.
*
*
En una segunda fase realiza un bucle infinito para
*
dar control en orden aleatorio a cada una de las tareas
*
que componen la especificacin.
*
*
Adicionalmente deberan incluirse en el proceso de
*
inicilizacin como corrutinas y de cesin de control
*
en cada uno de los pasos del bucle infinito, todas
*
aquellas rutinas de simulacin, almacenamiento,
*
presentacin, y control general de la ejecucin de
*
de la especificacin que fuesen necesarias. El orden
*
de estas rutinas no tiene por que ser aleatorio sino
*
que normalmente se har su activacin en un orden
*
determinado al final de la activacin de todas las
*
mquinas individuales.
*
*********************************************************************/
gestor()
{
int i,valor;
int modulo,tarea;
/**** Fase de inicializacin *********/
valor=setjmp(salto_vuelta_modulo_A); /* Establece punto de vuelta
de la corrutina */
if (valor==0) llamada_modulo_A(0); /* Activa la primera tarea del
primer mdulo */
/***** Fase de cesin cclico de control
********/
while(1)
{
for (i=0;i<n_total_tareas;i++)
{
decide_tarea_aleatoriamente(i,&modulo,&tarea);
switch (modulo)
{
case 0:
valor=setjmp(salto_vuelta_modulo_A); /* Punto de vuelta de la
corrutina */
if (valor==0)
longjmp(salto_ida_modulo_A[tarea],1); /* Va a la corrutina
correspondiente a la
tarea calculada del
mdulo A */
break;
case 1:
valor=setjmp(salto_vuelta_modulo_B);
if (valor==0) longjmp(salto_ida_modulo_B[tarea],1);
break;
} /* Fin del switch */
} /* Fin del bucle de llamada a todas las mquinas individuales */
valor=setjmp(salto_vuelta_mmi);
if (valor==0) longjmp(salto_ida_mmi,1);
printf("\n");
Pgina 64
}
return;
}
/****************************************************************
*
*
Esta rutina calcula aleatoriamente el mdulo y la tarea
*
a los que debe cederseles el control.
*
*
Para ello calcula unas tablas aleatorias que son inicializadas
*
cada vez que se ejecuta un paso en todas las mquinas
*
individuales.
*
****************************************************************/
decide_tarea_aleatoriamente(vez,modulo,tarea)
int vez,*modulo,*tarea;
{
static int tabla_modulo[n_total_tareas]={0,0,0,1,1}; /* Las constantes
*/
static int tabla_tarea[n_total_tareas] ={0,1,2,0,1}; /* son obtenidas
por
el generador de
cdigo C */
static int tabla_modulo_elegido[n_total_tareas];
static int tabla_tarea_elegida[n_total_tareas];
static int tarea_elegida[n_total_tareas];
int i,j,n,contador;
/***** La primera activacin en cada paso dispara el clculo de
las tablas aleatorias *****/
if (vez==0)
{
for (i=0;i<n_total_tareas;i++) tarea_elegida[i]=0;
for (i=0;i<n_total_tareas;i++)
{
n=random(n_total_tareas-i);
contador=-1;
for (j=0;j<n_total_tareas;j++)
{
if (tarea_elegida[j]==0) contador++;
if (n==contador)
{
tarea_elegida[j]=1;
tabla_modulo_elegido[i]=tabla_modulo[j];
tabla_tarea_elegida[i]=tabla_tarea[j];
break;
}
} /* Fin de la busqueda de la tarea elegida */
} /* Fin del for i */
} /* Fin del calculo de las tablas aleatorias */
/***** Determinacin del mdulo y tarea basado en las tablas *****/
*modulo=tabla_modulo_elegido[vez];
*tarea=tabla_tarea_elegida[vez];
return;
}
/*******************************************************************
*
*
Mdulo A correspondiente al cuerpo de un mdulo en ESTELLE
*
Pgina 65
*
Aqu figurarn las transiciones, actuaciones y, en
*
general todos aquellos procesos necesarios para la
*
ejecucin de una mquina individual.
*
*
La rutina tiene una primera fase de inicializacin
*
donde va activando recursivamente todas las mquinas
*
individuales. Cuando finaliza, activa la primera mquina
*
individual del mdulo siguiente.
*
*
La rutina no finaliza nunca sino que se le transfiere
*
y devuelve el control mediante la tcnica de corrutinas
*
*********************************************************************/
modulo_A(tarea)
int tarea;
{
int valor;
int paso;
int j;
char buf[2];
/**** Variables tomadas como ejemplo para comprobar que los valores
de las mismas son independientes para cada mquina individual */
j=random(100);
buf[0]=random(100);
buf[1]=random(100);
printf("Entra en mdulo A con tarea= %d; j= %d; buf: %d %d\n",
tarea,j,buf[0],buf[1]);
paso=-1;
while (1)
{
/****** Fase de inicializacin de la corrutina *****/
valor=setjmp(salto_ida_modulo_A[tarea]);
if (valor==0)
if( tarea < (n_tareas_modulo_A-1) && arrancando_modulo_A)
llamada_modulo_A(++tarea,RESERVA_STACK); /* Activa otra
tarea del mimo mdulo */
else
{
if (arrancando_modulo_A)
{
arrancando_modulo_A=0;
valor=setjmp(salto_vuelta_modulo_B);
if (valor==0)
llamada_modulo_B(0,RESERVA_STACK); /* Activa la primera
tarea del mdulo
siguiente */
}
longjmp(salto_vuelta_modulo_A,1);
}
/******
Fase de ejecucin de un paso de la mquina individual *****/
paso++;
printf("Mdulo A: Tarea %d; Paso %d; ",tarea,paso);
j++;
buf[0]++;
buf[1]++;
printf("j= %d; Buf: %d %d\n",j,buf[0],buf[1]);
Pgina 66
/*********************************************************************
*
*
Rutina para reservar espacio en el stack. Esta rutina debe
*
ser generada por el generador de cdigo para cada uno de
*
los mdulos de la especificacin.
*
*
Si la activacin de un mdulo que se realiza para cada mquina
*
individual se hiciera directamente llamando a la rutina
*
correspondiente, las variables del mdulo llamado se almacenaran
*
en el stack a continuacin de las variables del mdulo llamante
*
EN EL MOMENTO DE LA LLAMADA. Si posteriormente el mdulo llamante
*
al tener control en alguno de sus ejecuciones, necesitara ampliar
*
el nmero de variables almacenados en el stack, machacara
*
las variables del mdulo llamado.
*
*
Para evitarlo, la activacin se hace de forma que las variables
*
del mdulo llamado no empiecen a continuacin de las del mdulo
*
llamador. Para ello se realiza un cierto nmero de veces la
*
llamada recursiva a esta rutina antes de llamar definitivamente
*
la rutina correspondiente. Con ello las variables de esta rutina
*
son las que se colocan en la pila una y otra vez a continuacin
*
de las variables del mdulo llamante, y sern por tanto las
*
variables destruidas por el mdulo llamante en caso de ampliar
*
sus necesidades de uso del stack. Las variables destruidas no
*
necesitan ser conservadas por lo que esta destruccin no afecta
*
al funcionamiento del sistema.
*
***********************************************************************/
llamada_modulo_A(tarea,reserva)
int tarea,reserva;
{
reserva--;
if (reserva<=0) modulo_A(tarea);
else llamada_modulo_A(tarea,reserva);
return;
}
/******** Rutina correspondiente al mdulo B *******/
modulo_B(tarea)
int tarea;
{
int valor;
int paso;
int k;
char baf[2];
k=random(100);
baf[0]=random(100);
baf[1]=random(100);
printf("Entra en mdulo B con tarea= %d; k= %d; baf: %d %d\n",
tarea,k,baf[0],baf[1]);
paso=-1;
while (1)
{
valor=setjmp(salto_ida_modulo_B[tarea]);
if (valor==0)
if( tarea < (n_tareas_modulo_B-1) && arrancando_modulo_B)
llamada_modulo_B(++tarea,RESERVA_STACK);
else
{
if (arrancando_modulo_B)
{
arrancando_modulo_B=0;
Pgina 67
valor=setjmp(salto_vuelta_mmi);
if (valor==0)
llamada_mmi(RESERVA_STACK); /* Al ser el timo mdulo ESTELLE
activa el primer mdulo de gestin,
en este ejemplo el mmi que, adems,
es el nico */
}
longjmp(salto_vuelta_modulo_B,1);
}
paso++;
printf("Mdulo B: Tarea %d; Paso %d; ",tarea,paso);
k++;
baf[0]++;
baf[1]++;
printf("k= %d; Baf: %d %d\n",k,baf[0],baf[1]);
}
}
/****** Rutina de llamada al mdulo B *****/
llamada_modulo_B(tarea,reserva)
int tarea,reserva;
{
reserva--;
if (reserva<=0) modulo_B(tarea);
else llamada_modulo_B(tarea,reserva);
return;
}
/********************************************************************
*
*
Rutina que simula el Man Machine Interface (MMI)
*
********************************************************************/
mmi()
{
int tecla;
printf("Entra en el mmi\n");
while (1)
{
tecla=leetecla();
printf("MMI: Se puls la tecla %d\n",tecla);
}
}
/****** Rutina de llamada al mmi *****/
llamada_mmi(reserva)
int reserva;
{
reserva--;
if (reserva<=0) mmi();
else llamada_mmi(reserva);
return;
}
/**************************************************************
*
*
Rutina de lectura de tecla
*
*
Si no se ha pulsado niguna tecla devuelve el control
*
al gestor de tareas con tcnica de corrutina.
*
Pgina 68
*
Cuando se pulsa una tecla devuelve el control al MMI
*
para que ejecute un ciclo no muy largo y velva a llamar
*
a leetecla. Esta cesin de control se hace con tcnica de
*
subrutina normal.
*
*****************************************************************/
leetecla()
{
int i,j,valor;
while(!kbhit())
{
valor=setjmp(salto_ida_mmi);
if (valor==0) longjmp(salto_vuelta_mmi,1);
}
i=getch();
if (i!=0) return(i);
j=getch();
return(j<<8);
}
Programa GESCORM.C.
Programa ejemplo de gestin de mquinas mltiples con

corrutinas.
/********************************************************************
*
*
Programa ejemplo de gestin de mquinas mltiples
*
con corrutinas
*
********************************************************************/
#include <stdio.h>
#include <setjmp.h>
/* Estos include son necesarios para los */

/* procesos de gestin de corrutinas */
{
printf("\n\n\n");
gestor_modulos();
}
#define
#define
jmp_buf
jmp_buf
jmp_buf
n_maquinas_tipo_a 3
n_maquinas_tipo_b 2
punto_salto_maquina_a[n_maquinas_tipo_a];
punto_salto_maquina_b[n_maquinas_tipo_b];
punto_salto_gestor_modulos;
gestor_modulos()
{
int i;
for (i=0;i<n_maquinas_tipo_a;i++) arranca_maquina_a(i,100);

for (i=0;i<n_maquinas_tipo_b;i++) arranca_maquina_b(i,100);
for (;;)
{
for (i=0;i<n_maquinas_tipo_a;i++) corrutina_maquina_a(i);
for (i=0;i<n_maquinas_tipo_b;i++) corrutina_maquina_b(i);
}
}
maquina_a(tarea)
int tarea;
{
int valor,paso;
printf("Activada mquina A (%d)\n",tarea);
paso=0;
for (;;)
{
valor=setjmp(punto_salto_maquina_a[tarea]);
printf("Mquina A (%d). Paso %d\n",tarea,++paso);
arranca_maquina_a(tarea,reserva)
int tarea,reserva;
{
int valor;
reserva--;
if (reserva<=0)
{
if (valor==0) maquina_a(tarea);
}
else arranca_maquina_a(tarea,reserva);
return;
}
corrutina_maquina_a(tarea)
int tarea;
{
int valor;
if (valor==0) longjmp(punto_salto_maquina_a[tarea],1);
return;
}
maquina_b(tarea)
int tarea;
{
int valor,paso;
printf("Activada mquina B (%d)\n",tarea);
paso=0;
for (;;)
{
valor=setjmp(punto_salto_maquina_b[tarea]);
printf("Mquina B (%d). Paso %d\n",tarea,++paso);
} /* Fin del mdulo B */
arranca_maquina_b(tarea,reserva)
int tarea,reserva;
Pgina 69
Pgina 70
{
int valor;
reserva--;
if (reserva<=0)
{
if (valor==0) maquina_b(tarea);
}
else arranca_maquina_b(tarea,reserva);
return;
}
corrutina_maquina_b(tarea)
int tarea;
{
int valor;
if (valor==0) longjmp(punto_salto_maquina_b[tarea],1);
return;
}
Programa MAQSIMP1.C.
Representacin
mediante tablas.
de
una
mquina
de
estados
typedef struct
{
int
condicion;
int
accion;
int
nuevo_estado;
void
*siguiente_transicion;
} transicion;
typedef struct
{
int codigo;
int parametro;
} evento;
#define NULA
#define NUM_ES_A
#define NUM_EV_A
enum
enum
enum
enum
0
2
2
estados_a {ES1_A,ES2_A};
eventos_a {EV1_A,EV2_A};
condiciones_a {P1_A,P2_A};
salidas_a {SAL1_A,SAL2_A,SAL3_A,SAL4_A};
transicion transicion_ES1A_EV1A={NULA,SAL2_A,ES2_A,NULA};
transicion transicion_ES1A_EV2A={NULA,NULA,ES1_A,NULA};
simple
Pgina 71
transicion transicion_ES2A_EV1A={NULA,SAL2_A,ES2_A,NULA};
transicion transicion_ES2A_EV2A_1={P1_A,SAL3_A,ES1_A,NULA};
transicion transicion_ES2A_EV2A_2={P2_A,SAL4_A,ES2_A,NULA};
transicion maquina[NUM_ES_A][NUM_EV_A];
int estado_a=ES1_A;
int accion_inicial_a=SAL1_A;
evento lee_evento();
int estado_luz_roja,estado_luz_verde;
inicia_maquina_a()
{
maquina[ES1_A][EV1_A]=transicion_ES1A_EV1A;
maquina[ES2_A][EV2_A]=transicion_ES2A_EV2A_1;
transicion_ES2A_EV2A_1.siguiente_transicion=&transicion_ES2A_EV2A_2;
accion_a(accion_inicial_a);
}
maquina_a()
{
evento ultimo_evento;
transicion transicion_disparada,transicion_anterior;
ultimo_evento=lee_evento();
transicion_disparada=maquina[estado_a][ultimo_evento.codigo];
do
{
if (condicion_a(transicion_disparada.condicion))
{
estado_a=transicion_disparada.nuevo_estado;
accion_a(transicion_disparada.accion);
}
else
{
transicion_anterior=transicion_disparada;
transicion_disparada=*(transicion
*)(transicion_disparada.siguiente_transicion);
}
} while (transicion_anterior.siguiente_transicion!=NULA);
} /* Fin del programa */
condicion_a(condicion)
int condicion;
{
switch (condicion)
{
case P1_A:
if ( hay_solo_una_luz_encendida() &&
boton_y_luz_del_mismo_color() ) return(1);
else return(0);
case P2_A:
if (!hay_solo_una_luz_encendida() )return(1);
else return(0);
}
}
accion_a(accion)
int accion;
Pgina 72
{
switch (accion)
{
case SAL1_A:
activa_timer();
break;
case SAL2_A:
enciende_luz_roja_o_verde();
activa_timer();
break;
case SAL3_A:
apaga_una_luz();
break;
case SAL4_A:
informa_perdida_juego();
break;
}
}
Programa MAQSIMP2.C.
Representacin
mediante seleccin
condicin).
de
en
una mquina
de
estados
simple
cdigo de tipo (estado, evento,
typedef struct
{
int codigo;
int parametro;
} evento;
enum estados_a {ES1_A,ES2_A};
enum eventos_a {EV1_A,EV2_A};
int estado_a=ES1_A;
inicia_maquina_a()
{
activa_timer();
return;
}
maquina_a()
{
Pgina 73
switch(estado_a)
{
case ES1_A:
switch (ultimo_evento.codigo)
{
case EV1_A:
activa_timer();
estado_a=ES2_A;
break;
case EV2_A:
break;
} /* Fin del switch de los eventos del estado ES1_A */
break;
case ES2_A:
{
case EV1_A:
break;
case EV2_A:
if ( hay_solo_una_luz_encendida() && boton_y_luz_del_mismo_color()
)
{
apaga_una_luz();
estado_a=ES1_A;
}
else if (!hay_solo_una_luz_encendida())
{
}
break;
break;
} /* Fin del switch de los estados */
} /* Fin de la maquina a */
Programa MAQSIMP3.C
Representacin
mediante seleccin
condicin).
de
en
una mquina de estados simple

cdigo de tipo (evento, estado,
Pgina 74
typedef struct
{
int codigo;
int parametro;
} evento;
int estado_a=ES1_A;
inicia_maquina_a()
{
activa_timer();
return;
}
maquina_a()
{
switch(ultimo_evento.codigo)
{
case EV1_A:
switch (estado_a)
{
case ES1_A:
activa_timer();
estado_a=ES2_A;
break;
case ES2_A:
break;
} /* Fin del switch de los estados del evento EV1_A */
break;
case EV2_A:
switch (estado_a)
{
case ES1_A:
break;
case ES2_A:
)
{
apaga_una_luz();
estado_a=ES1_A;
}
{
}
break;
} /* Fin del switch de los estados del evento EV2_A */
break;
} /* Fin del switch de los eventos */
Pgina 75
Programa MAQSIMP.C.
Programa de simulacin de la mquina simple de juegos.

#include <simpro.h>
typedef struct
{
int codigo;
int parametro;
} evento;
enum maquinas {MAQUINA_A};
int estado_a=ES1_A;
main()
{
inicializa_lista_sucesos();
inicia_maquina_a();
for (;;)
{
maquina_a();
lee_teclado();
}
}
inicia_maquina_a()
{
activa_timer();
return;
}
maquina_a()
{
lee_evento();
switch(estado_a)
{
case ES1_A:
{
case EV1_A:
activa_timer();
estado_a=ES2_A;
Pgina 76
break;
case EV2_A:
break;
break;
case ES2_A:
{
case EV1_A:
activa_timer();
break;
case EV2_A:
)
{
apaga_una_luz();
estado_a=ES1_A;
}
{
}
break;
break;
} /* Fin del switch de los estados */
activa_timer()
{
genera_suceso(EV1_A,MAQUINA_A,0,0,5.);
return;
}
apaga_una_luz()
{
int luz;
luz=genera_error(0.5);
if (luz)
if (estado_luz_roja==1) estado_luz_roja=0;
else
estado_luz_verde=0;
else
if (estado_luz_verde==1) estado_luz_verde=0;
else
estado_luz_roja=0;
printf("%5.0f %d %d\n",tiempo_transcurrido(),
estado_luz_roja,estado_luz_verde);
return;
}
boton_y_luz_del_mismo_color()
{
int boton;
boton=ultimo_evento.parametro; /* 0:rojo; 1:verde */
if ( (boton==0) && (estado_luz_roja==1) ) return(1);
if ( (boton==1) && (estado_luz_verde==1) ) return(1);
return(0);
}
Pgina 77
hay_solo_una_luz_encendida()
{
int i;
i=estado_luz_roja+estado_luz_verde;
if (i==1) return(1);
else
return(0);
}
enciende_luz_roja_o_verde()
{
int luz;
luz=genera_error(0.5);
if (luz) estado_luz_roja=1;
else
estado_luz_verde=1;
printf("%5.0f %d %d\n",tiempo_transcurrido(),
estado_luz_roja,estado_luz_verde);
return;
}
informa_perdida_juego()
{
printf("Has perdido la partida. Para salir del juego pulsa x\n");
return;
}
lee_evento()
{
struct suceso ultimo_suceso;
int *puntero;
lee_proximo_suceso(&ultimo_suceso);
ultimo_evento.codigo=ultimo_suceso.codigo;
puntero=ultimo_suceso.parametros;
ultimo_evento.parametro=*puntero;
return;
}
lee_teclado()
{
char tecla;
static int boton;
tecla=getch();
if (tecla=='r')
{
boton=0;
genera_suceso(EV2_A,MAQUINA_A,0,&boton,0.);
return;
}
if (tecla=='v')
{
boton=1;
genera_suceso(EV2_A,MAQUINA_A,0,&boton,0.);
return;
}
if (tecla=='x') exit();
}

Desarrollo Protocolos

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Desarrollo Protocolos

Transféré par

Droits d'auteur :

Formats disponibles

Joaqun Luque Rodrguez

Ana Vernica Medina Rodrguez

Joaqun Luque Rodrguez

1.- Conceptos de Ingeniera de Protocolos.

comunicacin de un sistema informtico, es capaz de generar

siguientes (fig. 2):

Figura 1.- Contexto de la Ingeniera de Protocolos

a) Sntesis. Partiendo de la descripcin informal de

especificacin del protocolo. La especificacin de un

Figura 2.- La Ingeniera de Protocolos

Cada una de estas partes de la especificacin debe ser

destacan los siguientes lenguajes normalizados:

Entre estos errores destacan:

repetitiva sin realizar ningn progreso efectivo.

funciones para las que fue diseado, y esto no slo en

diferencia entre la validacin y la verificacin no es

Ingeniera de Protocolos no es slo obtener protocolos,

eficiencia, retardo, longitud de colas y otros, para

optimicen las prestaciones.

f) Generacin de pruebas. Aunque la especificacin haya

actividad se encarga de generar la batera de pruebas a

lenguaje de especificacin de las pruebas normalizado

aprobacin definitiva, debe ser probado con respecto a

respuesta, capacidad de trfico, etc.).

formularse en las siguientes diez reglas bsicas para el

Asegrese de que el problema est bien definido. Todos

Defina los servicios que deben realizarse en cada nivel

servicios (el qu viene antes que el cmo).

Disee la funcionalidad externa de cada nivel o mdulo

pequeas que pueden ser tratadas de forma similar.

Mantenga la simplicidad. Los protocolos rebuscados son

verificar, y normalmente menos eficientes. Existen muy

No mezcle cuestiones que son independientes.

desarrollo resuelve una clase de problemas y no tan

Antes de implementar el protocolo, valide y verifique

el protocolo, y analice sus prestaciones, comprobando

Realice las pruebas de homologacin y prestaciones de

10.- No se salte las reglas 1 a 7.

2.- El problema de la implementacin.

superada ya la fase de especificacin del mismo, presenta

semiautomtica o manual (fig. 3). Por la va automtica la

protocolo ejecutable requerido. En el procedimiento manual

fruto del cual se obtiene un documento de diseo.

c) Por ltimo se procede a codificar el diseo anterior

Figura 3.- La implementacin de protocolos

El procedimiento semiautomtico es una mezcla de los

informtico y codificacin. El resultado puede ser bien una

Cualquiera que sea el mtodo empleado la construccin

definicin de criterios de implementacin, aunque segn el

Cada uno de estos aspectos merece un estudio detenido

Figura 4.- Definicin de criterios de implementacin

Una capa por

Utilizacin de cdigo comn

Ocupa menos espacio

Mayor claridad conceptual

Sistema Operativo multitarea obligatorio

Obligatoria en Sistemas Operativos monotarea

Colas de tamao fijo

Transferencia de control con el IDU

Elimina el problema del control de flujo

Tabla 1.- Representacin de arquitecturas multicapa

2.1.- Representacin de arquitecturas multicapa.

Cuando se aborda el problema de implementar protocolos