• Author / Uploaded
• Julio Cesar

Citation preview

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-nominacioncaracteristicas-y-estructuras-tipos-de-nombres-resolucion-y-distribucionservidores-y-agentes-de-nombres-mapeo-de-direcciones-mapeo-de-rutas-modelode-terry