Sistemas Operativos Distribuidos

(1)

Sistemas Operativos Distribuidos

Comunicación en

Sistemas

Distribuidos

Comunicación en

Sistemas

Distribuidos

Sistemas Operativos Distribuidos

2 José María Peña SánchezFernando Pérez Costoya

Índice

• Introducción

• Modelos de interacción

– Arquitectura cliente-servidor

• 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

Comunicación en SD: Alternativas

Sistema de comunicación: Espina dorsal del SD.

Mecanismo de comunicación entre procesos:

– Memoria compartida (Distributed Shared Memory) vs. mensajes.

Paradigmas de comunicación:

– Paso de mensajes.

– Llamadas a procedimientos remotos (RPC). – Invocación de métodos remotos (RMI).

• Entornos distribuidos basados en objetos.

Patrón de comunicación:

– uno-a-uno (unidifusión) versus uno-a-muchos (multidifusión)

Modelos de interacción:

– Cliente/servidor vs. Peer-to-peer (de igual a igual)

Modelo cliente/servidor

• Dos roles diferentes en la interacció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

Cliente

Servidor

Interfaz de Servicio Petición (args.) Respuesta Resp=Código(args)

(2)

Sistemas Operativos Distribuidos

Cliente/servidor con proxy

• Tres roles diferentes en la interacción

– Cliente: Solicita servicio. – Servidor: Proporciona servicio.

– Proxy: Intermediario (puede realizar labor de cache)

Cliente

Proxy

Interfaz de Servicio 1

Petición (args.) Respuesta

Servidor

Interfaz de Servicio 2 Petición

Respuesta

Cliente/servidor con múltiples servidores

• Servicio con múltiples niveles:

– 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

• Múltiples servidores cooperan para proporcionar servicio

– 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

Código móvil

Requiere:

– Arquitecturas homogéneas, interpretación de código o máquinas virtuales (p.ej. JVM). – Consideraciones de seguridad – Ejemplo: applets

Cliente

Servidor

Interfaz de Servicio Petición Código Resp=Código(args)

Modelo editor/subscriptor

• 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

(3)

Sistemas Operativos Distribuidos

Modelo Peer-to-Peer

• Un único rol:

– Entidad

• Protocolo de diálogo

– Primitivas de interacción

• Ejemplo: Simulación paralela

– Después de cada paso, cada proceso comunica resultado parcial al resto

Entidad

Interfaz de Diálogo Entidad Entidad Entidad Entidad Entidad Entidad Entidad

Aspectos de diseño

Sistema de comunicaciones es normalmente una capa de

software situada sobre un protocolo de transporte

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)

Modo de operación síncrono o asíncrono

Operación asíncrona (p.e. sockets,

one-way

RPC/RMI):

– Emisor solicita operación y se le devuelve inmediatamente el control – Normalmente info. se copia a buffer de sistema de comunicaciones

Operación síncrona (clasificación de Tanenbaum):

– Emisor solicita operación y se bloquea hasta (grados de sincronía):

• que el nodo remoto recibe el mensaje

–Síncrono con respecto a transmisión (RPC/RMI asíncrona) • 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)

Grados de sincronía

EMISOR EMISOR

Núcleo Emisor

RED RECEPTORRECEPTOR

Núcleo Receptor 1 2 7 3 6 4 8 5 mensaje ACK/resp.

Asíncrono:[1:8] El emisor continúa al pasar el mensaje al núcleo.

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

(4)

Sistemas Operativos Distribuidos

Fiabilidad

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:

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

Direccionamiento

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:

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

Formatos de representación

Para transmisión información, emisor y receptor deben coincidir en la

interpretación de los bytestransmitidos.

Problemática:

– 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) Arquitectura little-endian Dato a enviar: 5 0 0 0 5 Valor: 0x224_+0x216_+0x28₊₅ Arquitectura big-endian Dato a recibido: 83.886.080 0 0 0 5 Valor: 5x224_+0x216_+0x28₊₀ 0 0 0 5 0 1 2 3 3 2 1 0

Marshalling

• Necesario aplanar y convertir info en emisor:

marshalling

– 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

– 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

(5)

Sistemas Operativos Distribuidos

Formato de representación externo

• Mejor si es estándar

• La información de tipos puede ser implícita o explícita:

– Implícita:

• 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

Protocolos basados en texto vs. binarios

• Marshalling

más sencillo con protocolos basados en texto

• Además, más fácil de interpretar por usuarios

– Pero menos eficiente

• Formato binario:

– XDR, CDR y Java RMI

• Formato texto:

– Web services(XML)

• Por ejemplo HTTP:

“GET //www.fi.upm.es HTTP/1.1”

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 Ey copiar Ny Sen 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)

• Una sola transferencia sin usar copia

• RPC/RMI se encargan de optimizar copias pero si se usa paso

de mensajes es responsabilidad del programador

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

(6)

Sistemas Operativos Distribuidos

Servicio concurrente

• 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 threadtermina • Sobrecarga al crearlos y destruirlos

– Bolsa de N threads/procesos pre-arrancados:

• Al finalizar trabajo el threadqueda 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 my máximo M

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

Servicio con/sin estado

• Determina si servidor mantiene información de clientes o no.

• Ventajas de servicio con estado:

– Mensajes de petición más cortos.

– Mejor rendimiento (se mantiene información en memoria). – Favorece estrategias de optimización:

• Estrategias predictivas: análisis del patrón de operaciones del cliente.

• Ventajas de servicio sin estado:

– 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

).

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

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

(7)

Sistemas Operativos Distribuidos

Caída del servidor

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

Comunicación de grupo

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

Aspectos de diseño de com. de grupo

• Modelos de grupos:

– Grupo abierto.

• Proceso externo puede mandar mensaje al grupo • Suele usarse para datos o servicios replicados

– 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

Orden de recepción de los mensajes

De acuerdo a las garantías de ofrecidas en la recepción de

mensajes de grupo se tienen:

– Orden FIFO: Los mensajes de una misma fuente llegan a cada receptor en el orden que son enviados.

• No hay ninguna garantía sobre mensajes de distintos emisores

– 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

(8)

Sistemas Operativos Distribuidos

Paso de mensajes

•Sockets de Berkeley

Primitivas de paso de mensajes

Operaciones básicas para envío y recepción.

Generalmente, con un modo de operación asíncrono:

–Envíono bloqueante y Recepciónbloqueante

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

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

Cliente-servidor con paso de mensajes

CLIENTE msj envío(msj,dir) msj SERVIDOR msj recepción(msj,dir) Mensaje msj,resp; msj.op=OP1; msj.args=ARGS; envío(msj,dir_servidor);

recepción(&resp, NULL);

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

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)

(9)

Sistemas Operativos Distribuidos

Sockets de Berkeley

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.

Conceptos básicos sobre sockets

• Dominios de comunicación.

• Tipos de

sockets

.

• Direcciones de

sockets

.

• Creación de un

socket

.

• Asignación de direcciones.

• Solicitud de conexión.

• Preparar para aceptar conexiones.

• Aceptar una conexión.

• Transferencia de datos.

1.- Creación del socket

2.- Asignación de dirección 91336

7377

3.- Aceptación de conexión

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.

Algunos ejemplos:

–PF_UNIX(o PF_LOCAL): comunicación dentro de una máquina.

–PF_INET: comunicación usando protocolos TCP/IP.

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_INETse corresponde con el protocolo TCP.

• Datagrama

(SOCK_DGRAM):

– Sin conexión.

– No fiable, no se asegura el orden en la entrega. – Mantiene la separación entre mensajes.

– Si PF_INETse corresponde con el protocolo UDP.

• Raw

(SOCK_RAW):

(10)

Sistemas Operativos Distribuidos

Direcciones de sockets

• 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 (connecto sendto).

• Se utiliza la estructura genérica de dirección:

–struct sockaddr mi_dir;

• Cada dominio usa una estructura específica.

– Uso de casten las llamadas.

– Direcciones en PF_INET(struct sockaddr_in).

– Direcciones en PF_UNIX(struct sockaddr_un).

Direcciones de sockets en PF_INET

Una dirección destino viene determinada por:

– 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:

– Dirección hosty puerto origen.

– Dirección hosty puerto destino.

– Protocolo de transporte (UDP o TCP).

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) •str: cadena a convertir.

• Devuelve la estructura que describe al host.

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

(11)

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.

Solicitud de conexión

Realizada en el cliente por medio de la funció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

Preparar para aceptar conexiones

• 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

(12)

Sistemas Operativos Distribuidos

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.

Aceptar una conexión

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 npor valor o usar memoria dinámica

– flujo principal realiza mallocy threadel free

Múltiples clientes con streams

• Con servidor iterativo no concurrente

– Si 1 conexión por petición

• 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 selectpara esperar simultáneamente la llegada de nuevas

peticiones de conexión o de datos por sockets conectados

• Con servidor concurrente

– 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

Otras funcionalidades

Obtener la dirección a partir de un descriptor:

– Dirección local: getsockname().

– Dirección del socket en el otro extremo: getpeername().

Transformación de valores:

– De formato hosta red:

• Enteros largos: htonl(). • Enteros cortos: htons().

– De formato de red a host:

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

(13)

Sistemas Operativos Distribuidos

Transferencia de datos con streams

• Modo de operación asíncrono

• Envío:

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:

int recv(int s,char *mem,int tam,int flags)

• 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

• Si se requiere leer Nbytes hay que usar un bucle

• No requiere correspondencia entre nº de

send

y de

recv

• Los

flags

implican aspectos avanzados

– como enviar o recibir datos urgentes (out-of-band).

Escenario de uso de sockets streams

Proceso cliente Proceso servidor socket() socket() bind() listen() accept() Posible Ejecución en Paralelo accept() connect() Abrir conexión close() Petición send()/write() Respuesta close() recv()/read() send()/write() recv()/read()

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

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

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 streampor 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 sendtoy de recv/recvfrom

• Se permite

connect

en socket datagrama:

– No realiza conexión física: sólo especifica destino para send/write

– No afecta al servidor pero…

(14)

Sistemas Operativos Distribuidos

Múltiples clientes con datagramas

• Con servidor iterativo no concurrente

– Las peticiones de clientes ya llegan intercaladas

• 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

Escenario de uso de sockets datagrama

Proceso socket() bind() close() Petición sendto() Respuesta recvfrom() Proceso socket() bind() close() recvfrom() sendto()

Uso de datagramas con conexión

Petición Respuesta Proceso socket() bind() close() recvfrom() sendto() Proceso cliente socket() connect() close() send()/write() recv()/read()

Datagramas vs streams

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

– Los mensajes de petición y respuesta son pequeños

• No se puede tolerar la sobrecarga de la conexión • Además, si son grandes hay que fragmentar y compactar

– Las operaciones son idempotentes

• Evita sobrecarga de gestionar cache de respuestas en servidor

– Se quiere dar servicio a un nº muy elevado de clientes

(15)

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

– NivelSOL_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

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