Sie sind auf Seite 1von 136

Sistemas operativos: una visin aplicada

Captulo 10
Introduccin a los sistemas distribuidos
Sistemas operativos: una visin aplicada 1 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 2 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 3 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 4 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 5 J. Carretero, F. Garca, P. de Miguel, F. Prez
Arquitectura de un sistema distribuido
Red de interconexin
Sistemas operativos: una visin aplicada 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 J. Carretero, F. Garca, P. de Miguel, F. Prez
Protocolos TCP/IP
Emisor
Receptor
Sistemas operativos: una visin aplicada 15 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 16 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 17 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 18 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 19 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 20 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
ha crecido en trminos
relativos


0
5
10
15
20
25
30
35
40
1985-1990 1990-1995 1995-2000 2000-20005
Sistemas operativos: una visin aplicada 21 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 22 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 23 J. Carretero, F. Garca, P. de Miguel, F. Prez
Sistema operativo en red (SOR)
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

Sistema operativo
Lenguajes de programacin
Aplicaciones
Red de interconexin
Hardware
Sistema operativo
Lenguajes de programacin
Aplicaciones
Hardware
Sistemas operativos: una visin aplicada 24 J. Carretero, F. Garca, P. de Miguel, F. Prez
Sistema operativo distribuido (SOD)
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

Sistema operativo distribuido
Lenguajes de programacin
Aplicaciones
Red de interconexin
Hardware Hardware
Sistemas operativos: una visin aplicada 25 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 26 J. Carretero, F. Garca, P. de Miguel, F. Prez
Middleware y entornos distribuidos
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

Sistema operativo
Middleware
Lenguajes de programacin
Aplicaciones
Red de interconexin
Hardware
Sistema operativo
Hardware
Sistemas operativos: una visin aplicada 27 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 28 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 29 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.
Colas de mensajes
Sockets
Mecanismo de alto nivel, ofrecen abstracciones donde el
programador no debe preocuparse de establecer protocolos
Llamadas a procedimientos remotos
Invocacin de mtodos remotos (entornos orientados a objetos)

Sistemas operativos: una visin aplicada 30 J. Carretero, F. Garca, P. de Miguel, F. Prez
Comunicacin cliente-sevidor
Protocolo tpico: peticin-respuesta
Muy utilizada en entornos distribuidos (ms del 90% de los
sistemas distribuidos utilizan la arquitectura cliente-servidor)
NCLEO
cliente
petcicin
respuesta
servidor
Mquina A Mquina B
NCLEO
RED
Sistemas operativos: una visin aplicada 31 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 32 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 33 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 34 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 35 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 36 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 37 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 38 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 39 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 40 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 41 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 42 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 43 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 44 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 45 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 46 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 47 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 48 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 49 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 50 J. Carretero, F. Garca, P. de Miguel, F. Prez
Transferencia de datos con streams I I
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); /* fallo */
else
return(0);
}

Sistemas operativos: una visin aplicada 51 J. Carretero, F. Garca, P. de Miguel, F. Prez
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 52 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 53 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 54 J. Carretero, F. Garca, P. de Miguel, F. Prez
Escenario tpico con sockets streams
Proceso cliente
Proceso servidor
socket()
socket()
bind()
listen()
accept()
Crear
thread
read()
close()
accept()
connect()
Abrir conexin
read()
close()
Peticin
write()
Respuesta
write()
Sistemas operativos: una visin aplicada 55 J. Carretero, F. Garca, P. de Miguel, F. Prez
Ejemplo (TCP)
NCLEO
cliente
sumar(5,2)
5+2
Restulado = 7
servidor
Mquina A Mquina B
NCLEO
RED
Sistemas operativos: una visin aplicada 56 J. Carretero, F. Garca, P. de Miguel, F. Prez
Servidor (TCP)
void main(int argc, char *argv[])
{
struct sockaddr_in server_addr, client_addr;
int sd, sc;
int size, val;
int size;
int num[2], res;

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 57 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)); // recibe la peticin

res = num[0] + num[1];

write(sc, &res, sizeof(int)); // se enva el resultado

close(sc);
}

close (sd);
exit(0);
}

Sistemas operativos: una visin aplicada 58 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 59 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)); // enva la peticin

read(sd, &res, sizeof(int)); // recibe la respuesta

printf("Resultado es %d \n", res);
close (sd);
exit(0);
}
Sistemas operativos: una visin aplicada 60 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 61 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 62 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 63 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 64 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 65 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 66 J. Carretero, F. Garca, P. de Miguel, F. Prez
Llamadas y mensajes en una RPC
SISTEMA CLIENTE
CDIGO DE LA APLICACIN
PREPARA
ENTRADA
CONVIERTE
SALIDA
INICIO
LLAMADA
suma(5,2)
FIN
LLAMADA = 7
RESGUARDO
CLIENTE
2
1
5
3
PROCEDIMIENTOS
EJECUTA
PROCEDIMIENTO
REMOTO
SISTEMA SERVIDOR
RESGUARDO
SERVIDOR
PREPARA
SALIDA
CONVIERTE
ENTRADA
4
6
7
Sistemas operativos: una visin aplicada 67 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 68 J. Carretero, F. Garca, P. de Miguel, F. Prez
RPC: protocolo bsico
cliente servidor


Desempaqueta
la respuesta
Se registra con un
servicio de nombres

recibe peticin
Ejecuta el
procedimiento
enva peticin
enlaza con
el servidor

prepara
parmetros,
enva peticin
Sistemas operativos: una visin aplicada 69 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 70 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 71 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 72 J. Carretero, F. Garca, P. de Miguel, F. Prez
Aplanamiento
SISTEMA CLIENTE
CDIGO DE LA APLICACIN
RESGUARDO
CLIENTE
Procedimiento(ABC, 123, 12.34)
aplanamiento
mensaje
Tira de bytes
A B C 123 12.34
PROCEDIMIENTOS
SISTEMA SERVIDOR
RESGUARDO
SERVIDOR
Extrae los
parmetros
A B C 123 12.34
Procedimiento(ABC, 123, 12.34)
Sistemas operativos: una visin aplicada 73 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 74 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 75 J. Carretero, F. Garca, P. de Miguel, F. Prez
Establecimiento de la comunicacin en una RPC
Servidor
de nombres
1. Registrar
procedimiento
5. Dar de baja
procedimiento
2. Buscar
servidor
3. Direccin
del servidor
4. Ejecutar
procedimiento
servidor
servidor
Mquina A Mquina B
Mquina C
Sistemas operativos: una visin aplicada 76 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 77 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 78 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 79 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 80 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
Reintentar y garantizar que la RPC se realiza al menos una vez
No vale para operaciones no idempotentes
Semntica a lo ms una vez
No reintentar, puede que no se realice ni una sola vez
Semntica de exactamente una
Sera lo deseable

Sistemas operativos: una visin aplicada 81 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 82 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 83 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 84 J. Carretero, F. Garca, P. de Miguel, F. Prez
Programacin con RPC
COMPILADOR C COMPILADOR C
COMPILADOR C COMPILADOR C
CABECERA CABECERA
FICHEROS
FUENTE DEL
CLIENTE
FICHEROS
OBJETO DEL
CLIENTE
FICHEROS
OBJETO DEL
SERVIDOR
EJECUTABLE
DEL
CLIENTE
EJECUTABLE
DEL
SERVIDOR
FICHEROS
FUENTE DEL
SERVIDOR
OBJETO
SUPLENTE
EN CLIENTE
OBJETO
SUPLENTE
EN SERVIDOR
MONTADOR MONTADOR
BIBLIOT.
RPC
BIBLIOT.
RPC
DESARROLLO
DE LA
INTERFAZ
DESARROLLO
DEL
CLIENTE
DESARROLLO
DEL
SERVIDOR
COMPILADOR IDL
SUPLENTE
EN SERVIDOR
SUPLENTE
EN CLIENTE
CABECERA
FICHERO
DE DEFINICIN
DE INTERFAZ
Sistemas operativos: una visin aplicada 85 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 86 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


Sistemas operativos: una visin aplicada 87 J. Carretero, F. Garca, P. de Miguel, F. Prez
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 88 J. Carretero, F. Garca, P. de Miguel, F. Prez
Ejemplo
NCLEO
cliente
sumar(5,2)
5+2
Restulado = 7
servidor
Mquina A Mquina B
NCLEO
RED
Sistemas operativos: una visin aplicada 89 J. Carretero, F. Garca, P. de Miguel, F. Prez
Esquema de la aplicacin
suma.x
repcgen
suma_svc.c
servidor.c
suma.h
suma_xdr.c
suma_clnt.c
cliente.c
Archivos para
el cliente
Archivos
comunes
Archivos para
el servidor
Sistemas operativos: una visin aplicada 90 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 91 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 SUMAVER ((u_long)99)
#define SUMA ((u_long)1)
extern int * suma_1(peticion *, CLIENT *);
extern int * suma_1_svc(peticion *, struct svc_req *);

#endif /* !_SUMA_H_RPCGEN */

Sistemas operativos: una visin aplicada 92 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 93 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 94 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 95 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 96 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 97 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 RL
p
(reloj lgico)
Cuando un proceso P genera un evento, RL
p
=RL
p
+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, RL
q
=max(RL
q
,t)
El algoritmo asegura que si a Y b entonces RL(a) < RL(b)


Sistemas operativos: una visin aplicada 98 J. Carretero, F. Garca, P. de Miguel, F. Prez
Mantenimiento de los relojes lgicos
Sistemas operativos: una visin aplicada 99 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
(T
a
, P
a
): marca de tiempo del evento a del proceso P
(T
a
, P
a
) < (T
b
, P
b
) s y solo si
T
a
< T
b
o
T
a
=T
b
y P
a
<P
b


Sistemas operativos: una visin aplicada 100 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 101 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
RV
i
[a] es el valor del reloj vectorial del proceso i cuando
ejecuta el evento a.
Mantenimiento de los relojes vectoriales
Inicialmente RV
i
= 0
Cuando un proceso i genera un evento
RV
i
[i ] = RV
i
[i ] +1
Todos los mensajes llevan el RV del envo
Cuando un proceso j recibe un mensaje con RV
RV
j
= max(RV
j
, RV ) (componente a componente)
RV
j
[j ] = RV
j
[j ] +1 (evento de recepcin)


Sistemas operativos: una visin aplicada 102 J. Carretero, F. Garca, P. de Miguel, F. Prez
Relojes vectoriales
P0
(1,0,0) (2,1,0) (3,1,2) (4,1,2) (5,1,2)
(1,0,1) (1,0,2) (1,0,3) (1,0,4) (5,1,5)
(0,1,0)
(1,2,3)
(4,3,3)
P1
P2
Sistemas operativos: una visin aplicada 103 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 ] y RV(b )[j ] > RV(b)[j ]


Sistemas operativos: una visin aplicada 104 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 105 J. Carretero, F. Garca, P. de Miguel, F. Prez
Algoritmo centralizado
Existe un proceso coordinador
0
entrada
OK
C
1 2
No hay respuespuesta
(bloquea al cliente)
0
entrada
C
1
2
OK
0
salida
C
1 2
Sistemas operativos: una visin aplicada 106 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
2
1
testigo
3
4
5
6
Sistemas operativos: una visin aplicada 107 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 108 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 109 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 110 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 111 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 112 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 113 J. Carretero, F. Garca, P. de Miguel, F. Prez
Estrategias para localizar una estacin inactiva
Nodo
Nodo
Tengo poca carga.
Podis mandarme procesos
Tengo mucha carga.
Busco estacin inactiva
(a) (b)
Sistemas operativos: una visin aplicada 114 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 115 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 116 J. Carretero, F. Garca, P. de Miguel, F. Prez
Planificacin de procesos
Sistemas operativos: una visin aplicada 117 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 118 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 119 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 120 J. Carretero, F. Garca, P. de Miguel, F. Prez
Arquitectura
Cliente
Servidor
Servidor
Cliente
RED DE INTERCONEXIN
......................
......................
........ ........ CTR
.....
CTR
.....
CTR
.....
CTR
.....
Sistemas operativos: una visin aplicada 121 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 122 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 123 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 124 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 125 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 126 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 127 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 128 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 129 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 130 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 131 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 132 J. Carretero, F. Garca, P. de Miguel, F. Prez
Uso de paginadores externos

Paginador externo
Mensajes
Transferir pgina
Fallos de pgina
Espacio de
direcciones
del proceso
Nodo A
Ncleo
Nodo B
Ncleo
Sistemas operativos: una visin aplicada 133 J. Carretero, F. Garca, P. de Miguel, F. Prez
Memoria compartida distribuida
Memoria
fsica
Nodo A
proceso
Memoria
fsica
Nodo B
proceso
Memoria
fsica
Nodo C
proceso
Red de interconexin
Memoria compartida distribuida
Sistemas operativos: una visin aplicada 134 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 135 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