2.3.7 MODELO DE TERRY

Los mensajes remitentes entre los procesos y objetos soportados por un sistema operativo precisa la presentación para el sistema operativo de los nombres de los objetos que los procesos quieren ganar acceso a.

El problema es cómo localizar objetos nombrados. Esto está directamente conectado a la gerencia del espacio de nombre y las estructuras de la facilidad de nombramiento.

Como ha visto, acto de servidores de nombre como agentes obligatorios distribuidos que amarran el nombre de un objeto para una cierta cantidad de sus propiedades, incluyendo la posición del objeto. Algunos servidores de nombre pueden almacenar información acerca de los objetos particulares. Tales servidores de nombre se llaman las autoridades que nombra o servidores autoritarios de nombre para eso objetan. El problema es cómo distribuir servidores de nombre, esto es, que de las estructuras de una facilidad de nombramiento es el mejor.

2.3.6 MAPEO DE RUTAS

Es un método específicamente desarrollado para la realización de estudios de Prospectiva Tecnológica. El modelo se basa en las directrices dictadas por las necesidades del mercado ayudando a identificar, seleccionar y desarrollar con posterioridad las alternativas de tecnología necesarias para satisfacer un conjunto de necesidades de un producto.

Se trata de una prospectiva por objetivos que, entre otras funciones, ayuda a identificar necesidades y tecnologías, proporciona información necesaria en la toma de decisiones, identifica tecnologías críticas o vacíos en tecnología que deben llenarse para poder desarrollar productos con desempeños específicos y analiza el proceso a través del tiempo.



2.3.5 MAPEO DE DIRECCIONES

Para poder ejecutar instrucciones, si no sabemos en qué parte de la memoria estarán cargadas, debemos tener un mecanismo de traducción de direcciones virtuales a reales. Para ello, se necesitan dos cosas. Primero, el compilador manejará una dirección base más un desplazamiento al referirse a las instrucciones. Segundo, el sistema operativo asignará como dirección base el número de página, al paginar al proceso. De esta manera, puede buscarse el inicio de una página en memoria, sumarle el desplazamiento y así obtener la dirección real de una instrucción.

Nótese que en el diagrama se tiene una tabla de proceso y ahí mismo se maneja la dirección inicial de la tabla de páginas. En algunos sistemas operativos, estas dos tablas se manejan por separado.

2.3.4 SERVIDORES Y AGENTES DE NOMBRES

En la actualidad, la ICANN está formalmente organizada como una corporación sin fines de lucro y de utilidad pública. Está administrada por una Junta de Directores, que está compuesta por seis representantes de las organizaciones de apoyo, sub-grupos que se ocupan de las secciones específicas de las políticas de ICANN en virtud de la competencia, ocho representantes independientes del interés público general, seleccionados a través de un Comité de Nominaciones que representa a todas las circunscripciones de la ICANN, y el Presidente y Director Ejecutivo, nombrado por el resto de la Junta.

En la actualidad hay tres organizaciones de apoyo: la GNSO (Generic Names Supporting Organization) se ocupa de la formulación de políticas sobre dominios genéricos de nivel superior, ccNSO (Country Code Names Supporting Organization) se ocupa de la elaboración de políticas relativas a códigos de países en dominios de nivel superior, la ASO (Address Supporting Organization) se ocupa de la formulación de políticas en direcciones IP.



2.2.2 RELOJES LOGICOS

Las computadoras poseen un circuito para el registro del tiempo conocido como dispositivo reloj .

Es un cronómetro consistente en un cristal de cuarzo de precisión sometido a una tensión eléctrica que:

• Oscila con una frecuencia bien definida que depende de:

          o Al forma en que se corte el cristal.

          o El tipo de cristal.

          o La magnitud de la tensión.

• A cada cristal se le asocian dos registros:

          o Registro contador.

          o Registro mantenedor.

• Cada oscilación del cristal decrementa en “1” al contador.
• Cuando el contador llega a “0”:

          o Se genera una interrupción.

          o El contador se vuelve a cargar mediante el registro mantenedor.

• Se puede programar un cronómetro para que genere una interrupción “x” veces por segundo.
• Cada interrupción se denomina marca de reloj.

Para una computadora y un reloj:

• No interesan pequeños desfasajes del reloj porque:

          o Todos los procesos de la máquina usan el mismo reloj y tendrán consistencia interna.

          o Importan los tiempos relativos.

Para varias computadoras con sus respectivos relojes:

• Es imposible garantizar que los cristales de computadoras distintas oscilen con la misma frecuencia.
• Habrá una pérdida de sincronía en los relojes (de software), es decir que tendrán valores distintos al ser leidos.

La diferencia entre los valores del tiempo se llama distorsión del reloj y podría generar fallas en los programas dependientes del tiempo.

Lamport demostró que la sincronización de relojes es posible y presentó un algoritmo para lograrlo.

Lamport señaló que la sincronización de relojes no tiene que ser absoluta:

• Si 2 procesos no interactúan no es necesario que sus relojes estén sincronizados.
• Generalmente lo importante no es que los procesos estén de acuerdo en la hora, pero sí importa que coincidan en el orden en que ocurren los eventos.

Los relojes físicos son relojes que:

• Deben ser iguales (estar sincronizados).
• No deben desviarse del tiempo real más allá de cierta magnitud.

2.2.1 RELOJES FISICOS

El algoritmo de Lamport proporciona un orden de eventos sin ambigüedades, pero [25, Tanenbaum]:

Los valores de tiempo asignados a los eventos no tienen porqué ser cercanos a los tiempos reales en los que ocurren. En ciertos sistemas (ej.: sistemas de tiempo real ), 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. Entre sí. La medición del tiempo real con alta precisión no es sencilla. Desde antiguo el tiempo se ha medido astronómicamente.

Los físicos definieron al segundo como el tiempo que tarda el átomo de cesio 133 para hacer 9.192.631.770 transiciones:

2.2 SINCRONIZACION SISTEMAS DISTRIBUIDOS

En sistemas con una única CPU las regiones críticas, la exclusión mutua y otros problemas de sincronización son resueltos generalmente utilizando métodos como semáforos y monitores. Estos métodos no se ajustan para ser usados en sistemas distribuidos ya que invariablemente se basan en la existencia de una memoria compartida.

En general los algoritmos distribuidos tienen las siguientes propiedades:

1)- la información relevante está repartida entre muchas máquinas

2)- los procesos toman decisiones basadas solamente en la información local disponible

3) - debería poder evitarse un solo punto que falle en el sistema

4)- no existe un reloj común u otro tiempo global exacto

Si para asignar un recurso de E/S un proceso debe recolectar información de todos los procesos para tomar la decisión esto implica una gran carga para este proceso y su caída afectaría en mucho al sistema.

Alcanzar la sincronización sin la centralización requiere hacer cosas en forma distinta a los sistemas operativos tradicionales.

2.1.4 TOLERANCIA A FALLOS

La difusión de los sistemas distribuidos incrementa la demanda de sistemas que esencialmente nunca fallen [25, Tanenbaum].

Los sistemas tolerantes a fallos requerirán cada vez más una considerable redundancia en hardware, comunicaciones, software, datos, etc.

La réplica de archivos sería un requisito esencial.

También debería contemplarse la posibilidad de que los sistemas funcionen aún con la carencia de parte de los datos.

Los tiempos de fallo aceptables por los usuarios serán cada vez menores.

2.1.3 COMUNICACION EN GRUPO

La comunicación se clasifica deacuerdo al numero de usuarios alos que se le a enviado el mensaje.

-BROADCAST O DIFUSION FORZADA un nodo emite todos los escuchan y solo contesta a quien va dirigido el mensaje

-MULTICAST se entrega el msj a todos los anfitriones HOST que están compuestos de ciertas características.

-UNICAST o POINTCAST un nodo emite y otro recibe, solo escucha aquel a quien se dirigió el msj.

Una clasificación adicional es la realizada en base a grupos

-LISTAS DE DESTINARIOS se tiene una lista de aquellos alos que se les enviara el mensaje.

-IDENTIFICADOR DE GRUPO se forman grupos y el msj es dirigido solo a los miembros de ese grupo.

-PREDICADOR DE PERTENENCIA se envía y otro recibe, solo escucha aquel a quien se dirigió el mensaje.

2.1.2 COMUNICACION CON RPC

RCP (REMOTE PROCEDURE CALL)

El mecanismo general para las aplicaciones cliente-servidor se proporciona por el paquete Remote Procedure Call (RPC). RPC fue desarrollado por Sun Microsystems y es una colección de herramientas y funciones de biblioteca. Aplicaciones importantes construidas sobre RPC son NIS, Sistema de Información de Red y NFS, Sistema de Ficheros de Red.

Un servidor RPC consiste en una colección de procedimientos que un cliente puede solicitar por el envío de una petición RPC al servidor junto con los parámetros del procedimiento. El servidor invocará el procedimiento indicado en nombre del cliente, entregando el valor de retorno, si hay alguno. Para ser independiente de la máquina, todos los datos intercambiados entre el cliente y el servidor se convierten al formato External Data Representation (XDR) por el emisor, y son reconvertidos a la representación local por el receptor. RPC confía en sockets estandard UDP y TCP para transportar los datos en formato XDR hacia el host remoto. Sun amablemente a puesto RPC en el dominio público; se describe en una serie de RFCs.

La comunicación entre servidores RPC y clientes es un tanto peculiar. Un servidor RPC ofrece una o más colecciones de procedimientos; cada conjunto se llama un programa y es idenficado de forma única por un número de programa. Una lista que relaciona nombres de servicio con números de programa se mantiene usualmente en /etc/rpc.

En esta figura, la llamada remota toma 10 pasos, en el primero de los cuales el programa cliente (o procedimiento) llama al procedimiento stub enlazado en su propio espacio de direcciones. Los parámetros pueden pasarse de la manera usual y hasta aquí el cliente no nota nada inusual en esta llamada ya que es una llamada local normal.

El stub cliente reúne luego los parámetros y los empaqueta en un mensaje. Esta operación se conoce como reunión de argumentos (parameter marshalling). Después que se ha construido el mensaje, se lo pasa a la capa de transporte para su transmisión (paso 2). En un sistema LAN con un servicio sin conexiones, la entidad de transporte probablemente sólo le agrega al mensaje un encabezamiento y lo coloca en la subred sin mayor trabajo (paso 3). En una WAN, la transmisión real puede ser más complicada.

Cuando el mensaje llega al servidor, la entidad de transporte lo pasa al stub del servidor (paso 4), que desempaqueta los parámetros. El stub servidor llama luego al procedimiento servidor (paso 5), pasándole los parámetros de manera estándar. El procedimiento servidor no tiene forma de saber que está siendo activado remotamente, debido a que se lo llama desde un procedimiento local que cumple con todas las reglas estándares. Únicamente el stub sabe que está ocurriendo algo particular.

Después que ha completado su trabajo, el procedimiento servidor retorna (paso 6) de la misma forma en que retornan otros procedimientos cuando terminan y, desde luego, puede retornar un resultado a un llamador. El stub servidor empaqueta luego el resultado en un mensaje y lo entrega a la interfaz con transporte (paso 7), posiblemente mediante una llamada al sistema, al igual que en el paso 2. Después que la respuesta retorna a la máquina cliente (paso 8), la misma se entrega al stub cliente (paso 9) que desempaqueta las respuestas. Finalmente, el stub cliente retorna a su llamador, el procedimiento cliente y cualquier valor devuelto por el servidor en el paso 6, se entrega al cliente en el paso 10. El propósito de todo el mecanismo de la Fig.1 es darle al cliente (procedimiento cliente) la ilusión de que está haciendo una llamada a un procedimiento local. Dado el éxito de la ilusión, ya que el cliente no puede saber que el servidor es remoto, se dice que el mecanismo es transparente. Sin embargo, una inspección más de cerca revela algunas dificultades en alcanzar la total transparencia.

2.1 COMUNICACION CLIENTE SERVIDOR SOCKETS

El proceso para la creacion de un servicio siempre comienza   con la creacion del Socker. Asi como el cliente necesita llamadas especificas en determinados mometos, el servidor trabajo de modo similar pero añade unas pocas llamadas extras al sistema. El servidor utiliza la llamada del sistema Socket(), pero debe hacer un trabajo extra que era opcional para el cliente,

el cliente   simpre realiza un a conexión activa porque la persigue energicamente
los servidores por   otro lado necesitan proporcionar un numero   de puesto especifico y consiste a los programas clientes si les va a prestar servicio. El programa servido que escriba debera utilizar las llamadas de sistema socker(), bind(), listen(), accept(). Y mientras el programa cliente es una conexión activa,el servidor es una conexión   pasiva. Las llamadas de isistemas() y accept() crean una coneccion solo cuando el cliente pide una conexión (similar a la accion de responder al timbre de un telefono

El ejemplo de servidor escucha en un socket (puerto 8000) esperando peticiones entrantes. Cualquier programa, como el client.c de ejemplo, puede conectar con este ser­vidor y pasarle hasta 16.384 hytes de datos
El servidor trata los datos como datos ASCII y los convierte en mayúsculas antes de pasárselos a! programa cliente.
Estos dos sencillos programas se pueden volver a utilizar fácilmente cuando se escriban programas cliente-servidor basados en socket

Los servidores que pueden recibir muchas peticiones simultáneas utilizan fork para crear un proceso separado para la administración de peti­ciones de servicio constitucionalmente caras.
server.c crea un socket permanente para la escucha de peticiones de ser­vicio; cuando un cliente conecta con el servidor, se crea un socket temporal. Cada vez que un cliente conecta con un servidor, se abre un nuevo socket temporal entre el cliente y el servidor.

2.1 COMUNICACION SOD

Se ha estudiado un modelo de interacción entre los procesos de un sistema distribuido que es el modelo cliente-servidor.

Para implementarlo, el sistema dispone de dos llamadas al sistema, send y receive, que las aplicaciones utilizan de forma conveniente.

Estas primitivas, a pesar de constituir la base de la construcción de los sistemas distribuidos, pertenecen a un nivel demasiado bajo como para programar de forma eficiente aplicaciones distribuidas.

UNIDAD 2 COMUNICACION EN LOS S.O DISTRIBUIDOS

La diferencia más importante entre un sistema distribuido y un sistema de un único procesador es la comunicación entre procesos .En un sistema de un solo procesador la comunicación supone implícitamente la existencia de la memoria compartida:

• Ej.: problema de los productores y los consumidores, donde un proceso escribe en un buffer compartido y otro proceso lee de él.

En un sistema distribuido no existe la memoria compartida y por ello toda la naturaleza de la comunicación entre procesos debe replantearse.
Los procesos, para comunicarse, deben apegarse a reglas conocidas como protocolos.
Para los sistemas distribuidos en un área amplia, estos protocolos toman frecuentemente la forma de varias capas y cada capa tiene sus propias metas y reglas.
Los mensajes se intercambian de diversas formas, existiendo muchas opciones de diseño al respecto; una importante opción es la “llamada a un procedimiento remoto”.
También es importante considerar las posibilidades de comunicación entre grupos de procesos, no solo entre dos procesos.