M.C. Juan Carlos Olivares Rojas

Presentación del tema: "M.C. Juan Carlos Olivares Rojas"— Transcripción de la presentación:

1 M.C. Juan Carlos Olivares Rojas
Procesos M.C. Juan Carlos Olivares Rojas @jcolivares Enero, 2010

2 Agenda Concepto de proceso Planificación de procesos
Operaciones sobre los procesos Comunicación interprocesos Ejemplos de sistemas ipc Comunicación en los sistemas clientes-servidor

3 Competencia Específica
Conoce y trata los conceptos de proceso, Mecanismos de procesos, Procesos del sistema operativo, Procesos de cliente servidor.

4 Calendarización Práctica sobre llamadas al sistema en sistemas Unix. Miércoles 3 de Febrero Virtualización de Sistemas Operativos. Miércoles 10 de Febrero. Investigación de la Estructura de Procesos en Minix. Martes 16 de Febrero Práctica de Procesos en Sistemas *X. Miércoles 17 de Febrero.

5 Calendarización Investigación sobre IPC en Sistemas Operativos Distribuidos. Martes 23 de Febrero. Práctica de RPC. Miércoles 24 de Febrero

6 Repaso Unidad I OS Architecture

7 Ring Level Architecture

8 Layer Architecture

9 Client-Server Architecture

10 Arquitectura de Windows NT
Archivos básicos

11 Arquitectura de Windows
Ejemplo de procesos

12 Signals

13 POSIX System Call

14 System Call

15 POSIX

16 Llamadas al Sistema

17 Concepto de proceso Un proceso es un programa en ejecución.
Para que un proceso pueda estar ejecutándose necesita de tener un espacio de memoria asignado. Es la unidad mínima de trabajo de los usuarios (un programa o software puede tener varios procesos).

18 Concepto de proceso El espacio de direcciones se compone además de direcciones para almacenar datos, código, la pila y el heap (montículo). Toda la información de los procesos en los SOs se guardan el PCB (Process Control Block) que es un arreglo o lista ligada que indica la descripción de cada uno de los procesos.

19 Procesos Los procesos tienen asignados un identificador de procesos (PID), el cual es la forma en que el SO trabaja con los procesos. Los procesos se ejecutan de manera secuencial pero pueden realizar bifurcaciones, motivo por el cual se necesita el contador de programa. Los programas pueden tener asignado distintas prioridades para darle más jerarquías.

20 Procesos La finalidad del administrador de procesos es realizar una buena administración (planificación) del tiempo de CPU de la computadora a fin de ejecutar más programas de manera más eficiente. Otra de las características básicas que presenta un proceso es el estado en el cual se encuentra. Existen tres estados básicos en proceso: Ejecución, Listo y Bloqueado.

21 Procesos Estado de los Procesos

22 Procesos Un proceso está en ejecución cuando tiene acceso real al tiempo de CPU. Un proceso está listo cuando se puede ejecutar, es decir, por algún motivo se suspendió para dejar ejecutar otro proceso Un proceso está bloqueado cuando está en espera de algún recurso (E/S) o de que ocurra un evento.

23 Procesos Otros modelos de estados de procesos incluyen otros estados como el de nacimiento, inactivo y diferencia entre bloqueado y en espera. Dentro de un CPU un y sólo un proceso puede estar ejecutándose al mismo tiempo. Los procesos se pueden dormir, despertar y ser asesinados antes de tiempo.

24 Procesos La implementación de procesos depende de la arquitectura del sistema operativo utilizada. Por ejemplo, la implementación de procesos en Windows se da de manera generalizada con llamada al sistema CreateProcess(). En Linux además de la llamada fork(), se encuentra clone() que clona un proceso de memoria pero puede compartir estructuras de datos.

25 Procesos en Sistemas *X

26 Planificación de procesos
Parte fundamental del administrador de procesos es garantizar que los procesos se ejecuten de manera equitativa para garantizar el buen desempeño del sistema. Generalmente se manejan diversos algoritmos para el manejo de la administración de los procesos dichos algoritmos se basan en la calendarización de procesos generalmente basado en indicadores únicos como la prioridad o los tiempos de ejecución.

27 Process Execution

28 Process List

29 Prioridad de Procesos

30 Operaciones sobre procesos
Las operaciones que existen sobre procesos básicamente va la creación, borrado y duplicado de un proceso. La modificación de un proceso es una actividad que la mayoría de los sistemas operativos no modifican. ¿Por qué? Seguridad y protección del sistema.

31 SysCalls para Procesos

32 Planificación de Procesos
La planificación de procesos es la etapa más importante del administrador de procesos ya que se encarga de administrar la disponibilidad del uso de CPU. Los planificadores no importando su complejidad deben respetar los siguientes elementos: equitatividad, eficiencia, tiempo de respuesta, retorno, volumen de producción.

33 Planificación de Procesos
La problemática con este tipo de administración es que los recursos son únicos e imprendecibles. Por este motivo el planificador trata de estimar algunas características. Un planificador no sabe cuanto tiempo tardará en ejecutarse un proceso y si este en algún momento se bloquea por alguna petición de entrada o de salida.

34 Planificación de Procesos
Por este motivo un planificador debe de asignar un tiempo predeterminado llamado Quantum para la ejecución de procesos. Un proceso puede ser interrumpido por otro proceso cuando este último requiera de una atención inmediata. Esto da origen a planificadores con prioridades.

35 Planificación de Procesos
La prioridad puede darse por jerarquía, por costos o por otro medio que sirva de discriminante. Las prioridades pueden ser dinámicas o estáticas. El planificador de procesos se encarga de mantener el contexto de cada una de las aplicaciones para poder realizar multitarea.

36 Planificación de Procesos
Existen diverso algoritmos de planificación de tareas, los cuales a continuación se describen. El algoritmo de round robin (torneo) es muy sencillo, el cual consiste en una lista ligada con los diferentes procesos donde se ejecutan uno por uno pasándose hacia el final de la cola.

37 Planificación de Procesos
La planificación en Round Robin no es la mejor dado a que es muy susceptible al tiempo del cuantum y al tamaño de la cola. La planificación por prioridad permite calendarizar los procesos de acuerdo a su importancia. Los sistemas UNIX cuentan con el comando nice para reducir la prioridad de un proceso.

38 Planificación de Procesos
En algunas ocasiones se suelen agregar diversas mezclas de algoritmos de planificación. Por ejemplo, se puede manejar un sistema de colas por prioridades, en donde cada cola trabaja como si fuera un sistema round robin. Otro algoritmo de planificación es el utilizar colas múltiples. En un principio el cuantum de tiempo aumentaba.

39 Planificación de Procesos
En un principio el quantum de tiempo aumenta en proporción del tiempo que está el proceso en ejecución teniendo 1, 2, N cantidad de quantum. Esto hace que los procesos más viejos tengan mayor prioridad. Otros planificadores de colas múltiples colocan los procesos de manera generalizada en colas de terminal, E/S, quantum corto, quantum largo, etc.

40 Planificación de Procesos
Un algoritmo de planificación más efectivo es el primer el trabajo más corto, dado que el promedio de retorno de cada proceso es menor siguiendo esta técnica, la desventaja es que es dificil calcular cual es el trabajo más corto. La planificación garantizada consiste en hacer promesas a los usuarios para después cumplirla. Una promesa fácil es 1/n.

41 Planificación de Procesos
Un mejor esquema es la planificación por loteria, la cual sonsiste en repartir boletos entre los procesos, a los procesos ganadores se les asigna tiempo de CPU. El secreto es asignar una cantidad de boletos equivalente al peso e importancia de los procesos. En sistemas muy especiales como los sistemas de tiempo real, el planificador debe considerar muchas restricciones.

42 Planificación de Procesos
Entre estas restricciones están la administración de eventos y de cumplir con los límites de tiempos establecidos. Otra alternativa de planificación es utilizar dos niveles. Un nivel para gestionar procesos en memoria principal y otro nivel para memoria secundaria. Con este esquema se obtiene mejor rendimiento cuando se utiliza memoria virtual.

43 Procesos Cooperativos
Los procesos cooperativos son aquellos que pueden trabajar de manera conjunta. Una de las mejores alternativas para la planificación de procesos consiste en que los mismos procesos gestionen con los demás su turno de uso CPU. Si se programa de buena manera puede funcionar, de lo contrario producirá un esquema de competencia.

44 Comunicación interprocesos
Los procesos en algunos SOs pueden crear otros procesos llamados subprocesos, teniendo una jerarquía de procesos padre e hijos. Estos procesos pueden trabajar de manera cooperativa para la resolución de un problema muy particular. Para ello necesitan comunicarse entre sí y a lo que a nivel de SO se llama IPC (Inter Process Communication).

45 IPC La parte más importante de la comunicación entre procesos es sin duda la transferencia de mensajes entre los diversos procesos. La transferencia de mensajes puede llevarse acabo en base a dos primitivas, enviar y recibir, que se pueden aplicar a casi cualquier recurso como a los archivos (leer y escribir).

46 IPC La comunicación entre procesos IPC se debe dar a través del kernel del Sistema Operativo. Tanto Windows como Linux y otros Sistemas Operativos implementan IPC pero lo hacen de manera particular. Los IPC de sistemas *X son los más comunes y estandarizados. A continuación se describirá algo de IPC en Linux.

47 IPC #include <sys/types.h> pid_t pid; hijo = getpid();
Padre = getppid(); Grupo = getpgrp(); Un subprocesos se crea con la instrucción fork()

48 IPC Existen otros tipos de usuarios y grupos los cuales son extendidos, es decir, no actúan como los usuarios reales. uid_t getuid(); /*usuario real*/ uid_t geteuid(); /*usuario extendido*/ gid_t getgid(); gid_t getegid(); Los subprocesos tienen una jerarquía muy marcada.

49 IPC //Validación de subprocesos if (pid == -1)
perror(“Error al crear proceso”); else { if (pid == 0) /*Proceso hijo*/ /*Proceso padre*/ }

50 Ejemplos de sistemas ipc
La principal problemática que se presenta consiste en las condiciones de competencia de los procesos. Por ejemplo, compartir una impresora. Si varios procesos pudieran acceder a la impresora se tendrían problemas de inconsistencias al momento de imprimir. A continuación se describirán algunos problemas de IPC para dar solución en la próxima unidad.

51 Ejemplos de IPC El problema del productor-consumidor: dos procesos comparte un mismo recurso compartido. El problema se presenta cuando el proceso productor produce más de lo que el buffer compartido puede soportar y cuando el proceso consumidor quiere consumir un valor del buffer cuando esta vació. Este tipo de problemas se puede presentar en casos similares como el de la impresora.

52 Ejemplos de Sistemas IPC
Otro problema clasico de IPC es el de la cena de los filosofos, el cual se basa en que existen cinco filosofos comensales sentados alrededor de una mesa circular. Cada filosofo tiene ante si un plato de espaguetti. El espaguetti es tan resbaloso que se necesitan dos tenedores para comerlo. Entre cada par de platos hay un tenedor.

53 Ejemplos de Sistemas IPC
Un filosofo puede comer y pensar. Para comer es necesario que disponga de dos tenedores La solucion mas obvia puede causar inconsistencias. Que pasaria si todos toman su tenedor de la izquierda al mismo tiempo. Podria mejorarse si uno filosofo toma su tenedor de la izquierda, verifica que el de su derecha este desocupado si no lo libera.

54 Ejemplos de Sistemas IPC
Por que falla esta opcion? Otro problema famoso es el problema del peluquero dormido en el cual se tienen un peluquero, una silla de peluqyero y n sillas de clientes. Si no hay ningun cliente el peluquero se duerme. Si llega un cliente y esta dormido el peluquero lo despierta.

55 Ejemplos de Sistemas IPC
Si llega un cliente mientras esta despierto el peluquero se forma en las sillas, o bien, se sale si las sillas estan todas ocupadas. Todos estos son ejemplo de IPC. Los mecanismos basicos son las tuberias, la cola de mensajes, los semaforos, la memoria compartida, los sockets, entre otros elementos.

56 Ejemplos de Sistemas IPC

57 Ejemplos de Sistemas IPC

58 Ejemplos de Sistemas IPC

59 Ejemplos de Sistemas IPC

60 Ejemplos de Sistemas IPC

61 Sistemas Distribuidos
“Es una colección de computadoras independientes que aparecen ante los usuarios del sistema como una única computadora” (Principio de transparencia) El objetivo de los SDs es descentralizar el cómputo basándose en el paradigma de “divide y vencerás”; logrando mayor eficacia, mayor tolerancia a fallos, seguridad, mayor velocidad, entre otros.*

62 Sistema Distribuidos Para lograr la distribución del cómputo se necesitan de diversas entidades que puedan atender una determinada cantidad de procesos en un momento determinado. La mayor problemática de los SDs es la gran heterogeneidad tanto en software y en especial en hardware, ya que se necesita de mucho esfuerzo para lograr la transparencia.

63 Características de un SD
Múltiples elementos de procesamiento. Mecanismos de intercomunicación. Independencia a fallos en los nodos de procesamiento. Estado de compartición. Esquema de protección. Sistemas Abiertos. Plataformas diversas (heterogéneas).

64 Ventajas y desventajas de los sistemas distribuidos
La base comparativa para obtener las ventajas y desventajas de los SD se hace con respecto a una computadora aislada. A continuación se mencionan las ventajas de los SD.

65 Ventajas de los SD Con el uso de SD se logra compartir información así como dispositivos periféricos entre más de un usuario. Los SD permiten dividir las cargas de trabajo entre diferentes computadoras de manera más eficaz. Cuando un nodo de procesamiento falla, el sistema en general sigue funcionando. Ejecución concurrente de procesos

66 Desventajas de los SD Debido a que la tecnología de los SD aún está siendo explorada, no se tiene la experiencia suficiente en el diseño, implantación y uso del software distribuido y se debe contestar a preguntas tales como: ¿Qué tipos de sistemas operativos, lenguajes de programación y aplicaciones son los adecuados para estos sistemas?,

67 Desventaja de los SD ¿Cuánto deben saber los usuarios de la distribución? Las redes de comunicación, pueden llegar a perder mensajes, latencia de las comunicaciones o saturación de mensajes. Otra de las desventajas de los SD es la vulnerabilidad que puede sufrir la información que puede llegar a estar disponible para un gran número de usuarios del sistema.

68 Desventajas de los SD Requerimientos de mayores controles de procesamiento y acceso. Administración más compleja. Costos.

69 Complejidad de los sistemas distribuidos
Los sistemas distribuidos tienen más de dos décadas de haber surgido pero son tan complicados en su construcción tanto como una red de transporte público como el metro, y pasará más tiempo para que podamos entenderlos correctamente y construir uno de la manera más apropiada.

70 Complejidad de los SD La fuente básica de la complejidad de los SD recae en la interconexión de componentes. Existen fallas en todos los sistemas, sólo que en un SD resultan más visibles. A continuación se muestran algunos problemas del sistema.

71 Complejidad de los SD Al interconectar dos o más elementos entre si, sus funcionalidades se interfieren. Pueden existir también fallas de propagación. Se pueden tener fallas por el tamaño del sistema.

72 Complejidad de los SD Las aplicaciones "distribuidas" deben estar preparadas para soportar fallas parciales; lo que representa una complejidad adicional en el diseño de éstas aplicaciones. Se deben tener mecanismos para la localización de recursos, la recuperación de éstos, así como la coordinación de las réplicas de los estados de los servidores.

73 Complejidad de los SD No se tiene disponibilidad de una memoria global y un reloj global, no se pueden predecir los retardos y mensajes. Se requiere más capacidad de almacenamiento. S requiere de sincronización para actualizar el estado del sistema. Compatibilidad.

74 Complejidad de los SD Los recursos compartidos deben ser accedidos por un proceso a la vez (exclusión mutua) y deben liberarse. Seriabilización. Los procesos deben solicitar recursos locales o remotos y posteriormente liberados en cualquier orden que puede ser no conocido.

75 Modelo Cliente-Servidor
Una arquitectura es un conjunto de reglas, definiciones, términos y modelos que se emplean para producir un producto. La Arquitectura Cliente/Servidor (C/S) agrupa conjuntos de elementos que efectúan procesos distribuidos y computo cooperativo.

76 Arquitectura Cliente/Servidor
Este modelo se basa en un protocolo solicitud – respuesta. El cliente envía una solicitud de cierto servicio al servidor, el servidor realiza el trabajo y regresa el resultado de la operación. La principal ventaja de este protocolo es su sencillez, únicamente se necesita la ubicación del servidor.

77 Arquitectura Cliente/Servidor
Beneficios: Mejor aprovechamiento de la potencia de cómputo (Repartición del trabajo). Reducción del tráfico en la red. Opera bajo sistemas abiertos. Facilita el uso de interfaces gráficas variadas y versátiles.

78 Cliente Conjunto de software y hardware que invoca los servicios de uno o varios servidores. Características: El Cliente oculta al servidor y la red. Mantener y procesar todo el diálogo con el usuario. Manejo de la interfaz, entrada de datos y validación.

79 Servidor Conjunto de hardware y software que responde a los requerimientos de un cliente. Tipos comunes de Servidores: Servidor de Archivos (FTP, Novell). Servidor de Bases de Datos (MySQL, ORACLE, INFORMIX). Servidor de Impresión. Servidor de Terminal. Servidor de Aplicaciones (Windows NT, Novell).

80 Servidor Funciones del Servidor:
Acceso, almacenamiento y organización de datos. Administración de recursos compartidos. Ejecución de toda la lógica para procesar una transacción.

81 Middleware Capa de software que se ejecuta sobre el sistema operativo local ofreciendo unos servicios distribuidos estandarizados. Sistema abierto independiente del fabricante. No depende del hardware y sistema operativo subyacente. Ejemplos: DCE (Open Group). CORBA (OMG).

82 Otras Arquitecturas P2P (Peer to Peer) Arquitecturas de intermediarios
Arquitecturas de 2, 3 y n-capas Clientes pesados, ligeros e inteligentes

83 Arquitectura de Sistemas Centralizados
Único computador (caro y de gran potencia) con terminales Soporte multiusuario – Ley de Grosch (obsoleta): Prestaciones = cto x (Precio)2

84 Arquitecturas de Sistemas Distribuidos
Cliente 1 Servidor Servidor Solicitud . Cliente Respuesta Cliente n Modelo Cliente/Servidor Tradicional Modelo Cliente/Servidor Concurrente El cliente realiza el front end de la aplicación, el servidor implementa el back end o la lógica del negocio Proxy en el lado cliente Proxy en el lado servidor Cliente Cliente Modelo Cliente/Servidor de n capas

85 Arquitectura de Sistemas Distribuidos
Coordinador C1 C1 C2 … Cn Cn P2P Simétrico Cluster Asimétrico Planificador Planificador Planificador . CPU Memoria Disco C1 CPU Memoria DISCO C2 CPU MEMORIA Disco Cn Grid computing

86 Características de Hardware
Los Sistemas Distribuidos necesitan forzosamente de una red de computadoras y de un sistema de recursos propios por cada nodo local.

87 Características de Software
El software necesario en sistemas distribuidos debe ser rediseñado con un paradigma totalmente contrario al centralizado.

88 Sistemas Operativos de Red
Un Sistema de Red (SR) es una colección de sistemas operativos locales, acompañado de servidores de impresión, de archivos, etc., conectados por medio de una red. Los SR se ejecutan como funciones locales autónomas a la administración de dispositivos, de procesos, de entradas y salidas, de archivos y recursos en general.

89 Sistemas Operativos de Red
Los principales sistemas operativos de red basados en Unix, a los cuales generalmente se les llama Sistemas *X o simplemente X, como son: HP-Aux (HP), AIX (IBM), Unix SCO (SuSE), Irix (Silicon Grpahics), Unix BSD, Solaris (Sun). Otros sistemas que están tomando auge son: Windows Server 2003/2008 (antes NT), Mac OS X Server (10.5).

90 Sistemas Operativos Distribuidos
Un Sistema Operativo Distribuido (SOD) extiende el concepto de administración de recursos e interfaces con el usuario hacia computadoras de memoria compartida, el cual consiste en varias computadoras autónomas conectadas por una red de comunicaciones.

91 Características de los SOD
Para cada uno de los usuarios debe de ser similar al trabajo en el Sistema Centralizado. Se ejecuta en múltiples Computadoras. Tiene varias copias del mismo Sistema Operativo o de diferentes Sistemas Operativos que proveen los mismos servicios. Transparencia

92 SOR vs SOD Los SOR se encargan de la administración de los recursos locales y trabajan en conjunto para lograr la compartición de recursos. En los SOD la administración de los recursos se hace de manera homogénea de todos los recursos aun y cuando se encuentren distintos SO.

93 SOR vs SOD

94 Sistema Operativo de Red Sistema Operativo Distribuido
SOR vs SOD Sistema Operativo de Red Sistema Operativo Distribuido Recursos propiedad de los nodos locales Recurso propiedad del sistema global Recursos locales administrados por el sistema operativo local Recursos locales administrados por un DO/S global Acceso ejecutado mediante un sistema operativo local Acceso ejecutado por el DO/S Solicitudes pasadas de un sistema operativo local a otro vía el NOS Solicitudes pasadas directamente de un nodo a otro vía el DO/S

95 SOR vs SOD Administración de la Memoria

96 SOR vs SOD Administración de la Memoria

97 Sistemas Operativos Distribuidos
En la vida real, los SOD son poco utilizado en entornos reales utilizándose de manera exclusiva en el ámbito académico y científico. A continuación se describen una serie de SOD. Otros SOD no listados son Solaris MC, Spring, Inferno, Sprite, etc.

98 Amoeba Creado en 1981 en Holanda por Andrew Tanenbaum y otros.
Es un Sistema Operativo (SO) creado desde cero, sin problemas de compatibilidades. Es totalmente transparente ya que no existen máquinas clientes ni servidores

99 Amoeba Está escrito en C y presenta balanceo de carga.
No hace uso de memoria compartida. Dispone de un micronúcleo que se ejecuta en cada máquina.

100 Mach Se originó en 1984 en la Carneige Mellon University.
Se fusionó con Unix BSD para dar un soporte a aplicaciones legadas. La OSF (Open Software Foundation) lo escoge como su SO llamándolo OSF/1.

101 Mach El código creció demasiado por lo que se tuvo que mantener un micronúcleo y el soporte para Unix se hizo a través de un emulador. En la década de 1990, surgió Mach 4. El Mac OS X está basado en Mach (versión NeXSTEP).

102 Chorus Se originó en Francia en el INRIA.
Es un sistema modular con soporte para aplicaciones Unix. Se caracteriza por el manejo excesivo de hilos.

103 Plan9 Se originó a finales de la década de 1980 con apoyo de IBM.
Es compatible con POSIX. Está conformada por protocolos especiales.

104 Comunicación en los sistemas clientes-servidor
Para lograr la distribución de procesos se requiere de mecanismos que permitan coordinar y controlar la ejecución de procesos en ambientes no centralizados, ya sean de manera local y remota. Los primeros protocolos para la distribución de procesos remotos fueron para máquinas homogéneas.

105 Comunicación Otra forma de comunicación fue la estandarización de sistemas heterogéneos con interfaz común UUCP (Unix to Unix Copy Protocol) que dio origen a los comandos R (rcopy, rlogin, rsh). rlogin rsh

106 Comunicación La comunicación entre procesos (IPC) es parte fundamental de las primitivas de sincronización de un sistema distribuido. Los mecanismos de comunicación entre procesos no sólo aplican a aplicaciones distribuidas sino a cualquier tipo.

107 Comunicación El mecanismo de comunicación entre procesos más famosos es el IPC (Inter Process Comunication) de Unix System V. El otro punto a tratar es sobre los mecanismos de intercomunicación entre entidades de procesamiento diferentes con diferentes sistemas operativos: POSIX.

108 Sockets Los sockets son el mecanismo de sincronización distribuida más importante. Se les denomina conectores por que pueden unir un proceso cliente y un proceso servidor, de manera semejante a como se puede unir un enchufe de un dispositivo eléctrico con su respectivo zócalo.

109 Sockets El mecanismo de sockets más conocido es el referente a la API de Berkeley. Está API está implementado en prácticamente todos los sistemas Unix, por lo que se maneja C, pero también está portado a otras arquitecturas como Windows (WinSock) y a otros lenguajes como Java

110 Sockets Los sockets trabajan sobre capa 4 (Transporte) del modelo OSI, aunque algunos autores la ubican en la capa 5 (Sesión). Para la comunicación de procesos remotos se necesita conocer la dirección de la máquina destino y el puerto donde se va a escuchar.

111 Sockets Los sockets no están casados con ningún tipo de red, por lo que se pueden implementar en diversos protocolos de red como IPX/SPX, NetBEUI, TCP/IP, siendo este último el más importante. Para hacer uso de sockets se necesitan dos cosas: una familia o protocolo a utilizar para la comunicación y un tipo de conexión.

112 RPC Las llamadas a procedimientos remotos (RPC) fue el primer intento por obtener un middleware para la construcción de sistemas distribuidos. Su funcionamiento se basa en la arquitectura cliente/servidor siendo totalmente transparente para el usuario.

113 RPC El problema del manejo de procesos distribuidos con sockets radica en que se basa en el flujo de E/S, haciendo los programas más difíciles de estructurar. En 1984 Birelly y Nelson idearon el modelo de RPC a semejanza del llamado de procedimientos locales (LPC).

114 RPC El nivel de transparencia en RPC es muy alto ya que el usuario no tiene que ver con detalles de conexión. La simplicidad de toda esta heterogeneidad en el llamado a un procedimiento remoto es realizado por los stubs (resguardos) tanto en el cliente como en el servidor.

115 RPC Para la transferencia de datos entre los stubs, se necesita de un proceso de empacar desempacar los parámetros y resultados. Dicho proceso recibe el nombre de marshalling. Los stubs se comunican con los núcleos de cada proceso logrando una transparencia muy alta.

116 RPC La secuencia de mensajes RPC es la siguiente:
El procedimiento cliente llama al stub del cliente de la manera usual. El stub del cliente construye un mensaje y hace un señalamiento al núcleo. El núcleo envía el mensaje al núcleo remoto.

117 RPC El núcleo remoto proporciona el mensaje al stub del servidor.
El stub del servidor desempaca los parámetros y llama al servidor. El servidor realiza el trabajo y regresa el resultado al stub. El stub del servidor empaca el resultado en un mensaje y hace un señalamiento al núcleo.

118 RPC El núcleo remoto envía el mensaje al núcleo del cliente.
El núcleo del cliente da el mensaje al stub del cliente. El stub desempaca el resultado y lo regresa al cliente. El manejo de los datos se hace a través de XDR (eXternal Data Representation).

119 RPC Para el envío de datos se utiliza la siguiente forma canónica: Complemento a 2 los enteros, ASCII caracteres, 0 (falso) y 1 verdadero, formato IEEE decimales, todo guardado como little endian. En la práctica RPC no es lo mismo que un procedimiento local a la hora de revisar los mecanismos de fallas.

120 RPC La semántica de fallas de RPC es la siguiente:
El cliente no puede localizar al servidor. Se pierde el mensaje de solicitud del cliente al servidor Se pierde el mensaje de respuestas del servidor al cliente. El servidor falla antes de recibir una solicitud.

121 RPC El cliente falla después de enviar una solicitud.
En general existen diversas implementaciones de RPC, siendo las más extendidas sobre TCP/IP, la cual tiene los siguientes puntos a favor: El protocolo ya ha sido diseñado, lo que ahorra trabajo considerable.

122 RPC Se dispone de muchas implementaciones.
Esta disponible en casi cualquier sistema Unix. Tanto TCP como UDP están soportados por muchas redes. Las implementaciones más evolucionadas de RPC incluye la de Sun ONC (Open Network Computing) y DCE (Distributed Computing Environmet).

123 RPC RPC está desarrollado en C, pero algunas versiones permiten programar en otros lenguajes como Fortran. Las implementaciones más actuales trabajan sobre XML formando los XML-RPC. Para la conexión entre un cliente y un servidor utilizando RPC se siguen dos pasos: localizar la máquina servidor, y localizar el proceso en esa máquina.

124 RPC Para encontrar dichos servicios se necesita de un demonio RPC que se encuentre monitoreando todos los procesos remotos, dicho proceso se llama portmap , el cual escucha en el puerto 111. Muchos servicios de red utilizan RPC para funcionar, entre ellos NFS, el cual es un sistema de archivos distribuidos.

125 RPC Un programa en RPC se crea a través de un lenguaje de definición de interfaces (IDL por sus siglas en Inglés). Tiene la extension .X program RAND_PROG { version RAND_VER { void INICIALIZA_RANDOM(long) =1; doble OBTEN_SIG_RANDOM(void) = 2; } =1; /*No. de version*/ } = 0x ; /*No. de programa*/

126 RPC rpcgen -c -a rand.x rand_server.c servidor
rand_svc.c stub del servidor (no se modifica) rand.h cabeceras rand_clnt.c stub del cliente (no se modifica) rand_client.c cliente rand_xdr.c manejo de estructuras

127 RPC 00000000-1FFFFFFF Definidos por sun
FFFFFFF Definidos por el usuario FFFFFFF Transitorios FFFFFFFF Reservados para usos futuros rpcinfo -s portmap

128 RPC const MAX = 100; typedef int Longitud; struct argumentos {
float salario; Longitud tam; }; Sólo se puede recibir y enviar un parámetro.

129 RPC Existen nuevas propuestas para mejorar el desempeño de RPC como RPC2 que maneja UDP. También se han diseñado mecanismos como MultiRPC para el manejo de RPCs en paralelos. Existen otras alternativas como LRPC (RPC ligeros) que se basan en optimizaciones de la copia de datos y de la planificación de los hilos. RPC está definido en el RFC 1831.

130 Comunicación en Grupo Se define a un grupo como un conjunto de procesos que actúan entre ellos encierto sistema. Los grupos son dinámicos, ya que pueden aceptar nuevos procesos o estos pueden dejar a su grupo. Los grupos pueden ser abiertos o cerrados dependiendo de cómo es el paso de mensajes entre los elementos del grupo.

131 Comunicación en Grupo En base a su organización los grupos pueden ser de compañeros (cuando todos los procesos son iguales y para hacer elecciones hacen recuento de votos) o Jerárquico (donde existe un proceso coordinador y el resto son trabajadores). Cuando entran nuevos procesos o se salen del grupo, se debe garantizar que los mensajes lleguen a los procesos que actualmente conforman el grupo.

132 Comunicación en grupo Una de las mayores problemáticas con respecto a la comunicación en Sistemas Distribuidos es la forma en como podemos comunicar varios procesos distribuidos a la vez. La comunicación tradicional es del tipo puntual (unicast) o bien hacia todos con el uso de la difusión (broadcast).

133 Comunicación en Grupo El problema radica en que al hacer un broadcast los mensajes llegan hacia todas las máquinas y no hay forma alguna de discriminar hacia un grupo determinado de procesos. Por otra parte, el hacer broadcast está limitado en muchas redes como Internet donde no existe, por este motivo suele utilizarse la técnica de multicast.

134 Comunicación en Grupo El problema del multicast es que se necesitan de direcciones IP especiales (Clase D) para poderse llevar acabo. En la práctica se utiliza muy poco y en lugar se usa comunicación con datagramas hacia un grupo de procesos donde la parte más importante es la coordinación entre procesos.

135 Multicast Java try { InetAddress grupo = InetAddress.getByName(args[1]); MulticastSocket s = new MulticastSocket(6789); s.joinGroup(grupo); byte [] m = args[0].getBytes(); DatagramPacket mensajeSalida = new DatagramPacket(m, m.length, grupo, 6789); s.send(mensajeSalida);

136 Multicast Java byte []buffer = new byte[1000];
for(int i=0; i<3; i++) { DatagramPacket mensajeEntrada = new DatagramPacket(buffer, buffer.length); s.receive(mensajeEntrada); System.out.println("Recibido: " + new String(mensajeEntrada.getData())); } s.leaveGroup(grupo); } catch (Exception e) { //Manejo de excepción}

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

138 Tolerancia a fallos Un Sistema Distribuido en base a la coordinación de sus procesos puede ser: Asíncrono: no hay coordinación en el tiempo. Síncrono: se suponen límites máximos para el retraso de mensajes. El primer factor a tomar en cuenta es que el canal de comunicación este libre de errores (canal confiable).

139 Tolerancia a Fallos Para garantizar que el canal sea confiable se debe de realizar lo siguiente: Retransmisión de mensajes. Debe haber redundancia de canales La entrega de un paquete sea dentro de un tiempo límite especificado En general, se considera que los canales de comunicación son fiables y que cuando falla la comunicación es debido a la caída del proceso.

140 Tolerancia a Fallos Las fallas de partición son las fallas de comunicación más importantes ya que fragmentan la red en pequeñas áreas llamadas particiones haciendo imposible el manejo de la consistencia de los datos. Son difíciles de detectar ya que no son visibles para todos los nodos de la red.

141 Tolerancia a Fallas Las fallas de partición pueden ser muy comunes por lo que los sistemas de archivos deben tener un mecanismo que permita reintegrar los datos una vez eliminada la partición. Esta idea atraído como consecuencia el uso de sistemas de archivos con soporte a desconexión, los cuales son útiles en entornos de cómputo móvil.

142 Tolerancia a Fallos

143 Tolerancia a Fallos

144 Tolerancia a Fallos Para prevenir errores se utilizan los Detectores de Fallo, los cuales son procesos que nos indican la presencia de fallos en un sistema. Los detectores de fallos no son necesariamente exactos y la mayoría de ellos se consideran “Detectores de Fallo No Fiables”

145 Tolerancia a Fallos Este tipo de detectores se basan en que si en un tiempo máximo predefinido no reciben mensajes de los nodos, los consideran sospechosos, aunque no necesariamente han fallado, esto puede ocurrir debido a retrasos en la transmisión. Un “Detector de Fallas Fiable” detecta los fallos en un sistema en forma exacta y normalmente requieren de hardware y software adicional.

146 Tolerancia a Fallos Para evitar fallas en los sistemas distribuidos se suelen utilizar técnicas de duplicación y replicación de datos.

147 Tolerancia a Fallos Se utiliza la duplicidad de los datos para tener sistemas tolerantes a fallos, de más fácil acceso, entre otras ventajas. El principal problema que presenta la duplicación de los datos tiene que ver con la transparencia de almacenamiento. Otro problema importante consiste en la consistencia de la información.

148 Tolerancia a Fallos Un sistema de archivos distribuidos se caracteriza por tener un servidor de réplicas. El servidor de réplicas debe contener un protocolo de actualización eficiente (e.g., no se debe enviar un mensaje de actualización a todas las copias).

149 Tolerancia a Fallos Se manejan esquemas de actualización de réplicas primarias y secundarias, basado en quorum, entre otros mecanismo. La duplicidad de los datos se puede hacer a nivel físico como los sistemas RAID. Las cachés son un ejemplo de duplicidad de datos que traen grandes beneficios.

150 Tolerancia a Fallos La mejor forma de evitar fallas tanto en sistemas distribuidos como centralizados es a través del correcto diseño de los sistemas. A continuación se presentan algunas recomendaciones o mejores prácticas para la construcción de sistemas distribuidos tolerante a fallas.

151 Consejos para construir SD
Duplicar la información para aumentar la disponibilidad. Usar copias locales de la información para permitir una operación autónoma. Utilizar cachés. Usar tiempos de espera para revocar.

152 Consejos para construir SD
Usar mecanismos estándares para llamadas remotas. Utilizar técnicas de criptografía para la autenticación y seguridad de la información.

153 Referencias Tanenbaum, Andrew (1996). Sistemas Operativos Distribuidos. México, Prentice Hall. Tanenbaum, Andrew, Van Steen, Maarten (2006). Distributed Systems Principles and Paradigms. Estados Unidos, Pearson Prentice Hall. Morales, F. (2009), Material del Curso de Sistemas Distribuidos II, ITM, México.

154 Referencias A. Tanenbaum, “Sistemas Operativos Distribuidos”, Prentice Hall, México, 1996, pp. 617, ISBN: G. Colouris, et al., “Sistemas Distribuídos. Conceptos y Diseño”, tercera edición, Pearson Addison Wesley, Espana, 2005, pp. 726, ISBN:

155 Bibliografía Tanenbaum, A., “Sistemas Operativos Modernos”, Tercera Edición, Pearson Educación Chavez-Carretero, “Sistemas Operativos” El material proporcionado en el curso es solamente referencia. La información vista en clase también se evalúa.

156 ¿Preguntas, dudas y comentarios?