ISFDyT “Pte.

Juan Domingo Perón”

Sistemas Operativos III

Unidad II

COMUNICACIÓN EN SISTEMAS
DISTRIBUIDOS

Prof.: Acosta, Jonathan Alejandro

Año 2020
Sistemas Operativos III Unidad II

Comunicación en los sistemas distribuidos

La diferencia principal entre un sistema distribuido y un sistema con un procesador es la comunicación entre
procesos. En un sistema con un procesador la mayor parte de la comunicación entre procesos supone la
existencia de memoria compartida. Un proceso escribe en un buffer compartido y otro proceso lee de él. En un
sistema distribuido no existe tal memoria compartida, por lo que toda la comunicación se basa en la
transferencia de mensajes.
Para los sistemas distribuidos de área amplia relativamente lentos, se utilizan los protocolos de capas orientadas
hacia la conexión como OSI y TCP/IP, dado que el problema principal a resolver es el transporte confiable de los
bits a través de líneas físicas pobres.
Para los sistemas basados en LAN, los protocolos con capas se utilizan muy poco. En vez de ellos, se adopta por
lo general un modelo mucho más sencillo en donde el cliente envía un mensaje al servidor y éste envía de
regreso una respuesta al cliente.
También se utiliza mucho la llamada a procedimientos remotos (RPC). Con ella un proceso cliente que se ejecuta
en una máquina llama a un procedimiento que se ejecuta en otra máquina.

Modelo Cliente - Servidor (C - S)

Es un modelo para el desarrollo de sistemas de información y es la integración de un sistema de red, con
recursos, medios y aplicaciones los cuales definidos modularmente en los servidores, ejecutan y atienden las
solicitudes de los clientes logrando un enlace transparente entre todos sus elementos. Sus componentes son: el
Cliente, el Servidor y la Infraestructura de Comunicaciones.

El servidor contiene la parte que será compartida por varios usuarios y el cliente solo la particular de cada
usuario.
Una computadora es servidor si ejecuta una aplicación/proceso que sea servidor.
Las características más importantes de la arquitectura cliente/servidor son:

Prof.: Acosta, Jonathan Alejandro 1

Sistemas Operativos III Unidad II

 El servidor presenta a todos sus clientes una interface única y bien definida.
 El cliente no necesita conocer la lógica del servidor, solo su interface externa.
 El cliente no depende de la ubicación física del servidor, ni del equipo físico en el que se encuentra, ni de su
sistema operativo.
 Los cambios en el servidor implican pocos o ningún cambio en el cliente.
Middleware es software que se sitúa entre un sistema operativo y las aplicaciones que se ejecutan en él.
Básicamente, funciona como una capa de traducción oculta para permitir la comunicación y la administración de
datos en aplicaciones distribuidas.
A veces, se le denomina “plumbing” (tuberías), porque conecta dos aplicaciones para que se puedan pasar
fácilmente datos y bases de datos por una “canalización”. El uso de middleware permite a los usuarios hacer
solicitudes como el envío de formularios en un explorador web o permitir que un servidor web devuelva páginas
web dinámicas en función del perfil de un usuario.

Beneficios del middleware:

 Pueden obtener una escalabilidad en la existencia de vínculos.
 Tienen la capacidad de hacer muchas tareas en representación del usuario.
 Permite realizar una conversión de los diferentes lenguajes.
 Comunicación más eficiente entre el cliente y el servidor.
 Gracias a un middleware los diferentes usuarios de las compañías acceden a diferentes tipos de
información e interactúan entre sí gracias a estos software.
 Permiten realizar transacciones comerciales.
 Permiten no escribir diferentes interfaces de programación

Tipos de middleware:
 Orientados a procedimiento: A través de procesos rígidos se usa a un Middleware para enlazar dos
procesos que son heterogéneos.
 Orientados a objetos: Se pueden realizar peticiones de forma simultánea de acuerdo a múltiples
clientes. La comunicación es “sincronizada diferida” o “no sincronizada”.
 MOM o Message-oriented Middleware: Existen dos tipos de Middleware (mensaje y espera y
publicación suscripción). El primer tipo trabaja cuando una aplicación envía un mensaje a diferentes
clientes a través del MOM cliente. Este es recibido y ordenado por el servidor MOM y los pone en cola.

Prof.: Acosta, Jonathan Alejandro 2

Sistemas Operativos III Unidad II

Con respecto al segundo, “publicación y suscripción”, un bus de información registra un evento de un

cliente y el publicador envía ese dato de evento al bus de la memoria. En ese momento la información
está disponible en el servidor MOM, el cual envía el anuncio al cliente o subscriptor.
 Orientados a componentes: El Middleware trabaja en una configuración de aquellos componentes que
tienen una función determinada, la cual fue programada para interactuar con otras funciones y
aplicaciones de un programa.
 Agentes: Los agentes cuentan con diferentes funciones específicas que pueden ser objetos o procesos
como también aquellos medios que se usan para la comunicación, tales como tuberías o canales.
 DAM o Data Access Middleware: Se dedican a procesar las transacciones, las puertas de entrada de las
bases de datos y de aquellos software que se distribuyen de acuerdo al procedimiento.
 Middleware de escritorio: Gracias a este tipo de Middleware se pueden realizar variaciones cuando se
presenta la información solicitada por el usuario, ya que se puede controlar el transporte y generar una
copia de seguridad.
 Middleware basados en la web: asisten al usuario cuando este navega por Internet. Se basan en el uso
de interfaz que logran encontrar los sitios que son de interés, como así también sirven para detectar
cambios de preferencias del usuario los cuales están en el historial de navegación.
 Middleware a tiempo real: Tienen la característica de tener la posibilidad de planificar las peticiones
que realiza el usuario. Las cuales son sensibles al tiempo y que se las necesitan en ese instante y no en
otro.
 Middleware especialistas: Esto está relacionado, por lo general, a aquellos usuarios que hacen una
tarea específica. Por lo que no pueden ser ajustados en algunas de las categorías de integración ni de
aplicación que hemos hablado hasta el momento.

A continuación se describen las características de los sistemas desarrollados en arquitectura cliente/Servidor:

Prof.: Acosta, Jonathan Alejandro 3

Sistemas Operativos III Unidad II

Se basa en un “protocolo solicitud / respuesta”:

 Es sencillo y sin conexión.
 No es complejo y orientado a la conexión como OSI o TCP / IP.
 El cliente envía un mensaje de solicitud al servidor pidiendo cierto servicio.
 El servidor:
o Ejecuta el requerimiento.
o Regresa los datos solicitados o un código de error si no pudo ejecutarlo correctamente.
 No se tiene que establecer una conexión sino hasta que ésta se utilice.
 La pila del protocolo es más corta y por lo tanto más eficiente.
 Si todas las máquinas fuesen idénticas solo se necesitarían tres niveles de protocolos.

Direccionamiento
Para que un cliente pueda enviar un mensaje a un servidor, debe conocer la dirección de éste. Los principales
métodos para direccionar procesos son:
 Integrar machine.number al código del proceso cliente: en el que machine indica el número de máquina
dentro de la red y number, el número de proceso dentro de esa máquina. Es un método no transparente.
 Dejar que los procesos elijan direcciones al azar y localizarlos mediante transmisiones: El emisor transmite
un paquete especial de localización con la dirección del proceso destino, todos los núcleos de las máquinas en la
red reciben este mensaje y verifican si la dirección es la suya; en caso de que lo sea, regresa un mensaje “aquí
estoy” con su dirección en la red (número de maquina). El núcleo emisor utiliza entonces esa dirección y la
captura para uso posterior. Su desventaja es que genera una carga adicional en el sistema.
 Generar un servidor de nombres: Cada vez que se ejecute un cliente en su primer intento por utilizar un
servidor, el cliente envía una solicitud al servidor de nombres (en ASCII) para pedirle el número de la máquina
donde se localiza el servidor. Una vez obtenida la dirección se puede enviar la solicitud de manera directa.
 También existe el método de dejar que cada proceso elija su propio identificador: En un espacio de
direcciones grande y disperso, por ej.: enteros binarios de 64 bits. La probabilidad de que dos procesos elijan el
mismo número es muy pequeña. Existe el problema, para el núcleo emisor, de saber a qué máquina enviar el
mensaje:
o En una LAN, el emisor puede transmitir un paquete especial de localización con la dirección del
proceso destino.
o Este paquete de transmisión será recibido por todas las máquinas de la red.
o Todos los núcleos verifican si la dirección es la suya; si lo es, regresa un mensaje aquí estoy con su
dirección en la red (número de máquina).
o El núcleo emisor utiliza esa dirección y la captura para evitar a posteriori una nueva búsqueda del
servidor.

Es un esquema transparente, pero la transmisión provoca una carga adicional en el sistema. Se puede evitar con
una máquina adicional para la asociación de los nombres de servicios y las direcciones de las máquinas.

Prof.: Acosta, Jonathan Alejandro 4

Sistemas Operativos III Unidad II

Primitivas de transferencia de mensajes en C – S

Generalmente se considera que las desventajas de las primitivas asíncronas no compensan las ventajas del
máximo paralelismo que permiten lograr.
Una primitiva síncrona es aquella en que el emisor se bloquea hasta que el receptor ha aceptado el mensaje y la
confirmación regresa al emisor.
 Todo lo demás es asíncrono con este criterio.
 Generalmente a las primitivas de envío se las conoce como send y a las de recepción como receive y
ambas pueden ser con bloqueo o sin bloqueo.
 Una recepción sin bloqueo le indica al núcleo la localización del buffer y regresa el control:
 El problema es saber quién hizo la llamada cuando se llevó a cabo la operación.

Prof.: Acosta, Jonathan Alejandro 5

Sistemas Operativos III Unidad II

Llamada al procedimiento remoto (RPC)

El RPC (del inglés Remote Procedure Call, Llamada a Procedimiento Remoto) es un protocolo que permite a un
programa de ordenador ejecutar código en otra máquina remota sin tener que preocuparse por las
comunicaciones entre ambos. El protocolo es un gran avance sobre los sockets usados hasta el momento. De
esta manera el programador no tenía que estar pendiente de las comunicaciones, estando éstas encapsuladas
dentro de las RPC.

RPC es la transferencia sincrónica de datos y control entre dos partes de un programa distribuido a través de
espacios de direcciones disjuntas. “La manera en que RPC logra hacer esto, es por medio de lo que se conoce
como STUB. En el caso del STUB servidor, se conoce como SKELETON. Estos Stubs y Skeletons permiten que al
momento de ser invocada la función remota esta pueda ser; simulada localmente.

Stub: en computación distribuida es un fragmento de código que convierte los parámetros pasados entre el
cliente y el servidor durante una llamada a procedimiento remoto (RPC).

Skeleton: es el objeto del lado del servidor que decodifica los parámetros, ubica el objeto llamado, llama el
método deseado, codifica el valor retornado, y envía la información de regreso al stub.

Objetivos de RPC
 Proporcionar un middelware que simplifique el desarrollo de aplicaciones distribuidas.
 Evitar que programador tenga que interactuar directamente con el interfaz de Sockets.
 Abstraer (ocultar) los detalles relativos a la red.
 El Servidor ofrece procedimientos que el cliente llama como si fueran procedimientos locales.
 Se busca ofrecer un entorno de programación lo más similar posible a un entorno no distribuido.
 El sistema RPC oculta los detalles de implementación de esas llamadas remotas Implementa la llamada
remota mediante un dialogo petición respuesta -- Mensaje de petición: identifica procedimiento
llamado, contiene parámetros de la llamada -- Mensaje de respuesta: contiene valor/es devuelto/s se
encarga de enviar/recibir mensajes para comunicar ambas partes se encarga de gestionar los contenidos
de esos mensajes (empaquetado y formateado de datos)

El mecanismo de RPC
 El stub del cliente: se encarga de empaquetar los parámetros y la solicitud, enviarlos al intermediario en
el servidor, y luego esperar la respuesta, desempaquetarla y entregarla a la aplicación.
 El programa principal del servidor (que incluye el stub y el dispatcher). se encarga de recibir peticiones,
desempaquetar los parámetros, invocar la función solicitada, pasarle los parámetros, luego obtener el
resultado, empaquetarlo y enviarlo al cliente.
 Las rutinas de serialización de datos: Se debe tomar en cuenta que las máquinas cliente y servidor
puedan ser de arquitectura diferente (y no compatible).
 Servicio de binding: Responsable de la transparencia de localización, gestiona la asociación entre el
nombre del procedimiento remoto (y su versión) con su localización en la maquina servidor (dirección,
puertos, skeleton, etc). Realiza la búsqueda del skeleton de la implementación concreta del
procedimiento remoto llamado por un cliente.

Prof.: Acosta, Jonathan Alejandro 6

Sistemas Operativos III Unidad II

Dispatcher: Parte de un programa encargada de lanzar un proceso en el servidor de un entorno cliente/servidor.

Prof.: Acosta, Jonathan Alejandro 7

Sistemas Operativos III Unidad II

Características del Stub

La base del mecanismo RPC consiste en la introducción de “representantes” que “hacen como si” fuesen el
cliente/servidor
 En el lado cliente, el representante del servidor se denomina Stub (o Proxy).
 El stub es quien proporciona transparencia en la invocación del cliente.
 El stub debe poseer llamadas con la misma declaración (forma) que el servidor.
 El cliente invoca las llamadas del stub “como si” fuese el servidor.
 El stub, a través de un protocolo RPC y con unos mecanismos de aplanamiento, envía un mensaje al
extremo remoto solicitando la “ejecución real” de la llamada.
 El stub, a través de un protocolo RPC y con unos mecanismos de desaplanamiento, recibe un mensaje
del extremo remoto y recupera el “resultado” de la invocación.
 El stub oculta los detalles de referencia del objeto remoto. Es decir, debe saber en qué dirección IP y en
qué puerto hay que contactar con el extremo remoto.
 Cada procedimiento que el cliente quiera invocar a través de RPCs necesita su propio stub.

Características del Skeleton

En el lado servidor, el representante del cliente se llama Skeleton
 El skeleton es quien proporciona transparencia en el lado del servidor.
 El skeleton debe conocer las llamadas ofrecidas por el servidor.
 El skeleton, a través de un protocolo RPC y con unos mecanismos de desaplanamiento, recibe un
mensaje del extremo remoto solicitando la “ejecución real” de la llamada.
 El skeleton invoca la llamada del servidor “como si” fuese el cliente.
 El skeleton, a través de un protocolo RPC y con unos mecanismos de aplanamiento, envía un mensaje al
extremo remoto indicando el “resultado” de la invocación. Cada procedimiento que el servidor exporte
a través de RPCs requiere su propio skeleton.

Prof.: Acosta, Jonathan Alejandro 8

Sistemas Operativos III Unidad II

Tipos de Semánticas
Semántica "tal-vez"
 Procedimiento remoto puede ejecutarse una vez o ninguna vez.
 El cliente puede recibir una respuesta o ninguna.
Funcionamiento
1. El cliente envía una petición y se queda a la espera un tiempo determinado.
2. Si no llega la respuesta dentro del tiempo de espera, continúa su ejecución.
3. El cliente no tiene realimentación en caso de fallo (no sabe que pasó).
Sólo admisible en aplicaciones donde se tolere la pérdida de peticiones y la recepción de respuestas con retraso
(fuera de orden).
Semántica "al-menos-una-vez"
 Procedimiento remoto se ejecuta una o más veces.
 El cliente puede recibir una o más respuestas.
Funcionamiento
1. El cliente envía una petición y queda a la espera un tiempo.
2. Si no llega respuesta o ACK dentro del tiempo de espera, repite la petición.
3. El servidor no filtra peticiones duplicadas (el procedimiento remoto puede ejecutarse repetidas veces).
4. El cliente puede recibir varias respuestas.
Sólo es aplicable cuando se usan exclusivamente operaciones idempotentes (repetibles). Nota: una operación es
idempotente si se puede ejecutar varias veces resultando el mismo efecto que si se hubiera ejecutado sólo una.
En ocasiones una operación no idempotente puede implementarse como una secuencia de operaciones
idempotentes. Admisible en aplicaciones donde se tolere que se puedan repetir invocaciones sin afectar a su
funcionamiento.
Semántica "como-máximo-una-vez"
 El procedimiento remoto se ejecuta exactamente una vez o no llega a ejecutarse ninguna.
 El cliente recibe una respuesta o una indicación de que no se ha ejecutado el procedimiento remoto.
Funcionamiento
1. El cliente envía la petición y queda a la espera un tiempo.
2. Si no llega respuesta o ACK dentro del tiempo de espera, repite la petición.
3. El servidor filtra las peticiones duplicadas y guarda historial con las respuestas enviadas (servidor con
memoria). El procedimiento remoto sólo se ejecuta una vez.
4. El cliente sólo recibe una respuesta si la petición llegó y se ejecutó el procedimiento, si no recibe
informe del error.
.

Prof.: Acosta, Jonathan Alejandro 9

Sistemas Operativos III Unidad II

Comunicación en Grupo
Una hipótesis subyacente e intrínseca de RPC es que la comunicación solo es entre dos partes: el cliente y el
servidor.
A veces existen circunstancias en las que la comunicación es entre varios procesos y no solo dos.
 Ej.: un grupo de servidores de archivo que cooperan para ofrecer un único servicio de archivos tolerante
a fallos:
o Sería recomendable que un cliente envíe el mensaje a todos los servidores para garantizar la
ejecución de la solicitud aunque alguno falle.
 RPC no puede controlar la comunicación de un servidor con muchos receptores, a menos que
realice RPC con cada uno en forma individual.

Un grupo es una colección de procesos que actúan juntos en cierto sistema o alguna forma determinada por el
usuario.
La propiedad fundamental de todos los grupos es que cuando un mensaje se envía al propio grupo, todos los
miembros del grupo lo reciben.
Se trata de una comunicación uno - muchos (un emisor, muchos receptores), que se distingue de
la comunicación puntual o punto a punto (un emisor, un receptor).
Los grupos son dinámicos:
 Se pueden crear y destruir.
 Un proceso se puede unir a un grupo o dejar a otro.
 Un proceso puede ser miembro de varios grupos a la vez.
La implantación de la comunicación en grupo depende en gran medida del hardware:
 En ciertas redes es posible crear una dirección especial de red a la que pueden escuchar varias
máquinas:
o Cuando se envía un mensaje a una de esas direcciones se lo entrega automáticamente a todas
las máquinas que escuchan a esa dirección.
o Esta técnica se denomina multitransmisión.
o Cada grupo debe tener una dirección de multitransmisión distinta.
Las redes que no soportan multitransmisión operan con transmisión simple:
 Significa que los paquetes que tienen cierta dirección se entregan a todas las máquinas.

Prof.: Acosta, Jonathan Alejandro 10

Sistemas Operativos III Unidad II

 Se puede utilizar para implantar los grupos, pero es menos eficiente que la multitransmisión.
 Cada máquina debe verificar, mediante su software, si el paquete va dirigido a ella:
o En caso negativo se descarta, pero para analizarlo se generó una interrupción y se dedicó ciclos
de cpu.
Otra solución es implantar la comunicación en grupo mediante la transmisión por parte del emisor de paquetes
individuales a cada uno de los miembros del grupo:
 En vez de un paquete se precisan “n” paquetes.
 Es menos eficiente que las soluciones anteriores.
 Es una solución válida particularmente con grupos pequeños.
 El envío de un mensaje de un emisor a un único receptor se llama unitransmisión.

Prof.: Acosta, Jonathan Alejandro 11

Sistemas Operativos III Unidad II

Tolerancia a fallos.
La tolerancia a fallas es considerada la principal característica que debe de tener un sistema distribuido para
alcanzar el principio de transparencia. Para lograr la tolerancia a fallos se necesita de una buena comunicación
entre procesos distribuidos y sobre todo de una correcta coordinación entre ellos.

Un Sistema Distribuido en base a la coordinación de sus procesos puede ser:

Asíncrono: no hay coordinación en el tiempo.

Síncrono: se suponen límites máximos para el retraso de mensajes.
El primer factor a tomar en cuenta es que el canal de comunicación este libre de errores (canal confiable). Para
garantizar que el canal sea confiable se debe tener QoS (Calidad en el Servicio) que implica realizar lo siguiente:
- Retransmisión de mensajes.
- Establecer redundancia de canales.
- Poner límite al tiempo de entrega de un paquete en lapso especificado.

Prevención en la Tolerancia a Fallos

Existen dos formas de aumentar la fiabilidad de un sistema.

 Prevención de fallos: Se trata de evitar que se implementen sistemas que pueden introducir fallos.

 Tolerancia a fallos: Se trata de conseguir que el sistema continué funcionando correctamente aunque se
presenten algunos fallos.

Un sistema que sea tolerante a fallos debería tener disponibilidad, confiabilidad, seguridad y con un programa
de Mantenimiento.

 Disponibilidad: La cualidad de un sistema de estar preparado en todo momento para operar.

 Confiabilidad: La garantía de que el Sistema puede llevar a cabo su trabajo con muy bajas
probabilidades de una caída repentina.

 Seguridad: La característica de que el Sistema puede recuperarse o repararse a sí mismo en caso de

presentarse algún tipo de fallo.

 Mantenimiento: Se refiere a que el sistema puede ser remplazado o reparado rápidamente mediante
los lineamientos un programa preventivo y un plan de contingencia.

Prof.: Acosta, Jonathan Alejandro 12

Sistemas Operativos III Unidad II

Tipos de fallos
Fallos en sistemas cliente-servidor.
En este esquema la capa de transporte se encarga de los fallos en comunicaciones, sin embargo si se usan
datagramas en vez de paquetes, es la aplicación la que tendrá que encargarse de ordenar dichos datagramas
fuera de secuencia, solicitar su retransmisión y/o restablecer los enlaces. La capa de transporte por sí misma
otorga el concepto de Calidad en el Servicio, (QoS) pero no es una solución definitiva para todos los casos.

Fallos en sistemas con RPC.

Pueden presentarse varias fallas, que el cliente no encuentre al servidor, que la petición del cliente se pierda
dentro del servidor o en la red , que el servidor se caiga al procesar un mensaje, que la respuesta del servidor a
una petición se pierda o que el cliente haga crash al recibir un mensaje. La responsabilidad principal en este
tema es la de restablecer y detener procesos para rebootear las maquinas, lo cual puede implicar que no se
restablezcan o no se detengan ciertos procesos concurrentes. Nuevamente, lo importante es el plan de acción
del sistema y la detección del origen del problema, ya que de ahi surge el mecanismo de restablecimiento del
fallo.

Errores Parciales vs. Errores graves.

Una característica de los S.O. distribuidos que los difiere de los sistemas centralizados es la noción de errores
parciales. Un error parcial es cuando algún componente del sistema falla, lo cual puede afectar algunos otros
componentes dentro de la red pero otros pueden seguir continuando sin ningún problema. EL secreto de la
buena operación es recuperar el fallo sin interrupción del servicio o afectación del rendimiento global, hecho
que depende a su vez del tipo de fallo, consideremos los siguientes:

 Falla de procesos: La ejecución arroja un estado incorrecto, los procesos provocan que el sistema se
desvíe de las especificaciones y el proceso con fallo pueda suspenderse momentáneamente.

 Falla de sistema: Ocurre por el algún desorden en el software y problemas del HW (como errores de
CPU, falla en la memoria principal, falla de energía, etc.)
 En caso de una falla de este tipo el sistema es detenido y reiniciado a un estado correcto, no obstante
que es un error generalizado no es tan grave, pero vale la pena documentarlo.

 Falla de amnesia: Ocurre cuando se reinicia el sistema a un estado predefinido, no depende del estado
del sistema antes de la falla sino de una mala calendarización. Tampoco es grave.

 Falla de Pausa: Ocurre cuando se reinicia el sistema al mismo estado en que se encontraba antes de la
falla. Tampoco es grave.

 Falla en medio de almacenamiento secundarios: Se dice que ocurre una falla de este tipo cuando los
datos almacenados no pueden ser accedidos (cualquiera de sus partes o en su totalidad) entonces
buscamos el restablecimiento por redundancia. Nótese que no obstante la naturaleza crítica de los fallos
mencionados, su efecto en el sistema en general es menos severo por virtud de la distribución.

Prof.: Acosta, Jonathan Alejandro 13

Sistemas Operativos III Unidad II

Recuperación de errores
Una forma prospectiva de trabajar con los errores es considerar que un error es un estado del sistema que es
distinto a los valores esperados, de tal suerte que la recuperación de una falla se aborda como un proceso de
recuperación de estados hasta un estado libre de error, puede ser previo o posterior.

Hay dos enfoques para hacer lo anterior:

1- Si la naturaleza del error y los daños causados pueden ser completamente calculados, entonces es posible
remover esos errores del estado del proceso (o sistema) y habilitar el movimiento hacia adelante del proceso a
un estado libre de error. Esta técnica es conocida como recuperación hacia adelante.

2- Si no es posible prever la naturaleza de las fallas y remover todos los errores en el estado del proceso (o
sistema), entonces el estado del proceso puede ser restaurado a un estado previo libre de error. Esta técnica es
conocida como recuperación hacia atrás.

La recuperación hacia adelante significa cercenar el fallo, y soslayarlo, de tal suerte que se asume la pérdida del
tiempo de procesamiento y los recursos involucrados. En cambio, en la recuperación hacia atrás, el proceso con
revertido a un estado previo con la esperanza de que ese estado previo esté libre de errores.

Hay dos formas de implementar una recuperación de error hacia atrás: el enfoque basado en la operación y el
enfoque basado en estado. Supongamos que tenemos un sistema modelo, que consiste de una máquina simple.
Asumimos que la máquina está conectada a un sistema de almacenamiento secundario y a un sistema de
almacenamiento estable que no pierde datos en caso de falla. El almacenamiento estable es usado para
almacenar un registro de las transacciones y puntos de recuperación. En comparación al almacenamiento
secundario, el almacenamiento estable es mucho más seguro, pero el almacenamiento secundario trabaja
continuamente.

a) Enfoque basado en la operación: Aquí, todas las modificaciones que se hacen al estado de un proceso son
registradas con suficiente detalle; para revertir el proceso a un estado previo, se procesan las transacciones de
este registro pero marcha atrás.

b) Enfoque basado en estado: El estado completo de un proceso es guardado en una instancia llamada punto de
restauración o verificación y su recuperación involucra reiniciar la ejecución del proceso en alguno de esos
puntos. Establecer esta instancia se conoce como tomar un punto de verificación. El punto de restauración es
entonces también un punto de revisión.

Al proceso de restauración de un proceso a un estado anterior se le refiere como rolar al proceso hacia atrás y al
proceso de reiniciar la ejecución en un estado se le conoce como transición forzada. Ambos métodos significan
el consumo de tiempo de CPU y retardan la terminación del proceso, mas es preferible retroceder el proceso
que cancelarlo. Por ello se acostumbra establecer muchos puntos de revisión.

Prof.: Acosta, Jonathan Alejandro 14