4.8 Estudio del rendimiento de la factibilidad de nombramiento, el modelo de Terry 4.8.1 Terry el modelo para estudiar actuación
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.
Los criterios diferentes pueden ser tomados en cuenta al desarrollar la facilidad de nombramiento para sistemas de cómputo distribuidos. En la etapa de análisis de la estructura de facilidad de nombramiento, usaremos la mayor parte de importante de esos criterios, a saber actuación. Este criterio es importante para un ambiente distribuido porque que hay usualmente un número de redes interconectadas (lo mismo es cierto en caso de una red de área local conectando un número grande de computadoras personales y / o los puestos de trabajo, y los servidores diferentes), lo cual insinúa que el costo de comunicación entre clientes y servidores de nombre es el cuello de botella principal en localizar recursos remotos. En este caso, la actuación de averiguaciones del servidor de nombre es dominada por el número de servidores de nombre que deben ser a los que se ganó acceso y el costo de ganar acceso a esos los servidores de nombre.
Los factores que afectan la eficiencia con la cual el espacio de nombre puede ser manejado y el costo de recuperar información del servidor de nombre son:
+ El di denota el costo de ejecutar una averiguación en NS, éste costado depende de tales factores como el tamaño global de la base de datos mantenida por NSi, y la clase de instalaciones de la base de datos utilizaron. Se asume que se compone con el paso del tiempo. + El cui es el costo de comunicar con NSi de cliente u, depende del sitio en el cual el cliente ejecuta, Este costo depende de tales factores como el número de portales de acceso atravesados, y la velocidad de líneas de transmisión. + El CUi especifica el costo completo de ganar acceso al servidor de nombre, NSi, remotamente de cliente u, y sea expresada por la siguiente fórmula:
El costo de recuperar la información del servidor de nombre acerca de un set de denominado así es que urce s depende de posición del cliente relativo a servidores diversos de nombre y la mezcla remisiva del cliente y puede ser expresado por la fórmula:
Donde Luk representa el coste total de poner en duda la información en partición de la base de datos dk, incluir el costo de localizar los datos deseados. Porque estamos interesados en el costo de recuperar la entrada del servidor de nombre de un objeto individual, ignoraremos los patrones de acceso del cliente en E (Lu) ‘ concentrándose sólo en Luk ‘
4.8.2 Structures de la facilidad de nombramiento
Las siguientes estructuras básicas de facilidad de nombramiento para los sistemas operativos distribuidos han sido identificadas por Terry (1984) e Indulska y Goscinski (1989):
(1) una facilidad centralizada de nombramiento (2) una facilidad replegada de nombramiento (3) una facilidad descentralizada de nombramiento (4) una facilidad distribuida de nombramiento (5) una facilidad jerárquica de nombramiento.
Una cierta cantidad de estas estructuras y sus modificaciones son ilustradas en Fig.7.29.
Las estructuras de facilidad Fig. 7.29 Nombre. El sistema (5) centralizado, – (6) - el sistema replegado, (7) el sistema descentralizado con división en los tipos del objeto, (1) completamente distribuyó sistema (2) recursos locales conocidos en cada nodo y el mensaje emitido por radio pasando para servidores del recurso en cada nodo, (3) distribuyó sistema (4) recursos locales conocidos en cada nodo, sistema con creces distribuido dirección del recurso determinó por una función de hashing que se definió sobre el set de identificadores del recurso, jerárquico -.
Ahora, describiremos estas estructuras de facilidad de nombramiento enfatizando evaluación de rendimiento. La presentación de estos temas se basa en la actuación que el modelo desarrolló por Terry, y también por Indulska y Goscinski.
Las instalaciones centralizadas de nombramiento
Una facilidad centralizada de nombramiento es implementada usando un servidor solo de nombre, lo cual mantiene una mesa o base de datos con tal que el nombre necesario para ocuparse de mapeos. Este sistema maneja un espacio plano de nombre donde los nombres son cadenas de caracteres no exhibiendo estructura. La base de datos del servidor de nombre es aumentada registrando servicios, va en procesión, pone a babor (los buzones) y otros detalles pertinentes que quieren ser públicamente sabidos. Los directorios del archivo pueden ser considerados como una causa especial de servicio de nombre. En este caso, Sk = NS. El servidor de nombre contiene que la colección completa de información aproximadamente toda nombró objetos en el ambiente distribuido. El costo de recuperación es simplemente Lk = C, dónde la C especifica el coste máximo de ganar acceso a servidor de nombre NS remotamente por la u más lejana del cliente.
La ventaja de esta estructura de nombramiento es su simplicidad, y la evitación de cualquier problemas de incongruencia que se identificó en algunos sistemas con más que un servidor. Las desventajas son fiabilidad de punto bajo del sistema enteramente distribuido, y el tráfico grande los retrasos aéreos y largos en ganar acceso al servidor y antes de iniciar una transmisión orientada en servicio requerida.
Los sistemas replegados de nombramiento
Una facilidad replegada de nombramiento maneja un espacio plano de nombre también. Cada nodo de la computadora (el sitio) del sistema distribuido mantiene una copia de la base de datos con tal que los mapeos del nombre a la dirección necesarios para el sistema entero. En este caso, Sk = { NS1. . . , NSN } ‘ Porque cada servidor de nombre contiene una” colección completa ‘ De información aproximadamente toda nombró objetos (los recursos) del sistema distribuido, cualquier cliente puede interrogar el servidor de nombre físicamente más cercano, implícito aquí N Smain?” que éste significa que el costo de recuperación es simplemente cañería maestra Lk = C.
Este sistema tiene las siguientes ventajas: Es muy rápido, que no tiene retrasos de levantes obligatorios de operación, el número de mensajes de orientes obligatorio es cero, y tiene fiabilidad alta. El problema mantienen consistencia entre copias, nombran problemas de materialización (si un proceso muere, entonces o un servicio se vuelve agotado) y requisitos grandes de memoria de cada nodo.
La entrada de la base de datos de nombre orientó descentralizó sistemas
Una entrada de la base de datos de nombre orientó descentralizó sistema también maneja un espacio plano de nombre, pero cada entrada del servidor de nombre es almacenada en algún sitio arbitrario. En este caso, Sk = { NS ¡ }. Tal solución para una estructura de facilidad de nombramiento insinúa que el almacenamiento y los problemas de consistencia, mencionadas en el acercamiento previo, es evitado. Ésta es la ventaja principal de esta estructura. El inconveniente de este sistema localiza los datos deseados, porque eso arruine necesite interrogar cada servidor de nombre. Por término medio, la mitad de servidores de nombre deben ser a los que se ganó acceso para recuperar información del objeto. Dado que los saques de nombre son puestos en duda en la ordenación numérica, la recuperación costada es como sigue:
Este sistema es valioso en términos de búsquedas del servidor de nombre.
Una modificación simple del citado anteriormente sistema es la facilidad distribuida de nombramiento. En este sistema cada nodo de la computadora (el sitio) mantiene una base de datos con tal que la dirección - nombre necesaria haciendo mapas para sus propios objetos locales (los procesos, los puertos, los servicios, los recursos). Este sistema requiere difundir en la red el nombre de un objeto pedido.
Ninguno de los sistemas descritos anteriormente son muy prácticos para sistemas distribuidos grandes. La situación puede ser mejorada añadiendo estructura para el nombre de un objeto. Esta estructura debería reflejar la autoridad de la gerencia para el nombre.
Los sistemas descentralizados de nombramiento
Una facilidad descentralizada de nombramiento es implementada usando un número de servidores de nombre operando en los dominios estrictamente definidos. La estructura se agrega para el nombre de un objeto (resource’s) para reflejar la autoridad de la gerencia para el nombre. La siguiente convención de nombramiento puede ser usada:
_ el servidor (1) correcto de @ nombre de _ nombre, donde _ el servidor de nombre identifica el servidor de nombre esto es responsable para información directiva acerca del objeto, y _ el nombre (2) correcto sin ambigüedades identifica el objeto en el contexto de la autoridad que nombra.
Si los servidores de nombre son sin ambigüedades nombrados luego el nombre completo _ servidor correcto de @ nombre de _ nombre es globalmente inequívoco. La gerencia efectiva de tal espacio de nombre siguiendo esta convención de nombramiento requiere que cada servidor de nombre sabe la posición de otros servidores de nombre.
Hay avances diferentes para descentralizar un espacio de nombre:
La partición de discos (1) geográfica (el reconocimiento médico): Si el sistema está compuesto de redes de área local múltiples conectadas de por ahí cruzan s y portales de acceso, entonces es natural tener un servidor de nombre para cada red; Y La partición de discos (2) organizativa (funcional): La partición del sistema entero en los dominios puede estar hecha con base en organizaciones.
Básicamente dividieron en partes nombrando sistemas individuales mapeo existe entre particiones de la base de datos y servidores de nombre, esto es, = la N de kilobyte y Sk = { NSk }. Tal estructura requiere dos accesos para obtener la información acerca de un objeto dado (el recurso): Uno para hallar la autoridad que nombra y uno para ganar acceso a los datos. Sólo un acceso es menester cuando la información deseada de nombramiento es almacenada en el servidor primario de nombre, N Smain. El costo de búsqueda es expresado por la fórmula:
Organizacionalmente dividieron en partes nombrando sistemas las particiones de la base de datos corresponda a las organizaciones en vez de servidores de nombre. Cada servidor de nombre puede ser la autoridad para algún subconjunto de las organizaciones. En este caso los nombres toman la forma @ organización correcta de _ nombre en la cual la autoridad para asignar nombres es explícitamente reconocida. En este caso el servicio de nombre puede ser con holgura uso reconfigurado del beca la asignación de objeto nombres es independiente de la asignación de la responsabilidad para mantener información acerca de los objetos.
Consideremos los costos de búsqueda. Suponga, por el momento, que los datos de cada organización están bajo la dirección de un servidor solo de nombre al igual que con un espacio de nombre físicamente subdividido, Sk = { NSJ. Para eficazmente ganar acceso a información acerca de un objeto dado, cada servidor de nombre debería saber cuál servidor de nombre tiene responsabilidad para cada organización. Basadas en esta estructura, las averiguaciones del servidor de nombre pueden ser tramitadas en pasos dobles como en sistemas de nombramiento físicamente subdivididos. El costo de búsqueda es expresado como sigue:
Dos recuperaciones de la base de datos son siempre precisadas desde que un servidor de nombre no puede determinar de todos modos es la autoridad para los datos deseados sin consultar la base de datos local. Si el servidor primario de nombre puede recuperar y puede devolver la entrada del servidor de nombre directamente al descubrir que es el sitio de almacenamiento para los datos deseados, entonces luego
Una de las ventajas más importantes de un espacio de nombre de organizacional-Partición es la facilidad con la cual la información replegada de nombramiento puede ser acomodada. Esto quiere decir que la base de datos del servidor de nombre puede a medias ser redundante. Del punto de la gerencia de vista, la copia soportadora requiere que el algoritmo de búsqueda describió arriba esté extendido de tal manera en lo que se refiere a reconocer varios servidores autoritarios de nombre para cada organización en vez de uno responsable solo. Como consecuencia, cada servidor de nombre debería saber la colección completa de servidores autoritarios de nombre para cada organización, Sk. Un ejemplo de un sistema basado en este acercamiento es el sistema Grapevine (Birrell Et Al. 1982). El costo de búsqueda del servidor de nombre viene bien
Esta fórmula fue desarrollada en la suposición que el servidor autoritario más cercano de nombre puede ser determinado con costo insignificante. El costo para un sistema con datos replegados debería estar menos del costo pues un sistema con espacio de nombre de organizacional-Partición desde que el servidor de nombre ganó acceso a por clientes diversos, N Smink? ‘ puede diferir de cliente para el cliente, considerando en el caso previo cada cliente se ve forzado a ganar acceso al mismo servidor de nombre.
La influencia de la copia de datos puede ser ilustrada por un ejemplo muy simple. Deje la R ser número de materiales noticiosos, R~N, distribuido uniformemente, esto es, R servidores autoritarios de nombre está seleccionado al azar para cada partición de la base de datos. Doy por supuesto que los servidores de nombre son ordenados algo semejante que C<C para yo < la j y NS. = NS.. Esta suposición no insinúa cualquier pérdida de generalidad.
Los sistemas jerárquicos de nombramiento
Una facilidad jerárquica de nombramiento es una extensión del sistema previo por nombres estructurados de dos partes extensibles para los nombres jerárquicos consistente en más que dos partes. Hay dos avances básicos: El número fijo de estratos, o una jerarquía arbitraria. Con gerencia jerárquica del espacio de nombre, los datos completos (Sk para toda k) de configuración del servidor de nombre no necesitan guardarse en cada servidor de nombre. Es suficiente que cada tienda del servidor de nombre lo suficientemente sólo información localizar los servidores autoritarios de nombre para el nivel de la parte superior de la jerarquía. Los servidores nivelados máximos de nombre deberían saber que los servidores autoritarios de nombre para el nombre espacian subárboles directamente bajo su control administrativo. Un análisis de estructuras jerárquicas de nombramiento puede ser realizado por recursivamente aplicar las técnicas para los nombres de dos partes. Considere un sistema usando los nombres de la forma _ nombre local: El dominio:La organización, esto es, una jerarquía con tres niveles.
El estudio del 4.8.3 Performance
La tela de rizo (la Tela De Rizo 1984) presenta dos resultados interesantes de un estudio de actuación para la red (el sistema Grapevine) ilustrada en Fig. 7.30. Los círculos representan 3 redes de área local de Ethernet Mbps, numeradas de 1 para 12, y las líneas representan enlaces largos de distancia con tasas de datos de ya sea 56 kilobits por segundo o 9.6 kilobits por segundo. Los rectángulos representan los servidores diversos de nombre, etiquetados de UNO para Q.
La actuación de un sistema distribuido es influenciada por la posición de los servidores de nombre. Esta influencia está a través de la base de datos objeta
La A Fig.7.30 sarople intemet { el froro adaptado Terry (1985) }.
Table7.1 Communication cuesta.
Eso es asignado a los servidores particulares de nombre y el costo de comunicarse con estos servidores.
Posponga 7.1 funciones los costos de comunicarse entre un cliente en cada red y cada servidor de nombre, dado que el molde de comunicación es proporcional para la transmisión de datos Tale del medio de comunicación.
Así, dado que la comunicación cuesta es normalizado así esa comunicación afirmo que un Ethernet local cuesta una unidad, oye T, transmisión sobre un 56K y 9.6K aplican delineador a lo 312K y 54T lanzado, respectivamente. El molde de comunicación puede diferir por varias órdenes de magnitud. Afortunadamente, la actuación arruine sea mejorada por copia.
La mesa 7.2 Effects de copia en la búsqueda cuesta.
Los efectos de copia en los costos de búsqueda son presentados en Table 7.2. Estos resultados han sido compilados usando las s de estimación de costos de comunicación dadas en Table 7.1 junto con Equation 7.7. La tela de rizo da por supuesto que las copias son uniformemente distribuidas. El costo decrece con el número de copias. Esto está a cobro enteramente para reducir la cantidad de comunicación entre clientes y los servidores de nombre muy remotos.
Escrito por martin91sexyboy el 02/05/2012 19:14 | Comentarios (0)
El “Technology Roadmapping” o mapeo de rutas tecnológicas, 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.
5.1. QUE ES EL ROADMAP?
El Roadmap o “Mapeo de rutas” describe un ambiente futuro, los objetivos que pueden llegar a obtenerse con ese ambiente y los planes para lograr los objetivos planteados a través del tiempo. Explicita una estructura, o arquitectura, como una vía para el entendimiento de cómo las partes de un complejo sistema tecnológico encajan, interactúan y evolucionan. Así mismo, articula aplicaciones, desafíos tecnológicos y soluciones tecnológicas en forma conjunta y ayuda a establecer las prioridades para la consecución de los objetivos.
QUE ES EL ROADMAPPING?
La mejor hoja de ruta es creada a partir de un trabajo en equipo, recibiendo las visiones y el conocimiento de un grupo de personas que llevan a cabo el plan de mapeo de rutas. El proceso de Roadmapping ayuda al equipo a reunir diversas perspectivas sobre todos los aspectos del ambiente y del plan. Así mismo ayuda al equipo a construir un consenso para llevar a cabo el plan de acción. El mapeo de rutas también es la base para la descripción de los objetivos.
ESTRUCTURA DEL ROADMAPPING
El mapeo de rutas explicita campos de acción y permite trazar directrices para el planteamiento de acciones orientadas a responder o desarrollar completamente un conjunto de preguntas:
“Por qué – Qué – Cómo - Cuándo” elementos importantes para poder desarrollar planes y proyectos de acción en la dirección de los objetivos planteados y alcanzar las metas buscadas. La siguiente figura describe las cuatro partes de la arquitectura con base en un mapeo de rutas.
El mapeo de rutas puede ser construido comenzando con la definición de las principales necesidades del mercado para luego definir las tecnologías necesarias. (Prospectiva por entradas del mercado). Recíprocamente, al mapeo también puede comenzar con la definición de tecnologías claves y proseguir con los requerimientos del mercado que pueden ser satisfechos con esas tecnologías. (Prospectiva por entradas de tecnologías)
Escrito por martin91sexyboy el 02/05/2012 19:12 | Comentarios (0)
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.
La traducción de direcciones virtuales para segmentos se maneja de manera similar.
Existe un esquema adicional, paginación/segmentación, que es la combinación de ambos. La memoria se divide en marcos de página, idealmente más pequeños que el tamaño del marco de página en un sistema de paginación tradicional. Cada segmento está compuesto por cierto número de páginas. Es decir, el tamaño del segmento es un múltiplo del tamaño de página. Este esquema pretende sacar ventaja de los beneficios de los otros dos. Este mismo mecanismo de traducción de direcciones virtuales puede aplicarse en paginación/segmentación.
Recordemos que este mapeo debe efectuarse siempre, instrucción por instrucción ejecutada. Por ello, entre más rápido sea el mecanismo, mejor. Existe una manera de mejorar dicho mecanismo mediante hardware.
Una memoria asociativa es muy cara, pero permite buscar en toda la memoria en un mismo pulso de reloj. Implementando memoria asociativa, podemos traducir direcciones para páginas o segmentos.
Sin embargo, el utilizar memoria asociativa implica que el número de marcos de página y/o el número de segmentos, se ve limitado por el tamaño de la memoria asociativa. Es decir, no puede haber más marcos de página que número de celdas en la memoria asociativa. Por ello, hay sistemas operativos que manejan una combinación de ambos. Se cargan a memoria las páginas/segmentos más utilizados, y la traducción se utiliza de manera normal. Solamente en aquellos casos en los que no encontrara la página/segmento en la memoria asociativa, efectuaría la traducción directa. Para esa instrucción, haría un doble mapeo. Sin embargo, el principio de localidad nos asegura que esto no sucederá con frecuencia.
Escrito por martin91sexyboy el 02/05/2012 19:11 | Comentarios (0)
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.
ICANN también se basa en algunos comités consultivos para recibir asesoramiento sobre los intereses y necesidades de los interesados que no participen directamente en las organizaciones de apoyo. Entre ellos figuran el Comité Asesor Gubernamental (GAC), que está integrado por representantes de un gran número de gobiernos nacionales de todo el mundo; el ALAC (At-Large Advisory Comité), que está integrado por representantes de organizaciones de los distintos usuarios de Internet de todo el mundo; el sistema DNS y TLG (Technical Liaison Group) compuesto por representantes de otras organizaciones técnicas internacionales de Internet.
Escrito por martin91sexyboy el 02/05/2012 19:10 | Comentarios (0)
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 donde se almacena el archivo en disco.
En un SAD transparente se agrega una nueva dimensión de abstracción ..: la ocultación de la ubicación de los archivos de la red. En un sistema de archivos convencionales la función de nominación produce como resultado un intervalo de direcciones en disco, en un SAD este intervalo crece para incluir la máquina especifica en cuyo disco se almacena el archivo. Si se extiende un poco mas el tratamiento de los archivos como abstracciones, llegamos a la posibilidad de replicas de archivos. Dado un nombre de archivo, la correspondencia devuelve un conjunto de posiciones de las replicas de este archivo. En esta abstracción se ocultan tanto la experiencia de copias como su ubicación.
Estructuras de Nominación ..:
Existen dos conceptos que hay que distinguir en relación con al correspondencia de nombres en un SAD.
Transparencia de Nominación, El nombre de archivo no revela ningún indicio sobre de la ubicación del almacenamiento físico del archivo.
Independencia de Ubicación, No es necesario modificar el nombre de un archivo cuando cambia su ubicación en el almacenamiento físico.
Esquema de Nominación ..:
Hay tres enfoques principales para los esquemas de nominación en un SAD. En el enfoque mas sencillo, 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. Por ejemplo, en Ibis, un archivo se identifica de manera única con el Nombre Anfitrión Local, donde nombre local es una ruta semejante a las de UNIX.
El segundo enfoque popularizado por el sistema de archivos de red (NFS, Network File System) de sun, ofrece una forma de unir directorios remotos a directorios locales, lo que da la apariencia a un árbol de directorios coherentes.
El tercer enfoque es la estructura mas compleja y difícil de mantener en la NFS, ya que cualquier directorio se puede unir a cualquier árbol de direcciones locales y la jerarquía resultante puede estar poco estructurada.
Escrito por martin91sexyboy el 02/05/2012 19:02 | Comentarios (0)
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 el objetivo es reducir el tráfico en la red. Esquema Básico, el concepto de memoria caché es sencillo, si los datos necesarios para satisfacer la solicitud de acceso no se encuentran en la memoria cache, se trae una copia de servicio al usuario y los accesos se llevan a cabo con la copia de memoria caché.
La idea es conservar allí los bloques de disco de acceso mas reciente, para así manejar localmente los accesos repetidos a la misma información y no aumentar el tráfico de la red. Se utiliza una política de reemplazo (por ejemplo, la de utilización menos reciente) para limitar el tamaño de la memoria caché. Políticas de Actualización, la política empleada para escribir los bloques de datos modificados en la copia maestra del servidor tiene un efecto decisivo sobre la confiabilidad y el rendimiento del sistema. La política mas sencilla consiste en escribir los datos directamente en el disco tan pronto se coloquen en una memoria caché. La ventaja de la escritura directa es su confiabilidad, ya que se pierde poca información si un sistema cliente falla. Sin embargo, esta política requiere que cada acceso de escritura espere hasta que se envíe la información al servidor, por lo que representa una escritura de escaso rendimiento. La memoria caché con escritura directa equivale a usar el servicio remoto para accesos de escritura y explotar la memoria cache únicamente para accesos de lectura. NFS proporciona el acceso de escritura directa.
Consistencia, una maquina cliente se enfrenta al problema de decidir si una copia de datos en memoria caché local es consistente con la copia maestra ( y por tanto, puede usarse). Si la maquina cliente determina que sus datos en memoria caché están desfasados, ya no pueden servir para los accesos y hay que colocar en la memoria caché una copia actualizada de los datos. Existen dos enfoques para verificar la validez de los datos en memoria caché ..:
Enfoque iniciado por el cliente, el cliente inicia una comprobación de validez, en la cual se pone en contacto con el servidor y comprueban si los datos locales son consistentes con la copia maestra. Enfoque iniciado por el servidor, el servidor anota, para cada cliente, las partes de los archivos que coloca en memoria cache, y cuando detecta una inconsistencia, debe reaccionar. Una posible fuente inconsistencia ocurre cuando dos clientes, que trabajan en modos conflictivos, colocan en memoria caché un archivo.
Comunicación en grupos (Algoritmos Para la Sincronización de Relojes)
Si una máquina tiene un receptor de UTC, todas las máquinas deben sincronizarse con ella. Si ninguna máquina tiene un receptor de UTC:• Cada máquina lleva el registro de su propio tiempo.• Se debe mantener el tiempo de todas las máquinas tan cercano como sea posible. Se supone que cada máquina tiene un cronómetro que provoca una interrupción “h” veces por segundo. Cuando el cronómetro se detiene, el manejador de interrupciones añade “1” a un reloj en software. El reloj en software mantiene un registro del número de marcas (interrupciones) a partir de cierta fecha acordada antes; al valor de este reloj se lo llama “C”.
Algoritmo de Cristian
Es adecuado para sistemas en los que:• Una máquina tiene un receptor UTC, por lo que se la llama despachador del tiempo.• El objetivo es sincronizar todas las máquinas con ella. Cada máquina envía un mensaje al servidor para solicitar el tiempo actual, periódicamente, en un tiempo no mayor que / 2 segundos. El despachador del tiempo responde prontamente con un mensaje que contiene el tiempo actual “CUTC”.Cuando el emisor obtiene la respuesta puede hacer que su tiempo sea “CUTC”.Un gran problema es que el tiempo no puede correr hacia atrás:• “CUTC” no puede ser menor que el tiempo actual “C” del emisor.• La atención del requerimiento en el servidor de tiempos requiere un tiempo del manejador de interrupciones.• También se debe considerar el tiempo de transmisión. El cambio del reloj se debe introducir de manera global:• Si el cronómetro genera 100 interrupciones por segundo:
Cada interrupción añade 10 mseg al tiempo. Para atrasar solo agregaría 9 mseg. Para adelantar agregaría 11 mseg.
La corrección por el tiempo del servidor y el tiempo de transmisión se hace midiendo en el emisor:• El tiempo inicial (envío) “T0”.• El tiempo final (recepción) “T1”.• Ambos tiempos se miden con el mismo reloj. El tiempo de propagación del mensaje será (T1 - T0) / 2. Si el tiempo del servidor para manejar la interrupción y procesar el mensaje es “I”:• El tiempo de propagación será (T1 - T0 - I) / 2. Para mejorar la precisión:• Se toman varias mediciones.• Se descartan los valores extremos.• Se promedia el resto. El tiempo de propagación se suma al tiempo del servidor para sincronizar al emisor cuando éste recibe la respuesta.
Algoritmo de Berkeley
En el algoritmo de Cristian el servidor de tiempo es pasivo. En el algoritmo de Berkeley el servidor de tiempo:• Es activo.• Realiza un muestreo periódico de todas las máquinas para preguntarles el tiempo.• Con las respuestas:
Calcula un tiempo promedio. Indica a las demás máquinas que avancen su reloj o disminuyan la velocidad del mismo hasta lograr la disminución requerida.
Es adecuado cuando no se dispone de un receptor UTC.
Algoritmos con Promedio
Los anteriores son algoritmos centralizados. Una clase de algoritmos descentralizados divide el tiempo en intervalos de resincronización de longitud fija:• El i -ésimo intervalo:
Inicia en “T0 + i R” y va hasta “T0 + (i + 1) R”. “T0” es un momento ya acordado en el pasado. “R” es un parámetro del sistema.
Al inicio de cada intervalo cada máquina transmite el tiempo actual según su reloj. Debido a la diferente velocidad de los relojes las transmisiones no serán simultáneas. Luego de que una máquina transmite su hora, inicializa un cronómetro local para reunir las demás transmisiones que lleguen en cierto intervalo “S”.Cuando recibe todas las transmisiones se ejecuta un algoritmo para calcular una nueva hora para los relojes. Una variante es promediar los valores de todas las demás máquinas. Otra variante es descartar los valores extremos antes de promediar (los “m” mayores y los “m” menores). Una mejora al algoritmo considera la corrección por tiempos de propagación.
Varias Fuentes Externas de Tiempo
Los sistemas que requieren una sincronización muy precisa con UTC se pueden equipar con varios receptores de UTC. Las distintas fuentes de tiempo generaran distintos rangos (intervalos de tiempo) donde “caerán” los respectivos UTC, por lo que es necesaria una sincronización. Como la transmisión no es instantánea se genera una cierta incertidumbre en el tiempo. Cuando un procesador obtiene todos los rangos de UTC:• Verifica si alguno de ellos es ajeno a los demás y de serlo lo descarta por ser un valor extremo.• Calcula la intersección (en el tiempo) de los demás rangos.• La intersección determina un intervalo cuyo punto medio será el UTC y la hora del reloj interno. Se deben compensar los retrasos de transmisión y las diferencias de velocidades de los relojes. Se debe asegurar que el tiempo no corra hacia atrás. Se debe resincronizar periódicamente desde las fuentes externas de UTC.
Exclusión Mutua
Cuando un proceso debe leer o actualizar ciertas estructuras de datos compartidas:• Primero ingresa a una región crítica para lograr la exclusión mutua y garantizar que ningún otro proceso utilizará las estructuras de datos al mismo tiempo. En sistemas monoprocesadores las regiones críticas se protegen con semáforos, monitores y similares. En sistemas distribuidos la cuestión es más compleja.
Un Algoritmo Centralizado
La forma más directa de lograr la exclusión mutua en un sistema distribuido es simular a la forma en que se lleva a cabo en un sistema monoprocesador. Se elige un proceso coordinador. Cuando un proceso desea ingresar a una región crítica:• Envía un mensaje de solicitud al coordinador:
Indicando la región crítica. Solicitando permiso de acceso.
• Si ningún otro proceso está en ese momento en esa región crítica:
El coordinador envía una respuesta otorgando el permiso.
• Cuando llega la respuesta el proceso solicitante entra a la región crítica. Si un proceso pide permiso para entrar a una región crítica ya asignada a otro proceso:• El coordinador no otorga el permiso y encola el pedido. Cuando un proceso sale de la región crítica envía un mensaje al coordinador para liberar su acceso exclusivo:• El coordinador extrae el primer elemento de la cola de solicitudes diferidas y envía a ese proceso un mensaje otorgando el permiso, con lo cual el proceso queda habilitado para acceder a la región crítica solicitada. Es un esquema sencillo, justo y con pocos mensajes de control. La limitante es que el coordinador puede ser un cuello de botella y puede fallar y bloquear a los procesos que esperan una respuesta de habilitación de acceso.
Un Algoritmo Distribuido
El objetivo es no tener un único punto de fallo (el coordinador central). Un ej. es el algoritmo de Lamport mejorado por Ricart y Agrawala. Se requiere un orden total de todos los eventos en el sistema para saber cuál ocurrió primero. Cuando un proceso desea entrar a una región crítica:• Construye un mensaje con el nombre de la región crítica, su número de proceso y la hora actual.• Envía el mensaje a todos los demás procesos y de manera conceptual a él mismo.• Se supone que cada mensaje tiene un reconocimiento. Si el receptor no está en la región crítica y no desea entrar a ella, envía de regreso un mensaje o.k. al emisor. Si el receptor ya está en la región crítica no responde y encola la solicitud. Si el receptor desea entrar a la región crítica pero aún no lo logró, compara:• La marca de tiempo del mensaje recibido con,• La marca contenida en el mensaje que envió a cada uno.• La menor de las marcas gana.• Si el mensaje recibido es menor el receptor envía un o.k.• Si su propio mensaje tiene una marca menor el receptor no envía nada y encola el pedido. Luego de enviar las solicitudes un proceso:• Espera hasta que alguien más obtiene el permiso.• Cuando llegan todos los permisos puede entrar a la región crítica. Cuando un proceso sale de la región crítica:• Envía mensajes o.k. a todos los procesos en su cola.• Elimina a todos los elementos de la cola. La exclusión mutua queda garantizada sin bloqueo ni inanición. El número de mensajes necesarios por entrada es “2(n - 1)”, siendo “n” el número total de procesos en el sistema. No existe un único punto de fallo sino “n”:• Si cualquier proceso falla no responderá a las solicitudes.• La falta de respuesta se interpretará como negación de acceso: o Se bloquearán los siguientes intentos de los demás procesos por entrar a todas las regiones críticas. Se incrementa la probabilidad de fallo en “n” veces y también el tráfico en la red. Se puede solucionar el bloqueo si:• El emisor espera y sigue intentando hasta que regresa una respuesta o,• El emisor concluye que el destinatario está fuera de servicio. Otro problema es que:• Se utilizará una primitiva de comunicación en grupo o,• Cada proceso debe mantener la lista de miembros del grupo, incluyendo los procesos que ingresan, los que salen y los que fallan.• Se complica para gran número de procesos. Un importante problema adicional es que:• Todos los procesos participan en todas las decisiones referentes a las entradas en las regiones críticas.• Se sobrecarga el sistema. Una mejora consiste en permitir que un proceso entre a una región crítica con el permiso de una mayoría simple de los demás procesos (en vez de todos):• Luego de que un proceso otorgó el permiso a otro para entrar a una región crítica, no puede otorgar el mismo permiso a otro proceso hasta que el primero libere su permiso.
Algoritmos de Elección
Son los algoritmos para la elección de un proceso coordinador, iniciador, secuenciador, etc.. 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.
Transacciones Atómicas
Las técnicas de sincronización ya vistas son de bajo nivel:
El programador debe enfrentarse directamente con los detalles de: La exclusión mutua. El manejo de las regiones críticas. La prevención de bloqueos. La recuperación de fallas.
Se precisan técnicas de abstracción de mayor nivel que:
Oculten estos aspectos técnicos. Permitan a los programadores concentrarse en los algoritmos y la forma en que los procesos trabajan juntos en paralelo.
Tal abstracción la llamaremos 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. Ejemplo: Un cliente llama al Banco mediante una PC con un módem para: Retirar dinero de una cuenta. Depositar el dinero en otra cuenta. La operación tiene dos etapas. Si la conexión telefónica falla luego de la primer etapa pero antes de la segunda: Habrá un retiro pero no un depósito. La solución consiste en agrupar las dos operaciones en una transacción atómica: Las dos operaciones terminarían o no terminaría ninguna. Se debe regresar al estado inicial si la transacción no puede concluir.
El Modelo de Transacción
Supondremos que:• El sistema consta de varios procesos independientes que pueden fallar aleatoriamente. El software subyacente maneja transparentemente los errores de comunicación.
Escrito por martin91sexyboy el 02/05/2012 19:00 | Comentarios (0)
Las computadoras poseen un circuito para el registro del tiempo conocido como dispositivo reloj [25, Tanenbaum].
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.
Para ciertos algoritmos lo que importa es la consistencia interna de los relojes:
No interesa su cercanía particular al tiempo real (oficial).
Los relojes se denominan relojes lógicos.
Los relojes físicos son relojes que:
Deben ser iguales (estar sincronizados).
No deben desviarse del tiempo real más allá de cierta magnitud.
Para sincronizar los relojes lógicos, Lamport definió la relación ocurre antes de (happens-before):
Si “a” y “b” son eventos en el mismo proceso y “a” ocurre antes de “b”, entonces “a –> b” es verdadero.
“Ocurre antes de” es una relación transitiva:
o Si “a –> b” y “b –> c”, entonces “a –> c”.
Si dos eventos “x” e “y” están en procesos diferentes que no intercambian mensajes, entonces “x –> y” no es verdadero, pero tampoco lo es “y –> x”:
o Se dice que son eventos concurrentes.
Necesitamos una forma de medir el tiempo tal que a cada evento “a”, le podamos asociar un valor del tiempo “C(a)” en el que todos los procesos estén de acuerdo:
Se debe cumplir que:
o Si “a –> b” entonces “C(a) < C(b)”. o El tiempo del reloj, “C”, siempre debe ir hacia adelante (creciente), y nunca hacia atrás (decreciente).
El algoritmo de Lamport asigna tiempos a los eventos.
Consideramos tres procesos que se ejecutan en diferentes máquinas, cada una con su propio reloj y velocidad (ver Figura 9.1 [25, Tanenbaum]):
El proceso “0” envía el mensaje “a” al proceso “1” cuando el reloj de “0” marca “6”.
El proceso “1” recibe el mensaje “a” cuando su reloj marca “16”.
Si el mensaje acarrea el tiempo de inicio “6”, el proceso “1” considerará que tardó 10 marcas de reloj en viajar.
El mensaje “b” de “1” a “2” tarda 16 marcas de reloj.
El mensaje “c” de “2” a “1” sale en “60” y llega en “56”, tardaría un tiempo negativo, lo cual es imposible.
El mensaje “d” de “1” a “0” sale en “64” y llega en “54”.
Lamport utiliza la relación “ocurre antes de”:
o Si “c” sale en “60” debe llegar en “61” o en un tiempo posterior. o Cada mensaje acarrea el tiempo de envío, de acuerdo con el reloj del emisor. o Cuando un mensaje llega y el reloj del receptor muestra un valor anterior al tiempo en que se envió el mensaje: + El receptor adelanta su reloj para que tenga una unidad más que el tiempo de envío.
Ejemplo de tres procesos cuyos relojes corren a diferentes velocidades - El algoritmo de Lamport corrige los relojes.
Este algoritmo cumple nuestras necesidades para el tiempo global, si se hace el siguiente agregado:
Entre dos eventos cualesquiera, el reloj debe marcar al menos una vez.
Dos eventos no deben ocurrir exactamente al mismo tiempo.
Con este algoritmo se puede asignar un tiempo a todos los eventos en un sistema distribuido, con las siguientes condiciones:
Si “a” ocurre antes de “b” en el mismo proceso, “C(a) < C(b)”.
Si “a” y “b” son el envío y recepción de un mensaje, “C(a) < C(b)”.
Para todos los eventos “a” y “b”, “C(a)” es distinto de “C(b)”.
Escrito por martin91sexyboy el 02/05/2012 18:58 | Comentarios (0)
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.
Se considera el día solar al intervalo entre dos tránsitos consecutivos del sol, donde el tránsito del sol es el evento en que el sol alcanza su punto aparentemente más alto en el cielo.
El segundo solar se define como 1 / 86.400 de un día solar.
Como el período de rotación de la tierra no es constante, se considera el segundo solar promedio de un gran número de días.
Los físicos definieron al segundo como el tiempo que tarda el átomo de cesio 133 para hacer 9.192.631.770 transiciones:
Se tomó este número para que el segundo atómico coincida con el segundo solar promedio de 1958. La Oficina Internacional de la Hora en París (BIH) recibe las indicaciones de cerca de 50 relojes atómicos en el mundo y calcula el tiempo atómico internacional (TAI). Como consecuencia de que el día solar promedio (DSP) es cada vez mayor, un día TAI es 3 mseg menor que un DSP:
La BIH introduce segundos de salto para hacer las correcciones necesarias para que permanezcan en fase: El sistema de tiempo basado en los segundos TAI. El movimiento aparente del sol. Surge el tiempo coordenado universal (UTC). El Instituto Nacional del Tiempo Estándar (NIST) de EE. UU. y de otros países: Operan estaciones de radio de onda corta o satélites de comunicaciones. Transmiten pulsos UTC con cierta regularidad establecida (cada segundo, cada 0,5 mseg, etc.). Se deben conocer con precisión la posición relativa del emisor y del receptor: Se debe compensar el retraso de propagación de la señal. Si la señal se recibe por módem también se debe compensar por la ruta de la señal y la velocidad del módem. Se dificulta la obtención del tiempo con una precisión extremadamente alta.
Escrito por martin91sexyboy el 02/05/2012 18:56 | Comentarios (0)
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.
No es posible reunir toda la información sobre el sistema en un punto y que luego algún proceso la examine y tome las decisiones.
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.
Idealmente, un sistema distribuido debería ser más confiable que las máquinas individuales. Alcanzar la sincronización sin la centralización requiere hacer cosas en forma distinta a los sistemas operativos tradicionales.
Escrito por martin91sexyboy el 02/05/2012 18:54 | Comentarios (0)
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.
Escrito por martin91sexyboy el 02/05/2012 18:49 | Comentarios (0)
Origen de los socket tuvo lugar en una variante del sistema operativo Unix conocida como BSD Unix. En la universidad de Berkeley, en los inicios del Internet, pronto se hizo evidente que los programadores necesitarían un medio sencillo y eficaz para escribir programas capaces de intercomunicarse entre sí. Esta necesidad dio origen a la primera especificación e implementación de sockets.
Cliente-Servidor es el modelo que actualmente domina el ámbito de comunicación, ya que descentraliza los procesos y los recursos. Es un Sistema donde el cliente es una aplicación, en un equipo, que solicita un determinado servicio y existe un software, en otro equipo, que lo proporciona.
Los servicios pueden ser;
a)Ejecución de un programa. b)Acceso a una Base de Datos. c)Acceso a un dispositivo de hardware.
Solo se requiere un medio físico de comunicación entre las maquinas y dependerá de ala naturaleza de este medio la vialidad del sistema.
Definición de Socket: designa un concepto abstracto por el cual dos programas (posiblemente situados en computadoras distintas) pueden intercambiarse cualquier flujo de datos, generalmente de manera fiable y ordenada.
Los sockets proporcionan una comunicación de dos vías, punto a punto entre dos procesos. Los sockets son muy versátiles y son un componente básico de comunicación entre interprocesos e intersistemas. Un socket es un punto final de comunicación al cual se puede asociar un nombre.
Para lograr tener un socket es necesario que se cumplan ciertos requisitos
1.Que un programa sea capaz de localizar al otro. 2.Que ambos programas sean capaces de intercambiarse información.
Por lo que son necesarios tres recursos que originan el concepto de socket
a)Un protocolo de comunicaciones, que permite el intercambio de octetos.
b)Una dirección del Protocolo de Red (Dirección IP, si se utiliza el Protocolo TCP/IP), que identifica una computadora.
c)Un número de puerto, que identifica a un programa dentro de una computadora. Con un socket se logra implementar una arquitectura cliente-servidor. la comunicación es iniciada por uno de los programas (cliente). Mientras el segundo programa espera a que el otro inicie la comunicación (servidor). Un Socket es un archivo existente en el cliente y en el servidor.
si un socket es un punto final de un puente de comunicaron de dos vías entre dos programas que se comunican a través de la red, ¿Cómo funciona?. Normalmente, un servidor funciona en una computadora específica usando un socket con un número de puerto especifico. El cliente conoce el nombre de la maquina (hostname) o el IP, en la cual el servidor esta funcionando y el numero del puerto con el servidor esta conectado.
Si el cliente lanza una demanda de conexión y el servidor acepta la conexión, este abre un socket en un puerto diferente, para que pueda continuar escuchando en el puerto original nuevas peticiones de conexión, mientras que atiende a las peticiones del cliente conectado. El cliente y el servidor pu8eden ahora comunicarse escribiendo o leyendo en sus respectivos sockets.
Los tipos de socket definen las propiedades de comunicación visibles para la aplicación. Los procesos se comunican solamente entre los sockets del mismo tipo. Existen cinco tipos de sockets.
El Cliente actúa de la siguiente forma.
1)Establece una conexión con el servidor (Crea un socket con el servidor). 2)Mandar mensajes al servidor o Esperar un mensaje de él.(Consultas) 3)Esperar su respuesta o contestarle(existen casos en que este paso no es necesario). 4)Repetir los pasos 2 y 3 mientras sea necesario. 5)Cerrar la conexión con el servidor.
El servidor actúa así.
1)Inicializa un puerto de comunicación, en espera de clientes que intenten conectarse a él (Crea un serverSocket).
2)Una vez que se conecta alguien, crea un hilo de ejecución para este usuario mientras que el thread principal vuelve al paso 1. Esto comunmente se hace para que el servidor puede atender a varios clientes al mismo tiempo.
3)Se comunica con el cliente mediante el socket creado entre el cliente y él.
4)Espera que el cliente se vaya o lo bota el mismo servidor (Cierrra el socket entre ellos) y elimina el thread de comunicación entre ellos.
Las propiedades de un socket dependen de las características del protocolo en el que se implementan. El protocolo más utilizado es TCP, aunque también es posible utilizar UDP o IPX. Gracias al protocolo TCP, los sockets tienen las siguientes propiedades:
I.Orientado a conexión. Se garantiza la transmisión de todos los octetos sin errores ni omisiones.
II.Se garantiza que todo octeto llegará a su destino en el mismo orden en que se ha transmitido.
Los tipos de socket definen las propiedades de comunicación visibles para la aplicación. Los procesos se comunican solamente entre los sockets del mismo tipo. Existen tres tipos básicos de sockets.
Socket de flujo : da un flujo de datos de dos vías, confiable, y sin duplicados sin límites de grabación. El flujo opera en forma parecida a una conversación telefónica. El tipo del socket es SOCK_STREAM, el cual en el dominio de Internet usa TCP (Transmission Control Protocol).
Socket de datagrama
soporta un flujo de mensajes de dos vías. En un socket de datagrama podría recibir mensajes en diferente orden de la secuencia de la cual los mensajes fueron envíados. Los límites de grabación en los datos son preservados. Los sockets de datagrama operan parecidos a pasar cartas hacia adelante y hacia atrás en el correo. El tipo de socket es SOCK_DGRAM, el cual en el dominio de internet usa UDP (User Datagram Protocol).
Socket de paquete secuencial
da una conexión de dos vías, secuencial y confiable para datagramas de una longitud fija máxima. El tipo de socket es SOCK_SEQPACKET. No hay protocolo en Internet implementado para este tipo de socket.
Implementando un socket en java
En un programa Cliente-Servidor un socket nos ayuda a representar las conexiones entre un programa cliente y uno servidor. En el lado del cliente se utiliza la clase Socket y en el del servidor el Server Socket para representar dichas conexiones.
POGRAMA CLIENTE
El programa cliente se conecta a un servidor indicando el nombre de la máquina y el número puerto (tipo de servicio que solicita) en el que el servidor está instalado. Una vez conectado, lee una cadena del servidor y la escribe en la pantalla:
import java.io.*; import java.net.*; class Cliente
{ static final String HOST = “localhost”; static final int PUERTO=5000; public Cliente( ) { try { Socket skCliente = new Socket( HOST , Puerto ); Input Stream aux = skCliente.getInputStream(); Data Input Stream? flujo = new Data Input Stream( aux ); System.out.println( flujo.readUTF() ); skCliente.close(); } catch( Exception e ) { System.out.println( e.getMessage() ); } } public static void main( String[] arg ) { new Cliente(); } }
En primer lugar se crea el Socket denominado skSocket, al que se le especifican el nombre de host (HOST) y el número de puerto (PORT) en este ejemplo constantes. Luego se asocia el flujo de datos de dicho Socket (obtenido mediante getInputStream), que es asociado a un flujo (flujo) Data Input Streamde? lectura secuencial. De dicho flujo capturamos una cadena ( readUTF()), y la imprimimos por pantalla (System.out). El Socket se cierra, una vez finalizadas las operaciones, mediante el método close(). Debe observarse que se realiza una gestión de excepción para capturar los posibles fallos tanto de los flujos de datos como del Socket.
PROGRAMA SERVIDOR
El programa servidor se instala en un puerto determinado, a la espera de conexiones, a las que tratará mediante un segundo SOCKET. Cada vez que se presenta un cliente, le saluda con una frase “Hola cliente N”. Este servidor sólo atenderá hasta tres clientes, y después finalizará su ejecución, pero es habitual utilizar ciclos infinitos (while(true)) en los servidores, para que atiendan llamadas continuamente.Tras atender cuatro clientes, el servidor deja de ofrecer su servicio:
import java.io.* ; import java.net.* ; class Servidor
{ static final int PUERTO=5000; public Servidor( ) { try { Server Socket skServidor = new Server Socket( PUERTO ); System.out.println(“Escucho el puerto “ + PUERTO ); for ( int numCli = 0; numCli < 3; numCli++; ) { Socket skCliente = skServidor.accept(); // Crea objeto System.out.println(“Sirvo al cliente “ + numCli); Output Stream aux = skCliente.getOutputStream(); Data Output Stream flujo= new Data Output Stream( aux ); flujo.writeUTF( “Hola cliente “ + numCli ); skCliente.close(); } // Cierra while System.out.println(“Demasiados clientes por hoy”); } catch( Exception e ) { System.out.println( e.getMessage() ); } } public static void main( String[] arg ) { new Servidor(); }
}
Utiliza un objeto de la clase Server Socket(skServer), que sirve para esperar las conexiones en un puerto determinado (PUERTO), y un objeto de la clase Socket (skCliente) que sirve para gestionar una conexión con cada cliente. Mediante un ciclo for y la variable numCli se restringe el número de clientes a tres, con lo que cada vez que en el puerto de este servidor aparezca un cliente, se atiende y se incrementa el contador.
Para atender a los clientes se utiliza la primitiva accept() de la clase Server Socket, que es una rutina que crea un nuevo Socket (skCliente) para atender a un cliente que se ha conectado a ese servidor. Se asocia al socket creado (skCliente) un flujo (flujo) de salida Data Output Stream de escritura secuencial, en el que se escribe el mensaje a enviar al cliente. El tratamiento de las excepciones es muy reducido en nuestro ejemplo, tan solo se captura e imprime el mensaje que incluye la excepción mediante getMessage().
Escrito por martin91sexyboy el 02/05/2012 18:47 | Comentarios (0)
En el anterior epígrafe hemos 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.
2.1.1 La operación RPC básica
La llamada a procedimiento remoto constituye un mecanismo que integra el concepto cliente-servidor con la programación convencional basada en llamadas a procedimientos. La idea surgió en 1984 y consiste en que el cliente se comunica con el servidor mediante una llamada ordinaria a un procedimiento. Esta llamada se denomina a procedimiento remoto porque el procedimiento invocado se encuentra en otro espacio de direccionamiento, en la misma o en distinta máquina que el cliente. La información se transporta en los parámetros de la llamada y el resultado es devuelto en el retorno de la llamada. El cliente no tiene que utilizar las primitivas send y receive como en el modelo cliente-servidor puro, de modo que la programación de aplicacio-nes distribuidas se hace más sencilla.
La figura 2.7 muestra un ejemplo del uso de RPC. El cliente necesita de un servicio que es la suma de dos enteros. El servicio se invoca mediante a una llamada a función tal y como se hace en un programa convencional escrito en C. La única diferencia es que la función se ejecuta en una máquina diferente de una forma completamente transparente al usuario.
Fig. 2.7 Computando una suma de forma remota.
La función suma(2, 3); de la figura se implementa en el cliente como una rutina de biblioteca que se denomina el cabo o “stub” cliente. Recordemos cómo se implementan las llamadas al sistema en un lenguaje como C en un sistema operativo centralizado. Estas acaban almacenando los parámetros de la llamada en los registros de la CPU y ejecutando una instrucción de trap al sistema operativo. En un sistema distribuido las cosas son básicamente iguales. La función suma contiene una llamada al sistema send seguida de una llamada receive, donde el programa cliente que invoca suma(2, 3); es suspendido hasta que llega la respuesta del servidor, según el modelo de interacción cliente-servidor. Como podemos ver, el mecanismo RPC no es sino el modelo cliente-servidor, pero con una interfaz más sencilla que hace que el cliente invoque al servicio por su nombre y sin necesidad de gestionar números de puerto.
En cuanto al servidor, el cabo no es una función como era suma en el cliente, sino que es el programa principal. El programador del servicio sólo se ocupa del procedimiento que invoca el cliente. Las llamadas de receive y send en el servidor son ejecutadas por el cabo, que recibe el mensaje, determina el procedimiento solicitado -suma en este caso- y, finalmente, lo invoca. Todos los pasos implicados son los siguientes:
1. El cliente llama al cabo cliente en la manera convencional. 2. El cabo cliente construye un mensaje empaquetando los parámetros del procedimiento y salta al kernel mediante un trap. 3. El kernel local envía el mensaje al kernel remoto. 4. El kernel remoto entrega el mensaje al cabo servidor. 5. El cabo servidor desempaqueta los parámetros y llama al procedimiento de servicio. 6. El procedimiento de servicio hace el trabajo y devuelve el resultado. 7. El cabo servidor empaqueta el resultado y salta al kernel mediante un trap. 8. El kernel remoto envía el mensaje al kernel local. 9. El kernel local envía el mensaje al cabo del cliente, ahora suspendido esperándolo. 10. El cabo local desempaqueta el resultado y lo devuelve al cliente.
2.1.2 El paso de parámetros
La función del cabo cliente es empaquetar los parámetros en un mensaje y enviarlo al cabo servidor. Este examina el código del procedimiento en una sentencia tipo switch e invoca el procedimiento de forma local. El resultado es de nuevo empaquetado en un mensaje y enviado al cabo cliente. Esta interacción, que parece directa, no es tan simple como aparenta ser. Mientras las arquitecturas del cliente y del servidor sean iguales no se presenta ningún problema especial. En un entorno distribuido, sin embargo, cada arquitectura tiene su propia representación de números, caracteres, etc. Por ejemplo, los mainframe IBM utilizan el código EBCDIC para los caracteres en lugar del código ASCII, como el IBM PC. Problemas similares ocurren con la representación de coma flotante o los enteros negativos (complemento a 1 o complemento a 2).
Otro problema surge con la forma de almacenar un entero. La arquitectura PC mantiene una representación “little endian”, a saber, el byte menos significativo en el byte más bajo de memoria. La arquitectura SPARC utiliza un almacenamiento “big endian”, es decir, el byte más significativo en el byte más bajo de la memoria. Un 486 operando en modo protegido representa un entero con cuatro bytes, de modo que el 5 lo representa como 0005. Supongamos que es el primer parámetro de la llamada a procedimiento suma de la Fig. 2.7 y que el servidor ejecuta en una estación SPARC. Los bytes se envían a la red siguiendo su posición en la memoria, de modo que circulará por ella la secuencia de bits del cinco, luego la del cero tres veces. Según llegan los bytes se van almacenando en el buffer del mensaje comenzando por el byte más bajo, de modo que en la memoria de la máquina servidora tenemos los cuatro bytes almacenados de la misma forma que en la memoria del 486, es decir, 0005, el 5 en el byte más bajo. Sin embargo, para la UCP SPARC, este número no es el cinco, sino 5*2563, casi 84 millones. Por lo tanto, es preciso realizar una conversión en la máquina SPARC antes de entregar los parámetros al procedimiento de servicio. Nótese, no obstante, que si es otra máquina SPARC la que envía el entero 5, no es necesario realizar la conversión.
Una forma de solucionar todos estos problemas de representación es convertir los datos a una forma canónica antes de ser enviados a la red. Cuando los parámetros llegan a su destino, por ejemplo, es preciso reconvertir el formato canónico al de la arquitectura del servidor. El problema de este método es que es ineficiente en interacciones entre máquinas de igual arquitectura, de modo que otra aproximación al problema es incorporar en el mensaje un primer byte que identifique la arquitectura del emisor. Si es la misma que la del receptor, no es necesaria conversión alguna.
El problema más difícil de tratar en las llamadas a procedimiento remoto es el paso de punteros, ya que estos sólo tienen sentido en un espacio de direccionamiento dado. Un entero pasado a una rutina de servicio tiene un significado pleno, pero un puntero es simplemente una referencia inútil. No obstante, el paso de punteros en las aplicaciones de usuario es tan común que el prescindir de ellos en las llamadas a rutinas remotas haría perder al concepto de RPC gran parte de su atractivo. Afortunadamente, el problema puede abordarse. En el lenguaje C, por ejemplo, están disponibles dos formas de pasar parámetros. Los enteros y caracteres se pasan por valor. Esto significa que, al invocar un procedimiento con un parámetro que es un entero, se hace una copia del entero en la pila. La rutina invocada trabaja con esta copia. La variable original no se toca. Los vectores, sin embargo, se pasan por referencia. Ello significa que no se copia en la pila el vector completo en la llamada, sino sólo su dirección. El programador de la rutina que recibe la referencia es consciente de que trabaja con un puntero al vector original, que es realmente modificado en la rutina. En Pascal, por defecto, todas las variables se pasan por valor. El paso por referencia es controlado por el programador añadiendo el modificador var a la definición del parámetro que se pasa por referencia en la declaración de la rutina.
Un mecanismo adicional de paso de parámetros es denominado de copia-restauración. Consiste en realizar una copia del parámetro en la pila. Si esta copia parámetro es modificada en el procedimiento, se restaura su nuevo valor a la variable original. Algunos compiladores de Ada utilizan este mecanismo en parámetros in out, si bien ello no está especificado en la definición del lenguaje. La estrategia de copia con restauración puede ser utilizada para pasar punteros a procedimientos remotos. Supongamos la invocación del procedimiento remoto
cuenta = read(df, buf, nbytes);
La implementación más directa consiste en copiar al buffer del mensaje local un vector de “nbytes” caracteres en lugar de buf, que es la referencia al vector. El mensaje es entonces enviado al cabo servidor. Ahora el buffer del mensaje se encuentra en el espacio de direccionamiento de este último, invocará la rutina de servicio read con la referencia al vector recibido en el mensaje, es decir de forma convencional por referencia. Ahora el mensaje es devuelto con su contenido actualizado a la rutina cabo del cliente, que restaura el vector del mensaje a su vector original. Para optimizar este mecanismo eludimos en el cabo cliente la copia del vector al mensaje en caso de lectura. En el caso de la escritura, prescindiremos de restaurarlo. Como vemos, es posible pasar punteros a procedimientos remotos siempre que sean referencias a estructuras sencillas como vectores. No obstante, no podemos enviar a procedimientos remotos referencias a estructuras de datos complejas como listas o árboles.
2.1.3 Especificación de interfase
El servidor RPC puede ser considerado como un módulo u objeto que implementa unas operacio-nes sobre datos ocultos. El servidor da a conocer estas operaciones a los clientes mediante lo que se denomina su interface, constituida por las declaraciones de los métodos que soporta.
Como sabemos, el objetivo del mecanismo RPC es lograr que un programa tenga acceso a los servicios de uno de estos módulos, aunque residan en otro espacio de direccionamiento, posiblemente remoto. La figura 2.8 muestra los componentes de una implementación RPC. La mitad rayada constituye el software adicional de empaquetamiento y desempaquetamiento de parámetros y primitivas de comunicación que debe ser ocultado al programador. Por brillante que sea la idea de la interacción cliente-servidor a través de RPC, si el programador debe encarar la construcción de los cabos, el progreso de los sistemas distribuidos se verá comprometido por la falta de uso en la práctica. Es preciso que la generación de cabos en el cliente y el servidor se realice de forma automática. Pues bien, la interfaz del servidor se utiliza como la base de esta generación automática de cabos.
El primer paso es definir el interfaz, es decir, el conjunto de los prototipos de los procedimientos de servicio, mediante un lenguaje determinado, denominado lenguaje de interfase. La figura 2.8, a) muestra un ejemplo de servidor. La figura 2.8, b) su definición de interfaz. Un compilador especial toma como entrada el fichero escrito en el lenguaje de interfase y como salida genera el código objeto de los procedimientos que constituyen el cabo cliente, por una parte, y el cabo servidor, por la otra. El programa cliente se enlaza con estos procedimientos objeto para generar el ejecutable. En cuanto al servidor, los procedimientos de servicio, escritos por el programador, se compilan previamente a lenguaje objeto y, a continuación, se enlazan con los procedimientos cabo, entre los que figura el procedimiento principal del servidor RPC.
include <header.h>
void main(void) {
struct mensaje m1, m2; /* Mensajes entrante y saliente */ int r; while(1) { receive(FILE_SERVER, &m1); /* El servidor se bloquea esperando un mensaje */ switch(m1.opcode) { case CREATE: r = do_create(&m1, &m2); break; case READ: r = do_read(&m1, &m2); break; case WRITE: r = do_write(&m1, &m2); break; case DELETE: r = do_delete(&m1, &m2); break; case DELETE: r = E_BAD_OP; break; } m2.result = r; send(m1.source, &m2); }
}
a)
include <header.h>
specification of file_server, version 3.1
long read(in char name[MAX_PATH], out char buf[BUF_SIZE], in long bytes, in long position); long write(in char name[MAX_PATH], in char buf[BUF_SIZE], in long bytes, in long position); int create(in char[MAX_PATH], in int mode); int delete(in char[MAX_PATH]);
end;
b)
Fig. 2.8 Ejemplo de un servidor y su definición de interfase.
Una de las implementaciones RPC más populares es Sun RPC, desarrollada por Sun Microsys-tems. Supongamos que deseamos un servidor de tiempo que proporcione dos servicios. Uno, invocado por la función bin_date_1 que devuelve el número de segundos transcurridos desde las cero horas del 1 de enero de 1970. Otro, invocado por la función str_date_2. Esta función toma un parámetro, que es un número de segundos transcurridos desde el instante antes citado, y devuelve la hora y la fecha en una cadena de caracteres. La figura 2.9 describe los pasos implicados en la creación de los procesos servidor y cliente a partir de la especificación de interfaz en el sistema Sun RPC.
Fig. 2.9 Sun RPC
2.1.4 Enlace dinámico
No es conveniente que un servicio esté ligado a una máquina. A veces las máquinas no están operativas, de modo que los servicios se mueven a otra máquina. El cliente está interesado en el servicio, no en qué máquina ejecuta el servidor. Para solicitar un servicio, un cliente podría enviar un mensaje en una sentencia como la siguiente
send(33.33.33.33@20, &mens);
en el código fuente que implementa la llamada RPC. Esta solución es inflexible, puesto que, si dentro de la máquina 33.33.33.33 el servidor pasa a escuchar en otro puerto distinto del 20, el cliente debe ser recompilado. Lo mismo ocurre si el servidor cambia de máquina.
En contraste, el cliente debería invocar el servicio por su nombre, sin hacer referencia a dirección alguna. La figura 2.8 b) muestra la especificación formal del servidor de ficheros 2.8 a). En la especificación formal del servidor intervienen el nombre del servidor y su número de versión. Ambos datos identifican un servidor. Un servidor con el mismo nombre y la misma versión, no obstante, pueden estar replicados en dos o más máquinas a fin de mejorar el servicio o propor-cionar tolerancia a fallos. El cliente debe solicitar un servicio invocando su nombre y versión, sin citar dirección alguna. El número de versión es conveniente a fin de que un servidor que evoluciona conserve su nombre. Un servidor puede evolucionar ofertando nuevos servicios, cancelando otros y modificando otros. A pesar de esta evolución, es preciso que clientes antiguos, desconocedores de los cambios, sigan obteniendo el mismo tipo de servicio. Es preciso compren-der, no obstante, que un servidor con el mismo nombre pero con número de versión distinto es un servidor diferente.
Las ventajas de identificar al servidor por su nombre son evidentes, pero, ¿cómo el cliente localiza al servidor? ¿Quién le proporciona su dirección? Este es un problema al que algunos sistemas RPC, entre ellos Sun RPC, dan respuesta mediante lo que se llama el enlace dinámico, que no es sino averiguar la dirección del servidor en tiempo de ejecución. El enlace dinámico está basado en un tercer proceso denominado el enlazador. Cuando el servidor arranca, en su código de inicialización previo al bucle principal, envía un mensaje al enlazador a fin de registrarse como un proceso que presta un servicio. El enlazador es, al fin y al cabo, un registrador de servicios, un servidor de nombres. El servidor entrega su nombre, su número de versión y su dirección. Se dice que el servidor exporta su interfaz. No sería extraño que dos programadores diesen el mismo nombre a dos servidores distintos, de modo que, a pesar de que no aparezca, cada servidor RPC tiene asociado, además del nombre y la versión, un identificador numérico, generalmente de 32 bits, que también entrega en la operación de registro. Dos servidores distintos deben tener identificadores distintos (se entiende aquí servidor como programa, no como proceso). Si bien sería raro, es posible que dos programadores que terminan dos servidores RPC, coincidan en darles el mismo identificador. Lo que ocurra cuando ambos traten de registrarse depende de cada implementación particular del software RPC, pero es lógico pensar que el enlazador rechazaría la segunda petición de registro.
Supongamos que un cliente invoca el procedimiento remoto read de la figura 2.8 b). El cabo del cliente percibe que aún no dispone de la dirección del servidor, de manera que envía un mensaje al enlazador solicitando la dirección de un servidor cuyo nombre y versión el cliente proporciona en los campos del mensaje. El enlazador busca en sus tablas tal servidor y, si está registrado, proporciona su dirección al cliente en el mensaje de réplica. La principal ventaja del enlace dinámico es que el servidor puede estar en cualquier máquina. Incluso puede haber varios servidores. En enlazador proporciona al cliente la dirección del servidor menos sobrecargado, más cercano, etc. Una desventaja es el tiempo que lleva el registro del servidor y la solicitud del cliente. Muchos procesos cliente sólo hacen una llamada a procedimiento remoto. Por otra parte el enlazador puede llegar a ser una máquina muy solicitada, hasta el punto de necesitar varios enlazadores replicados. Mantener la consistencia de los mismos conlleva más tráfico en el sistema.
2.1.5 Semántica RPC en presencia de fallos
El objetivo de la llamada a procedimiento remoto es conseguir la ejecución de procedimientos en otras máquinas sin cambiar la forma en que se invoca el procedimiento en el código fuente. Salvo algunas excepciones como que un procedimiento remoto no puede usar variables globales, el objetivo ha sido alcanzado plenamente. Mientras no se produzcan errores la transparencia de la llamada remota está conseguida, ya que el programador no necesita saber que la llamada que realiza es a un procedimiento remoto. Los problemas llegan cuando bien cliente o bien servidor dejan de operar correctamente, ya que las diferencias entre llamadas locales y remotas no son fáciles de enmascarar. Vamos a considerar cinco situaciones de fallo:
1. El cliente no es capaz de localizar al servidor. 2. El mensaje del cliente al servidor se pierde. 3. El mensaje de réplica de servidor a cliente se pierde. 4. El servidor se cae tras recibir el mensaje del cliente. 5. El cliente se cae tras recibir la réplica.
El cliente no puede localizar al servidor Puede haber varias causas. Una es que el servidor se cae. Otra es que el servidor se actualiza y un cliente antiguo invoca una versión del servidor que ya no ejecuta. Una solución es que la llamada devuelva −1 como código de error. Sin embargo, −1 puede ser un resultado válido como en la llamada RPC de suma. Otro intento de solución es escribir un manejador de excepción (señales en C) para los errores producidos en las llamadas RPC. Sin embargo, esta solución acaba con la transparencia respecto a las llamadas locales. Lo mejor es recibir el resultado en parámetros de salida de la llamada RPC y que esta devuelva 0 en caso de ejecución con éxito y un código de error en otro caso.
La petición del cliente se pierde Este caso tiene un tratamiento sencillo. El núcleo del cliente arranca un temporizador cuando envía el mensaje al servidor. Si al cabo de un plazo no ha llegado réplica o reconocimiento del servidor, el cliente da el mensaje por perdido y lo reenvía. Si todos los reenvíos se pierden, el kernel del cliente considera que el servidor no está activo y devuelve un error al cabo cliente, que lo pasa a la aplicación. Estamos en el caso anterior.
La réplica del servidor se pierde Este problema es más complejo. Cuando en el caso anterior venció el plazo sin que llegase la respuesta del servidor, asumimos que se había perdido el mensaje enviado por el cliente. Pero existe la posibilidad de que el mensaje perdido fuese la réplica. De cualquier forma, establecimos que lo que había que hacer era el reenvío del mensaje. En el primer caso, el servidor recibe el mensaje reenviado por primera vez. Todo vuelve a funcionar correctamente. En el segundo caso el servidor recibe el mensaje por segunda vez. Sirve la petición dos veces, como si en el programa cliente hubiésemos invocado la llamada una segunda vez. En algunos casos, la repetición de una operación en el servidor no causa ningún daño. Por ejemplo, el leer los 20 primeros bytes de un fichero. Las peticiones que tienen esta propiedad se dicen que son idempotentes. Otras veces, la re-petición sí ocasiona perjuicios, como puede ser el añadir 20 bytes a ese fichero o retirar de una cuenta bancaria 500 millones de pesetas. La solución a este problema pasa por numerar las peticiones. Las retransmisiones llevan el mismo número de secuencia que la transmisión original. Entonces el kernel del servidor detecta que la réplica se ha perdido y la reenvía, sin operar sobre el servidor. Una versión distinta de esta solución es introducir en la cabecera de la petición un bit de retransmisión.
El servidor se cae La figura 2.10 a) muestra la secuencia de eventos producidos en un servidor en el servicio de una petición. El sistema operativo del servidor recibe el paquete entrante con el mensaje, que entrega al cabo para que invoque la ejecución del procedimiento que sirve la petición. A continuación, el cabo pasa la réplica al sistema operativo que lo envía en un paquete al cliente. Ahora bien, tras haberse ejecutado el procedimiento de servicio, el servidor puede sufrir una caída que impide la emisión de la réplica al cliente. Es el caso b) de la figura. Por el contrario, la caída puede producirse tras la recepción del paquete, pero previamente a la ejecución del procedimiento de servicio. Es el caso c).
Las consecuencias de los casos b) y c) es diferente. Supongamos que la operación remota es escribir un texto en la impresora. El servidor primero carga el texto en la memoria interna de la impresora y después escribe en un registro de la misma para iniciar la impresión. El servidor puede caerse antes de establecer el bit o después de establecer el bit. En el primer caso, la operación no será realizada. En el segundo caso, sí, ya que la impresora continúa su trabajo con independencia de que el servidor esté activo o no lo esté.
Podemos pensar que este caso tiene la misma complejidad que la pérdida de la réplica, examina-da en el caso anterior. No es así. La pérdida de la réplica supone un reenvío de la solicitud de impresión. El núcleo del servidor se dará cuenta de que el mensaje tiene un número de secuencia repetido y enviará de nuevo la réplica si repetir la impresión. En contraste, la caída del servidor supone la pérdida del registro de los números de secuencia de mensajes del cliente. Por esta razón, tras un rearranque, el servidor no puede saber si la re-petición de impresión ha sido servida con anterioridad, de modo que volverá a ser servida. Si la caída se produjo en el caso c) la impresión no se hizo, de modo que reiniciar la operación es lo correcto. Sin embargo, si la caída se produjo en el caso b) reiniciar la operación supone repetirla. Lo peor del caso b) es que ni cliente ni servidor sabrán nunca si la operación se realizó con anterioridad o no.
Fig. 2.10 Caída del servidor. a) Operación correcta. b) Caída tras servir el mensaje c) Caída antes de servir el mensaje.
La discusión anterior viene a decir, en esencia, que la ejecución de un procedimiento remoto está envuelta en un factor de incertidumbre que hay que asumir a la hora de programar una aplicación distribuida. Para reducir este factor aleatorio, los implementadores de un sistema RPC toman una de estas tres aproximaciones en cuanto a la semántica de la llamada RPC. La primera se denomina semántica de “al menos una vez”. Esta filosofía de implementación de un software RPC garantiza a la aplicación cliente que el procedimiento remoto va a ejecutarse al menos una vez, pero posiblemente más. Mientras el servidor de figura 2.10 está caído, el cliente no cesa de enviarle nuevas solicitudes de impresión. Llega un momento en que el servidor rearranca y su decisión es ejecutar la petición. Ante el caso b) de la figura 2.10, el servidor está repitiendo la operación. En el caso c) no la repite. De cualquier forma, este mecanismo garantiza la impresión al menos una vez.
La segunda aproximación se denomina semántica de “como máximo una vez”. A la aplicación cliente no se le garantiza que la llamada se ejecute. Tras el rearranque, el servidor RPC puede tomar la decisión de ignorar las peticiones entrantes y de enviar un mensaje de aviso al cliente informándole de la caída, para que este tome las medidas oportunas. La llamada devolverá un código de error parecido a “rearranque de servidor”. El cliente tendrá garantizado que el procedimiento no se ha ejecutado más de una vez. Lo que nunca sabrá es si se ejecutó alguna vez. Otra aproximación que puede tomar el cliente, si la caída se prolonga, es renunciar tras un número de reintentos determinado. También en este caso, desconoce si el procedimiento se ejecutó.
La tercera filosofía que puede adoptar el software RPC es no garantizar nada a la aplicación de usuario. Si el servidor se cae, tras el rearranque, informa de la caída y sigue ejecutando peticiones como si nada hubiese ocurrido. El procedimiento puede no haberse ejecutado o puede haberse ejecutado una o más veces. La ventaja de esta semántica es que es fácil de implementar.
El cliente se cae Puede ocurrir que un cliente haya invocado una llamada RPC y, antes de que la respuesta llegue, el cliente se cae. La operación que se realiza en el servidor no se hace ahora en beneficio de nadie y se dice que ha quedado huérfana. Las operaciones huérfanas son un problema. Cuando el cliente rearranca, puede eliminar las operaciones iniciadas mediante un mensaje especial. Esta solución se denomina exterminación de huérfanos. Esta solución, sin embargo, es problemática porque puede tener consecuencias impredecibles. Por ejemplo, un huérfano puede haber bloqueado uno o más ficheros o registros en una base de datos. Si la operación se aborta, quedarán bloqueados para siempre. Por otra, parte, una operación RPC puede haber solicitado servicios remotos en otras máquinas que habría que abortar igualmente. Desde luego, una de las soluciones, tal vez la mejor, es esperar a que terminen los huérfanos aunque ellos represente una carga inútil de ciclos de UCP.
2.1.6 Implementación de software RPC
El éxito o el fracaso de un sistema operativo distribuido radica en sus prestaciones. Si un sistema es lento, no tiene éxito. Las prestaciones de un sistema operativo distribuido radican en gran parte en la velocidad de las comunicaciones, y esta velocidad depende fundamentalmente de la implementación del protocolo de comunicación más que en sus principios abstractos. En esta sección vamos a discutir la implementación de software RPC.
Protocolos RPC En los sistemas comerciales actuales, el software RPC está implementado como una biblioteca de funciones que el programa de usuario invoca. Tanto el cabo cliente como el cabo servidor no son sino un conjunto de llamadas a funciones de la biblioteca RPC. Veamos el ejemplo de Sun RPC. El siguiente mandato UNIX es el que se utiliza para compilar el programa cliente rdate de la figura 2.9.
# cc -o rdate rdate.c date_clnt.c -lrpclib
donde se aprecia el enlace de la biblioteca de Sun RPC, rpclib. El mandato para generar el servidor RPC es similar. La aplicación de usuario rdate invoca funciones RPC del cabo que, a su vez, invocan las llamadas al sistema de comunicaciones del sistema operativo para enviar los mensajes al servidor RPC. Así, el software RPC puede entenderse como un nivel de servicio entre cliente o servidor y el sistema operativo, tal como ilustra la figura 2.11. Generalmente, las llamadas al sistema de comunicaciones de los sistemas UNIX están implementadas mediante la pila de protocolos TCP/IP, que forman parte del núcleo de UNIX. IP es el protocolo de nivel de red (nivel tres en la pila OSI).
TCP es uno de los protocolos de transporte de la pila TCP/IPTCP es un protocolo del nivel de transporte (nivel cuatro en la pila OSI), orientado a conexión. La comunicación entre dos procesos mediante conexión se basa en establecer un circuito virtual entre ambas máquinas antes del hacer envío alguno. El establecimiento de una conexión es costoso en tiempo y recursos, pero garantiza la fiabilidad total de la comunicación.
El otro protocolo de transporte de la pila TCP/IP es UDP, no orientado a conexión. UDP no es fiable. No usa reconocimientos para hacer saber al proceso emisor la llegada de un paquete. No garantiza la estricta secuencia de los paquetes en el receptor, ya que cada uno de ellos circula por una ruta que no tiene por qué ser la misma. Los paquetes entrantes no son ordenados, sino entregados a la aplicación según llegan. Tampoco dispone de control de flujo, de modo que una máquina rápida puede desbordar a una más lenta o más cargada, con la consecuente pérdida de paquetes. En resumen, si se usa UDP como protocolo de transporte, los paquetes pueden ser perdidos y, si llegan, hacerlo desordenadamente. Una aplicación de usuario que use UDP asume toda la responsabilidad de implementar la fiabilidad de la comunicación. UDP es, sin embargo, mucho más rápido que TCP. Se usa en redes altamente fiables como las redes locales. En ellas prácticamente no existen errores de comunicación que corrompan paquetes, de modo que la sobrecarga que TCP representa no está justificada y el programador de una aplicación de red puede entender perfectamente UDP como un protocolo fiable. En entornos de área ancha, sin embargo, el uso de TCP es imperativo.
Fig. 2.11 Contexto del software de Sun RPC.
A la hora de construir un software RPC, hay que considerar varias cuestiones. Una de ellas es el un protocolo orientado a conexión es que la comunicación es mucho más fácil de implementar. Se envía un mensaje y tenemos la seguridad plena de que ha llegado a su destino. No hay que preocuparse por reconocimientos ni paquetes desordenados. En suma, el nivel de transporte ya está soportado por el protocolo de comunicación utilizado. Como alternativa, puede pensarse en utilizar protocolo de comunicación que utilizan las funciones de la biblioteca RPC. La primera decisión que tomar es la elección de un protocolo orientado a conexión o no orientado a conexión. La ventaja de un protocolo menos sofisticado como UDP en un entorno fiable como una red local.
Una segunda cuestión a ponderar es el uso de un protocolo de comunicación de propósito general o bien diseñar un protocolo específico que se adapte mejor al paradigma RPC. Sun RPC utiliza la primera opción, construido sobre la pila TCP/IP. Las ventajas de usar un protocolo estándar como TCP/IP son evidentes, ya que
1. El protocolo no hay que diseñarlo ni implementarlo. 2. Está disponible en casi todos los sistemas UNIX.
El inconveniente de implementar RPC sobre un protocolo de comunicación estándar como TCP o UDP es la pérdida de prestaciones. Por ejemplo, uno de los campos de la cabecera de un paquete IP es el “checksum” de los campos de la cabecera, que es costoso de computar.
La alternativa al protocolo estándar es un protocolo específicamente diseñado para soportar RPC. La desventaja es el tiempo de concepción y desarrollo de este protocolo y la integración en el sistema operativo. La ventaja es un aumento considerable en la velocidad de las comunicaciones, un factor clave en sistemas operativos distribuidos.
Una tercera cuestión a considerar en el diseño del software RPC es la longitud permitida de los mensajes RPC. Supongamos una llamada RPC read para leer un fichero de 64 Kbytes. Una llamada RPC conlleva una fuerte carga de comunicación por sí misma, con independencia de la cantidad de datos implicados, de modo que conviene realizar la lectura en una sóla llamada. Para ello necesitamos mensajes suficientemente grandes. Sun RPC tiene un límite de mensaje limitado a 8 Kbytes. También hay que considerar la longitud de los paquetes de los protocolos subyacen-tes. Por ejemplo, los paquetes Ethernet están limitados a 1536 bytes, de manera que una llamada RPC a menudo debe ser partida en muchos marcos ethernet, aumentando así la sobrecarga de comunicación.
Reconocimientos En la sección anterior discutimos la posibilidad de implementar RPC sobre un protocolo no fiable como UDP o incluso IP. La fiabilidad es entonces responsabilidad del protocolo RPC y debe ser implementada mediante reconocimientos. Una llamada RPC puede ser la escritura de un bloque de 4 Kbytes. Seguramente, la llamada RPC debe ser partida por el protocolo de transporte RPC en varios paquetes de nivel inferior, supongamos cuatro paquetes como indica la figura 2.12. La estrategia de la figura 2.12b es que el servidor envíe un paquete de nivel inferior con un código de reconocimiento para cada paquete de nivel inferior recibido. Ya que la llamada RPC necesita cuatro paquetes, son precisos cuatro paquetes de reconocimiento. Esta estrategia se denomina protocolo de parada y espera. La alternativa es esperar a que llegue el último paquete de la llamada RPC y entonces el servidor envía un paquete de reconocimiento al cliente. Esta estrategia se denomina protocolo de ráfaga. Con parada y espera, si un paquete se pierde, el temporizador establecido para el paquete por el cliente agota su plazo y el cliente retransmite el paquete. Con el protocolo de ráfaga, supongamos que se pierde el mensaje 1 y el dos y el tres llegan correcta-mente. El servidor tiene dos alternativas. Una es no enviar el reconocimiento de la llamada RPC. El temporizador del cliente para la llamada agota el plazo y el cliente retransmite los cuatro paquetes de la llamada. La otra es lo que se llama la repetición selectiva. El servidor envía un paquete de reconocimiento de los paquetes 0, 2 y 3 y solicitud de reenvío del paquete 1. La repetición selectiva requiere más gestión, pero usa mejor el ancho de banda de la red. Ya que la pérdida de paquetes en redes locales raramente ocurre, conviene evitar el uso de la repetición selectiva. En redes de área ancha la repetición selectiva es una opción conveniente.
Fig. 2.12 a) Un mensaje de 4 Kbytes. b) Protocolo de parada y espera. c) Protocolo blast.
Un problema incluso más importante en el diseño de protocolos de red y transporte es el de control de flujo. Cuando llega un paquete a un adaptador de Ethernet, por ejemplo, este eleva una interrupción a la UCP para que el manejador copie el paquete del adaptador a la memoria principal. Algunos de estos adaptadores son deshabilitados mientras el paquete se lee, de modo que si un segundo paquete llega en medio de la lectura, parte del mismo se pierde. En general, cuando los paquetes llegan más aprisa de lo que pueden ser atendidos, parte de los mismos se pierden, produciéndose un error denominado de “overrun” o sobreflujo. El sobreflujo es un problema más serio que los paquetes corrompidos por el ruido en las líneas.
Volvamos a la figura 2.12. Con un protocolo de parada y espera el error de sobreflujo no puede producirse, por que el segundo paquete no se envía hasta de que no se ha reconocido el primero. Sí puede producirse sobreflujo en un servidor con un número alto de clientes, no obstante. Con el protocolo de ráfaga, mucho más eficiente que el de parada y espera, tenemos el problema del sobreflujo. La solución es que el cliente no envíe el segundo paquete hasta después de un tiempo suficiente como para que termine el trabajo de la rutina de interrupción y el adaptador vuelva a aceptar paquetes. Si el retraso necesario para enviar el segundo paquete es corto, el cliente puede realizar espera activa. Si es largo puede establecer una alarma.
Un protocolo de transporte de propósito general no tiene por qué tener conocimiento del tipo de adaptador de red existente en la máquina. Al fin y al cabo, este es un problema del nivel de enlace. Si el protocolo de nivel de enlace es Ethernet, no fiable, la fiabilidad se deja en manos del protocolo de red. Si este protocolo, como IP, tampoco es fiable, la fiabilidad descansa en el nivel de transporte. Si el protocolo de transporte es UDP, no fiable, es la aplicación de usuario -por ejemplo, el cabo RPC- el garante de la fiabilidad de la llamada RPC, a través de reconocimientos.
Otra posibilidad es que el software RPC implemente el nivel de transporte, descansando directamente sobre el nivel de red. Esta segunda posibilidad permite la optimización del protocolo de transporte por dos razones. La primera es el conocimiento de que está sirviendo únicamente a llamadas RPC, lo que puede ahorrar reconocimientos debido al modelo de interacción cliente servidor. La segunda razón es que el transporte RPC puede ser codificado con conocimiento del tipo de adaptador hardware de la red a la que pertenecen clientes y servidores, evitando desde un principio el problema del sobreflujo, por ejemplo.
Copias La copia de datos entre espacios de direccionamiento es el cuello de botella en las prestaciones de un software RPC. En el mejor de los casos, cuando un mensaje llega al adaptador de red, este puede copiarlo a un buffer del driver del adaptador en el kernel. El kernel lo copia a continuación al espacio del proceso de usuario en una estructura de datos del cabo.
2.2 Comunicación de grupos
La comunicación RPC tiene dos partes, una, el cliente, dos, el servidor. Hay situaciones en que este modelo no es el idóneo en un sistema con un conjunto de servidores de ficheros replicados a fin de proporcionar tolerancia a fallos. Un programa cliente que hace una escritura a disco debe hacer llegar la petición simultáneamente a todos los servidores y no a uno de ellos únicamente. El problema puede solucionarse invocando tantas llamadas RPC como servidores existentes. Existe, sin embargo, otro paradigma de comunicación disponible para los sistemas distribuidos que es la comunicación de grupos, más apropiado en casos como este.
2.2.1 Introducción a la comunicación de grupos
La característica principal de un grupo de procesos es que cuando se envía un mensaje al grupo, todos sus componentes lo reciben. Por otra parte, los grupos son dinámicos. Los grupos nacen y mueren y en cada grupo terminan algunos procesos y se incorporan otros. Por lo tanto es necesario un mecanismo de gestión de grupos. Un proceso puede pertenecer a más de un grupo y abandonar un grupo para unirse a otro. Un grupo es una abstracción cuyo propósito es evitar, en las llamadas de comunicación con grupos de procesos, parámetros molestos como el número de elementos en el grupo o la localización de cada proceso del grupo y proporcionar primitivas más potentes y transparentes, como el ejemplo anterior de envío de un mensaje a un conjunto de servidores de ficheros. El cliente no debería saber cuantos servidores están disponibles en cada momento ni en qué máquinas concretas han sido arrancados.
La implementación de grupos depende mucho del hardware de comunicación disponible. En algunas redes, como ethernet, existen unas direcciones especiales en las que pueden escuchar más de una máquina. Para ello es necesario configurar el adaptador de red ethernet en cada máquina. Un único marco o enviado a esta dirección es leído por todas las máquinas que escuchan en ella. Estas direcciones se denominan multicasting. Si el nivel de enlace de la red soporta multicasting, como es el caso de ethernet, la implementación de grupos es sencilla. Basta asignar a cada grupo una dirección multicasting diferente. Existen redes que si bien no admiten multicasting, sí admiten difusión. Marcos ethernet con la dirección de destino 111…111 son recibidos por todas las máquinas de la red. La difusión puede ser utilizada para implementar grupos, pero es menos eficiente, porque el marco se envía a todas las máquinas, tanto las que pertenecen al grupo como las que no. De todas formas, el envío al grupo de procesos requiere de un solo paquete. Si el nivel de enlace no proporciona multicasting ni difusión, aún es posible la implementación de grupos. Para ello, el emisor debe enviar un paquete particular a cada miembro del grupo. Por supuesto, esta es la implementación menos eficiente.
2.2.2 Aspectos de diseño
La comunicación de grupos comparte muchos aspectos de la comunicación estándar de paso de mensajes, tales como primitivas con buffer o sin buffer, bloqueantes o no bloqueantes, etc. No obstante, existen más posibilidades adicionales a elegir en la comunicación de grupos. En esta sección examinamos algunos de estos aspectos particulares en la comunicación de grupos.
2.2.2.1 Grupos cerrados frente a grupos abiertos
Los protocolos que soportan comunicación de grupos pueden dividirse en dos categorías. Una es la de los grupos cerrados. En ellos sólo los miembros del grupo pueden enviarse mensajes entre sí. Procesos que no pertenecen al grupo no pueden enviar mensajes al grupo como tal, si bien, por supuesto, sí pueden enviar mensajes particulares a cada miembro del grupo a título particular. Otros protocolos soportan grupos abiertos. Un proceso que no pertenece a un grupo puede enviar mensajes a este grupo. Los grupos cerrados son utilizados típicamente en procesa-miento en paralelo, donde los procesos tienen su propio cometido y no interactúan con el mundo exterior. Los grupos abiertos son apropiados para problemas como el de los servidores replica-dos, donde un cliente envía una petición al grupo. Los miembros del grupo también necesitan hacer uso de la comunicación en grupo y no sólo un proceso externo, por ejemplo para decidir quién debe ejecutar una petición dada.
2.2.2.2 Grupos de iguales frente a grupos jerárquicos
En algunos grupos un proceso es el jefe o coordinador y el resto trabajan para él. En otros, todos los procesos tienen la misma categoría y las decisiones se toman de forma colectiva. En el primer caso, cuando uno de los trabajadores o un cliente externo solicita una petición, esta es enviada al coordinador, que decide cuál de los trabajadores es el más apropiado para servirla. Cada una de estas organizaciones tiene sus ventajas y sus inconvenientes. Los grupos pares no tienen un único punto de fallo. Si un trabajador deja de existir, la carga se reparte en el resto. Sin embargo, incurren en el retraso que supone el ponerse de acuerdo para decidir quién sirve una petición. Los grupos jerárquicos tienen las propiedades opuestas.
2.2.2.3 Pertenencia a grupos
Se necesita un método para crear, destruir y modificar los grupos. Una solución es introducir un proceso denominado el servidor de grupos. El servidor de grupos mantiene tablas con los grupos existentes y sus integrantes. Esta solución es eficiente y fácil de implementar. El problema es que el servidor de grupos es una técnica centralizadora y, como tal, constituye un único punto de fallo. La opción opuesta es la gestión distribuida. Un nuevo proceso que se incorpora al grupo puede enviar un mensaje al grupo y todos los procesos toman nota de su existencia. Cuando un proceso del grupo termina, envía un mensaje de adiós.
Surge un problema cuando un proceso del grupo termina inesperadamente. El resto del grupo tiene que descubrirlo experimentalmente, ya que el proceso nunca responde a nada. Cuando todos los miembros lo han constatado, se le da de baja.
2.2.2.4 Direccionamiento de grupos
Para dirigir un mensaje a un grupo, el grupo debe tener una dirección. Si el nivel de enlace de la red -en adelante, la red- soporta multicasting, se puede implementar una dirección de grupo como una dirección multicasting. Si la red soporta difusión, pero no multicasting, el mensaje debe ser recibido por todos los núcleos y extraer de él la dirección del grupo. Si ninguno de los procesos de la máquina es miembro del grupo, el mensaje es descartado. En otro caso, es pasado a todos los procesos que pertenecen al grupo. Si la red no soporta ni difusión ni multicasting, el núcleo de la máquina emisora tendrá que tener una lista de los procesos que pertenecen al grupo y enviar un mensaje a cada uno de los componentes del grupo.
2.2.2.5 Primitivas send y receive
No es conveniente que los procesos de usuario puedan utilizar las primitivas send y recei-ve por separado. Según Tanenbaum, send y receive se corresponden en programación distribuida con la construcción “go to” en programación convencional. Su utilización provoca más trastornos que utilidad. Si RPC es la primitiva de comunicación usada por los procesos de usuario, la comunicación de grupo debiera poder construirse mediante RPC. El problema es tratar con una llamada a procedimiento que devuelve tantos valores como procesos tiene un grupo. No parece posible, de modo que una aproximación común es volver a las primitivas send y receive en los procesos de usuario.
Si se permite send y receive a los procesos de usuario, se pueden aprovechar estas primitivas para realizar la comunicación de grupo. En el caso de la comunicación convencional cliente servidor, el primer parámetro de send es un número de puerto en la red y el segundo parámetro es el mensaje. Se puede utilizar send para la comunicación de grupos empleando como primer parámetro la dirección de un grupo de procesos en lugar de un puerto determinado. Así unifica-mos la comunicación punto a punto y la comunicación de grupos en una primitiva única. La implementación de send que haga el núcleo o la rutina de biblioteca puede ser una de las tres citadas en el apartado de direccionamiento de grupos. send puede ser con buffer o sin buffer, bloqueante o no bloqueante, fiable o no fiable, etc, igual que en la comunicación punto a punto. La comunicación de grupo no cambia las cosas.
Enviar a un grupo obliga al núcleo del sistema que envía a hacer una comunicación multicasting a todos los miembros del grupo, pero ¿qué es recibir de un grupo? Puede entenderse que todos los miembros del grupo van a enviar una réplica diferente y por lo tanto un envío a un grupo debería continuar en el programa de usuario con tantas operaciones receive como miembros tuviese el grupo. Ello, no obstante, significa una pérdida de transparencia, ya que un proceso externo no debe conocer la estructura interna de un grupo.
2.2.2.6 Atomicidad de la difusión
Una de las características de la comunicación de grupos es que un mensaje enviado a un grupo debe ser recibido por todos los miembros del grupo o por ninguno de ellos. A esta propiedad se la denomina la atomicidad de la difusión o simplemente la atomicidad. La atomicidad facilita en gran medida la programación de sistemas distribuidos. Supongamos, por ejemplo, una base de datos distribuida. Una base de datos distribuida puede tener una relación cuyos atributos estén repartidos en máquinas dispersas geográficamente. El acceso a una tupla significa enviar un mensaje a todas las máquinas. Supongamos la creación de una tupla de estas características. Si uno de los mensajes se pierde, la base de datos queda en un estado inconsistente. La tupla debe crearse en su totalidad o no crearse y la aplicación ser informada del éxito o del fracaso de la operación entera, no sólo un éxito parcial. Implementar la atomicidad de la difusión no es tan simple como parece. Por ejemplo, uno de los adaptadores de red tal vez acaba de recibir un paquete y antes de que esté preparado para recibir uno nuevo, llega el paquete de difusión, que no puede ser aceptado y simplemente se pierde. Todas las máquinas del grupo han recibido el paquete excepto una, lo que arruina la difusión completa. Para cerciorarse de que todo ha ido bien, el emisor de la difusión debe esperar las confirmaciones de los miembros del grupo. Si una falta, deberá repetir la difusión o reenviar el mensaje en particular.
Puede ocurrir que antes de repetir la difusión o hacer el reenvío, el emisor de la difusión se caiga. En esta situación, el cliente debe rearrancar, pero nunca sabrá cuántos son los mensajes que realmente han sido enviados y cuántos los que han fallado. Algunos miembros del grupo han recibido el mensaje y otros no. Una situación inaceptable e ¿incorregible? No, queda alguna esperanza. Existe un algoritmo que demuestra que la atomicidad es posible. El emisor realiza la difusión, inicializa temporizadores y realiza los reenvíos necesarios. Cuando un miembro del grupo recibe un mensaje nuevo, envía el mensaje a todos los miembros del grupo -de nuevo utilizando temporizadores y retransmisiones si son necesarias-. Si el mensaje no es nuevo, simplemente es descartado. No importa cuantas máquinas caigan en el proceso de envíos y reenvíos, lo importante es que de los procesos supervivientes en el grupo todos han recibido el mensaje.
Escrito por martin91sexyboy el 02/05/2012 18:45 | Comentarios (0)
En el anterior epígrafe hemos estudiado un modelo deinteracción entre los procesos de un sistema distribuido que es elmodelo cliente-servidor. Para implementarlo, el sistema dispone de dosllamadas al sistema, send y receive, que las aplicaciones utilizan deforma conveniente. Estas primitivas, a pesar de constituir la base dela construcción de los sistemas distribuidos, pertenecen a un niveldemasiado bajo como para programar de forma eficiente aplicacionesdistribuidas.
Escrito por martin91sexyboy el 23/02/2012 05:21 | Comentarios (0)
·Elaboraren coordinación con el estudiante una lista de palabras claves a investigar porunidad
·Propiciarel desarrollo y la realización de prácticas.
·Propiciarla investigación en diversas fuentes de información
·Programarcesiones de exposición de resultados de las investigaciones y practicasesperadas
·Solicitarun reporte por cada una de las temáticas encargadas como Investigación.
·Solicitarun reporte individual sobre los resultados obtenidos por cada una de laspracticas
·Integraral estudiante a la red de laboratorio para no generar problemas de seguridad.
DEFINICONES DE SISTEMASDISTRIBUIDOS
SISTEMA DISTRIBUIDO: un sistema distribuido es una colecciónde computadoras independientes que dan al usuario la impresión de construir un únicosistema coherente.
Por Jesús Carretero Pérez
Es una colección de multiprocesadores posiblemente heterogéneosque comparten memoria distribuida y hacen uso de relojes lógicos para su interacciónhacen uso de una red de intercomunicación.
Escrito por martin91sexyboy el 15/02/2012 04:32 | Comentarios (0)
Los sistemasdistribuidos están basados en las ideas básicas de transparencia, eficiencia,flexibilidad, escalabilidad y fiabilidad. Sin embargo estos aspectos son enparte contrarios, y por lo tanto los sistemas distribuidos han de cumplir en sudiseño el compromiso de que todos los puntos anteriores sean solucionados demanera aceptable.
Escrito por martin91sexyboy el 15/02/2012 03:45 | Comentarios (0)
Concepto y Características de Sor Son aquellos sistemas quemantienen a dos o más computadoras unidas a través de algún medio decomunicación (físico o no), con el objetivo primordial de poder compartir losdiferentes recursos y la información del sistema.
El primer Sistema Operativo de red estaba enfocado a equipos conun procesador Motorola 68000, pasando posteriormente a procesadores Intel comoNovell NetWare. Los Sistemas Operativos de red mas ampliamente usadosson: Linux,Novell Netware, Personal NetWare, LAN Manager, Windows NT ServerUNIX, LANtastic?.
Una posibilidad es el software débilmente acoplado en hardwaredébilmente acoplado [25, Tanenbaum]: Es una solución muy utilizada. Ej.: unared de estaciones de trabajo conectadas mediante una LAN. Cada usuario tieneuna estación de trabajo para su uso exclusivo: Tiene su propio S. O.
Escrito por martin91sexyboy el 15/02/2012 03:44 | Comentarios (0)
Una dirección generada por la CPU se denomina direcciónlógica en cambio a la que es percibida por unidad de memoria se denomina direcciónfísica.
Los esquemas devinculación de direcciones durante la compilación y durante la carga dan pie aun entorno en el que las direcciones lógicas y físicas son las mismas. En cambio,la ejecución del esquema de vinculación de direcciones durante la ejecuciónproduce un entorno en el que las direcciones lógicas y físicas difieren. Eneste caso la dirección lógica suele llamarse dirección virtual.
Direccionamientológico y físico El proceso desde que los datos son incorporados al ordenadoshasta que se transmiten al medio se llama encapsulación. Estos datos sonformateados, segmentados, identificados con el direccionamiento lógico y físicopara finalmente ser enviados al medio. A cada capa del modelo OSI lecorresponde una PDU (Unidad de Datos) siguiendo por lo tanto el siguiente ordende encapsulamiento: DATOS-SEGMENTOS-PAQUETES-TRAMAS-BITS
CAPA
TRANSMITE
APLICACIÓN
DATOS
PRESENTACION
SESIÓN
TRANSPORTE
SEGMENTOS
RED
PAQUETES
ENLACE DED DATOS
TRAMAS
FÍSICA
BITS
Debido a queposiblemente la cantidad de los datos sean demasiados, la capa de transportedesde de origen, se encarga de segmentarlos para así ser empaquetadosdebidamente, esta misma capa en el destino se encargara de reensamblar losdatos y colocarlos en forma secuencial, ya que no siempre llegan a su destinoen el orden en que han sido segmentados, así mismo acorde al protocolo que seeste utilizando habrá corrección de errores. Estos segmentos son empaquetados(paquetes o datagramas) e identificados en la capa de red con la direcciónlógica o IP correspondiente al origen y destino. Ocurre lo mismo con ladirección MAC en la capa de enlace de datos formándose las tramas o frames paraser transmitidos a través de alguna interfaz.
Escrito por martin91sexyboy el 15/02/2012 03:42 | Comentarios (0)
Aunque el hardware es importante, el software lo es más. La imagenque presenta y la forma de pensar de los usuarios de un sistema, quedadeterminada en gran medida por el software del sistema operativo, no por elhardware.
Se puede distinguir dos tipos de sistemas operativos para los devarios CPU: los débilmente acoplados y los fuertemente acoplados.
El software débilmente acoplado permite que las máquinas y losusuarios de un sistema distribuido sean independientes entre sí en lofundamental, pero que interactúen en cierto grado cuando sea necesario.
En el software fuertemente acoplado el programa de aplicación y elsistema operativo necesario para soportarlo, están muy acoplados.
Sistemas Operativos de red
Los Sistemas Operativos de red permiten a los usuarios enestaciones de trabajo independientes la comunicación por medio de un sistemacompartido de archivos, pero dejan que cada usuario domine su propia estaciónde trabajo.
Sistemas realmente distribuidos
Los sistemas operativos distribuidos convierten toda la colecciónde hardware y software en un sistema integrado, muy parecido a un sistema tradicionalde tiempo completo.
Sistemas de multiprocesador con tiempo compartido
Los multiprocesadores con memoria compartida también ofrecen laimagen de único sistema, pero lo hacen mediante la vía de centralizar todo, porlo que en realidad, este caso es un sistema. Los multiprocesadores con memoriacompartida no son sistemas distribuidos.
Escrito por martin91sexyboy el 15/02/2012 03:31 | Comentarios (0)
Con el paso de los años, se han propuesto diversos esquemas declasificación para los sistemas de cómputo con varios CPU, pero ninguno deellos ha tenido un éxito completo ni se ha adoptado de manera amplia. Acontinuación se muestra la taxonomía presentada por Flynn (1972) que considerados características esenciales: el número de flujo de instrucciones y número deflujos de datos.
SISD: Una computadora con un flujo de instrucciones y uno de datos.Todas las computadoras tradicionales de un procesador caen dentro de estacategoría.
SIMD: Un flujo de Instrucciones y varios flujos de datos. Este tipo serefiere a ordenar procesadores con unidad de instrucción que busca unainstrucción y después instruye a varias unidades de datos para que la lleven acabo en paralelo, cada una con sus propios datos.
MISD: Un flujo de varias instrucciones y un flujo de datos.
MIMD: Un grupo de computadoras independientes, cada una con su propiocontador del programa y datos. Todos los sistemas distribuidos son MIMD.
Las computadoras MIMD se clasifican en dos grupos: aquellas quetienen memoria compartida, que por lo general se llaman multiprocesadores yaquellas que no, que a veces reciben el nombre de multicpomputadoras. Ladiferencia esencial es ésta: en un multiprocesador, existe un espacio dedirecciones virtuales, compartido por todos los CPU. En contraste, en unamulticomputadora, cada máquina tiene su propia memoria.
Cada una de estas categorías se puede subdividir, con base en laarquitectura de la red de interconexión: con bus y con conmutador. Enla primera queremos indicar que existe una red, plano de base, bus, cable uotro medio que conecta todas las máquinas. Los sistemas con conmutador notienen sólo una columna vertebral como en la televisión por cable, sino quetienen cables individuales de una máquina a otra y utilizan varios patronesdiferentes de cableado.
Otra dimensión de la taxonomía es que, en ciertos sistemas, lasmáquinas están fuertemente acopladas y en otras están débilmenteacopladas. En un sistema fuertemente acoplado, el retraso que seexperimenta al enviar un mensaje de una computadora a otra es corto y la tasade transmisión de los datos, es decir, el número de bits por segundo que sepuede transferir, es alta. En un sistema débilmente acoplado ocurre locontrario: el retraso de los mensajes entre las máquinas es grande y la tasa detransmisión de los datos es baja. Los sistemas fuertemente acoplados tienden autilizarse como sistemas distribuidos aunque esto no siempre es cierto.
Escrito por martin91sexyboy el 15/02/2012 03:30 | Comentarios (0)
CP es un protocolo orientado a conexión. No hayrelaciones maestro/esclavo. Las aplicaciones, sin embargo, utilizan un modelocliente/servidor en las comunicaciones.
Un servidor es unaaplicación que ofrece un servicio a usuarios de Internet; un cliente es el quepide ese servicio. Una aplicación consta de una parte de servidor y una decliente, que se pueden ejecutar en el mismo o en diferentes sistemas.
Los usuariosinvocan la parte cliente de la aplicación, que construye una solicitud para eseservicio y se la envía al servidor de la aplicación que usa TCP/IP comotransporte.
El servidor es unprograma que recibe una solicitud, realiza el servicio requerido y devuelve losresultados en forma de una respuesta. Generalmente un servidor puede tratarmúltiples peticiones (múltiples clientes) al mismo tiempo.
Escrito por martin91sexyboy el 15/02/2012 03:28 | Comentarios (0)
“Sistemas cuyos componentes hardware y software, están enordenadores conectados en red, se comunican y coordinan sus acciones medianteel paso de mensajes, para el logro de un objetivo. Se establece la comunicaciónmediante un protocolo prefijado por un esquema cliente-servidor”.
Introducción.- Donde especificamos el preámbulo del tema, elobjetivo del trabajo y el contenido del mismo.
Desarrollo.- Donde se describen los aspectos involucrados en lossistemas distribuidos.
Referencias.- Donde especificamos las fuentes que fueronconsultadas para el presente estudio.
DESARROLLO
Sistemas Distribuidos
Definición:
Características:
Concurrencia.- Esta característica de los sistemas distribuidospermite que los recursos disponibles en la red puedan ser utilizadossimultáneamente por los usuarios y/o agentes que interactúan en la red.
Carencia de reloj global.- Las coordinaciones para latransferencia de mensajes entre los diferentes componentes para la realizaciónde una tarea, no tienen una temporización general, esta más bien distribuida alos componentes.
Fallos independientes de los componentes.- Cada componente delsistema puede fallar independientemente, con lo cual los demás pueden continuarejecutando sus acciones. Esto permite el logro de las tareas con mayorefectividad, pues el sistema en su conjunto continua trabajando.
Evolución:
Procesamiento central (Host).- Uno de los primeros modelos deordenadores interconectados, llamados centralizados, donde todo elprocesamiento de la organización se llevaba a cabo en una sola computadora,normalmente un Mainframe, y los usuarios empleaban sencillos ordenadorespersonales.
Los problemas de este modelo son:
Cuando la carga de procesamiento aumentaba se tenía que cambiar elhardware del Mainframe, lo cual es más costoso que añadir más computadorespersonales clientes o servidores que aumenten las capacidades.
El otro problema que surgió son las modernas interfaces gráficasde usuario, las cuales podían conllevar a un gran aumento de tráfico en losmedios de comunicación y por consiguiente podían colapsar.
Grupode Servidores.- Otro modelo que entró a competir con el anterior, también untanto centralizado, son un grupo de ordenadores actuando como servidores,normalmente de archivos o de impresión, poco inteligentes para un número deMinicomputadores que hacen el procesamiento conectados a una red de área local.
Escrito por martin91sexyboy el 15/02/2012 03:21 | Comentarios (0)
