Procesos M C Juan Carlos Olivares Rojas jolivaresuvaq

Procesos M. C. Juan Carlos Olivares Rojas jolivares@uvaq. edu. mx juancarlosolivares@hotmail. com @jcolivares http: //antares. itmorelia. edu. mx/~jcolivar Enero, 2010

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

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

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

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

Repaso Unidad I • OS Architecture

Ring Level Architecture

Layer Architecture

Client-Server Architecture

Arquitectura de Windows NT • Archivos básicos

Arquitectura de Windows • Ejemplo de procesos

Signals

POSIX System Call

System Call

POSIX

Llamadas al Sistema

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).

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.

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.

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.

Procesos • Estado de los Procesos

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.

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.

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 Create. Process(). • En Linux además de la llamada fork(), se encuentra clone() que clona un proceso de memoria pero puede compartir estructuras de datos.

Procesos en Sistemas *X

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.

Process Execution

Process List

Prioridad de Procesos

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.

Sys. Calls para Procesos

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.

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.

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.

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.

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.

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.

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.

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, 4. . . 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.

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.

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.

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.

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.

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).

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).

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.

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

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.

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

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.

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.

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.

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.

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.

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.

Ejemplos de Sistemas IPC

Ejemplos de Sistemas IPC

Ejemplos de Sistemas IPC

Ejemplos de Sistemas IPC

Ejemplos de Sistemas IPC

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. *

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.

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).

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.

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

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? ,

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 (My. SQL, ORACLE, INFORMIX). – Servidor de Impresión. – Servidor de Terminal. – Servidor de Aplicaciones (Windows NT, Novell).

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.

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).

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

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

Arquitecturas de Sistemas Distribuidos Cliente 1 Solicitud Cliente . Servidor Respuesta Cliente n Modelo Cliente/Servidor Tradicional Cliente . Servidor Proxy en el lado cliente Modelo Cliente/Servidor Concurrente Proxy en el lado servidor Modelo Cliente/Servidor de n capas Cliente

Arquitectura de Sistemas Distribuidos C 0 Coordinador C 2 C 1 … C 1 Cn C 2 P 2 P Cn Cluster Simétrico Grid computing Asimétrico Planificador CPU Memoria Disco C 1 CPU Memoria DISCO C 2 Planificador. . . CPU MEMORIA Disco Cn

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.

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

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.

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 (Su. SE), 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).

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.

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

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.

SOR vs SOD

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 Solicitudes pasadas directamente operativo local a otro vía el NOS de un nodo a otro vía el DO/S

SOR vs SOD Administración de la Memoria

SOR vs SOD Administración de la Memoria

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.

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

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.

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.

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 Ne. XSTEP).

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.

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

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.

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 jcolivar@antares. itmorelia. edu. mx • rsh jcolivar@antares. itmorelia. edu. mx

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.

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.

Sockets • Los sockets son el mecanismo sincronización distribuida más importante. de • 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.

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 (Win. Sock) y a otros lenguajes como Java

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.

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, Net. BEUI, 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.

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.

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).

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.

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.

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

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

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

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.

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

RPC 5. 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.

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).

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.

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.

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*/ } = 0 x 31111111; /*No. de programa*/

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

RPC • • 0000 -1 FFFFFFF Definidos por sun 20000000 -3 FFFFFFF Definidos por el usuario 40000000 -5 FFFFFFF Transitorios 60000000 -FFFF Reservados para usos futuros • rpcinfo -s • portmap

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

RPC • Existen nuevas propuestas para mejorar el desempeño de RPC como RPC 2 que maneja UDP. También se han diseñado mecanismos como Multi. RPC 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.

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.

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.

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).

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.

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.

Multicast Java try { Inet. Address grupo = Inet. Address. get. By. Name(args[1]); Multicast. Socket s = new Multicast. Socket(6789); s. join. Group(grupo); byte [] m = args[0]. get. Bytes(); Datagram. Packet mensaje. Salida = new Datagram. Packet(m, m. length, grupo, 6789); s. send(mensaje. Salida);

Multicast Java byte []buffer = new byte[1000]; for(int i=0; i<3; i++) { Datagram. Packet mensaje. Entrada = new Datagram. Packet(buffer, buffer. length); s. receive(mensaje. Entrada); System. out. println("Recibido: " + new String(mensaje. Entrada. get. Data())); } s. leave. Group(grupo); } catch (Exception e) { //Manejo de excepción}

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.

Tolerancia a fallos • Un Sistema Distribuido en base a coordinación de sus procesos puede ser: la – 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).

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.

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.

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.

Tolerancia a Fallos

Tolerancia a Fallos

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”

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.

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

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.

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).

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.

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.

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.

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.

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.

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

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

¿Preguntas, dudas y comentarios?