INSTITUTO TECNOLÓGICO DE

CHETUMAL
Ingeniería en Tecnologías de la Información y
Comunicaciones

Sistemas Operativos II

Docente: Calos Azueta.

Alumno: Albores Chi Juan Leonel, Wilmer Morales Gómez, Jorge

Francisco Miguel.
Unidad 2: Comunicación en los sistemas operativos distribuidos.
Semestre: 7°

Fecha: Viernes 11 de Septiembre de 2015

Contenido
Contenido ........................................................................................................................................ 1
1 Comunicación: comunicación con cliente–servidor, comunicación con llamada a
procedimiento remoto, comunicación en grupo, tolerancia a fallos. .............................. 3
1.2 Comunicación Cliente-Servidor....................................................................................... 3
1.3 Comunicación por RPC (Remote Call Procedure) ...................................................... 4
1.4 Comunicación entre grupos de procesos. ................................................................... 5
1.5 Tolerancia a Fallos .............................................................................................................. 7
2 Sincronización: relojes físicos, relojes lógicos, usos de la sincronización. ............ 12
1.1 Relojes Físicos ................................................................................................................... 13
1.2 Relojes Lógicos ................................................................................................................. 13
1.3 Sincronización .................................................................................................................... 14
3. Nominación: características y estructuras, tipos de nombres, resolución y
distribución, servidores y agentes de nombres, mapeo de direcciones, mapeo de
rutas, modelo de Terry. ............................................................................................................... 16
1.1 Características ................................................................................................................... 17
1.2 Estructuras de nombres .................................................................................................. 17
1.3 Tipos de nombre ................................................................................................................ 18
1.4 Agentes y Servidores de nombres. .............................................................................. 20
1.5 Mapeo de rutas ................................................................................................................... 20
1.6 Mapeo de direcciones ...................................................................................................... 20
1.7 Modelo Terry ....................................................................................................................... 21
4 Comunicación de procesos a través del paso de mensajes en sistemas
distribuidos. ................................................................................................................................... 22
Comunicación Simétrica. ....................................................................................................... 23
Comunicación Asimétrica. ..................................................................................................... 23
Conclusión ..................................................................................................................................... 25
Bibliografía ..................................................................................................................................... 26
Modelos de comunicación. Una de las tareas más complejas en S.O.D. es la
implementación y uso de memoria compartida, ya que esto nos obliga a atravesar
las capas de software construyendo un puente de comunicación con una estructura
de memoria no monolítica sobre la arquitectura de red. Han sido estudiadas desde
hace tiempo y están establecidas como paradigma tecnológico; para poder
transferirlas se requiere un mecanismo de paso de mensajes, (mediante colas FIFO
y buffers), el paso de mensajes parece el mecanismo de comunicación natural en
sistemas débilmente acoplados, pero al igual que cualquier tecnología tiene
ventajas y desventajas, en este caso respecto a las alternativas con RPC's (llamada
a procedimientos remotos) independientemente de si usa o no variables
compartidas; Entonces el costo de recursos para mantener variables
compartidas en un ambiente multi-equipos es alto y equivalente al costo de diseñar
y operar los algoritmos de paso de mensajes o administrar RPC's, y si se desea
restar complejidad a cualquiera de ambos métodos habrá de ser mediante el
sacrificio de la eficiencia por la simplicidad.
1 Comunicación: comunicación con cliente–servidor,
comunicación con llamada a procedimiento remoto, comunicación
en grupo, tolerancia a fallos.

1.2 Comunicación Cliente-Servidor.

Es una arquitectura de paso de mensajes, que puede operar variables compartidas
mediante un archivo público de acceso remoto (tipo CGI-BIN o MIME); es una
solución muy socorrida pues su propiedad de distribución de trabajo aprovecha la
versatilidad de que un servidor puede también ser cliente de otros servidores. El
acceso a los terceros recursos se hace mediante el intermedio del servidor, quien
se convierte en cliente de otros. Por ejemplo un servidor web puede ser cliente de
los servicios DNS, MySQL, POP3, SMTP, pero ser anfitrión de Java, PHP, ASP,
HTML, FTP; o por ejemplo un buscador web es servidor de consultas para usuarios
pero es cliente de toda la web en dónde hace sus búsquedas. El número de
encadenamiento entre nodos cliente-servidor con otros iguales debería ser muy
grande pues esto exigiría tareas extra de administración de tráfico, que están
contempladas inherentemente en el propio esquema de paso de mensajes. El
número de encadenamiento de clientes-servidores se define como Modelo de N
capas.

En un sistema distribuido, las necesidades de comunicación conducen a utilizar

esquemas específicos de gestión de los recursos para los que el paso de mensajes
resulta adecuado. Un recurso estará a cargo de un proceso gestor, con quien
deberá comunicarse cualquier proceso que pretenda acceder a él, siguiendo un
esquema cliente-servidor; lo que permite expresar el acceso a servicios mediante
un protocolo de petición-respuesta. El modelo cliente-servidor se puede
implementar mediante un mecanismo de paso de mensajes específico, como por
ejemplo el mecanismo de transporte TCP para HTTP y HTTPS, la Interfaz CGI/BIN
o la interfaz de sockets de UNIX para TCP/IP o UDP/IP.
1.3 Comunicación por RPC (Remote Call Procedure)
Para trabajar con procesos distribuidos que necesitan compartir recursos con otros
procesos también se han diseñado interfaces que permiten manejar un espacio de
direcciones común sobre un sistema de memoria física distribuida: sistemas
de memoria compartida distribuida (DSM). La idea es ofrecer a las aplicaciones
diseñadas según un modelo de memoria compartida, un soporte para su ejecución
en un entorno distribuido. Con el objetivo de disminuir la diferencia semántica entre
programas que usan servicios locales (mediante llamadas al sistema) y programas
que usan servicios remotos, se han desarrollado mecanismos que encapsulan los
detalles de direccionamiento y sincronización del envío-recepción de la petición y/o
respuesta.

Así, en los lenguajes procedurales, las llamadas a procedimientos remotos RPC's

(Remote Precedure Call), proporcionan una sintaxis de llamada a función como
interfaz para el acceso a servicios.
Ejemplo de RPC:
En los lenguajes orientados a objetos, cada recurso es un objeto identificado
unívocamente en el sistema distribuido, al que se accede invocando los métodos
definidos para esa clase de objeto. El acceso a os objetos se realiza mediante una
interfaz de invocación de métodos remotos (por ejemplo, RMI de Java).
La Tabla siguiente resume los mecanismos que implementan los modelos de
comunicación sobre arquitecturas de memoria independiente y memoria
compartida.
1.4 Comunicación entre grupos de procesos.
En sistemas distribuidos es de gran interés el soporte de primitivas de paso de
mensajes de amplia cardinalidad es decir de 1:N, ya que existe la necesidad de
intercomunicar a los procesos con otros, ya sea replicados o similares, ya sean
procesos anfitriones o clientes de otros. El concepto de grupos de procesos que se
comunican entre sí crea la necesidad de un gestor, cuyas funciones son similares a
aquellas de las tareas de Control de Acceso a Usuarios.
Una de las formas de comunicación con cardinalidad múltiple es el de difusión; que
permite enviar un mensaje a todas las direcciones accesibles por el emisor, y se
usa en redes locales. Un caso particular de defunción, el multicast, permite
seleccionar un subconjunto de direcciones a las que enviar el mensaje. El soporte
para multicast es muy útil en sistemas replicados, como se verá más adelante.
Como ejemplo, el protocolo IP reserva un conjunto de direcciones para multicast.
Ejemplo de Comunicación entre Grupos:
El estándar de POSIX significa Interfaz de Sistema Portable tipo UNIX,
(Portable Operating System Interface UniX type) y establece una familia de
estándares de llamadas al sistema operativo definidos por el IEEE y especificados
formalmente en el IEEE 1003. Persiguen generalizar las interfaces de los sistemas
operativos para que una misma aplicación pueda ejecutarse en distintas
plataformas. Estos estándares surgieron de un proyecto de normalización de
las API y describen un conjunto de interfaces de aplicación adaptables a una gran
variedad de implementaciones de sistemas operativos.
Los grupos de procesos que se diseñan bajo una especificación POSIX trabajan en
función de señales. Una señal es una instrucción de alto nivel que se dirige a un
grupo de procesos, la razón de esto es que a diferencia de un S.O. centralizado, en
el que se ha de multiplexar (Intercalar) la ejecución de varios procesos, aquí la
distribución de un proceso obedece a una necesidad de terminarlo en menor tiempo
dividiéndolo en tareas más pequeñas, todas idénticas repartidas por la red; de tal
manera que es fácil entender las funciones del administrador de grupos de procesos
pues es más simple replicar un proceso idéntico muchas veces, que manejar un
conjunto diverso de procesos.
Los grupos de procesos están a su vez agrupados en sesiones, que residen en una
capa de software que se encarga de administrarlos de la misma forma en que se
administran las sesiones de usuarios. Los grupos de procesos no pueden migrar de
una sesión a otra, y un proceso sólo puede crear nuevos grupos de procesos que
pertenezcan a la misma sesión a la que pertenece. Un proceso únicamente puede
unirse a un grupo de procesos que esté en su misma sesión. Nuevas imágenes de
proceso creadas por una llamada a una función de la familia exec heredarán el
grupo de proceso y la sesión de la imagen original.
Un segundo uso no relacionado del término grupo de procesos aparece en el
contexto de sincronía virtual, un modelo de ejecución distribuido en el que grupos
de procesos corriendo en diferentes máquinas se asocian para compartir eventos,
replicar datos o coordinar acciones, no tanto basado en un reloj de tiempo real sino
en un esquema de eventos disparadores.
El desarrollo de Internet está forzando la evolución de los protocolos de nivel de
red. Así, el protocolo IPv4, cuyas direcciones de 32 bits suponen un problema de
escalabilidad, está dejando paso al IPv6, que especifica direcciones de 128 bits.
Internet y los nuevos paradigmas de cómputo están imponiendo sus estilos de
comunicación. De este modo, se aprecia una tendencia general a la utilización de
HTTP como protocolo de acceso a servicios, como evolución del esquema RPC
clásico. Por otra parte, la distribución de servicios ha provocado una evolución del
esquema cliente-servidor clásico hacia estructuras peer-to-peer, donde los roles de
cliente y servidor son intercambiables. En tales sistemas, habitualmente dinámicos,
los nodos indistintamente ofrecen y solicitan servicios, y eventualmente cooperan
en la búsqueda de servicios y en el encaminamiento de peticiones.

Podemos resumir la Disposiciones Generales de la comunicación:

Utilizando el servicio básico de acceso al medio, el cliente debe localizar e iniciar la
comunicación con el servidor.
No se utiliza la metodología de compartición de archivos, ya que todos los accesos
a la información se llevan a cabo a través de servicios de datos (paquetes o
datagramas).
Los programas de manejo y control de información solo se envían y reciben los
resultados de las operaciones.
Debido a la flexibilidad de establecer sesiones con múltiples servidores y manejo de
información en varias bases de datos (en sitios remotos es requerido el uso de
estilos transaccionales y cooperativos).
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 esté 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.

En general, se considera que los canales de comunicación son fiables y que cuando
falla la comunicación es debido a la caída del proceso, sin embargo algunos fallos
en el funcionamiento de un Sistema Distribuido pueden originarse por:
- Especificaciones impropias o con errores.
- Diseño deficiente del software o el hardware.
- Deterioros o averías en hardware.

1.5 Tolerancia a Fallos

Existen dos formas de aumentar la fiabilidad de un sistema.
1. Prevención de fallos: Se trata de evitar que se implementen sistemas que
pueden introducir fallos.
2. 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.

En el aspecto preventivo deben tomarse en cuenta que se pueden presentar Fallos

Transitorios (se presentan una vez y al volver a intentar la operación ya no ocurren),
Intermitentes (se presentan de forma cíclica o al ejecutar ciertas operaciones) y
Permanentes (no se resuelven hasta remplazar lo dañado). La orientación del
mantenimiento debe definir cuál de estos escenarios es el que se presenta; de
hecho el primero es el más difícil de atender pues el primer paso para reparar una
falla es aislarla e identificarla.
Una buena estrategia comienza con la clasificación e identificación del universo de
fallas, ya que cada una de ellas debe tener un plan emergente en consecuencia, la
siguiente figura resume un esquema de este tipo:
El aspecto fundamental es identificar las causas de la falla, que es la labor más
complicada, sobre todo en el entendido de que no se debe interrumpir el servicio.
Nuevamente, los fallos que no presentan un patrón repetitivo son los más difíciles
de identificar y por lo tanto de resolver. La experiencia y el hecho de conocer a
detalle el sistema funcionando por largo tiempo pueden ayudar en este respecto.

Una de las acciones necesarias se conoce como enmascaramiento de errores por

redundancia, que consiste en ocultarlos a los procesos no locales por medio de:

a) Redundancia de Tiempo.
b) Redundancia de Información.
c) Redundancia física.

Todos estos significan duplicar el recurso correspondiente, de tal manera que

siempre haya un remplazo disponible, un mecanismo de corrección de errores en
datos, y un esquema de reintentos de operaciones; la estrategia resultante se
establece bajo la premisa de que es inevitable que aparezcan fallos, sobre todo en
comunicaciones. De tal suerte los mecanismos de checksum, paridad etc. son muy
socorridos para operar el ambiente distribuido.

Otro punto clave es el uso de Grupos de Procesos, que entre otras cosas facilita la
comunicación con múltiples entidades remotas, así es más fácil el direccionamiento
por grupos que por entidades individuales; especialmente en el ámbito de fallos en
procesos, es importante comunicarse con la entidad donde ocurre el fallo, pero
también el notificar a las otras entidades que comparten el recurso que falla. Los
grupos pueden dar tratamiento a los errores de forma cooperativa o mediante una
jerarquía que delimita quienes participan en ello, las soluciones generalmente tienen
efectos colaterales, por ejemplo las jerarquías de procesos pueden generar
procesos huérfanos, o las cooperativas pueden ser ineficientes si la dispersión
aumenta.

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 ahí 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.

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.

2 Sincronización: relojes físicos, relojes lógicos, usos de la

sincronización.

Sincronización.
La sincronización de procesos en los sistemas distribuidos resulta más compleja
que en los centralizados, debido a que la información y el procesamiento se
mantienen en diferentes nodos.
Un sistema distribuido debe mantener vistas parciales y consistentes de todos los
procesos cooperativos.
Sincronización es la forma de forzar un orden parcial o total en cualquier conjunto
de evento.
Se utilizan algoritmos distribuidos para sincronizar el trabajo común entre los
procesos y estos algoritmos tienen las siguientes propiedades:
Inaceptable que se concentre en un nodo, a toda la información y procesamiento.

1.1 Relojes Físicos

Los relojes físicos son relojes que: Deben ser iguales (estar sincronizados).No
deben desviarse del tiempo real más allá de cierta magnitud. En ciertos sistemas
es importante la hora real del reloj:
 Se precisan relojes físicos externos (más de uno).
 Se deben sincronizar: Con los relojes del mundo real.

1.2 Relojes Lógicos

El software del reloj lógico
El software para el reloj toma generalmente la forma de un manejador de dispositivo,
aunque no es un dispositivo de bloque.
Las principales funciones del software manejador del reloj son:
 Mantener la hora del día o tiempo real
 Evitar que los procesos se ejecuten durante más tiempo del permitido.

 Mantener un registro del uso del CPU.

 Controlar llamadas al sistema tipo "alarm" por parte de los procesos del
usuario.
 Proporcionar cronómetros guardianes de partes del propio sistema
 Realizar resúmenes, monitoreo y recolección de estadísticas.

1.3 Sincronización
La sincronización es la coordinación de procesos que se ejecutan simultáneamente
para completar una tarea, con el fin de obtener un orden de ejecución correcto y
evitar así estados inesperados que interrumpan la Comunicación en los sistemas
operativos distribuidos.
Memoria Caché
En los sistemas de archivos convencionales, el fundamento para la memoria caché
es la reducción de la E/S de disco (lo que aumenta el rendimiento), en un SAD
(Sistema de Archivos Distribuido) el objetivo es reducir el tráfico en la red.
La copia de memoria caché.
Conservar allí los bloques de disco de acceso más reciente, para así manejar
localmente los accesos repetidos a la misma información y no aumentar el tráfico
de la red. La caché es un área de memoria utilizada para agilizar los procesos de
lectura-escritura.
Exclusión mutua
La condición de exclusión mutua se aplica a los os que no pueden ser compartidos.
Por ejemplo, varios procesos no pueden compartir simultáneamente una impresora.
Los archivos de sólo lectura son un buen ejemplo de recurso que puede
compartirse. Si varios procesos intentan abrir un archivo de sólo lectura al mismo
tiempo, puede concedérseles acceso al archivo de forma simultánea. Un proceso
no necesita esperar nunca para acceder a un recurso compartible
Algoritmos de Elección
Son los algoritmos para la elección de un proceso coordinador, iniciador,
secuenciador. El objetivo de un algoritmo de elección es garantizar que iniciada una
elección ésta concluya con el acuerdo de todos los procesos con respecto a la
identidad del nuevo coordinador.
Transacción atómica, transacción o acción atómica.
La principal propiedad de la transacción atómica es el “todo o nada”: O se hace todo
lo que se tenía que hacer como una unidad o no se hace nada.
Un esquema para garantizar la adecuada sincronización de la información en
sistemas centralizados como distribuidos es el uso de transacciones.
Las transacciones manejan 4 propiedades básicas: atómicas, consistentes, aisladas
y durables (ACID por sus siglas en inglés).
Las primitivas de las transacciones son:
 BEGIN_TRANSACTION (inicio de transacción)
 END_TRANSACTION (fin de transacción)
 ABORT_TRANSACTION (deshacer operación)
 READ (leer datos de un archivo u objeto)
 WRITE (escribir datos a un archivo u objeto)

Interbloqueo
Una situación de interbloqueo tiene lugar cuando ninguno de los procesos que
compiten.
Por los recursos del sistema o interactúan entre sí puede avanzar por carecer de
algún recurso o esperar a que se produzca algún tipo de evento.
El interbloqueo se define como el conjunto de procesos que compiten por los
recursos del sistema o bien se comunican unos con otros. A diferencia de otros
problemas de la gestión de concurrente de procesos, para el caso general no existe
una solución eficiente.

3. Nominación: características y estructuras, tipos de nombres,

resolución y distribución, servidores y agentes de nombres,
mapeo de direcciones, mapeo de rutas, modelo de Terry.

Nominación: En los sistemas distribuidos los nombres hacen referencia a cualquier

entidad, ya sea un archivo, un periférico, un proceso, etc. que se pueden encontrar
en máquinas remotas.
Los servidores de nombres ayudan a localizar fácilmente y hacer transparente el
acceso a los recursos (transparencia de localización).
1.1 Características
Una de las tareas más relevantes en la operación de Sistema Operativo Distribuido.
Es la administración de recursos, que se presentan estructurados en plataformas o
catálogos de servicios y aplicaciones. Las fronteras entre plataformas de trabajo son
muy relativas, pero imponen restricciones porque las prestaciones del sistema
operativo operan siempre en el direccionamiento de bajo nivel, y al trasladar su
servicio a un ambiente distribuido tenemos que diferenciar cada entidad para que
puedan compartir los recursos.
Entonces el direccionamiento normal del S.O. puede extenderse a un ambiente de
red mediante una capa de software que etiqueta los identificadores de recursos
nombres que pueden ser o no simbólicamente más significativos, pero que
establecen un conjunto de elementos del sistema con reglas particulares en una
nomenclatura. Este conjunto y sus reglas constituyen un pequeño universo llamado
Dominio. El uso de etiquetas en un dominio es un elemento creador de contexto,
que nos ayudará a localizar y transparentar el acceso a los recursos, logrando la
conectividad de entidades y la transparencia de localización.

1.2 Estructuras de nombres

La nominación es una correspondencia entre objetos de datos lógicos y físicos. Por
ejemplo, los usuarios tratan con objetos de datos lógicos representados por nombre
de archivos, mientras que el sistema manipula bloques de datos físicos
almacenados en las pistas de los discos. Generalmente un usuario se refiere a un
archivo utilizando un nombre, el cual se transforma en un identificador numérico de
bajo nivel, que a su vez se corresponde con bloques en disco. Esta correspondencia
multinivel ofrece a los usuarios la abstracción de un archivo, que oculta los detalles
de cómo y dónde se almacena el archivo en disco, pero implica el manejo de una
estructura semántica que si bien no requiere de ser perfecta, debe ser consistente.
Hay por lo menos cuatro principios básicos que una convención de nombramiento
debe satisfacer:
Generalidad: Una convención de nombramiento debe poder nombrar una variedad
de entidades en diversas aplicaciones tanto como en diversos ambientes.
Múltiples definiciones de la misma entidad (alias): porque una entidad puede ser
conocida por diversos nombres en diversos ambientes, la convención de
nombramiento debe permitir la característica de nombres múltiples y dejar el
problema de la resolución a algunos mecanismos de la conversión de dirección.
Distribuible: Es probable que la convención de nombramiento se manifieste, en una
cierta forma, como directorio, ayudar a la validación y a la conversión de direcciones
conocidas. Los nombres de la base de datos se pueden fragmentar entre los
anfitriones de la red, basados posiblemente en la organización geográfica ó en los
requerimientos de los usuarios.
Amigable al usuario: El usuario debe estar en una posición para deducir el nombre
de entradas del conocimiento que él posee. El convenio del nombramiento no debe
permitir ningún alcance para la interpretación incorrecta de los nombres.

1.3 Tipos de nombre

Hay tres enfoques principales para los esquemas de nominación.
El primero consiste en que los archivos se nombran con una combinación del
nombre de su anfitrión y su nombre local, lo que garantiza un nombre único dentro
de todo el sistema.
El segundo enfoque popularizado por el sistema de archivos de red NFS (Network
File System) de Sun Microsystems, ofrece una forma de unir directorios remotos a
directorios locales, lo que da la apariencia a un árbol de directorios monolítico.
El tercer enfoque utiliza la noción de que cualquier directorio se puede unir a
cualquier árbol de direcciones locales con la jerarquía resultante que puede estar
poco estructurada.
Hay que tener presente que la complejidad semántica de la estructura puede
balancearse hacia sistemas de nombres menos compactos pero más largos. Al final
hay que gastar ese recurso informático en espacio de almacenamiento o tiempo de
procesamiento (un algoritmo). La elección de un enfoque u otro nos llevará igual a
un esquema conceptual de nominación, por ejemplo usar nombres de animales para
los servidores. Ya que se busca evitar en lo posible la ambigüedad, es deseable
que ningún objeto tenga el mismo nombre que otro objeto, sin importar que sean
idénticos, deben ser inconfundibles. Las primitivas de acceso a a los servicios no se
compilan y por lo tanto queda a las capas de aplicación procesarlas (refinarlas o
prepararlas) si esto es necesario, por ejemplo para evitar fallas por errores.
Los nombres de ciertos recursos pueden ser absolutos o relativos dependiendo de
la importancia del domicilio de su ubicación, es una cuestión de rol, ya que un
nombre relativo cumple un rol definido en su contexto (root, anonymous, invitado);
mientras que un nombre absoluto no requiere necesariamente de ello. Otro
mecanismo de optimización es que los nombres pueden tener alias, los cuales son
otros nombres más compactos que se usan en contextos específicos para hacer
referencia al mismo objeto de forma más económica lo que permite usar
encabezados más pequeños en los mensajes relativos a los recursos.
Algunas consideraciones generales para el uso de nombres son las
siguientes:
Los identificadores se utilizan para una variedad amplia de propósitos, tales como:
referencia, localización, programación, manejo de recurso, control de errores,
sincronización, protección, y compartición de recursos.
Los identificadores (nombres; Nombres del usuario y de sistema, y puertos;
direcciones; y las rutas) existen en diversas formas en todos los niveles de la
arquitectura de un SD.
Los identificadores aparecen en diversas formas (convenientes para la gente o las
computadoras). Algunos son únicos dentro de un contexto global para el sistema
entero (Internet), otros son únicos solamente dentro de un contexto local (red
sencilla).
Los nombres pueden referir el objeto directa o indirectamente:
 Por un nombre o una dirección explícita
 Por la fuente
 Por el identificador del grupo
 Por la ruta de acceso
 Resolución y distribución
La resolución es el proceso de convertir un nombre hacia la ubicación real del
recurso, como mencionamos antes, esto nos obliga crear una tabla de asociaciones
de nombres lógicos con los recursos físicos. Aunque es un trabajo simple, vale la
pena considerarlo seriamente desde un punto de vista de la cardinalidad; la cual
surge de la necesidad de comunicar a cualquier recurso con todos los demás.
Aunque el mecanismo es bastante sencillo, los S.O.D. requieren que en todo
momento el acceso a un recurso se controle y/o documente; por lo que en toda
transacción se registra el objeto y/o el usuario que accede al recurso transparente.
Esto funciona de manera natural en los servidores HTTP o en sistemas UNIX, pero
en un ambiente distribuido no existe de manera explícita un control de transacciones
ya que éstas están dispersas.
1.4 Agentes y Servidores de nombres.
Las entidades que contienen los repositorios donde se almacenan los nombres en
los modelos de 3-capas en adelante, atienden a un solo cliente que a su vez es
quien entrega los nombres resueltos a los destinatarios. Existen entonces 2 roles
para el servicio de nombres, los servidores que tienen un estructura completa de
acceso público y los agentes que son los módulos de software encargados de
solicitar la solución de los nombres.
1.5 Mapeo de rutas
Como hemos visto, en algunos recursos como los nombres, las direcciones de
memoria y dispositivos de e/s, existe el concepto del recurso físico, cuando es
direccionado directamente; y del recurso lógico cuando es direccionado mediante
un mecanismo de abstracción. El mapeo de rutas es un mecanismo imprescindible
para el acceso a recursos en directorios compartidos, es una abstracción que
permite compactar los encabezados y establecer la sintaxis para adaptarlos a
variables de entorno locales de las entidades.
En un sistema distribuido, el usar un nombre para los propósitos de la comunicación
no es bastante, ya que los procesos se comunican desde diferentes computadoras.
El conocimiento de su localización actual es necesario, lo que conduce a los
parámetros mínimos de referencia: un nombre, una dirección, y una ruta.
Este conjunto contiene un objeto (por ejemplo, un recurso o un servidor) específico,
al cual busca el proceso solicitante, mediante una dirección específica y la ruta
dentro de esa dirección específica. Cada uno de estos identificadores representa un
atascamiento más apretado de la información; Los nombres son mapeados en
direcciones, este mapeo es necesario para la aplicación en ejecución, puesto que
la sintaxis y la semántica de nombres dependen enteramente de qué tipos de
entidades se están nombrando y también qué uso se está haciendo de ellas. A su
vez las direcciones son mapeadas en los enrutadores y las rutas en las tableas de
enrutamiento.

1.6 Mapeo de direcciones

Para que un cliente pueda enviar un mensaje a un servidor, debe conocer la
dirección de éste. El Kernel del emisor tiene que construir un mensaje con el número
de la solicitud, la dirección de enlace de los datos y colocar el mensaje en la LAN.
La tarjeta de interfaz de servidor vera el mensaje y reconocerá la solicitud como
propia y la aceptara.
Si solo existe un proceso en ejecución en la máquina de destino, su núcleo sabrá
qué hacer con el mensaje recibido (dárselo al único proceso en ejecución). Sin
embargo si existen existen varios procesos en ejecución en la máquina de destino,
no hay forma de identificar cuál de ellos obtiene el mensaje. Como el núcleo no tiene
forma de decidirlo, se necesita un esquema de direccionamiento en el que solo se
puede ejecutar un proceso en cada máquina. Esta solución simple y económica a
veces es una seria restricción.
Otro tipo de sistema de direccionamiento consiste en enviar mensajes a los
procesos en vez de a las máquinas. Aunque este método elimina toda ambigüedad
a cerca de quien es el verdadero receptor, presenta el problema de cómo identificar
los procesos. Un esquema común consiste en utilizar pares nombre-proceso, similar
al concepto del dominio. Con este esquema el núcleo lee el número de máquina
para identificar a quién solicitar la recepción, y el número del proceso en esta
máquina para determinar a cual proceso va dirigido el mensaje.

1.7 Modelo Terry

Un modelo de denominación creado por Douglas Brian Terry, que propone tener:
 Facilidad centralizada de nombramiento.
 Facilidad replegada de nombramiento.
 Facilidad descentralizada de nombramiento.
 Facilidad distribuida de nombramiento.
 Facilidad jerárquica de nombramiento.
Entre otros trabajos, Terry participó en la creación de BIND (Berkeley Internet Name
Domain) que es el software más difundido en Internet y sistemas UNiX para la
implementación de sistemas DNS. El modelo plantea la uniformidad en la
convención de usos de nombres en la idea de un NameSpace (espacio de nombres)
administrado por un NameServer con la figura de un servidor maestro llamado
autoritativo.
Para entornos con un número considerable de subredes y anfitriones, la
comunicación e identificación de nombres de recursos constituye un cuello de
botella, de tal suerte que el desempeño de un servidor de nombres será proporcional
a la cantidad de servidores de nombres que contienen repositorios, y por ello es
necesario establecer métricas que minimicen el costo promedio de localización de
recursos.
Una vez adoptada una convención de nombres, los siguientes factores influirán en
la eficiencia:
 Los patrones de referencia de los clientes hacia la información del servidor.
 La elección de servidores autoritativos (maestros) que sólo contienen
repositorios de nombre pero no atienden a usuarios.
 La cantidad de espejeo de la información de nombres de servidores.
 El número de servidores de nombres, en línea.
 La potencia de cada servidor de nombres en individual.

El modelo se basa en la implementación de un conjunto de servidores de nombres

NS1-NS2-NS3.... y en la suposición de que una fracción de ellos estar disponible
en un momento dado. A su vez un número de F servidores se encuentran fuera de
línea o desconectados, y se considera que los tiempos y periodos de interrupción
del servicio están distribuidos uniformemente, es decir que todos los servidores
tienen las mismas probabilidades y frecuencia de desconexión.

4 Comunicación de procesos a través del paso de mensajes en

sistemas distribuidos.
Los procesos de un S.O. pueden comunicarse entre sí al compartir espacios de
memoria, ya sean variables compartidas o buffers, o a través de las herramientas
provistas por las rutinas de Comunicación Interprocesos.
Para comunicar procesos en un ambiente distribuido, además del uso de un sistema
de nombres de recursos, se necesita un esquema de comunicación lógico que dé
sentido a estas transacciones. El sistema operativo provee mínimamente dos
primitivas, enviar y recibir, normalmente llamadas send y receive, pero tendrá que
implementar un enlace de comunicación entre los procesos. Este enlace puede ser
unidireccional o multidireccional según permita la comunicación en solo uno o en
varios sentidos, y dependiendo de la forma en que se dispara la comunicación.

Comunicación Síncrona: Quien envía permanece bloqueado esperando a que

llegue una respuesta del receptor antes de realizar cualquier otro ejercicio.
Comunicación Asíncrona: Quien envía continúa con su ejecución inmediatamente
después de enviar el mensaje al receptor.
Comunicación Persistente: El receptor no tiene que estar operativo al mismo
tiempo que se realiza la comunicación, el mensaje se almacena tanto tiempo como
sea necesario para poder ser entregado.
Comunicación Transitoria: El mensaje se descarta si el receptor no está operativo
al tiempo que se realiza la comunicación. Por lo tanto no será entregado.
Comunicación Directa: Los primitivos enviar y recibir usan directamente el nombre
del proceso con el que se comunican. Por ejemplo: enviar (mensaje, A) envía
un mensaje al proceso A.
Obsérvese que la primitiva sólo debe especificar cuál va a ser el proceso Destino,
ya que el proceso fuente viene direccionado en la comunicación.
Las operaciones básicas Send y Receive se definen de la siguiente manera: Send
(P, mensaje); envía unmensaje al proceso P. Receive (Q, mensaje); espera la
recepción de un mensaje por parte del proceso Q.
Comunicación Indirecta.
Es aquella donde la comunicación está basada en un gateway, enrutador, puente o
switch, ya que el emisor y el receptor están a distancia.
Comunicación Simétrica.
Todos los procesos pueden enviar o recibir. También establece una llamada
bidireccional para el caso de dos procesos.
Comunicación Asimétrica.
Un proceso puede enviar, los demás procesos solo reciben. También llamada
unidireccional o no interactiva. Es el esquema típico de algunos servidores de
Internet.

Comunicación con uso de buffers automático.

El transmisor se bloquea hasta que el receptor recibe el mensaje completo, pero
éste tiene capacidad para recibirlo aunque no esté listo para procesarlo.

La comunicación y sincronización en S.O.D. es más compleja y se establece en

canales lentos y menos confiables que los buses internos de una computadora, lo
que incorpora problemas como la pérdida de mensajes, la llegada de datagramas
desordenados, la heterogeneidad de los nodos y su diferente rendimiento, etc.

La forma natural de comunicar y sincronizar procesos en los sistemas distribuidos

es mediante paso de mensajes; los procesos intercambian mensajes mediante las
primitivas que además establecen una extensión de los semáforos en la que se
transmite más información en un contexto sincronizado.
Una de las ventajas de emplear mecanismos de comunicación y sincronización
basados en paso de mensaje es la portabilidad de las soluciones programadas para
diferentes arquitecturas de computadoras, incluidos los sistemas con memoria
compartida, otra ventaja es que no existe el problema del acceso en exclusión
mutua a datos compartidos, ya que no hay contienda por el acceso al recurso, sino
un fila en espera. Un sistema operativo o lenguaje de programación podría ofrecer
herramientas, algunas basadas en memoria compartida y otras basadas en la
comunicación mediante pasó de mensajes, por lo que podríamos llegar a tener un
mismo proceso o hilo que empleara las dos posibilidades. Los siguientes son
aspectos relevantes en el diseño de los sistemas de paso de mensajes:

1. Identificación en el proceso de comunicación.

2. Sincronización.
3. Características del canal (capacidad, flujo de datos, etc).
Conclusión
En este presente trabajo realizamos una investigación acerca de los
diferentes tipos de comunicación que se pueden realizar con los
Sistemas Distribuidos, a partir de este punto ya tenemos una amplio
conocimiento de las formas de operar de cada uno de los métodos antes
mencionados para poder elegir cual podríamos aplicar en un momento
dado que los requieras con el fin de no tomar decisiones erróneas. Pero
sobre todo temas antes vistos nos dan una gran claridad de cómo es
que funcionan las comunicaciones en los sistemas que normalmente
utilizamos sin darnos cuenta que realmente estamos haciendo un uso
de ellos en la vida diaria.
Bibliografía

Romero, Fernando, Tinetti, Fernando Gustavo (2007). Sincronización de relojes en

ambientes distribuidos. Recuperado de
http://sedici.unlp.edu.ar/handle/10915/20474
Patricia López Martínez, Julio Medina y José M. Drake. Recuperado de
http://www.ctr.unican.es/publications/plm-jlm-jmd-2004.pdf
mc. j. adrian herrero perezrul. Recuperado de
https://sites.google.com/site/mrtripus/home/sistemas-operativos-2/2-3-nominacion-
caracteristicas-y-estructuras-tipos-de-nombres-resolucion-y-distribucion-
servidores-y-agentes-de-nombres-mapeo-de-direcciones-mapeo-de-rutas-modelo-
de-terry