Procesos

M.C. Juan Carlos Olivares Rojas

jolivares@uvaq.edu.mxjuancarlosolivares@hotmail.com

@jcolivareshttp://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 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.

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

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

SysCalls 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 subprocesosif (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 (MySQL, 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• P2P (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 Servidor

Solicitud

Respuesta

Modelo Cliente/Servidor Tradicional

Cliente 1

Servidor

Modelo Cliente/Servidor Concurrente

ClienteProxy en el lado cliente

Modelo Cliente/Servidor de n capas

ClienteProxy en el lado

servidor

Cliente n

.

.

Arquitectura de Sistemas Distribuidos

C1

C2

CnP2P

Simétrico

C0Coordinador

C1

C2

Cn…

Cluster

Asimétrico

Planificador

CPUMemoria

DiscoC1

Planificador

CPUMemoriaDISCO

C2

Planificador

CPUMEMORIA

DiscoCn

.

.

.

Grid computing

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

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 operativo local a otro vía el NOS

Solicitudes pasadas directamente 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 NeXSTEP).

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.

Plan9• 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 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.

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

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

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.

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

RPC8. 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 (eXternal 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 servidor3.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*/} = 0x31111111; /*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• 00000000-1FFFFFFF Definidos por sun• 20000000-3FFFFFFF Definidos por el

usuario• 40000000-5FFFFFFF Transitorios• 60000000-FFFFFFFF Reservados para

usos futuros

• rpcinfo -s• portmap

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

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 Javatry {

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

Multicast Javabyte []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}

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

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-13-219908-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, 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.

¿Preguntas, dudas y comentarios?