Sistemas Operativos Distribuidos
Anuncio
Sistemas Operativos Distribuidos
Índice
Sistemas Operativos Distribuidos
• Introducción
• Modelos de interacción
– Arquitectura cliente-servidor
Comunicación en
Sistemas
Distribuidos
• Aspectos de diseño del sistema de comunicaciones
• Paso de mensajes
– Sockets
• Llamadas a procedimientos remotos (RPC)
– Sun RPC
• Invocación de métodos remotos
– Java RMI
Sistemas Operativos Distribuidos
2
Comunicación en SD: Alternativas
Sistema de comunicación: Espina dorsal del SD.
Mecanismo de comunicación entre procesos:
Modelo cliente/servidor
• Dos roles diferentes en la interacción
– Memoria compartida (Distributed Shared Memory) vs. mensajes.
Paradigmas de comunicación:
– Cliente: Solicita servicio.
– Servidor: Proporciona servicio.
• Variantes del modelo básico:
– Intermediarios, uso de múltiples servidores, código móvil, modelo
editor/subscriptor
– Paso de mensajes.
– Llamadas a procedimientos remotos (RPC).
– Invocación de métodos remotos (RMI).
• Entornos distribuidos basados en objetos.
Interfaz de Servicio
Petición (args.)
Patrón de comunicación:
– uno-a-uno (unidifusión) versus uno-a-muchos (multidifusión)
Modelos de interacción:
Cliente
– Cliente/servidor vs. Peer-to-peer (de igual a igual)
Sistemas Operativos Distribuidos
3
2-Comunicaciones
Fernando Pérez Costoya
José María Peña Sánchez
Respuesta
Servidor
Resp=Código(args)
Fernando Pérez Costoya
José María Peña Sánchez
Sistemas Operativos Distribuidos
4
Fernando Pérez Costoya
José María Peña Sánchez
1
Sistemas Operativos Distribuidos
Cliente/servidor con proxy
Cliente/servidor con múltiples servidores
• Tres roles diferentes en la interacción
• Servicio con múltiples niveles:
– Cliente: Solicita servicio.
– Servidor: Proporciona servicio.
– Proxy: Intermediario (puede realizar labor de cache)
– Funcionalidad dividida en varios niveles:
• P.ej. 3 niveles: presentación, lógica de negocio y acceso a datos
– Cada nivel puede implementarse como un servidor
• Servidores actúan como clientes de otros servidores
Interfaz de Servicio 1
Petición (args.)
Cliente
Respuesta
• Múltiples servidores cooperan para proporcionar servicio
Proxy
Interfaz de Servicio 2
Respuesta
Petición
– Ejemplo: En SFD para traducir nombre de archivo colaboran aquellos
servidores que almacenan parte de la ruta
– Ejemplo: Para actualizar dato replicado deben intervenir todos los
servidores que almacenan una réplica
Servidor
Sistemas Operativos Distribuidos
5
Fernando Pérez Costoya
José María Peña Sánchez
Código móvil
– Arquitecturas homogéneas, interpretación de código o máquinas
virtuales (p.ej. JVM).
– Consideraciones de seguridad
– Ejemplo: applets
Interfaz de Servicio
Petición
Código
Servidor
Resp=Código(args)
Sistemas Operativos Distribuidos
7
2-Comunicaciones
Fernando Pérez Costoya
José María Peña Sánchez
Modelo editor/subscriptor
Requiere:
Cliente
Sistemas Operativos Distribuidos
6
Fernando Pérez Costoya
José María Peña Sánchez
• Cliente (subscriptor) pide a servidor (editor) que le notifique
cuando ocurra un determinado evento
• Cliente continúa su ejecución
• Cuando ocurre el evento, servidor se lo comunica al cliente:
– Comunicación servidor hacia cliente (callback)
• Ejemplo de uso: coherencia de cache en SFD
– Cliente lee fichero y lo guarda en cache
• Acceso siguiendo modelo cliente/servidor convencional
– Cliente queda subscrito a notificaciones para mantener coherencia
– Si otro cliente modifica el fichero, servidor informa a clientes que
tienen copia en cache mediante callback
Sistemas Operativos Distribuidos
8
Fernando Pérez Costoya
José María Peña Sánchez
2
Sistemas Operativos Distribuidos
Modelo Peer-to-Peer
Aspectos de diseño
• Un único rol:
– Entidad
Entidad
• Protocolo de diálogo
– Primitivas de interacción
Entidad
Entidad
Sistema de comunicaciones es normalmente una capa de
software situada sobre un protocolo de transporte
Entidad
Entidad
• Ejemplo: Simulación paralela
Entidad
Entidad
– Después de cada paso, cada proceso
comunica resultado parcial al resto
Entidad
Entidad
Interfaz de Diálogo
Sistemas Operativos Distribuidos
9
Fernando Pérez Costoya
José María Peña Sánchez
Con independencia del paradigma usado, existen distintas
alternativas en el diseño de un sistema de comunicaciones:
–
–
–
–
–
–
–
Modo de operación síncrono o asíncrono
Fiabilidad
Mecanismo de direccionamiento
Representación de datos
Eficiencia en la comunicación
Aspectos de diseño específicos del modelo cliente-servidor
Unidifusión vs. Multidifusión (Comunicación de grupo)
Sistemas Operativos Distribuidos
10
Fernando Pérez Costoya
José María Peña Sánchez
Grados de sincronía
Modo de operación síncrono o asíncrono
Operación asíncrona (p.e. sockets, one-way RPC/RMI):
EMISOR
EMISOR
– Emisor solicita operación y se le devuelve inmediatamente el control
– Normalmente info. se copia a buffer de sistema de comunicaciones
1
Operación síncrona (clasificación de Tanenbaum):
8
7
Núcleo
Emisor
RED
ACK/resp.
mensaje
6
5
RECEPTOR
RECEPTOR
Núcleo
Receptor
4
2
3
Asíncrono: [1:8] El emisor continúa al pasar el mensaje al núcleo.
– Emisor solicita operación y se bloquea hasta (grados de sincronía):
– Síncrono con respecto a transmisión (RPC/RMI asíncrona)
Síncrono con respecto a transmisión : [1:2:3:6:7:8]: El emisor espera a que el
núcleo receptor recoja el mensaje.
Síncrono con respecto a recepción : [1:2:3:4:5:6:7:8]: El emisor espera a que el
proceso receptor recoja el mensaje.
Síncrono con respecto a respuesta (Petición-Respuesta):
[1:2:3:4:<servicio>:5:6:7:8]: El emisor espera a que el receptor procese la
operación para reanudar la ejecución (respuesta sirve de ACK).
• que el nodo remoto recibe el mensaje
• que el proceso remoto recibe el mensaje
– Síncrono con respecto a recepción
• que el proceso remoto procese y responda al mensaje
– Síncrono con respecto a respuesta (p.e. RPC/RMI)
– protocolo petición/respuesta característico de cliente-servidor
Otro aspecto: comunicación persistente
– No es necesario que proceso receptor esté presente
– Sistema de comunicación guarda mientras mensaje
• Sistemas de colas de mensajes (MQSeries de IBM, MS-MQ, JMS)
Sistemas Operativos Distribuidos
11
2-Comunicaciones
Fernando Pérez Costoya
José María Peña Sánchez
Sistemas Operativos Distribuidos
12
Fernando Pérez Costoya
José María Peña Sánchez
3
Sistemas Operativos Distribuidos
Fiabilidad
Direccionamiento
Servicio de comunicación debe de ser fiable:
–
–
–
–
Garantía de que el mensaje ha sido recibido en nodo(s) destino(s)
Mantenimiento del orden en la entrega de los mensajes
Control de flujo para evitar “inundar” al nodo receptor
Fragmentación de los mensajes para eliminar limitaciones en tamaño
máximo de mensajes
Puede garantizarlo:
Información que identifica los receptores de una comunicación.
Mecanismos:
– Dirección dependiente de la ubicación:
• No proporciona transparencia
• Por ejemplo:
– Sockets: dirección IP de máquina + dirección puerto local.
– Sun RPC: dirección IP de máquina + número de programa.
– Dirección independiente de la ubicación:
– El protocolo de comunicación subyacente
• TCP lo garantiza; UDP no.
– El propio servicio de comunicación
• Debe usar timeouts, ACKs, detección de duplicados, control de flujo,
fragmentación/compactación de mensajes, etc.
• Facilita transparencia.
• Por ejemplo: RPC de DCE
• Necesidad de proceso de localización:
– Mediante broadcast.
– Uso de un servidor, con ubicación conocida, para permitir localización.
• Uso de cache en clientes para evitar repetir localización.
Sistemas Operativos Distribuidos
13
Fernando Pérez Costoya
José María Peña Sánchez
Sistemas Operativos Distribuidos
14
Fernando Pérez Costoya
José María Peña Sánchez
Formatos de representación
Marshalling
Para transmisión información, emisor y receptor deben coincidir en la
interpretación de los bytes transmitidos.
Problemática:
• Necesario aplanar y convertir info en emisor: marshalling
–
–
–
–
Tamaño de los datos numéricos.
Ordenación de bytes.
Formatos de texto: ASCII vs Unicode.
“Aplanamiento” (serialize) de estructuras de datos (en Java RMI, object serialization)
– Y la operación inversa (unmarshalling) en receptor
• Alternativas:
– S. de comunicación no lo hace
• aplicaciones deben encargarse de hacerlo (sockets)
– S. de comunicación en emisor convierte a formato de receptor
• Debe de saber transformar al formato de cualquier receptor
Arquitectura
little-endian
Dato a enviar: 5
3
2
1
0
0005
Valor: 0x224+0x216+0x28+5
Sistemas Operativos Distribuidos
15
2-Comunicaciones
0005
Arquitectura
big-endian
0
1
2
3
0005
Valor: 5x224+0x216+0x28+0
Dato a recibido: 83.886.080
Fernando Pérez Costoya
José María Peña Sánchez
– S. de comunicación en receptor convierte a su formato
• Debe de saber transformar desde el formato de cualquier emisor
– S. de comunicación en emisor convierte a formato externo
• Sólo se requiere saber transformar de nativo a externo y viceversa
• Ineficiente si formatos de emisor y receptor iguales pero distintos del
externo
Sistemas Operativos Distribuidos
16
Fernando Pérez Costoya
José María Peña Sánchez
4
Sistemas Operativos Distribuidos
Formato de representación externo
Protocolos basados en texto vs. binarios
• Mejor si es estándar
• La información de tipos puede ser implícita o explícita:
• Marshalling más sencillo con protocolos basados en texto
• Además, más fácil de interpretar por usuarios
– Implícita:
– Pero menos eficiente
• emisor y receptor conocen de qué tipo es cada parámetro
• no viaja info. de tipos con los datos transmitidos
• Ejemplos: XDR de Sun (RFC 1832) y CDR de Corba
– Explícita:
• info. explícita de tipos asociada con los datos transmitidos
• Ejemplos: Java RMI y XML usado en web services
• Permite reflexión
• Formato binario:
– XDR, CDR y Java RMI
• Formato texto:
– Web services (XML)
• Por ejemplo HTTP:
“GET //www.fi.upm.es HTTP/1.1”
Sistemas Operativos Distribuidos
17
Fernando Pérez Costoya
José María Peña Sánchez
Eficiencia en la comunicación
• Fundamental minimizar copias de información
• Ejemplo: transferencia de un entero N y un string S
– Opción 1: Definir estructura E y copiar N y S en sendos campos de E
• Requiere copia
– Opción 2: Usar dos transferencias
• Mayor consumo de ancho de banda y nº de llamadas
– Opción 3: Usar primitivas de tipo scatter/gather (readv, writev)
Sistemas Operativos Distribuidos
18
Fernando Pérez Costoya
José María Peña Sánchez
Aspectos de diseño de cliente/servidor
Se van a considerar 3 aspectos específicos:
• Esquemas de servicio concurrente
• Servicio con estado o sin estado
• Comportamiento del servicio ante fallos
• Una sola transferencia sin usar copia
• RPC/RMI se encargan de optimizar copias pero si se usa paso
de mensajes es responsabilidad del programador
Sistemas Operativos Distribuidos
19
2-Comunicaciones
Fernando Pérez Costoya
José María Peña Sánchez
Sistemas Operativos Distribuidos
20
Fernando Pérez Costoya
José María Peña Sánchez
5
Sistemas Operativos Distribuidos
Servicio concurrente
Servicio con/sin estado
• Determina si servidor mantiene información de clientes o no.
• Ventajas de servicio con estado:
• Threads vs. Procesos: generalmente threads:
– Más ligeros y mayor grado de compartición
• Alternativas en control de la concurrencia:
– Creación dinámica de threads/procesos según llegan peticiones
• Al finalizar trabajo el thread termina
• Sobrecarga al crearlos y destruirlos
• Estrategias predictivas: análisis del patrón de operaciones del cliente.
• Ventajas de servicio sin estado:
– Bolsa de N threads/procesos pre-arrancados:
• Al finalizar trabajo el thread queda en espera de más peticiones
• En fase de pocas peticiones, gasto de recursos innecesario
• En fase de mucha carga, pueden ser insuficiente
– Esquema híbrido con un mínimo m y máximo M
• m pre-arrancados; siempre nº de thr./proc. existentes ≤ M y ≥ m
• Se crea thr./proc. si llega petición, ninguno libre y nº < M
• Se destruye thr./proc. si lleva inactivo un tiempo prefijado y nº > m
Sistemas Operativos Distribuidos
21
– Mensajes de petición más cortos.
– Mejor rendimiento (se mantiene información en memoria).
– Favorece estrategias de optimización:
Fernando Pérez Costoya
José María Peña Sánchez
– Más tolerantes a fallos (ante rearranque del servidor).
• Peticiones autocontenidas.
– Reduce el número de mensajes: no hay comienzos/finales de sesión.
– Más económicos para el servidor (no consume recursos de memoria)
• Servicios inherentes con estado (cerrojos distribuidos).
• Estado sobre servicios sin estado (HTTP+cookies).
Sistemas Operativos Distribuidos
22
Comportamiento del servicio ante fallos
• ¿Qué se garantiza con respecto al servicio ante fallos?
–
–
–
–
No garantizar nada: El servicio puede ejecutarse de 0 a N veces
Semántica de al menos una vez: Se ejecuta de 1 a N veces
Semántica de como mucho una vez: Se ejecuta 0 ó 1 vez
Semántica de exactamente una: Se ejecuta 1 vez; Sería lo deseable
• Algunas operaciones pueden repetirse sin problemas
(operaciones idempotentes)
– Operación idempotente + al menos una vez ≈ exactamente una
– Una transferencia bancaria que añade dinero no es idempotente
– Una que fija una cantidad o lee estado de cuenta sí lo es
• Tipos de fallos:
– Pérdida de petición o de respuesta
– Caída del servidor
Sistemas Operativos Distribuidos
23
2-Comunicaciones
Fernando Pérez Costoya
José María Peña Sánchez
Fernando Pérez Costoya
José María Peña Sánchez
Pérdida de petición/respuesta
• Si comunicación fiable, no hay problema
• Si no fiable:
–
–
–
–
Si no respuesta, retransmisión de mensaje cuando se cumple plazo
Número de secuencia en el mensaje
Si se ha perdido petición, retransmisión no causa problemas
Si se ha perdido respuesta, retransmisión causa re-ejecución
• Si la operación es idempotente, no es erróneo pero gasta recursos
• Si no, es erróneo
• Se puede guardar un histórico de respuestas (cache de respuestas):
– Si nº de secuencia duplicado, no se ejecuta pero manda respuesta
– Arregla error para operaciones no idempotentes
– Evita gasto de recursos para operaciones idempotentes, aunque puede
que gaste más la gestión de la propia cache
Sistemas Operativos Distribuidos
24
Fernando Pérez Costoya
José María Peña Sánchez
6
Sistemas Operativos Distribuidos
Caída del servidor
Comunicación de grupo
• Si cae servidor no siempre puede saber si ejecutado servicio
• Si comunicación fiable:
– Semántica de como mucho una vez
• Si llega respuesta, se ha ejecutado exactamente una vez
• Si no llega (servidor caído), se ha ejecutado 0 ó 1 vez
– Para semántica al menos una vez (con operaciones Idempotentes)
• Retransmitir hasta que haya respuesta (servidor se recupere) o usar un
sistema de transacciones distribuidas
• Si comunicación no fiable (que conlleva retransmisión):
– Si llega finalmente respuesta, semántica de al menos una vez
– Si no llega, no hay ninguna garantía (0 a N veces)
Destino de mensaje es un grupo de procesos: multidifusión
Posibles usos en los sistemas distribuidos:
– Uso de datos replicados: actualizaciones múltiples.
– Uso de servicios replicados.
– Operaciones colectivas en cálculo paralelo.
Implementación depende de si red tiene multicast (IP-multicast)
– Si no, se implementa enviando N mensajes
Un proceso puede pertenecer a varios grupos
Existe una dirección de grupo
El grupo suele tener carácter dinámico
– Se pueden incorporar y retirar procesos del grupo
– Gestión de pertenencia debe coordinarse con la comunicación
Sistemas Operativos Distribuidos
25
Fernando Pérez Costoya
José María Peña Sánchez
Aspectos de diseño de com. de grupo
– Grupo abierto.
Orden de recepción de los mensajes
– Orden FIFO: Los mensajes de una misma fuente llegan a cada
receptor en el orden que son enviados.
• Proceso externo puede mandar mensaje al grupo
• Suele usarse para datos o servicios replicados
• No hay ninguna garantía sobre mensajes de distintos emisores
– Grupo cerrado.
• Sólo procesos del grupo pueden mandar mensajes.
• Suele usarse en procesamiento paralelo (modelo peer-to-peer)
• Comunicación fiable (atomicidad)
– O reciben todos los procesos el mensaje o ninguno
• Con unidifusión fiable (TCP): en medio, se puede caer emisor
• Con multicast IP: pérdida de mensajes
• Orden de recepción de los mensajes
2-Comunicaciones
Fernando Pérez Costoya
José María Peña Sánchez
De acuerdo a las garantías de ofrecidas en la recepción de
mensajes de grupo se tienen:
• Modelos de grupos:
Sistemas Operativos Distribuidos
27
Sistemas Operativos Distribuidos
26
Fernando Pérez Costoya
José María Peña Sánchez
– Ordenación causal: Si entre mensajes enviados por dos emisores
existe una posible relación “causa-efecto”, todos los procesos del
grupo reciben primero mensaje “causa” y después mensaje “efecto”.
• Si no hay relación, no se garantiza ningún orden de entrega
• Concepto de “causalidad” se estudia en capítulo “Sincronización”
– Ordenación total: Todos los mensajes (de varias fuentes) enviados
a un grupo son recibidos en el mismo orden por todos los elementos,
pero puede que no se mantenga orden FIFO o causal...
– Ordenación total FIFO
– Ordenación total causal
Sistemas Operativos Distribuidos
28
Fernando Pérez Costoya
José María Peña Sánchez
7
Sistemas Operativos Distribuidos
Primitivas de paso de mensajes
Sistemas Operativos Distribuidos
Operaciones básicas para envío y recepción.
Generalmente, con un modo de operación asíncrono:
– Envío no bloqueante y Recepción bloqueante
Paso de mensajes
Pueden ser con conexión o sin conexión
– con conexión:
• existen primitivas para conectar y desconectar
• operaciones de envío y recepción no incluyen direcciones
– sin conexión:
• operaciones de envío y recepción incluyen direcciones
•Sockets de Berkeley
Evaluación del paradigma de paso de mensajes:
–
–
–
–
Programación compleja
Aplicable a cualquier modelo de interacción (clie-serv, peer-to-peer)
Puede ser el único disponible en plataformas con recursos limitados
Puede requerirse por eficiencia o restricciones en uso de recursos
Sistemas Operativos Distribuidos
30
Cliente-servidor con paso de mensajes
msj
CLIENTE
envío(msj,dir)
Mensaje msj,resp;
msj.op=OP1;
msj.args=ARGS;
envío(msj,dir_servidor);
recepción(&resp, NULL);
...
Sistemas Operativos Distribuidos
31
2-Comunicaciones
SERVIDOR
msj
msj
recepción(msj,dir)
while (TRUE) {
Mensaje msj,resp;
recepción(&msj,&dir_clie);
switch(msj.op) {
case OP1:
resp=hacer_OP1(msj.args);
case OP2:
resp=hacer_OP2(msj.args);
...
}
envío(resp,dir_clie);
}
Fernando Pérez Costoya
José María Peña Sánchez
Fernando Pérez Costoya
José María Peña Sánchez
Cliente-servidor con paso de mensajes
• El programador debe de ocuparse de aspectos tales como:
–
–
–
–
–
–
–
Elección de formato de representación y marshalling
Si comunicación no fiable, garantizar envío de mensajes
Asegurar semántica de comportamiento ante fallos
Si limitación en tamaño de mensajes, fragmentación y compactación
Minimizar copias en la transmisión
Gestión de esquema de concurrencia elegido
Si se usa mecanismo de comunicación con conexión, establecer
esquema de correspondencia entre peticiones y conexiones
• 1 conexión por cada petición (como HTTP/1.0)
– Más sencillo. Petición: conexión, envío de petición, recepción de
respuesta, cierre de conexión
– Mayor sobrecarga
• Varias peticiones de cliente usan misma conexión (como HTTP/1.1)
– Más complejo pero menor sobrecarga
Sistemas Operativos Distribuidos
32
Fernando Pérez Costoya
José María Peña Sánchez
8
Sistemas Operativos Distribuidos
Sockets de Berkeley
Conceptos básicos sobre sockets
Aparecieron en 1981 en UNIX BSD 4.2
– Intento de incluir TCP/IP en UNIX.
– Diseño independiente del protocolo de comunicación.
Un socket es punto final de comunicación (dir. IP y puerto).
Abstracción que:
– Ofrece interfaz de acceso a servicios de red en nivel de
transporte.
– Representa extremo de comunicación bidireccional.
Actualmente:
– Disponibles en casi todos UNIX y prácticamente todos los SSOO
• WinSock: API de sockets de Windows.
– En Java como clase nativa.
Sistemas Operativos Distribuidos
33
Fernando Pérez Costoya
José María Peña Sánchez
•
•
•
•
•
•
•
•
•
Dominios de comunicación.
Tipos de sockets.
Direcciones de sockets.
1.- Creación del socket
7
Creación de un socket.
37
67
33
91
Asignación de direcciones.
Solicitud de conexión.
2.- Asignación de dirección
Preparar para aceptar conexiones.
Aceptar una conexión.
Transferencia de datos.
3.- Aceptación de conexión
Sistemas Operativos Distribuidos
34
Dominios de comunicación
•
•
•
•
Un dominio representa una familia de protocolos.
Un socket está asociado a un dominio desde su creación.
Sólo se pueden comunicar sockets del mismo dominio.
Los servicios de sockets son independientes del dominio.
Fernando Pérez Costoya
José María Peña Sánchez
Tipos de sockets
• Stream (SOCK_STREAM):
–
–
–
–
Orientado a conexión.
Fiable, se asegura el orden de entrega de mensajes.
No mantiene separación entre mensajes (stream).
Si PF_INET se corresponde con el protocolo TCP.
• Datagrama (SOCK_DGRAM):
Algunos ejemplos:
– PF_UNIX (o PF_LOCAL): comunicación dentro de una máquina.
– PF_INET: comunicación usando protocolos TCP/IP.
–
–
–
–
Sin conexión.
No fiable, no se asegura el orden en la entrega.
Mantiene la separación 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 Distribuidos
35
2-Comunicaciones
Fernando Pérez Costoya
José María Peña Sánchez
Sistemas Operativos Distribuidos
36
Fernando Pérez Costoya
José María Peña Sánchez
9
Sistemas Operativos Distribuidos
Direcciones de sockets
Direcciones de sockets en PF_INET
• Cada socket debe tener asignada una dirección única.
• Dependientes del dominio.
• Las direcciones se usan para:
– Asignar una dirección local a un socket (bind).
– Especificar una dirección remota (connect o sendto).
• Se utiliza la estructura genérica de dirección:
– Dirección del host: 32 bits.
– Puerto de servicio: 16 bits.
Estructura struct sockaddr_in:
–
–
–
–
Debe iniciarse a 0 (bzero).
sin_family: dominio (AF_INET).
sin_port: puerto.
sin_addr: dirección del host.
Una transmisión está caracterizada por cinco parámetros únicos:
– struct sockaddr mi_dir;
• Cada dominio usa una estructura específica.
– Uso de cast en las llamadas.
– Direcciones en PF_INET (struct sockaddr_in).
– Direcciones en PF_UNIX (struct sockaddr_un).
Sistemas Operativos Distribuidos
37
Una dirección destino viene determinada por:
Fernando Pérez Costoya
José María Peña Sánchez
Obtención de la dirección del host
Usuarios manejan direcciones en forma de texto:
– decimal-punto: 138.100.8.100
– dominio-punto: laurel.datsi.fi.upm.es
• Conversión a binario desde decimal-punto:
int inet_aton(char *str,struct in_addr *dir)
• str: contiene la cadena a convertir.
• dir: resultado de la conversión en formato de red.
• Conversión a binario desde dominio-punto:
struct hostent *gethostbyname(char *str)
– Dirección host y puerto origen.
– Dirección host y puerto destino.
– Protocolo de transporte (UDP o TCP).
Sistemas Operativos Distribuidos
38
Fernando Pérez Costoya
José María Peña Sánchez
Creación de un socket
La función socket crea uno nuevo:
int socket(int dom,int tipo,int proto)
– Devuelve un descriptor de fichero (igual que un open de fichero).
– Dominio (dom): PF_XXX
– Tipo de socket (tipo): SOCK_XXX
– Protocolo (proto): Dependiente del dominio y del tipo:
• 0 elige el más adecuado.
• Especificados en /etc/protocols.
El socket creado no tiene dirección asignada.
• str: cadena a convertir.
• Devuelve la estructura que describe al host.
Sistemas Operativos Distribuidos
39
2-Comunicaciones
Fernando Pérez Costoya
José María Peña Sánchez
Sistemas Operativos Distribuidos
40
Fernando Pérez Costoya
José María Peña Sánchez
10
Sistemas Operativos Distribuidos
Asignación de direcciones
La asignación de una dirección a un socket ya creado:
int bind(int s,struct sockaddr* dir,int tam)
– Socket (s): Ya debe estar creado.
– Dirección a asignar (dir): Estructura dependiendo del dominio.
– Tamaño de la dirección (tam): sizeof().
Si no se asigna dirección (típico en clientes) se le asigna
automáticamente (puerto efímero) en la su primera utilización
(connect o sendto).
Asignación de direcciones (PF_INET)
Direcciones en dominio PF_INET
–
–
–
–
Puertos en rango 0..65535.
Reservados: 0..1023.
Si se le indica el 0, el sistema elige uno.
Host: una dirección IP de la máquina local.
• INADDR_ANY: elige cualquiera de la máquina.
Si el puerto solicitado está ya asignado la función bind
devuelve un valor negativo.
El espacio de puertos para streams (TCP) y datagramas (UDP)
es independiente.
Sistemas Operativos Distribuidos
41
Fernando Pérez Costoya
José María Peña Sánchez
Solicitud de conexión
int connect(int s,struct sockaddr* d,int tam)
– Socket creado (s).
– Dirección del servidor (d).
– Tamaño de la dirección (tam).
Si no se ha asignado dirección, se asigna una automáticamente.
Un socket stream sólo permite un único connect durante su vida
Para conectarse con el mismo u otro hay que crear un nuevo socket
Normalmente se usa con streams pero también con datagramas
–
Más adelante se analiza uso con datagrama
Sistemas Operativos Distribuidos
43
2-Comunicaciones
Fernando Pérez Costoya
José María Peña Sánchez
Preparar para aceptar conexiones
Realizada en el cliente por medio de la función:
–
Sistemas Operativos Distribuidos
42
Fernando Pérez Costoya
José María Peña Sánchez
• Realizada en el servidor stream después de haber creado
(socket) y reservado dirección (bind) para el socket:
int listen(int sd, int baklog)
– Socket (sd): Descriptor de uso del socket.
– Tamaño del buffer (backlog): Nº máximo de peticiones pendientes
de aceptar que se encolarán
• Hace que el socket quede preparado para aceptar conexiones.
• Con el mismo socket se pueden aceptar un número ilimitado
de peticiones de conexión
Sistemas Operativos Distribuidos
44
Fernando Pérez Costoya
José María Peña Sánchez
11
Sistemas Operativos Distribuidos
Aceptar una conexión
Aceptar una conexión
Realizada en el servidor stream después de haber preparado la
conexión (listen):
int accept(int s,struct sockaddr *d,int *tam)
– Socket (sd): Descriptor de uso del socket.
– Dirección del cliente (d): Dirección del socket del cliente devuelta.
– Tamaño de la dirección (tam): Parámetor valor-resultado
• Antes de la llamada: tamaño de dir
• Después de la llamada: tamaño de la dirección del cliente que se
devuelve.
La semántica de la función accept es la siguiente:
• Cuando se produce la conexión, el servidor obtiene:
– La dirección del socket del cliente.
– Un nuevo descriptor (socket) conectado al socket del cliente.
• Después de conexión quedan activos 2 sockets en el servidor:
– El original para aceptar nuevas conexiones
– El nuevo para enviar/recibir datos por la conexión establecida.
• Facilita construcción de servidores concurrentes
– En servidores multithread, cuidado con condición de carrera en:
while (true) {
n=accept(s, …);
pthread_create(…, &n);
}
• Puede pasarse n por valor o usar memoria dinámica
– flujo principal realiza malloc y thread el free
Sistemas Operativos Distribuidos
45
Fernando Pérez Costoya
José María Peña Sánchez
Múltiples clientes con streams
• Con servidor iterativo no concurrente
• Se intercalan peticiones de los clientes (1 por iteración)
– Si varias peticiones de cliente usan misma conexión
• No se trata a otro cliente hasta que no termine el actual o bien…
• Uso de select para esperar simultáneamente la llegada de nuevas
peticiones de conexión o de datos por sockets conectados
• Con servidor concurrente
Otras funcionalidades
– Dirección local: getsockname().
– Dirección del socket en el otro extremo: getpeername().
Transformación de valores:
– De formato host a red:
• Enteros largos: htonl().
• Enteros cortos: htons().
– De formato de red a host:
– Si 1 conexión por petición
• Cada thr./proc. sirve una petición y termina su labor
– Si varias peticiones de cliente usan misma conexión
• Cada thr./proc. sirve peticiones hasta que cliente cierra el socket
– En ambos casos también puede usarse bolsa de thr/proc o híbrido
• Al terminar trabajo thr./proc queda esperando un plazo en semáforo
• Cuando llega petición de conexión, flujo principal elige un thr./proc en
espera y le desbloquea pasándole el socket conectado
2-Comunicaciones
Fernando Pérez Costoya
José María Peña Sánchez
Obtener la dirección a partir de un descriptor:
– Si 1 conexión por petición
Sistemas Operativos Distribuidos
47
Sistemas Operativos Distribuidos
46
Fernando Pérez Costoya
José María Peña Sánchez
• Enteros largos: ntohl().
• Enteros cortos: ntohs().
Cerrar la conexión:
– Para cerrar ambos tipos de sockets: close().
• Si el socket es de tipo stream cierra la conexión en ambos sentidos.
– Para cerrar un único extremo: shutdown().
Sistemas Operativos Distribuidos
48
Fernando Pérez Costoya
José María Peña Sánchez
12
Sistemas Operativos Distribuidos
Transferencia de datos con streams
Escenario de uso de sockets streams
• Modo de operación asíncrono
• Envío:
Proceso servidor
socket()
int send(int s,char *mem,int tam,int flags)
• Devuelve el nº de bytes enviados.
– Puede usarse write (o writev) sobre el descriptor de socket.
• Recepción:
bind()
Proceso cliente
listen()
socket()
int recv(int s,char *mem,int tam,int flags)
Abrir conexión
connect()
• Devuelve el nº de bytes recibidos (0 si cliente ha cerrado socket)
– Puede usarse read (o readv) sobre el descriptor de socket.
– Lectura puede devolver menos bytes de los pedidos
accept()
Posible
Ejecución
en Paralelo
accept()
Petición
recv()/read()
send()/write()
• Si se requiere leer N bytes hay que usar un bucle
Respuesta
• No requiere correspondencia entre nº de send y de recv
• Los flags implican aspectos avanzados
recv()/read()
send()/write()
close()
close()
– como enviar o recibir datos urgentes (out-of-band).
Sistemas Operativos Distribuidos
49
Fernando Pérez Costoya
José María Peña Sánchez
Transferencia de datos con datagramas
Envío:
int sendto(int s,char *mem,int tam,
int flags,struct sockaddr *dir, int *tam)
Recepción:
int recvfrom(int s,char *mem,int tam,
int flags,struct sockaddr *dir, int *tam)
• Puede usarse recv (read) si no se necesita conocer
Sistemas Operativos Distribuidos
50
Más sobre datagramas
• Un socket datagrama puede usarse para enviar información a
diferentes sockets durante su vida
• Por un socket puede llegar información de distintos clientes
– En stream por socket conectado llega información de un solo cliente
• Se mantiene separación entre mensajes:
– Una lectura consume un mensaje
– Si el tamaño leído es menor que mensaje, el resto se pierde
– Correspondencia entre nº de sendto y de recv/recvfrom
dirección de envío (por ejemplo, en un cliente)
• No se establece una conexión (connect/accept) previa.
• Para usar un socket para transferir basta con crear el socket y
reservar la dirección (bind).
• En el cliente no sería necesario bind
• Se permite connect en socket datagrama:
Sistemas Operativos Distribuidos
51
Sistemas Operativos Distribuidos
52
2-Comunicaciones
Fernando Pérez Costoya
José María Peña Sánchez
Fernando Pérez Costoya
José María Peña Sánchez
– No realiza conexión física: sólo especifica destino para send/write
– No afecta al servidor pero…
– permite que cliente pueda ser idéntico usando stream o datagrama
Fernando Pérez Costoya
José María Peña Sánchez
13
Sistemas Operativos Distribuidos
Múltiples clientes con datagramas
Escenario de uso de sockets datagrama
• Con servidor iterativo no concurrente
– Las peticiones de clientes ya llegan intercaladas
Proceso
• Con servidor concurrente
– Después de recibir mensaje, flujo principal crea thr/proc que lo tratará
y enviará la respuesta
– Puede usarse modelo dinámico, de bolsa de thr/proc o híbrido
• Al terminar trabajo thr./proc queda esperando un plazo en semáforo
• Cuando flujo principal lee petición, elige un thr./proc en espera y le
desbloquea pasándole el mensaje leído
Proceso
socket()
socket()
bind()
bind()
Petición
sendto()
recvfrom()
recvfrom()
Respuesta
close()
Sistemas Operativos Distribuidos
53
Fernando Pérez Costoya
José María Peña Sánchez
Uso de datagramas con conexión
socket()
socket()
connect()
bind()
Sistemas Operativos Distribuidos
54
Fernando Pérez Costoya
José María Peña Sánchez
Datagramas vs streams
– Los mensajes de petición y respuesta son pequeños
Petición
• No se puede tolerar la sobrecarga de la conexión
• Además, si son grandes hay que fragmentar y compactar
recvfrom()
send()/write()
close()
• Uso mayoritario de streams
• Datagramas en comunicaciones que no toleran sobrecarga de
conexión, retransmisión y control de flujo, pero admiten
pérdida de información (p.ej. transmisión de voz)
• En cliente/servidor más conveniente stream excepto si:
Proceso
Proceso cliente
sendto()
Respuesta
recv()/read()
sendto()
close()
close()
– Las operaciones son idempotentes
• Evita sobrecarga de gestionar cache de respuestas en servidor
– Se quiere dar servicio a un nº muy elevado de clientes
• Datagramas no requieren tanta información en S.O. como streams
Sistemas Operativos Distribuidos
55
2-Comunicaciones
Fernando Pérez Costoya
José María Peña Sánchez
Sistemas Operativos Distribuidos
56
Fernando Pérez Costoya
José María Peña Sánchez
14
Sistemas Operativos Distribuidos
Configuración de opciones
Existen varios niveles dependiendo del protocolo afectado como
parámetro:
– SOL_SOCKET: opciones independientes del protocolo.
– IPPROTO_TCP: nivel de protocolo TCP.
– IPPTOTO_IP: nivel de protocolo IP.
Consultar opciones asociadas a un socket: getsockopt()
Modificar opciones asociadas a un socket: setsockopt()
– Nivel SOL_SOCKET. Para reutilizar direcciones:SO_REUSEADDR
– Nivel IPPTOTO_IP. Para usar multicast IP:
IP_MULTICAST_TTL, IP_MULTICAST_IF,
IP_MULTICAST_LOOP, IP_ADD_MEMBERSHIP,
IP_DROP_MEMBERSHIP
Sistemas Operativos Distribuidos
57
2-Comunicaciones
Fernando Pérez Costoya
José María Peña Sánchez
Multidifusión IP
• Implementación de comunicación de grupo sobre IP
• Emisor envía datagrama a dirección IP de multidifusión
– Empieza por 1110. De 239.0.0.0 a 239.255.255.255 para temporales.
• Emisor puede formar parte del grupo o no
• Procesos se incorporan y abandonan el grupo
• Control del ámbito de propagación mediante time-to-live:
– el host (0), la subred (1), el site (32), ...
• No fiable. No garantiza ningún orden de entrega
• Necesario construir encima protocolos para lograr fiabilidad y
un determinado orden de entrega.
Sistemas Operativos Distribuidos
58
Fernando Pérez Costoya
José María Peña Sánchez
15
