You are on page 1of 136

Sistemas operativos: una visin aplicada

Captulo 10 Introduccin a los sistemas distribuidos

Contenido
Sistemas distribuidos Sistemas operativos distribuidos Comunicacin de procesos Sincronizacin de procesos Gestin de procesos Sistemas de archivos Gestin de memoria

Sistemas operativos: una visin aplicada

J. Carretero, F. Garca, P. de Miguel, F. Prez

Conceptos previos
Un programa es un conjunto de instrucciones. Un proceso es un programa en ejecucin. Una red de computadores es un conjunto de computadores conectados por una red de interconexin. Un sistema distribuido (SD) Modelo fsico: conjunto de nodos (procesadores sin memoria ni reloj comn) conectados por una red. Modelo lgico: conjunto de procesos que ejecutan concurrentemente en uno o ms computadores que colaboran y comunican intercambiando mensajes. Un protocolo es un conjunto de reglas e instrucciones que gobiernan la comunicacin en un sistema distribuido, es decir, el intercambio de mensajes.
Sistemas operativos: una visin aplicada 2 J. Carretero, F. Garca, P. de Miguel, F. Prez

Caractersticas
Compartir recursos (HW, SW, datos). Acceso a recursos remotos.
Modelo cliente-servidor Modelo basado en objetos

Ofrecen una buena relacin coste/rendimiento Capacidad de crecimiento Tolerancia a fallos, disponibilidad Replicacin Concurrencia Velocidad Paralelismo
Sistemas operativos: una visin aplicada 3 J. Carretero, F. Garca, P. de Miguel, F. Prez

Desventajas
Necesidad de software ms complejo Problemas de fiabilidad Problemas de seguridad y confidencialidad

Sistemas operativos: una visin aplicada

J. Carretero, F. Garca, P. de Miguel, F. Prez

Arquitectura de un sistema distribuido

Red de interconexin

Sistemas operativos: una visin aplicada

J. Carretero, F. Garca, P. de Miguel, F. Prez

Redes e interconexin
Paquete: tipo de mensaje que se intercambia entre dos dispositivos de comunicacin. Tamao limitado por el hardware Mensaje: objeto lgico que se intercambian entre dos o ms procesos. Su tamao puede ser bastante grande. Un mensaje se descompone en paquetes. Subsistema de comunicacin: conjunto de componentes HW y SW que proporcionan servicios de comunicacin en un sistema distribuido. Protocolo: conjunto de reglas e instrucciones que gobiernan el intercambio de paquetes y mensajes
Sistemas operativos: una visin aplicada 6 J. Carretero, F. Garca, P. de Miguel, F. Prez

Propiedades de un subsistema de comunicacin


Tasa de transferencia: velocidad de transferencia Latencia: tiempo necesario para transferir un mensaje vaco Tiempo de transferencia = latencia + tamao/tasa de trasferencia Paquetes/segundo Capacidad de crecimiento. Aumento en el n de nodos Calidad de servicio Importante en aplicaciones multimedia y de tiempo real Fiabilidad del subsistema Mecanismos de deteccin de errores Seguridad: proteccin de los paquetes Confidencialidad: proteger la identidad de los emisores
Sistemas operativos: una visin aplicada 7 J. Carretero, F. Garca, P. de Miguel, F. Prez

Tipos de redes de computadores


Redes de rea local (LAN, Local Area Network) Redes que enlazan sistemas cercanos Posibilidad de difusin de mensajes (broadcast) Redes de rea extensa (WAN, Wide Area Network) Poco ancho de banda (20-500 Kbps) Bajas latencias Redes telefnicas, redes pblicas de datos, fiabra ptica RDSI, B-RDSI, ATM Nuevos desarrollos en telecomunicaciones (ATM y RDSI) Diferencias entre LAN y WAN cada vez ms borrosas

Sistemas operativos: una visin aplicada

J. Carretero, F. Garca, P. de Miguel, F. Prez

Protocolos de comunicacin
Protocolo: conjunto de reglas y formatos que permiten la comunicacin entre procesos. La definicin de un protocolo tiene dos parte: Especificacin de la secuencia de mensajes que deben intercambiarse. Especificacin del formato de mensajes. El software de red se organiza en niveles

Sistemas operativos: una visin aplicada

J. Carretero, F. Garca, P. de Miguel, F. Prez

Funciones de una pila de protocolos


Segmentacin y ensamblado de mensajes Encapsulado: incorporacin de informacin de control a los datos Direccin del emisor y receptor Cdigo de deteccin de errores Control de conexin Protocolos orientados a conexin Protocolos no orientados a conexin:
No se asegura el orden secuencial de los datos transmitidos

Entrega ordenada en protocolos orientados a conexin Nmeros de secuencia


Sistemas operativos: una visin aplicada 10 J. Carretero, F. Garca, P. de Miguel, F. Prez

Funciones de una pila de protocolos II


Control de flujo: funcin realizada en el receptor para limitar la cantidad o tasa de datos que enva el emisor. Control de errores: se basan en el uso de una secuencia de comprobacin y reenvo. Direccionamiento, conseguir que los mensajes alcancen al receptor Multiplexacin: necesario para un uso ms eficiente de los servicios Servicios de transmisin: Prioridad Calidad de servicio Seguridad
Sistemas operativos: una visin aplicada 11 J. Carretero, F. Garca, P. de Miguel, F. Prez

Ejemplos de protocolos
Protocolos internet: Originados por el trabajo de DARPA en los 70 Muy utilizados en la actualidad Gran crecimiento durante los 90 debido al uso del Web Protocolos OSI (open system interconection) Estndar desarrollado por ISO Estndares propietarios SNA de IBM (aos 70) DECnet desarrollado por DEC NetWare: red de Novell para redes de PC

Sistemas operativos: una visin aplicada

12

J. Carretero, F. Garca, P. de Miguel, F. Prez

Protocolos TCP/IP
Resultado de la investigacin y desarrollo llevados a cabo en la red ARPANET (financiada por DARPA) en los aos 70 Familia de protocolos utilizados en Internet En los 90 se ha establecido como la arquitectura comercial dominante: Se especificaron y utilizaron antes de OSI Independiente de la tecnologa de red utilizada Internet est construida sobre un conjunto de protocolos TCP/IP. Espectacular desarrollo de World Wide Web

Sistemas operativos: una visin aplicada

13

J. Carretero, F. Garca, P. de Miguel, F. Prez

Protocolos TCP/IP

Emisor

Receptor

Sistemas operativos: una visin aplicada

14

J. Carretero, F. Garca, P. de Miguel, F. Prez

Protocolo Internet (nivel IP)


La transmisin no es fiable (no se asegura la recepcin de los paquetes IP). Los paquetes se pueden descartar por: Expiracin del tiempo de vida Congestin Error en la suma de comprobacin Control de flujo muy limitado Calidad de servicio muy limitado Seguridad: normal o alto Retardo: normal o bajo Rendimiento: normal o alto

Sistemas operativos: una visin aplicada

15

J. Carretero, F. Garca, P. de Miguel, F. Prez

Protocolos de transporte
Protocolo TCP Orientado a conexin Garantiza que los datos se entregan en el orden en el que se envan Las conexiones TCP se ven como un flujo de bytes La transmisin se considera fiable. Pueden perderse mensajes (sobrecarga en la red, fallos en encaminadores, etc.) Cuando los mensajes son muy pequeos, TCP los retrasa hasta conseguir uno ms grande
Esta opcin debe desactivarse si es necesario

Escrituras concurrentes sobre una misma conexin TCP pueden provocar que los datos se entremezclen.
Sistemas operativos: una visin aplicada 16 J. Carretero, F. Garca, P. de Miguel, F. Prez

Protocolos de transporte
Protocolo UDP Protocolo de datagramas no orientado a conexin. Protocolo no fiable
Los paquetes se pueden perder, duplicar, recibir en orden distinto al enviado

Tamao mximo del mensaje: 64 KB

Sistemas operativos: una visin aplicada

17

J. Carretero, F. Garca, P. de Miguel, F. Prez

Encaminamiento
Permite que los paquetes viajen del proceso emisor al receptor. Algoritmo: Un programa de aplicacin genera un paquete, o bien se lee un paquete de la interfaz de red. Si el paquete es para la mquina, se acepta. En caso contrario, se incrementa el contador de saltos, si se excede el mximo, el paquete se descarta. Si el paquete no es para la mquina se busca en la tabla de encaminamiento y se retransmite a la interfaz adecuada.
Tablas estticas, las ms utilizadas Tablas dinmicas

Sistemas operativos: una visin aplicada

18

J. Carretero, F. Garca, P. de Miguel, F. Prez

Papel del sistema operativo


El SW de comunicacin de un sistema operativo se organiza como un conjunto de componentes con tareas concretas Subsistema de almacenamiento: buffers donde almacenar los paquetes que llegan y se envan (limitado) En implementaciones UNIX tpicas TCP reserva para cada puerto (socket) un buffer de 8 KB y UDP 2 buffers de 8KB. El tamao se puede incrementar hasta 64 KB. Los mensajes a enviar se copian a estos buffers El contenido de estos buffers se fragmenta y se copian a nuevos bloques de memoria a utilizar por IP IP enva finalmente los paquetes por la interfaz de red correspondiente
Sistemas operativos: una visin aplicada 19 J. Carretero, F. Garca, P. de Miguel, F. Prez

Papel del sistema operativo


Un sistema operativo puede perder paquetes cuando la tasa de envos y de recepcin es muy grande. En sistemas operativos multiusuario la prdida de paquetes suele producirse a rfagas debido a los algoritmos de planificacin. La latencia del SO 40 ha crecido en trminos 35 relativos 30
25 20 15 10 5 0 1985-1990 1990-1995 1995-2000 2000-20005

Sistemas operativos: una visin aplicada

20

J. Carretero, F. Garca, P. de Miguel, F. Prez

Dnde se pierde el tiempo?


Cdigos de correccin (Checksum) Sobre datos TCP y UDP Sobre cabeceras IP Copias de datos Entre usuario y kernel Estructura de datos Gestin de los buffers, colas de defragmentacin de paquetes IP, Sistema Operativo Sobrecarga impuesta por las operaciones del SO

Sistemas operativos: una visin aplicada

21

J. Carretero, F. Garca, P. de Miguel, F. Prez

Contenido
Sistemas distribuidos

Sistemas operativos distribuidos


Comunicacin de procesos Sincronizacin de procesos Gestin de procesos Sistemas de archivos Gestin de memoria

Sistemas operativos: una visin aplicada

22

J. Carretero, F. Garca, P. de Miguel, F. Prez

Sistema operativo en red (SOR)


Aplicaciones Lenguajes de programacin Sistema operativo Hardware Red de interconexin Aplicaciones Lenguajes de programacin Sistema operativo Hardware

El usuario ve un conjunto de mquinas independientes No hay transparencia Se debe acceder de forma explcita a los recursos de otras mquinas Difciles de utilizar para desarrollar aplicaciones distribuidas
Sistemas operativos: una visin aplicada 23 J. Carretero, F. Garca, P. de Miguel, F. Prez

Sistema operativo distribuido (SOD)


Aplicaciones Lenguajes de programacin Sistema operativo distribuido Hardware Red de interconexin Hardware

Se comporta como un SO nico (visin nica) Distribucin. Transparencia Se construyen normalmente como microncleos que ofrecen servicios bsicos de comunicacin Mach, Amoeba, Chorus. Todos los computadores deben ejecutar el mismo SOD
Sistemas operativos: una visin aplicada 24 J. Carretero, F. Garca, P. de Miguel, F. Prez

Transparencia
Acceso: acceso a recursos remotos y locales de igual forma Posicin: acceso a los recursos sin necesidad de conocer su situacin Concurrencia: acceso concurrente a recursos compartidos sin interferencias Replicacin: Acceso a recursos replicados sin conocimiento de que lo son Fallos: mantenimiento del servicio en presencia de fallos. Migracin: permite que los recursos y objetos se muevan sin afectar a la operacin de los programas. Capacidad de crecimiento: facilidad para crecer sin afectar a la estructura del sistema
Sistemas operativos: una visin aplicada 25 J. Carretero, F. Garca, P. de Miguel, F. Prez

Middleware y entornos distribuidos


Aplicaciones Lenguajes de programacin Middleware Sistema operativo Hardware Red de interconexin Sistema operativo Hardware

Servicios y protocolos estndarizados: Sistemas abiertos Ofrecen servicios no incluidos en el SO (servicios de ficheros distribuidos, servicios de nombres, ...) Facilitan el desarrollo de aplicaciones distribuidas Independientes del HW y del SO subyacente. DCE, CORBA, DCOM, Legion, Globe, Globus
Sistemas operativos: una visin aplicada 26 J. Carretero, F. Garca, P. de Miguel, F. Prez

Servicios de un sistema operativo distribuido


Servicios de comunicacin Servicios de sincronizacin Gestin distribuida de procesos Sistemas de archivos distribuidos Memoria compartida distribuida

Sistemas operativos: una visin aplicada

27

J. Carretero, F. Garca, P. de Miguel, F. Prez

Contenido
Sistemas distribuidos Sistemas operativos distribuidos

Comunicacin de procesos
Sincronizacin de procesos Gestin de procesos Sistemas de archivos Gestin de memoria

Sistemas operativos: una visin aplicada

28

J. Carretero, F. Garca, P. de Miguel, F. Prez

Comunicacin en sistemas distribuidos


La comunicacin de procesos es fundamental en cualquier sistema distribuido Existen diferentes posibilidades todas ellas basadas en el paso de mensajes Mecanismos de bajo nivel, el programador debe preocuparse de establecer los protocolos de comunicacin, representacin de datos, etc. Mecanismo de alto nivel, ofrecen abstracciones donde el programador no debe preocuparse de establecer protocolos
Colas de mensajes Sockets

Llamadas a procedimientos remotos Invocacin de mtodos remotos (entornos orientados a objetos)


29 J. Carretero, F. Garca, P. de Miguel, F. Prez

Sistemas operativos: una visin aplicada

Comunicacin cliente-sevidor
Muy utilizada en entornos distribuidos (ms del 90% de los sistemas distribuidos utilizan la arquitectura cliente-servidor)
Mquina A cliente NCLEO respuesta petcicin Mquina B servidor NCLEO RED

Protocolo tpico: peticin-respuesta


Sistemas operativos: una visin aplicada 30 J. Carretero, F. Garca, P. de Miguel, F. Prez

Comunicacin de grupos
Utiliza mensajes multicast til para: Ofrecer tolerancia a fallos basado en servicios replicados Localizar objetos en sistemas distribuidos Mejor rendimiento mediante datos replicados Actualizaciones mltiples Operaciones colectivas en clculo paralelo

Sistemas operativos: una visin aplicada

31

J. Carretero, F. Garca, P. de Miguel, F. Prez

Sockets
Aparecieron en 1981 en UNIX BSD 4.2 Intento de incluir TCP/IP en UNIX Diseo independiente del protocolo de comunicacin Un socket es punto final de comunicacin (direccin IP y puerto) Abstraccin que: Ofrece interfaz de acceso a los servicios de red en el nivel de transporte
Protocolo TCP Protocolo UDP

Representa un extremo de una comunicacin bidireccional con una direccin asociada


Sistemas operativos: una visin aplicada 32 J. Carretero, F. Garca, P. de Miguel, F. Prez

Sockets: introduccin
Sujetos a proceso de estandarizacin dentro de POSIX (POSIX 1003.1g) Actualmente Disponibles en casi todos los sistemas UNIX En prcticamente todos los sistemas operativos
WinSock: API de sockets de Windows

En Java como clase nativa

Sistemas operativos: una visin aplicada

33

J. Carretero, F. Garca, P. de Miguel, F. Prez

Sockets UNIX
Dominios de comunicacin Tipos de sockets Direcciones de sockets Creacin de un socket Asignacin de direcciones Solicitud de conexin Preparar para aceptar conexiones Aceptar una conexin Transferencia de datos

Sistemas operativos: una visin aplicada

34

J. Carretero, F. Garca, P. de Miguel, F. Prez

Dominios de comunicacin
Un dominio representa una familia de protocolos Un socket est asociado a un dominio desde su creacin Slo se pueden comunicar sockets del mismo dominio Algunos ejemplos: PF_UNIX (o PF_LOCAL): comunicacin dentro de una mquina PF_INET: comunicacin usando protocolos TCP/IP Los servicios de sockets son independientes del dominio

Sistemas operativos: una visin aplicada

35

J. Carretero, F. Garca, P. de Miguel, F. Prez

Tipos de sockets
Stream (SOCK_STREAM) Orientado a conexin Fiable, se asegura el orden de entrega de mensajes No mantiene separacin entre mensajes Si PF_INET se corresponde con el protocolo TCP Datagrama (SOCK_DGRAM) Sin conexin No fiable, no se asegura el orden en la entrega Mantiene la separacin entre mensajes Si PF_INET se corresponde con el protocolo UDP Raw (SOCK_RAW) Permite el acceso a los protocolos internos como IP
Sistemas operativos: una visin aplicada 36 J. Carretero, F. Garca, P. de Miguel, F. Prez

Direcciones de sockets
Cada socket debe tener asignada una direccin nica Las direcciones se usan para: Asignar una direccin local a un socket (bind) Especificar una direccin remota (connect o sendto) Dependientes del dominio Se utiliza la estructura genrica struct sockaddr Cada dominio usa una estructura especfica Direcciones en PF_UNIX (struct sockaddr_un)
Nombre de fichero

Direcciones en PF_UNIX (struct sockaddr_in) Uso de conversin de tipos (casting) en las llamadas

Sistemas operativos: una visin aplicada

37

J. Carretero, F. Garca, P. de Miguel, F. Prez

Direcciones de sockets en PF_INET


Host (32 bits) + puerto (16 bits) Una direccin IP se almacena en una estructura de tipo: struct in_addr Estructura struct sockaddr_in Debe iniciarse a 0 sin_family: dominio (AF_INET) sin_port: puerto sin_addr: direccin del host Funcin que facilita el nombre de la mquina en la que se ejecuta: int gethostname(char *name, int namelen);
Sistemas operativos: una visin aplicada 38 J. Carretero, F. Garca, P. de Miguel, F. Prez

Obtencin de la direccin de host


Usuarios manejan direcciones en forma de texto: decimal-punto: 138.100.8.100 dominio-punto: laurel.datsi.fi.upm.es Algunas funciones para trabajar con direcciones: char *inet_ntoa(struct in_addr in); Devuelve una direccin en notacin decimal-punto. struct hostent *gethostbyname(char *str);
Convierte una direccin en notacin dominio-punto a una estructura que describe mquina. Algunos campos de la estructura struct hostent:
char *name nombre oficial de la mquina char **h_addr_list lista de direcciones
Sistemas operativos: una visin aplicada 39 J. Carretero, F. Garca, P. de Miguel, F. Prez

Ejemplo
Programa que obtiene la direccin en formato decimal-punto a partir de un formato dominio-punto.
void main(int argc, char **argv) { struct hostent *hp; struct in_addr in; hp = gethostbyname(argv[1]); if (hp == NULL) { printf(Error en gethostbyname\n); exit(0); } memcpy(&in.s_addr,*(hp->h_addr_list),sizeof(in.s_addr)); printf(%s es %s\n, hp->h_name, inet_ntoa(in)); }

Sistemas operativos: una visin aplicada

40

J. Carretero, F. Garca, P. de Miguel, F. Prez

Direcciones de sockets II
En TCP/IP los nmeros se emplean con formato big-endian. En computadores que no utilicen este formato es necesario emplear funciones para traducir nmeros entre el formato que utiliza TCP/IP y el empleado por el propio computador: u_long htonl (u_long hostlong) u_short htons (u_short hostshort) u_long ntohl (u_long netlong) u_short ntohs (u_short netshort) Las primera traduce un nmero de 32 bits representado en el formato del computador al formato de red (TCP/IP).

Sistemas operativos: una visin aplicada

41

J. Carretero, F. Garca, P. de Miguel, F. Prez

Creacin de un socket
int socket(int dominio, int tipo, int protocolo) Crea un socket devolviendo un descriptor de fichero dominio: PF_XXX tipo: SOCK_XXX protocolo: dependiente del dominio y tipo
0 elige el ms adeucado Especificados en /etc/protocols

El socket creado no tiene direccin asignada

Sistemas operativos: una visin aplicada

42

J. Carretero, F. Garca, P. de Miguel, F. Prez

Asignacin de direcciones
int bind(int sd, struct sockaddr *dir, int long) sd: descriptor devuelto por socket dir: direccin a asignar long: longitud de la direccin Si no se asigna direccin (tpico en clientes) Se le asigna automticamente (puerto efmero) en la su primera utilizacin (connect o sendto) Direcciones en dominio PF_INET Puertos en rango 0..65535. Reservados: 0..1023. Si 0, el sistema elige uno Host: una direccin local IP
INNADDR_ANY: elige cualquiera de la mquina

El espacio de puertos para streams y datagramas es indendiente


Sistemas operativos: una visin aplicada 43 J. Carretero, F. Garca, P. de Miguel, F. Prez

Solicitud de conexin
Realizada en el cliente int connect(int sd, struct sockaddr *dir, int long) sd: descriptor devuelto por socket dir: direccin del socket remoto long: longitud de la direccin Si el socket no tiene direccin asignada, se le asigna una automticamente Normalmente se usa con streams

Sistemas operativos: una visin aplicada

44

J. Carretero, F. Garca, P. de Miguel, F. Prez

Preparar para aceptar conexiones


Realizada en el servidor stream despus de socket y bind int listen(int sd, int baklog) sd: descriptor devuelto por socket backlog:
Nmero mximo de peticiones pendientes de aceptar que se encolarn (algunos manuales recomiendan 5)

Hace que el socket quede preparado para aceptar conexiones.

Sistemas operativos: una visin aplicada

45

J. Carretero, F. Garca, P. de Miguel, F. Prez

Aceptar una conexin


Realizada en el servidor stream despus de socket, bind y listen Cuando se produce la conexin, el servidor obtiene: La direccin del socket del cliente Un nuevo descriptor que queda conectado al socket del cliente Despus de la conexin quedan activos dos sockets en el servidor: El original para aceptar nuevas conexiones El nuevo para enviar/recibir datos por la conexin

Sistemas operativos: una visin aplicada

46

J. Carretero, F. Garca, P. de Miguel, F. Prez

Aceptar una conexin


int accept(int sd, struct sockaddr *dir, int *long) sd: descriptor devuelto por socket dir: direccin del socket del cliente devuelta long: parmetor valor-resultado
Antes de la llamada: tamao de dir Despus de la llamada: tamao de la direccin del cliente que se devuelve.

Sistemas operativos: una visin aplicada

47

J. Carretero, F. Garca, P. de Miguel, F. Prez

Obtener la direccin de un socket


Obtener la direccin a partir del descriptor int getsockname(int sd, struct sockaddr *dir, int *long)
sd: descriptor devuelto por socket dir: direccin del socket devuelta long: parmetro valor-resultado (igual que en accept)

Obtener la direccin del socket en el toro extremo de la conexin: int gerpeername(int sd, struct sockaddr *dir, int *long)
sd: descriptor devuelto por socket dir: direccin del socket remoto long: parmetro valor-resultado

Sistemas operativos: una visin aplicada

48

J. Carretero, F. Garca, P. de Miguel, F. Prez

Transferencia de datos con streams


Una vez realizada la conexin, ambos extremos puede transferir datos. Envo: int write(int sd, char *mem, int long);
Devuelve el n de bytes enviados

Tambin puede utilizarse el servicio send. Recepcin: int read(int sd, char *mem, int long);
Devuelve el n de bytes recibidos

Tambin puede utilizarse el servicio recv Es importante comprobar siempre el valor que devuelven estas llamadas: pueden no transferirse todos los datos.
Sistemas operativos: una visin aplicada 49 J. Carretero, F. Garca, P. de Miguel, F. Prez

Transferencia de datos con streams II


Funcin que enva un bloque de datos con reintentos:
int enviar(int socket, char *mensaje, int longitud)
{ int r; int l = longitud; do { r = write(socket, mensaje, l); l = l r; mensaje = mensaje + r; } while ((l>0) && (r>=0)); if (r < 0) return (-1); else return(0); }
Sistemas operativos: una visin aplicada 50 J. Carretero, F. Garca, P. de Miguel, F. Prez

/* fallo */

Transferencia de datos con datagramas


No hay conexin real Para usar un socket para transferir basta con: Crearlo: socket Asignarle una direccin: bind (si no, lo har el sistema) Envo: int sendto(int sd, char *men, int long, int flags, struct sockaddr *dir, int long) Devuelve el n de bytes enviados dir: direccin del socket remoto y long la longitud Rccepcin: int recvfrom(int sd, char *men, int long, int flags, struct sockaddr *dir, int long) Devuelve el n de bytes enviados dir: direccin del socket remoto y long la longitud

Sistemas operativos: una visin aplicada

51

J. Carretero, F. Garca, P. de Miguel, F. Prez

Cerrar un socket
Se usa close para cerrar ambos tipos de sockets Si el socket es de tipo stream, close cierra la conexin en ambos sentidos Se puede cerrar un nico extremo: int shutdown(int st, int modo)
sd: descriptor devuelto por socket modo: SHUT_RD, SHUT_RW o SHUT_RDWR

Sistemas operativos: una visin aplicada

52

J. Carretero, F. Garca, P. de Miguel, F. Prez

Configuracin de opciones
Existen varios niveles dependiendo del protocolo afectado como parmetro SOL_SOCKET: opciones independientes del protocolo IPPROTO_TCP: nivel de protocolo TCP IPPTOTO_IP: nivel de protocolo IP Consultar opciones asociadas a un socket
int getsockopt(int sd, int nivel, int opc, char *val, int *long)

Modificar las opciones asociadas a un socket


int setsockopt(int sd, int nivel, int opc, char *val, int long) Ejemplos (nivel SOL_SOCKET): SO_REUSEADDR: permite reutilizar direcciones

Sistemas operativos: una visin aplicada

53

J. Carretero, F. Garca, P. de Miguel, F. Prez

Escenario tpico con sockets streams


Proceso servidor

socket()

Proceso cliente
bind() listen()

socket()

Abrir conexin
connect()

accept() accept()

Crear thread

write()

Peticin
read()

read()

Respuesta
write()

close()

close()

Sistemas operativos: una visin aplicada

54

J. Carretero, F. Garca, P. de Miguel, F. Prez

Ejemplo (TCP)

Mquina A cliente sumar(5,2)

Mquina B servidor 5+2

NCLEO

Restulado = 7

NCLEO RED

Sistemas operativos: una visin aplicada

55

J. Carretero, F. Garca, P. de Miguel, F. Prez

Servidor (TCP)
void main(int argc, char *argv[]) { struct sockaddr_in server_addr, int sd, sc; int size, val; int size; int num[2], res;

client_addr;

sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); val = 1; setsockopt(sd, SOL_SOCKET, SO_REUSEADDR, (char *) &val, sizeof(int)); bzero((char *)&server_addr, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_addr.s_addr = INADDR_ANY; server_addr.sin_port = 4200; bind(sd, &server_addr, sizeof(server_addr));

Sistemas operativos: una visin aplicada

56

J. Carretero, F. Garca, P. de Miguel, F. Prez

Servidor (TCP)
listen(sd, 5); size = sizeof(client_addr); while (1) { printf("esperando conexion\n"); sc = accept(sd, (struct sockaddr *)&client_addr,&size); read(sc, (char *) num, 2 *sizeof(int)); res = num[0] + num[1]; write(sc, &res, sizeof(int)); close(sc); } close (sd); exit(0); } // se enva el resultado // recibe la peticin

Sistemas operativos: una visin aplicada

57

J. Carretero, F. Garca, P. de Miguel, F. Prez

Cliente (TCP)
void main(void) { int sd; struct sockaddr_in server_addr; struct hostent *hp; int num[2], res; sd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); bzero((char *)&server_addr, sizeof(server_addr)); hp = gethostbyname ("arlo.datsi.fi.upm.es"); memcpy (&(server_addr.sin_addr), hp->h_addr, hp->h_length); server_addr.sin_family = AF_INET; server_addr.sin_port = 4200;

Sistemas operativos: una visin aplicada

58

J. Carretero, F. Garca, P. de Miguel, F. Prez

Cliente (TCP)
// se establece la conexin connect(sd, (struct sockaddr *) &server_addr, sizeof(server_addr)); num[0]=5; num[1]=2; write(sd, (char *) num, 2 *sizeof(int)); read(sd, &res, sizeof(int)); printf("Resultado es %d \n", res); close (sd); exit(0); } // enva la peticin

// recibe la respuesta

Sistemas operativos: una visin aplicada

59

J. Carretero, F. Garca, P. de Miguel, F. Prez

Servidor (datagramas)
void main(void) { int num[2]; int s, res, clilen; struct sockaddr_in server_addr, client_addr; s = socket(AF_INET, SOCK_DGRAM, 0);

bzero((char *)&server_addr, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_addr.s_addr = INADDR_ANY; server_addr.sin_port = 7200; bind(s, (struct sockaddr *)&server_addr, sizeof(server_addr));

Sistemas operativos: una visin aplicada

60

J. Carretero, F. Garca, P. de Miguel, F. Prez

Servidor (datagramas)
clilen = sizeof(client_addr); while (1) { recvfrom(s, (char *) num, 2* sizeof(int), 0, (struct sockaddr *)&client_addr, &clilen); res = num[0] + num[1]; sendto(s, (char *)&res, sizeof(int), 0, (struct sockaddr *)&client_addr, } }

clilen);

Sistemas operativos: una visin aplicada

61

J. Carretero, F. Garca, P. de Miguel, F. Prez

Cliente (datagramas)
void main(int argc, char *argv[]){ struct sockaddr_in server_addr, client_addr; struct hostent *hp; int s, num[2], res; if (argc != 2){ printf("Uso: client <direccion_servidor> \n"); exit(0); } s = socket(AF_INET, SOCK_DGRAM, 0); hp = gethostbyname (argv[1]); bzero((char *)&server_addr, sizeof(server_addr)); server_addr.sin_family = AF_INET; memcpy (&(server_addr.sin_addr), hp->h_addr, hp->h_length); server_addr.sin_port = 7200;

Sistemas operativos: una visin aplicada

62

J. Carretero, F. Garca, P. de Miguel, F. Prez

Cliente (datagramas)
bzero((char *)&client_addr, sizeof(client_addr)); client_addr.sin_family = AF_INET; client_addr.sin_addr.s_addr = INADDR_ANY; client_addr.sin_port = htons(0); bind (s, (struct sockaddr *)&client_addr, sizeof(client_addr)); num[0] = 2; num[1] = 5;

sendto(s, (char *)num, 2 * sizeof(int), 0, (struct sockaddr *) &server_addr, sizeof(server_addr));


recvfrom(s, (char *)&res, sizeof(int), 0, NULL, NULL); printf("2 + 5 = %d\n", res); close(s); }

Sistemas operativos: una visin aplicada

63

J. Carretero, F. Garca, P. de Miguel, F. Prez

Llamadas a procedimientos remotos (RPC)


RPC (remote procedure call): llamadas a procedimiento remoto (Birrel y Nelson 1985) Hbrido entre llamadas a procedimientos y paso de mensajes Las RPC constituyen el ncleo de muchos sistemas distribuidos Llegaron a su culminacin con DCE (Distributed Computing Environment) Han evolucionado hacia orientacin a objetos Invocacin de mtodos remotos (CORBA, RMI)

Sistemas operativos: una visin aplicada

64

J. Carretero, F. Garca, P. de Miguel, F. Prez

Funcionamiento de las RPC


El proceso que realiza la llamada empaqueta los argumentos en un mensaje, se los enva a otro proceso y espera el resultado El proceso que ejecuta el procedimiento extrae los argumentos del mensaje, realiza la llamada de forma local, obtiene el resultado y se lo enva de vuelta al proceso que realiz la llamada Objetivo: acercar la semntica de las llamadas a procedimiento convencional a un entorno distribuido (transparencia).

Sistemas operativos: una visin aplicada

65

J. Carretero, F. Garca, P. de Miguel, F. Prez

Llamadas y mensajes en una RPC


SISTEMA CLIENTE
CDIGO DE LA APLICACIN INICIO FIN LLAMADA LLAMADA = 7 suma(5,2)

SISTEMA SERVIDOR
PROCEDIMIENTOS

1
RESGUARDO CLIENTE

EJECUTA PROCEDIMIENTO REMOTO


RESGUARDO SERVIDOR

PREPARA ENTRADA CONVIERTE SALIDA

CONVIERTE ENTRADA

6
PREPARA SALIDA

Sistemas operativos: una visin aplicada

66

J. Carretero, F. Garca, P. de Miguel, F. Prez

Suplentes (stubs)
Se generan automticamente por el software de RPC En el cliente: Localizan al servidor Empaquetan los parmetros y construyen los mensajes Envan el mensaje al servidor Espera la recepcin del mensaje y devuelven los resultados En el servidor Realizan tareas similares Los suplentes son independientes de la implementacin que se haga del cliente y del servidor. Slo dependen de la interfaz.

Sistemas operativos: una visin aplicada

67

J. Carretero, F. Garca, P. de Miguel, F. Prez

RPC: protocolo bsico


enlaza con el servidor prepara parmetros, enva peticin

cliente

servidor
Se registra con un servicio de nombres

recibe peticin Ejecuta el procedimiento enva peticin

Desempaqueta

la respuesta

Sistemas operativos: una visin aplicada

68

J. Carretero, F. Garca, P. de Miguel, F. Prez

Aspectos de diseo de las RPC


Lenguaje de definicin de interfaces. Generador de suplentes. Transferencia de parmetros Enlace dinmico (binding) Semntica de las RPC en presencia de fallos

Sistemas operativos: una visin aplicada

69

J. Carretero, F. Garca, P. de Miguel, F. Prez

Lenguaje de definicin de interfaces


Una interfaz especifica un nombre de servicio que utilizan los clientes y servidores Nombres de procedimientos y parmetros (entrada y salida). Los compiladores pueden disearse para que los clientes y servidores se escriban en lenguajes diferentes. Tipos de RPC Integrado con un lenguaje de programacin (Cedar, Argus) Lenguaje de definicin de interfaces especfico para describir las interfaces entre los clientes y los servidores (RPC de Sun y RPC de DCE)

Sistemas operativos: una visin aplicada

70

J. Carretero, F. Garca, P. de Miguel, F. Prez

Transferencia de parmetros
Una de las funciones de los resguardos es empaquetar los parmetros en un mensaje: aplanamiento (marshalling) Problemas en la representacin de los datos Servidor y cliente pueden ejecutar en mquinas con arquitecturas distintas Transmisin con un formato estndar:
XDR (external data representation) es un estndar que define la representacin de tipos de datos

El receptor se encarga de la conversin (CORBA). Problemas con los punteros Una direccin slo tiene sentido en un espacio de direcciones

Sistemas operativos: una visin aplicada

71

J. Carretero, F. Garca, P. de Miguel, F. Prez

Aplanamiento
SISTEMA CLIENTE
CDIGO DE LA APLICACIN
Procedimiento(ABC, 123, 12.34)

SISTEMA SERVIDOR
PROCEDIMIENTOS
Procedimiento(ABC, 123, 12.34)

aplanamiento

RESGUARDO CLIENTE
mensaje C 123 12.34

RESGUARDO SERVIDOR
A B C 123 12.34

Tira de bytes

Extrae los parmetros

Sistemas operativos: una visin aplicada

72

J. Carretero, F. Garca, P. de Miguel, F. Prez

Enlace dinmico (Binding)


Enlace dinmico: permite localizar objetos con nombre en un sistema distribuido, en concreto, servidores que ejecutan las RPC. Tipos de enlace: Enlace no persistente: la conexin entre el cliente y el servidor se establece en cada RPC. Enlace persistente: la conexin se mantiene despus de la primera RPC.
til en aplicaciones con muchas RPC repetidas Problemas si lo servidores cambian de lugar

Sistemas operativos: una visin aplicada

73

J. Carretero, F. Garca, P. de Miguel, F. Prez

Enlazador dinmico
Enlazador dinmico (binder): Es el servicio que mantiene una tabla de traducciones entre nombres de servicio y direcciones. Incluye funciones para: Registrar un nombre de servicio Eliminar un nombre de servicio Buscar la direccin correspondiente a un nombre de servicio Como localizar al enlazador dinmico: Ejecuta en una direccin fija de un computador fijo. El sistema operativo se encarga de indicar su direccin Difundiendo un mensaje (broadcast) cuando los procesos comienzan su ejecucin.

Sistemas operativos: una visin aplicada

74

J. Carretero, F. Garca, P. de Miguel, F. Prez

Establecimiento de la comunicacin en una RPC


Mquina A
Servidor de nombres 5. Dar de baja procedimiento 3. Direccin del servidor 2. Buscar servidor 1. Registrar procedimiento

Mquina B
servidor

Mquina C
servidor

4. Ejecutar procedimiento

Sistemas operativos: una visin aplicada

75

J. Carretero, F. Garca, P. de Miguel, F. Prez

Semntica de las RPC en presencia de fallos


Problemas que pueden plantear las RPC El cliente no es capaz de localizar al servidor Se pierde el mensaje de peticin del cliente al servidor Se pierde el mensaje de respuesta del servidor al cliente El servidor falla despus de recibir una peticin El cliente falla despus de enviar una peticin

Sistemas operativos: una visin aplicada

76

J. Carretero, F. Garca, P. de Miguel, F. Prez

Cliente no puede localizar al servidor


El servidor puede estar cado El cliente puede estar usando una versin antigua del servidor La versin ayuda a detectar accesos a copias obsoletas Cmo indicar el error al cliente Devolviendo un cdigo de error (-1)
No es transparente
Ejemplo: sumar(a,b)

Elevando una excepcin


Necesita un lenguaje que tenga excepciones

Sistemas operativos: una visin aplicada

77

J. Carretero, F. Garca, P. de Miguel, F. Prez

Prdida de mensajes del cliente


Es la ms fcil de tratar Se activa una alarma (timeout) despus de enviar el mensaje Si no se recibe una respuesta se retransmite

Sistemas operativos: una visin aplicada

78

J. Carretero, F. Garca, P. de Miguel, F. Prez

Prdidas en los mensajes de respuesta


Ms difcil de tratar Se pueden emplear alarmas y retransmisiones, pero: Se perdi la peticin? Se perdi la respuesta? El servidor va lento? Algunas operaciones pueden repetirse sin problemas (operaciones idempotentes) Una transferencia bancaria no es idempotente Solucin con operaciones no idempotentes es descartar peticiones ya ejecutadas Un n de secuencia en el cliente Un campo en el mensaje que indique si es una peticin original o una retransmisin
Sistemas operativos: una visin aplicada 79 J. Carretero, F. Garca, P. de Miguel, F. Prez

Fallos en los servidores


El servidor no ha llegado a ejecutar la operacin Se podra retransmitir El servidor ha llegado a ejecutar la operacin El cliente no puede distinguir los dos
Qu hacer?

No garantizar nada Semntica al menos una vez Semntica a lo ms una vez


Sera lo deseable

Reintentar y garantizar que la RPC se realiza al menos una vez No vale para operaciones no idempotentes No reintentar, puede que no se realice ni una sola vez

Semntica de exactamente una

Sistemas operativos: una visin aplicada

80

J. Carretero, F. Garca, P. de Miguel, F. Prez

Fallos en los clientes


La computacin est activa pero ningn cliente espera los resultados (computacin hurfana) Gasto de ciclos de CPU Si cliente rearranca y ejecuta de nuevo la RPC se pueden crear confusiones

Sistemas operativos: una visin aplicada

81

J. Carretero, F. Garca, P. de Miguel, F. Prez

Aspectos de implementacin
Protocolos RPC Orientados a conexin
Fiabilidad se resuelve a bajo nivel, peor rendimiento

No orientados a conexin Uso de un protocolo estndar o un especfico


Algunos utilizan TCP o UDP como protocolos bsicos

Sistemas operativos: una visin aplicada

82

J. Carretero, F. Garca, P. de Miguel, F. Prez

Programacin con un paquete de RPC


El programador debe proporcionar: La definicin de la interfaz (idl)
Nombres de las funciones Parmetros que el cliente pasa al servidor Resultados que devuelve el servidor al cliente

El cdigo del cliente El cdigo del servidor El compilador de idl proporciona: El resguardo del cliente El resguardo del servidor

Sistemas operativos: una visin aplicada

83

J. Carretero, F. Garca, P. de Miguel, F. Prez

Programacin con RPC


DESARROLLO DE LA INTERFAZ
FICHERO DE DEFINICIN DE INTERFAZ

COMPILADOR IDL
SUPLENTE EN CLIENTE CABECERA SUPLENTE EN SERVIDOR

COMPILADOR C

FICHEROS FUENTE DEL CLIENTE COMPILADOR C

CABECERA

CABECERA

FICHEROS FUENTE DEL SERVIDOR COMPILADOR C FICHEROS OBJETO DEL SERVIDOR MONTADOR EJECUTABLE DEL SERVIDOR

COMPILADOR C

OBJETO SUPLENTE EN CLIENTE

FICHEROS OBJETO DEL CLIENTE MONTADOR

BIBLIOT. RPC

BIBLIOT. RPC

OBJETO SUPLENTE EN SERVIDOR

DESARROLLO DEL CLIENTE


Sistemas operativos: una visin aplicada

EJECUTABLE DEL CLIENTE

DESARROLLO DEL SERVIDOR

84

J. Carretero, F. Garca, P. de Miguel, F. Prez

Ejemplos de paquetes de RPC


RPC de Sun (1990) utilizado en NFS RPC del proyecto ANSA (1989) desarrollado por Architecture Project Management Ltd. (Cambridge, Inglaterra) RPC de DCE (1990), estndar desarrollado por Open Software Foundation

Sistemas operativos: una visin aplicada

85

J. Carretero, F. Garca, P. de Miguel, F. Prez

RPC de Sun
Utiliza como lenguaje de definicin de interfaz XDR: Una interfaz contiene un n de programa y un n de versin. Cada procedimiento especfica un nombre y un n de procedimiento Los procedimientos slo aceptan un parmetro. Los parmetros de salida se devuelven mediante un nico resultado El lenguaje ofrece una notacin para definir:
constantes definicin de tipos estructuras, uniones programas
86 J. Carretero, F. Garca, P. de Miguel, F. Prez

Sistemas operativos: una visin aplicada

RPC de Sun
rpcgen es el compilador de interfaces que genera: Suplente del cliente Suplente del servidor y procedimiento principal del servidor. Procedimientos para el aplanamiento (marshalling) Fichero de cabecera (.h) con los tipos y declaracin de prototipos. Enlace dinmico El cliente debe especificar el host donde ejecuta el servidor El servidor se registra (n de programa, n de versin y n de puerto) en el portmapper local El cliente enva una peticin al portmapper del host donde ejecuta el servidor
Sistemas operativos: una visin aplicada 87 J. Carretero, F. Garca, P. de Miguel, F. Prez

Ejemplo

Mquina A cliente sumar(5,2)

Mquina B servidor 5+2

NCLEO

Restulado = 7

NCLEO RED

Sistemas operativos: una visin aplicada

88

J. Carretero, F. Garca, P. de Miguel, F. Prez

Esquema de la aplicacin
cliente.c Archivos para el cliente suma_clnt.c

repcgen suma.x

suma_xdr.c Archivos comunes suma.h

suma_svc.c Archivos para el servidor servidor.c


Sistemas operativos: una visin aplicada 89 J. Carretero, F. Garca, P. de Miguel, F. Prez

suma.x
struct peticion { int a; int b; };

program SUMAR { version SUMAVER { int SUMA(peticion) = 1; } = 1; } = 99;

Sistemas operativos: una visin aplicada

90

J. Carretero, F. Garca, P. de Miguel, F. Prez

suma.h
#ifndef _SUMA_H_RPCGEN #define _SUMA_H_RPCGEN #include <rpc/rpc.h> struct peticion { int a; int b; }; #define #define extern extern SUMAVER ((u_long)99) SUMA ((u_long)1) int * suma_1(peticion *, CLIENT *); int * suma_1_svc(peticion *, struct svc_req *);

#endif /* !_SUMA_H_RPCGEN */

Sistemas operativos: una visin aplicada

91

J. Carretero, F. Garca, P. de Miguel, F. Prez

servidor.c
#include "suma.h"

int *suma_1_svc(peticion *argp, struct svc_req *rqstp) { static int result;


result = argp->a + argp->b; return(&result); }

Sistemas operativos: una visin aplicada

92

J. Carretero, F. Garca, P. de Miguel, F. Prez

cliente.c
#include "suma.h" main( int argc, char* argv[] ) { CLIENT *clnt; int *res; peticion suma_1_arg; char *host; if(argc < 2) { printf("usage: %s server_host\n", argv[0]); exit(1); } host = argv[1];

Sistemas operativos: una visin aplicada

93

J. Carretero, F. Garca, P. de Miguel, F. Prez

cliente.c II
/* localiza al servidor */ clnt = clnt_create(host, SUMAR, SUMAVER, "udp"); if (clnt == NULL) { clnt_pcreateerror(host); exit(1); } suma_1_arg.a = 5; suma_1_arg.b = 2; res = suma_1(&suma_1_arg, clnt); if (res == NULL) { clnt_perror(clnt, "call failed:"); } printf("La suma es %d\n", *res); clnt_destroy( clnt ); }

Sistemas operativos: una visin aplicada

94

J. Carretero, F. Garca, P. de Miguel, F. Prez

Contenido
Sistemas distribuidos Sistemas operativos distribuidos Comunicacin de procesos

Sincronizacin de procesos
Gestin de procesos Sistemas de archivos Gestin de memoria

Sistemas operativos: una visin aplicada

95

J. Carretero, F. Garca, P. de Miguel, F. Prez

Relojes lgicos
En ausencia de un reloj global la relacin causa-efecto (precede a) es la nica posibilidad de ordenar eventos Relacin de precedencia (Lamport) Si a y b son dos eventos del mismo proceso y a ocurri antes que b, entonces a Y b Si a=send(m) y b=receive(m), entonces a Y b La relacin es transitiva Dos eventos son concurrentes (a || b) si no se puede deducir entre ellos una relacin de causalidad potencial

Sistemas operativos: una visin aplicada

96

J. Carretero, F. Garca, P. de Miguel, F. Prez

Relojes lgicos (algoritmo de Lamport)


tiles para ordenar eventos en ausencia de un reloj comn. Algoritmo de Lamport (1978) Cada proceso P mantiene una variable entera RLp (reloj lgico) Cuando un proceso P genera un evento, RLp=RLp+1 Cuando un proceso enva un mensaje m a otro le aade el valor de su reloj Cuando un proceso Q recibe un mensaje m con un valor de tiempo t, el proceso actualiza su reloj, RLq=max(RLq,t) El algoritmo asegura que si a Y b entonces RL(a) < RL(b)

Sistemas operativos: una visin aplicada

97

J. Carretero, F. Garca, P. de Miguel, F. Prez

Mantenimiento de los relojes lgicos

Sistemas operativos: una visin aplicada

98

J. Carretero, F. Garca, P. de Miguel, F. Prez

Relojes lgicos totalmente ordenados


Los relojes lgicos de Lamport imponen slo una relacin de orden parcial: Eventos de distintos procesos pueden tener asociado una misma marca de tiempo. Se puede extender la relacin de orden para conseguir una relacin de orden total aadiendo el n de proceso (Ta, Pa): marca de tiempo del evento a del proceso P (Ta, Pa) < (Tb, Pb) s y solo si Ta < Tb o Ta=Tb y Pa<Pb

Sistemas operativos: una visin aplicada

99

J. Carretero, F. Garca, P. de Miguel, F. Prez

Problemas de los relojes lgicos


No bastan para caracterizar la causalidad Dados RL(a) y RL(b) no podemos saber:
si a precede a b si b precede a a si a y b son concurrentes

Se necesita una relacin (F(e), <) tal que: a Y b si y slo si F(a) < F(b) Los relojes vectoriales permiten representar de forma precisa la relacin de causalidad potencial

Sistemas operativos: una visin aplicada

100

J. Carretero, F. Garca, P. de Miguel, F. Prez

Relojes vectoriales
Desarrollado independientemente por Fidge, Mattern y Schmuck Todo proceso lleva asociado un vector de enteros RV RVi[a] es el valor del reloj vectorial del proceso i cuando ejecuta el evento a. Mantenimiento de los relojes vectoriales Inicialmente RVi= 0 Cuando un proceso i genera un evento Todos los mensajes llevan el RV del envo Cuando un proceso j recibe un mensaje con RV
RVj = max(RVj , RV ) (componente a componente) RVj[j ] = RVj[j ] +1 (evento de recepcin)
Sistemas operativos: una visin aplicada 101 J. Carretero, F. Garca, P. de Miguel, F. Prez

RVi[i ] = RVi[i ] +1

Relojes vectoriales
(1,0,0) (2,1,0) (3,1,2) (4,1,2) (5,1,2)

P0

P1
(0,1,0)

(1,2,3) (4,3,3)

P2
(1,0,1) (1,0,2) (1,0,3) (1,0,4) (5,1,5)

Sistemas operativos: una visin aplicada

102

J. Carretero, F. Garca, P. de Miguel, F. Prez

Propiedades de los relojes vectoriales


RV < RV si y solo si RV RV y RV[i ] RV[i ], i Dados dos eventos a y b a precede a b si y solo si RV(a) < RV(b) Si a es un evento del proceso i y b es un evento del proceso j (con i j) a precede a b si y solo si RV(a)[i ] RV(b)[i ]
RV(a)[i ] = RV(b)[i ] cuando a es el evento de envo a j y b es el evento de recepcin.

a y b son concurrentes si y solo si


RV(a)[i ] > RV(b)[i ]
Sistemas operativos: una visin aplicada

y RV(b )[j ] > RV(b)[j ]


103 J. Carretero, F. Garca, P. de Miguel, F. Prez

Exclusin mutua distribuida


Los procesos ejecutan el siguiente fragmento de cdigo entrada() SECCIN CRTICA salida() Requisitos para resolver el problema de la seccin crtica Exclusin mutua Progreso Espera acotada Algoritmos Algoritmo centralizado Algoritmo distribuido Anillo con testigo
Sistemas operativos: una visin aplicada 104 J. Carretero, F. Garca, P. de Miguel, F. Prez

Algoritmo centralizado
Existe un proceso coordinador

0
entrada

1
OK

1
entrada

1
salida

2
OK

No hay respuespuesta (bloquea al cliente)

Sistemas operativos: una visin aplicada

105

J. Carretero, F. Garca, P. de Miguel, F. Prez

Anillo con testigo


Los procesos se ordenan conceptualmente como un anillo. Por el anillo circula un testigo. Cuando un proceso quiere entrar en la SC debe esperar a recoger el testigo Cuando sale de la SC enva el testigo al nuevo proceso del anillo
testigo

1 2

5 4
Sistemas operativos: una visin aplicada 106

J. Carretero, F. Garca, P. de Miguel, F. Prez

Algoritmo distribuido
Algoritmo de Ricart y Agrawala requiere la existencia un orden total de todos los mensajes en el sistema Un proceso que quiere entrar en una seccin crtica (SC) enva un mensaje a todos los procesos (y a l mismo) Cuando un proceso recibe un mensaje Si el receptor no est en la SC ni quiere entrar enva OK al emisor Si el receptor ya est en la SC no responde Si el receptor desea entrar, compara la marca de tiempo del mensaje. Si el mensaje tiene una marca menor enva OK. En caso contrario entra y no enva nada. Cuando un proceso recibe todos los mensajes puede entrar
Sistemas operativos: una visin aplicada 107 J. Carretero, F. Garca, P. de Miguel, F. Prez

Contenido
Sistemas distribuidos Sistemas operativos distribuidos Comunicacin de procesos Sincronizacin de procesos

Gestin de procesos
Sistemas de archivos Gestin de memoria

Sistemas operativos: una visin aplicada

108

J. Carretero, F. Garca, P. de Miguel, F. Prez

Modelos de sistema
Conjunto de estaciones de trabajo El sistema consta de estaciones de trabajo a las que tienen acceso los usuarios. Pool de procesadores Los usuarios con terminales. Los procesos se envan a procesadores de un pool. Modelo hbridos Trabajos interactivos en las estaciones de trabajo. Trabajos no interactivos en en el pool de procesadores.

Sistemas operativos: una visin aplicada

109

J. Carretero, F. Garca, P. de Miguel, F. Prez

Asignacin de procesadores
Objetivo: decidir en qu procesador se debera ejecutar un proceso para equilibrar la carga y optimizar el rendimiento. Evitar que un nodo est inactivo mientras hay procesos esperando a ejecutar. Suposiciones: Todos los procesadores son compatible en el cdigo. La velocidad de los procesadores puede ser distinta. Conectividad total: cualquier procesador puede comunicarse con cualquier otro.

Sistemas operativos: una visin aplicada

110

J. Carretero, F. Garca, P. de Miguel, F. Prez

Estaciones de trabajo inactivas


En entornos tpicos con estaciones de trabajo se desperdicia cerca del 80% de ciclos totales de CPU. Uso de estaciones de trabajo inactivas: Ejecutar procesos de forma totalmente transparente en mquinas remotas que se encuentran inactivas . Los usuarios de las estaciones de trabajo inactivas no deberan observar una degradacin del rendimiento como consecuencia de la ejecucin de procesos remotos.

Sistemas operativos: una visin aplicada

111

J. Carretero, F. Garca, P. de Miguel, F. Prez

Empleo de estaciones de trabajo inactivas


Qu es una estacin de trabajo inactiva? Una que lleva varios minutos sin recibir entrada del teclado o ratn y que no est ejecutando procesos interactivos. Cmo localizar estaciones inactivas? Dirigidas por el servidor: la estacin inactiva anuncia su disponibilidad. Dirigida por el cliente: un cliente enva un mensaje al resto para localizar una estacin inactiva.

Sistemas operativos: una visin aplicada

112

J. Carretero, F. Garca, P. de Miguel, F. Prez

Estrategias para localizar una estacin inactiva


Tengo poca carga. Podis mandarme procesos

Tengo mucha carga. Busco estacin inactiva

Nodo

Nodo

(a)

(b)

Sistemas operativos: una visin aplicada

113

J. Carretero, F. Garca, P. de Miguel, F. Prez

Algoritmos de distribucin de la carga


Poltica de transferencia: determina cuando transferir. Poltica de seleccin: selecciona el proceso a transferir. Poltica de ubicacin: selecciona el nodo al que transferir. Poltica de informacin: decide cundo, desde dnde y qu informacin sobre otros nodos recoger.

Sistemas operativos: una visin aplicada

114

J. Carretero, F. Garca, P. de Miguel, F. Prez

Planificacin de procesos en sistemas distribuidos


Definicin del problema: Dado un conjunto de tareas con ciertas restricciones de precedencia y requisitos de clculo y comunicacin, Dado un conjunto de procesadores conectados por una red de interconexin, Encontrar la asignacin de tareas a procesadores y el orden de ejecucin con el objetivo de minimizar el tiempo de ejecucin total.

Sistemas operativos: una visin aplicada

115

J. Carretero, F. Garca, P. de Miguel, F. Prez

Planificacin de procesos

Sistemas operativos: una visin aplicada

116

J. Carretero, F. Garca, P. de Miguel, F. Prez

Complejidad del problema


El problema en su forma general es NP-completo Algoritmos con complejidad polinomial: Cuando slo hay dos procesadores. En el caso general se utilizan heursticas. Los planificadores se eligen por 2 mtricas: El rendimiento del plan generado. La eficacia del planificador: tiempo tomado por el planificador para generar un plan.

Sistemas operativos: una visin aplicada

117

J. Carretero, F. Garca, P. de Miguel, F. Prez

Contenido
Sistemas distribuidos Sistemas operativos distribuidos Comunicacin de procesos Sincronizacin de procesos Gestin de procesos

Sistemas de archivos
Gestin de memoria

Sistemas operativos: una visin aplicada

118

J. Carretero, F. Garca, P. de Miguel, F. Prez

Sistema de archivos distribuido


Objetivo principal: compartir datos entre usuarios ofreciendo transparencia Objetivos secundarios: rendimiento (debera ser comparable al de un sistema tradicional) tolerancia a fallos disponibilidad

Sistemas operativos: una visin aplicada

119

J. Carretero, F. Garca, P. de Miguel, F. Prez

Arquitectura
Cliente

......................

Cliente

RED DE INTERCONEXIN

Servidor

......................
CTR CTR

Servidor

CTR

........

........

CTR

.....
Sistemas operativos: una visin aplicada

.....
120

.....

.....

J. Carretero, F. Garca, P. de Miguel, F. Prez

Componentes
Servicio de directorio: Gestin de los nombres de los archivos Objetivo: ofrecer un espacio de nombres nico Servicio de archivos: Proporciona acceso a los datos de los archivos

Sistemas operativos: una visin aplicada

121

J. Carretero, F. Garca, P. de Miguel, F. Prez

Mtodos de accesos remotos


Modelo carga/descarga Transferencias completas del fichero Localmente se almacenan en memoria o discos locales Normalmente utilizan semntica de sesin Eficiencia en las transferencias Llamada open con mucha latencia Mltiples copias de un fichero Modelo de servicios remotos El servidor debe proporcionar todas las operaciones sobre el fichero. Acceso por bloques Modelo cliente/servidor Empleo de cache en el cliente Combina los dos modelos anteriores.

Sistemas operativos: una visin aplicada

122

J. Carretero, F. Garca, P. de Miguel, F. Prez

Tipos de servidores
Servidores con estado Cuando se abre un fichero, el servidor almacena informacin y da al cliente un identificador nico a utilizar en las posteriores llamadas Cuando se cierra un fichero se libera la informacin Servidores sin estado Cada peticin es autocontenida (fichero y posicin)

Sistemas operativos: una visin aplicada

123

J. Carretero, F. Garca, P. de Miguel, F. Prez

Tipos de servidores II
Ventajas de los servidores con estado Mensajes de peticin ms cortos Mejor rendimiento (se mantiene informacin en memoria) Facilita la lectura adelantada. El servidor puede analizar el patrn de accesos que realiza cada cliente Es necesario en invalidaciones iniciadas por el servidor Ventajas de los servidores sin estado Ms tolerante a fallos No son necesarios open y close. Se reduce el n de mensajes No se gasta memoria en el servidor para almacenar el estado

Sistemas operativos: una visin aplicada

124

J. Carretero, F. Garca, P. de Miguel, F. Prez

Cache de bloques
El empleo de cache de bloques permite mejorar el rendimiento Explota el principio de proximidad de referencias
Proximidad temporal Proximidad espacial

Lecturas adelantadas
Mejora el rendimiento de las operaciones de lectura, sobre todo si son secuenciales

Escrituras diferidas
Mejora el rendimiento de las escrituras Otros tipos de cache

Cache de nombres Cache de metadatos del sistema de ficheros


Sistemas operativos: una visin aplicada 125 J. Carretero, F. Garca, P. de Miguel, F. Prez

Localizacin de las cache en un SFD


Cache en los servidores Reducen los accesos a disco Cache en los clientes Reducen el trfico por la red Reducen la carga en los servidores Mejora la capacidad de crecimiento Dos posibles localizaciones
En discos locales
Ms capacidad, Ms lento No voltil, facilita la recuperacin

En memoria principal
Menor capacidad Ms rpido Memoria voltil

Sistemas operativos: una visin aplicada

126

J. Carretero, F. Garca, P. de Miguel, F. Prez

Tamao de la unidad de cache


Mayor tamao puede incrementar la tasa de aciertos y mejorar la utilizacin de la red pero Aumentan los problemas de coherencia Depende de las caractersticas de las aplicaciones En memoria cache grandes Es beneficioso emplear bloques grandes (8 KB y ms) En memorias pequeas El uso de bloques grandes es menos adecuado

Sistemas operativos: una visin aplicada

127

J. Carretero, F. Garca, P. de Miguel, F. Prez

Polticas de actualizacin
Escritura inmediata (write-through) Buena fiabilidad En escrituras se obtiene el mismo rendimiento que en el modelo de accesos remotos Las escrituras son ms lentas Escritura diferida (write-back) Escrituras ms rpidas. Se reduce el trfico en la red Los datos pueden borrarse antes de ser enviados al servidor Alternativas
Volcado (flush) peridico (Sprite) Write-on-close

Sistemas operativos: una visin aplicada

128

J. Carretero, F. Garca, P. de Miguel, F. Prez

Problema de la coherencia de cache


El uso de cache en los clientes de un sistema de ficheros introduce el problema de la coherencia de cache: Mltiples copias. El problema surge cuando se coutiliza un fichero en escritura: Coutilizacin en escritura secuencial
Tpico en entornos y aplicaciones distribuidas.

Coutilizacin en escritura concurrente


Tpico en aplicaciones paralelas.

Sistemas operativos: una visin aplicada

129

J. Carretero, F. Garca, P. de Miguel, F. Prez

Soluciones al problema de la coherencia


No emplear cache en los clientes. Solucin trivial que no permite explotar las ventajas del uso de cache en los clientes (reutilizacin, lectura adelantada y escritura diferida) No utilizar cache en los clientes para datos compartidos en escritura (Sprite). Accesos remotos sobre una nica copia asegura semntica UNIX Mecanismos de cache sin replicacin de datos Basado en esquemas cooperativos que definen un nico espacio global formado por la unin de todas las cache del sistema. Los datos fluyen a travs de las caches sin replicacin Empleo de protocolos de coherencia de cache

Sistemas operativos: una visin aplicada

130

J. Carretero, F. Garca, P. de Miguel, F. Prez

Contenido
Sistemas distribuidos Sistemas operativos distribuidos Comunicacin de procesos Sincronizacin de procesos Gestin de procesos Sistemas de archivos

Gestin de memoria

Sistemas operativos: una visin aplicada

131

J. Carretero, F. Garca, P. de Miguel, F. Prez

Uso de paginadores externos

Nodo A

Nodo B
Paginador externo Transferir pgina

Espacio de direcciones del proceso

Fallos de pgina Mensajes

Ncleo

Ncleo

Sistemas operativos: una visin aplicada

132

J. Carretero, F. Garca, P. de Miguel, F. Prez

Memoria compartida distribuida


Nodo A proceso Nodo B proceso Nodo C proceso

Memoria compartida distribuida Memoria fsica Memoria fsica Memoria fsica Red de interconexin

Sistemas operativos: una visin aplicada

133

J. Carretero, F. Garca, P. de Miguel, F. Prez

Caractersticas
Se construye utilizando paso de mensajes. Modelo de programacin ms sencillo, no es necesario el paso de mensajes. Sincronizacin utilizando construcciones tradicionales (semforos, mutex, ...). Rendimiento? Los accesos a memoria no son siempre locales Modelos: Basado en hardware (arquitectura NUMA). Basado en pginas. Basado en objetos
Sistemas operativos: una visin aplicada 134 J. Carretero, F. Garca, P. de Miguel, F. Prez

Implementacin
Replicacin y caching (igual que los sistemas de ficheros) Las escrituras se realizan localmente Aparece un problema en el acceso a variables compartidas (en escritura). Problema idntico a la coherencia de cache

Sistemas operativos: una visin aplicada

135

J. Carretero, F. Garca, P. de Miguel, F. Prez