Grado de acoplamiento Modelo cliente/servidor Esquema cliente

Grado de acoplamiento Modelo cliente/servidor Sea cual sea el modelo, conlleva interacción entre entidades Interacción tradicional implica acoplamiento espacial y temporal Desacoplamiento espacial (de referencia) ± Entidad inicia interacción no hace referencia directa a la otra entidad No necesitan conocerse entre sí ± ³9LGDV´GHHQWLGDGHVTXHLQWHUDFFLRQDQno tienen que coincidir Ej. de ambos desacoplamientos: memoria compartida 2 desacoplamientos son independientes entre sí (VWRVPRGRVGHRSHUDFLyQ³LQGLUHFWRV´SURSRUFLRQDQIOH[LELOLGDG David Wheeler (el inventor de la subrutina): ± ³All problems in computer science can be solved by another level of indirection...except for the problem of too many layers of indirection´ Sistemas Distribuidos 1 Fernando Pérez Costoya Esquema cliente/servidor Servidor Respuesta Resp=Código(args) ± Operaciones específicas para cada servicio eQIDVLVHQRSHUDFLRQHV³DFFLRQHV´ ± Mismas ops. para todos servicios pero sobre distintos recursos (REST) Énfasis en recursos: ops. CRUD (HTTP GET, PUT, DELETE, POST) ± Ejemplo: AddBook(nb) vs. PUT /books/ISBN-8448130014 HTTP/1.1 Fernando Pérez Costoya Posibles repartos entre C y S Arquitectura típica de aplicación basada en 3 capas: ± Presentación (interfaz de usuario gráfica: GUI) ± Aplicación: lógica de negocio ± Acceso a datos ± Nada: máquina cliente sólo incluye servidor gráfico (p.e. X11 o VNC) ± Envía a app. eventos ratón/teclado y recibe de app. info. a dibujar en: Píxeles (VNC) o Primitivas gráficas (X11) Sólo GUI GUI + parte de la lógica de negocio GUI + lógica de negocio GUI + lógica de negocio + parte de lógica de acceso Sistemas Distribuidos 5 ± 6HUYLGRU³FXHOORGHERWHOODó problemas de escalabilidad ± Servidor punto crítico de fallo ± Mal aprovechamiento de recursos de máquinas cliente Normalmente, acoplamiento espacial y temporal Servidor ofrece colección de servicios que cliente debe conocer Normalmente, petición especifica recurso, operación y args. ± NFS: READ, file_handle, offset, count ± HTTP: GET /index.html HTTP/1.1 Sistemas Distribuidos 2 Fernando Pérez Costoya ¿Qué parte del trabajo realiza el cliente y cuál el servidor? ³*URVRUGHOFOLHQWH´&DQWLGDGGHWUDEDMRTXHUHDOL]D ± Pesados (Thick/Fat/Rich Client) vs. Ligeros (Thin/Lean/Slim Client) Ventajas de clientes ligeros ± Menor coste de operación y mantenimiento ± Mejor seguridad ± Mayor autonomía ± Mejor escalabilidad Cliente gasta menos recursos de red y de servidor ± Más ágil en respuesta al usuario (M³LQWHOLJHQFLDHQFOLHQWH´-DYDVFULSWYDOLGDOHWUD1,)HQIRUP Sistemas Distribuidos 4 Fernando Pérez Costoya Cliente/servidor con caché Mejora latencia, reduce consumo red y recursos servidor Aumenta escalabilidad ± Mejor operación en SD o La que no usa la red ¿Qué labor de la aplicación se le asigna a máquina cliente? $OWHUQDWLYDVGH³JURVRU´FUHFLHQWH ± ± ± ± Pasivo: responde a petición de servicio Ventajas de clientes pesados Alternativas en diseño de la interfaz de servicio Sistemas Distribuidos 3 Activo: inicia interacción ± Servidor: Proporciona servicio Reparto funcionalidad entre C y S Interfaz de Servicio Petición (args.) Cliente ± Cliente: Solicita servicio Desventajas de arquitectura cliente/servidor Desacoplamiento temporal (menos frecuente) Arquitectura asimétrica: 2 roles en la interacción Fernando Pérez Costoya Necesidad de coherencia: sobrecarga para mantenerla ± ¿Tolera el servicio que cliente use datos obsoletos? SFD normalmente no; pero servidor de nombres puede que sí (DNS) Puede posibilitar modo de operación desconectado ± CODA ± HTML5 Offline Web Applications Pre-fetching: puede mejorar latencia de operaciones pero ± Si datos anticipados finalmente no requeridos: gasto innecesario Para arreglar la falacia 2 hemos estropeado la 3 Sistemas Distribuidos 6 Fernando Pérez Costoya Cliente/servidor con proxy Cliente/servidor jerárquico Componentes intermediarios entre cliente y servidor $FW~DQFRPR³WXEHUtDV´ ± Pueden procesar/filtrar información y/o realizar labor de caché Servidor actúa como cliente de otro servicio ± Igual que biblioteca usa servicio de otra biblioteca División vertical Símil con clases FilterInputStream|FilterOutputStream de Java Funcionalidad dividida en varios niveles (multi-tier) ± P. ej. Aplicación típica con 3 capas: Diversos tipos: forward proxy, reverse proxy, gateways, ... Interfaz de servicio de proxy debe ser igual que el del servidor: ± Proxy se comporta como cliente y servidor convencional ± 6HSXHGHQ³HQJDQFKDU´VXFHVLYRVproxies de forma transparente ± Esta característica es una de las claves del éxito de la Web Presentación Aplicación: lógica de negocio Acceso a datos ± Cada nivel puede implementarse como un servidor División horizontal Múltiples servidores idénticos cooperan en servicio ± Traducir un nombre de fichero en SFD ± Traducir de nombre de máquina a IP usando DNS Sistemas Distribuidos 7 Fernando Pérez Costoya Sistemas Distribuidos 8 Esquema multi-servidor Fernando Pérez Costoya Scale-up vs Scale-out Servidor único: ± Cuello de botella: afecta a latencia y ancho de banda ± Punto único de fallo: afecta a fiabilidad Mejorar prestaciones nodo servidor (escalado vertical: scale-up) ± mejora rendimiento pero no escalabilidad ni tolerancia a fallos Uso de múltiples servidores (interacción M-N) C C ± Escalado horizontal (scale-out) ± Mejora latencia, escalabilidad y tolerancia a fallos ± Requiere esquema de reparto de carga C p p S C C p p S S p C S p C C C S Si servicio requiere datos replicados (p.e. DNS, Google FS) ± Necesidad (y sobrecarga) de mantener coherencia entre las réplicas ± Esquema simétrico: Actualización simultánea en todas las réplicas ± Esquema asimétrico: Actualizar en primario y propagar a secundarios ± Push: primario envía cambios a secundarios ± Pull: secundario solicita cambios a primario Sistemas Distribuidos 9 Fernando Pérez Costoya Código móvil Sistemas Distribuidos 10 Fernando Pérez Costoya Código por demanda Viaja el código en vez de los datos y/o resultados Requiere: ± Arquitecturas homogéneas o ± Interpretación de código o ± Máquinas virtuales Interfaz de Servicio Petición Modelos alternativos Cliente ± Código por demanda (COD) Servidor envía código a cliente P.e. applets Código Servidor Resp=Código(args) ± Evaluación remota (REV) Cliente dispone de código pero ejecución debe usar recursos servidor P.ej. Cyber-Foraging ± Agentes móviles Componente autónomo y activo que viaja por SD Sistemas Distribuidos 11 Fernando Pérez Costoya Sistemas Distribuidos 12 Fernando Pérez Costoya Evaluación remota Localización del servidor Servidor en máquina con dirección DM y usando puerto PS Interfaz de Servicio Petición(args)+Código Cliente Servidor Respuesta Resp=Código(args) ± ¿Cómo lo localiza el cliente? o Binding ± Otro servidor proporciona esa información o problema huevo-gallina Binder: mantiene correspondencias ID servicio o (DM, PS) ± Cliente debe conocer dirección y puerto del Binder Características deseables de ID de servicio: ± ± ± ± ± Ámbito global Mejor nombre de texto de carácter jerárquico (como pathname) Transparencia de ubicación Posible replicación: ID servicio o (DM1, PS1) | (DM2, PS2) .... Convivencia de múltiples versiones del servicio Suele estar englobado en un mecanismo más general ± Servicio de nombres (tema 4): Gestiona IDs de todos los recursos Sistemas Distribuidos 13 Fernando Pérez Costoya Alternativas en la ID del servicio Sistemas Distribuidos 14 Fernando Pérez Costoya (1) ID servicio = [DM+pto] 1. Uso directo de dirección DM y puerto PS ± No proporciona transparencia 2. Nombre servicio + dir servidor (Java RMI Registry, Sun RPC) ± ± Servidor (binder) en cada nodo: nombre de servicio o puerto Impide migración del servidor 3. Nombre de servicio con ámbito global (DCE, CORBA, Mach) ± ± Servidor con ubicación conocida en el sistema Dos opciones: M2 M1 1 C DM2 + ptoS DM2 + ptoS S a) Sólo binder global: nombre de servicio o [DM+PS] b) Opción: binder global (BG) + binder local (BL) en puerto conocido BG: ID o [DM] ; BL: ID o [PS] Uso de caché en clientes para evitar repetir traducción ± Sistemas Distribuidos 15 Fernando Pérez Costoya (2) ID servicio = [DM+idsrv]: Alta Dirección de servicio Info. de contacto Mecanismo para detectar que traducción en caché ya no es válida Sistemas Distribuidos 16 Fernando Pérez Costoya (2) ID servicio = [DM+idsrv]: Consulta M2 M2 Idsrv o ptoS 2 Idsrv o ptoS DM2 + ptoB binder M1 C DM2+idsrv 1 Idsrv o ptoS M2 Binder o ptoB C DM2+idsrv Info. conocida Mensaje Info. binder ¿idsrv? ptoS M2 2 DM2 + ptoS S Binder o ptoB Fernando Pérez Costoya 1 Binder o ptoB DM2 + ptoS S Sistemas Distribuidos 17 DM2 + ptoB binder M1 Binder o ptoB Sistemas Distribuidos 18 Fernando Pérez Costoya (3a) ID servicio = [idsrv]; Sólo BG: Alta (3a) ID servicio = [idsrv]; Sólo BG: Consulta M3 M3 Idsrv o DM2 + ptoS 2 M1 C idsrv idsrvo DM2 + ptoS DM3 + ptoB binder Idsrv o DM2 + ptoS C M2 1 bindero DM3+ptoB DM3 + ptoB binder M1 1 idsrv ¿idsrv? DM2 + ptoS bindero DM3+ptoB M2 2 DM2 + ptoS S DM2 + ptoS S bindero DM3 +ptoB Sistemas Distribuidos 19 Fernando Pérez Costoya (3b) ID servicio = [idsrv]; BG+BL: Alta M1 C M2 Idsrv o ptoS idsrv DM2 + ptoL BL 2 BL o ptoL | BGo DM3+ptoB Idsrv o ptoS M2 1 M3 Idsrv o DM2 BG DM3 + ptoB DM2 + ptoS S 3 4 Idsrv o DM2 BL o ptoL | BGo DM3+ptoB Sistemas Distribuidos 21 Fernando Pérez Costoya Recapitulación del Binding bindero DM3 +ptoB Sistemas Distribuidos 20 Fernando Pérez Costoya (3b) ID servicio = [idsrv]; BG+BL: Consulta BL o ptoL | BGo DM3+ptoB C ¿idsrv? M1 idsrv M2 2 DM2 DM2 + ptoL BL Idsrv o ptoS 1 ¿idsrv? ptoS 3 M2 M3 BG DM3 + ptoB Idsrv o DM2 DM2 + ptoS S BL o ptoL | BGo DM3+ptoB Sistemas Distribuidos 22 Fernando Pérez Costoya Servicio a múltiples clientes Servidor concurrente (p.e. servidor web Apache) Caso con BG y BL + versiones: ± Un flujo de ejecución atiende sólo una petición en cada momento ± Se bloquea esperando datos de ese cliente y envía respuesta ± Servidor: Elige puerto local Informa a binder local del alta: Servidor basado en eventos (p.e. servidor web Nginx) ± (id. servicio + versión) = puerto ± Un flujo de ejecución atiende múltiples peticiones simultáneamente ± Espera (y trata) evento asociado a cualquiera de las peticiones Informa a binder global del alta: ± (id. servicio + versión) = dir máquina Evento: actividad asociada con 1 petición (p.e. llegada datos de cliente) Al terminar, notifica la baja a ambos binder : ± Implementación en UNIX de espera simultánea; alternativas: ± Ambos eliminan (id. servicio + versión) select/poll/epoll; uso de señales de t.real; operaciones asíncronas (aio) ± Para aprovechar paralelismo HW: un flujo de ejecución/procesador ± Cliente: Consulta a binder global Servidor concurrente vs. basado en eventos: ± (id. servicio + versión) o dir. máquina Peor escalabilidad (The C10K problem: http://kegel.com/c10k.html) Consulta a binder en dir. máquina Sobrecarga creación/destrucción/planificación de procesos/threads, más cambios de contexto, más gasto de memoria (p.e. pilas de threads« ± (id. servicio + versión) o puerto 3URJUDPDFLyQPHQRV³RVFXUD´ Sistemas Distribuidos 23 Fernando Pérez Costoya Sistemas Distribuidos 24 Fernando Pérez Costoya Servidor concurrente: alternativas Threads (T) vs. Procesos (P) ± Generalmente threads: Más ligeros y comparten más recursos ± Pero más problemas de sincronización Creación dinámica de T/P según llegan peticiones ± Sobrecarga de creación y destrucción ± 1 operación cliente-servidor conexión, envío de petición, recepción de respuesta, cierre de conexión Conexiones persistentes: N peticiones cliente misma conexión ± Al finalizar trabajo, en espera de más peticiones ± Poca carga o gasto innecesario ± Mucha carga o insuficientes ± Más complejo pero menor sobrecarga ± Esquema usado en HTTP/1.1 (además, pipeline de peticiones) ± Dado que servidor admite nº limitado de conexiones Esquema híbrido con mínimo m y máximo M ± Dificulta reparto de servicio entre clientes ± m pre-arrancados; m T/P M ± Si petición, ninguno libre y nº < M o se crea ± Si inactivo tiempo prefijado y nº > m o se destruye ± Implica que servidor mantiene un estado ± Dificulta reparto de carga en esquema con escalado horizontal ± Facilita server push Fernando Pérez Costoya Evolución de HTTP Sistemas Distribuidos 26 Fernando Pérez Costoya HTTP: conexiones simultáneas Cliente necesita pedir varios objetos al mismo servidor HTTP/1.0 &RQQHFW_*(7_5HVS_&ORVH_&RQQHFW_*(7_5HVS_&ORVH_« Sobrecarga conexiones + latencia de conexiones y peticiones HTTP/1.0 + conexiones persistentes Paralelismo también mediante conexiones simultáneas HTTP/1.0 Connect | GET | Resp | Close ««««««««««« Connect | GET | Resp | Close HTTP/1.0 + conexiones persistentes &RQQHFW_*(7_5HVS_*(7_5HVS_«_&ORVH Latencia de peticiones HTTP/1.1 (conexiones persistentes + pipeline de peticiones) &RQQHFW_*(7_*(7_«_5HVS_5HVS_«_&ORVH No latencia acumulada Servicio paralelo de peticiones &RQQHFW_*(7_5HVS_*(7_5HVS_«_&ORVH ««««««««««« &RQQHFW_*(7_5HVS_*(7_5HVS_«_&ORVH HTTP/1.1 (conexiones persistentes + pipeline de peticiones) &RQQHFW_*(7_*(7_«_5HVS_5HVS_«_&ORVH ««««««««««« &RQQHFW_*(7_*(7_«_5HVS_5HVS_«_&ORVH aunque respuestas deben llegar en orden Sistemas Distribuidos 27 En caso de que se use un esquema con conexión 1 conexión por cada petición ± Más sencillo pero mayor sobrecarga (¡9 mensajes con TCP!) ± Protocolos de transporte orientados a C/S (T/TCP, TCP Fast Open) Conjunto (pool) de N T/P pre-arrancados: Sistemas Distribuidos 25 Gestión de conexiones Fernando Pérez Costoya Sistemas Distribuidos 28 Fernando Pérez Costoya Servicio con/sin estado Client Pull vs Server Push C/S: modo pull ĺFOLHQWH³H[WUDH´GDWRVGHOVHUYLGRU Escenario: servidor dispone de información actualizada P.e. retransmisión web en modo texto de acontecimiento deportivo P.e. servicio de chat basado en servidor centralizado ¿Cómo recibe cliente actualizaciones? Alternativas: Cliente polling periódico al servidor (web: HTTP refresh; Ajax polling) Servidor responde inmediatamente, con nuevos datos si los hay Long Polling: Servidor no responde hasta que tenga datos Server PushVHUYLGRU³HPSXMD´GDWRVKDFLDHOFOLHQWH Cliente mantiene conexión persistente y servidor envía actualizaciones Web: HTTP Server Push, Server-Sent Events, Web Sockets Usar editor/subscriptor en vez de cliente/servidor ¿Servidor mantiene información de clientes? Ventajas de servicio con estado (aka con sesión remota): ± Mensajes de petición más cortos ± Mejor rendimiento (se mantiene información en memoria) ± Favorece optimización de servicio: estrategias predictivas Ventajas de servicio sin estado: ± Más tolerantes a fallos (ante rearranque del servidor) Peticiones autocontenidas. ± Reduce nº de mensajes: no comienzos/finales de sesión. ± Más económicos para servidor (no consume memoria) ± Mejor reparto carga y fiabilidad en esquema con escalado horizontal Servicio sin estado base de la propuesta REST Estado sobre servicios sin estado ± Cliente almacena estado y lo envía al servidor (p.e. HTTP+cookies) Sistemas Distribuidos 29 Fernando Pérez Costoya Sistemas Distribuidos 30 Fernando Pérez Costoya Servicio de ficheros con estado: OPEN C x C S RSHQ³I´ 3 Servicio de ficheros con estado: READ x N | pos 0 23(1³I´ x S read(3,b,t) 3 x x N | ant+tl READ, x, t DATOS, tl (leído) ³I´LQRGR1 Sistemas Distribuidos 31 ³I´LQRGR1 Fernando Pérez Costoya Servicio de ficheros con estado: LSEEK C x x N | pos p LSEEK,x,m=SEEK_SET,p p Fernando Pérez Costoya Servicio de ficheros con estado: CLOSE C S lseek(3,m,p) 3 Sistemas Distribuidos 32 S close(3) 3 - OK ³I´LQRGR1 Sistemas Distribuidos 33 ³I´LQRGR1 Fernando Pérez Costoya Servicio de ficheros sin estado: OPEN C S RSHQ³I´ 3 N | pos 0 Sistemas Distribuidos 34 Fernando Pérez Costoya Servicio de ficheros sin estado: READ C S read(3,b,t) %86&$5³I´ N 3 N | ant+tl READ, N, ant, t DATOS, tl (leído) ³I´LQRGR1 Sistemas Distribuidos 35 - x CLOSE, x Fernando Pérez Costoya ³I´LQRGR1 Sistemas Distribuidos 36 Fernando Pérez Costoya Servicio de ficheros sin estado: LSEEK C Servicio de ficheros sin estado: CLOSE C S lseek(3,m,p) S close(3) 3 N | pos p 3 - ³I´LQRGR1 Sistemas Distribuidos 37 ³I´LQRGR1 Fernando Pérez Costoya Sistemas Distribuidos 38 Aplicaciones de leases Leases Mecanismo para mejorar tolerancia a fallos en SD ± Detección y tratamiento de caídas de nodos Aparecerán a menudo: Binding, caídas del cliente, suscripción en Ed/Su, caché de SFD, etc. Aplicación típica (genérica) de leases: ± Proceso A gestiona algún tipo de recurso vinculado con proceso B Proceso B no tiene por qué contactar de nuevo con A ± 6L%FDH$QRORGHWHFWD\HOUHFXUVRTXHGD³DEDQGRQDGR´ Modo de operación ± ± ± ± Fernando Pérez Costoya A otorga a B un lease que dura un plazo de tiempo B debe enviar a A mensaje de renovación lease antes de fin de plazo Si B cae y no renueva leaseVHFRQVLGHUDUHFXUVR³DEDQGRQDGR´ Si A cae, en reinicio obtiene renovaciones &RQVXILFLHQWHLQIRUPDFLyQSXHGH³UHFRQVWUXLUÓRVUHFXUVRV No confundir con un simple temporizador ± Proceso envía petición a otro y arranca temporizador Leases en servicios con estado Algunos servicios son inherentemente con estado ± P. ej. cerrojos distribuidos Uso de leases en servicio de cerrojos distribuido ± Servidor asigna lease a cliente mientras en posesión de cerrojo ± Clientes en posesión de cerrojos deben renovar su lease ± Rearranque de S: debe procesar primero peticiones de renovación Tiempo de reinicio de servicio > tiempo de renovación ± Reconstrucción automática de estado después de re-arranque de S ± Caída de cliente: falta de renovación Revocación automática de cerrojos de ese cliente Si se cumple antes de ACK, vuelve a enviar petición (lease) Sistemas Distribuidos 39 Fernando Pérez Costoya Serv. cerrojos con estado: leases (1) C1 C2 C3 Sistemas Distribuidos 40 Fernando Pérez Costoya Serv. cerrojos con estado: leases (2) C1 C2 C3 lock(m1) lock(m2) lock(m3) lock(m1) lock(m2) lock(m3) .............. .............. .............. .............. .............. .............. unlock(m1) unlock(m2) unlock(m3) unlock(m1) unlock(m2) unlock(m3) m1 o libre m2 o C2 m3 o libre Sistemas Distribuidos 41 c1 o lock(m1) cola de mensajes de S c2 o lease(m2) S Fernando Pérez Costoya m1 o C1 m2 o C2 m3 o libre Sistemas Distribuidos 42 c1 o lease(m1) cola de mensajes de S c2 o lease(m2) S Fernando Pérez Costoya Serv. cerrojos con estado: leases (3) C1 C2 Serv. cerrojos con estado: leases (4) C3 C1 C2 C3 lock(m1) lock(m2) lock(m3) lock(m1) lock(m2) lock(m3) .............. .............. .............. .............. .............. .............. unlock(m1) unlock(m2) unlock(m3) unlock(m1) unlock(m2) unlock(m3) cola de mensajes de S m1 o C1 m2 o C2 m3 o libre Ø S Sistemas Distribuidos 43 Fernando Pérez Costoya Serv. cerrojos con estado: leases (5) C1 C2 C3 lock(m1) lock(m2) lock(m3) .............. .............. .............. unlock(m1) unlock(m2) unlock(m3) c3 o lock(m3) m1 o C1 m2 o C2 m3 o libre Sistemas Distribuidos 45 cola de mensajes de S S Fernando Pérez Costoya Sistemas Distribuidos 44 ± 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 ops. idempotentes) ± Retransmitir hasta respuesta (servidor se recupere) o fin de plazo ± Usar un sistema de transacciones distribuidas Fernando Pérez Costoya Comportamiento del servicio ante fallos ¿Qué se garantiza con respecto al servicio ante fallos? ± ± ± ± Nada: Servicio puede ejecutar 0 a N veces Al menos una vez (1 a N veces) Como mucho una vez (0 ó 1 vez) Exactamente una vez: Sería lo deseable Operaciones repetibles (idempotentes) ± Cuenta += cantidad (NO) ± Cuenta = cantidad (SÍ) 2SHUDFLyQLGHPSRWHQWHDOPHQRVYH]§H[DFWDPHQWH Tipos de fallos: ± Pérdida de petición o de respuesta (sólo si comunicación no fiable) ± Caída del servidor ± Caída del cliente Sistemas Distribuidos 46 Fallos con comunicación fiable Si cae servidor no siempre puede saber si ejecutado servicio Semántica de como mucho una vez c1 o lease(m1) c3 o lock(m3) cola de mensajes de S c2 o lease(m2) Treinicio>Tlease S Fernando Pérez Costoya Fallos con comunicación no fiable Pérdida de petición/respuesta ± ± ± ± Si no respuesta, retransmisión cuando se cumple plazo Nº de secuencia en mensaje de petición Si pérdida de petición, retransmisión no causa problemas Si pérdida de respuesta, retransmisión causa re-ejecución Si operación idempotente, no es erróneo pero gasta recursos Si no, es erróneo ± Se puede guardar histórico de respuestas (caché de respuestas): Si nº de secuencia duplicado, no se ejecuta pero manda respuesta Caída del servidor ± Si llega finalmente respuesta, semántica de al menos una vez ± Si no llega, no hay ninguna garantía (0 a N veces) Sistemas Distribuidos 47 Fernando Pérez Costoya Sistemas Distribuidos 48 Fernando Pérez Costoya Caída del cliente Modelo editor/subscriptor 0HQRV³WUDXPiWLFD´SUREOHPDGHFRPSXWDFLyQKXpUIDQD ± Gasto de recursos inútil en el servidor Alternativas: Sistema de eventos distribuidos Suscriptor S (subscriber): interés por ciertos eventos (filtro) Editor E (publisher) genera un evento ± Se envía a subscriptores interesados en el mismo ± Uso de épocas: Peticiones de cliente llevan asociadas un nº de época En rearranque de cliente C: transmite (++nº de época) a servidores Servidor aborta servicios de C con nº de época menor ± (GLWRUHV\VXEVFULSWRUHVQRVHFRQRFHQHQWUHVtFOLHQWHVHUYLGRU Normalmente, push: suscriptor recibe evento ± Alternativa, pull: suscriptor pregunta si hay eventos de interés ± Pull requiere que se almacenen eventos (+ complejo) ± Uso de leases: Servidor asigna lease mientras dura el servicio Si cliente no renueva lease se aborta el servicio ± Posibilita mecanismo desacoplado en el tiempo Abortar un servicio no es trivial ± Puede dejar incoherente el estado del servidor (p.e. cerrojos) ± En ocasiones puede ser mejor no abortar Sistemas Distribuidos 49 Paradigma asíncrono y desacoplado en espacio Fernando Pérez Costoya Operaciones modelo editor/subscriptor Facilita uso en sistemas heterogéneos Diversos aspectos relacionados con la calidad de servicio ± RUGHQGHHQWUHJDILDELOLGDGSHUVLVWHQFLDSULRULGDGWUDQVDFFLRQHV« Ejemplos: Mercado bursátil, subastas, chat, app domótica, etc. Sistemas Distribuidos 50 Fernando Pérez Costoya Modelo editor/subscriptor (push) Estructura típica del evento: [atrib1=val1; atrib2=val2; «@ ± Un atributo puede ser el tema del evento suscribe(tipo) [So]: interés por cierto tipo de eventos Su1 suscribe(tipo5) notifica(ev5) Ed1 ± Posible uso de leases en suscripción baja(tipo) [So]: cese del interés publica(evento) [Eo]: generación de evento notifica(evento) [oS]: envío de evento (esquema push) obtiene() [So]: lee siguiente(s) evento(s) (esquema pull) Su2 Su3 suscribe(tipo3) publica(ev5) suscribe(tipo5) notifica(ev5) ± Puede ser bloqueante o no (si no hay eventos, respuesta inmediata) Extensión de modelo: creación dinámica de tipos de eventos ± anuncia(tipo) : se crea un nuevo tipo de evento ± baja_tipo(tipo): se elimina tipo de evento ± notifica_tipo(tipo) [oS]: aviso de nuevo tipo de eventos Sistemas Distribuidos 51 Fernando Pérez Costoya Modelo editor/subscriptor (pull) Su1 Su2 Su3 Su4 suscribe(tipo5) obtiene() Ed1 suscribe(tipo3) publica(ev5) suscribe(tipo5) obtiene() baja(tipo1) Su4 baja(tipo1) Ed2 Ed3 3RVLEOHH[WHQVLyQDQXQFLRGHQXHYRWLSRGHHYHQWRĻ6 Sistemas Distribuidos 52 Fernando Pérez Costoya Filtro de eventos por tema S se subscribe a tema y recibe notificaciones sobre el mismo Temas disponibles: ± Carácter estático: implícitamente conocidos ± Carácter dinámico: uso de operación de anuncio Ej. Creación de un nuevo valor en el mercado Ed2 Ed3 Organización del espacio de temas: ± Plano ± Jerárquico: (Ej. bolsas_europeas/españa/madrid) ± Uso de comodines en suscripción (Ej. bolsas_europeas/españa/*) Filtrados adicionales deben hacerse en aplicación ± Ej. Interesado en valores inmobiliarios de cualquier bolsa española 3RVLEOHH[WHQVLyQDQXQFLRGHQXHYRWLSRGHHYHQWRĻ6 Sistemas Distribuidos 53 Fernando Pérez Costoya Aplicación debe subscribirse a todas las bolsas españolas y descartar todos los eventos no inmobiliarios Sistemas Distribuidos 54 Fernando Pérez Costoya Filtro de eventos por contenido Cliente/servidor vs. Editor/suscriptor Debe cumplirse condición sobre atributos del evento ± Extensión del esquema previo: tema es un atributo del evento 8VRGHOHQJXDMHSDUDH[SUHVLyQGHODFRQGLFLyQ§64/ Filtrado de grano más fino y dinámico que usando temas Cl Ed genera datos genera datos ± Ej. Interés en valores inmobiliarios de cualquier bolsa española Menor consumo de ancho de banda ± Llegan menos datos a nodos subscriptor Simplifica app. subscriptora pero complica esquema Ed/Su ± Puede involucrar varios tipos de eventos de forma compleja ± Ejemplo (Tanenbaum): ± ³Avísame cuando la habitación H420 esté desocupada más de 10 segundos estando la puerta abierta´ Sistemas Distribuidos 55 Fernando Pérez Costoya Implementaciones editor/suscriptor imprime datos almacena datos proyecta datos imprime datos almacena datos proyecta datos Se1 Se2 Se3 Su1 Su2 Su3 ¿En cuál es más fácil añadir nuevo consumidor de datos? ¿Y si queremos que generador sepa cuándo ha procesado datos cada consumidor? Sistemas Distribuidos 56 Fernando Pérez Costoya Implementación ed/su sin intermediario Comunicación directa Su1 No proporciona desacoplamiento espacial Uso de intermediario (broker) Ed1 Su2 Desacoplamiento espacial pero cuello de botella y único punto de fallo Ed2 Uso de red de intermediarios Su3 ± 'LVWULEXFLyQGHHYHQWRV\DSOLFDFLyQGHILOWURV³LQWHOLJHQWH´ Su4 Ed3 Posible uso de comunicación de grupo en cualquiera de ellas ± Ej. Comunicación directa + comunicación de grupo Contacto directo ed./ suscr. Ed/Su basado en temas: tema = dirección de grupo Sistemas Distribuidos 57 p Acoplamiento espacial Fernando Pérez Costoya Implementación ed/su con intermediario Su1 Ed1 Fernando Pérez Costoya Implementación ed/su con red interm. Su1 Int. Su2 Int. Int. Su3 Ed3 Su4 Int. Ed1 Int. Su2 Ed2 Su3 Su4 Sistemas Distribuidos 58 Int. Int. Int. Ed2 Int. Ed3 Proceso intermediario n Desacoplamiento espacial Red de intermediarios p Cuello botella y punto fallo n Desacoplamiento espacial n Escalabilidad y fiabilidad Sistemas Distribuidos 59 Fernando Pérez Costoya Sistemas Distribuidos 60 Fernando Pérez Costoya Paradigmas de comunicación Paso de mensajes MPI ± Comunicación punto a punto 8QLGLIXVLyQGHPHQVDMHVQRSHUVLVWHQWHVVRFNHWV03,« ± Comunicación de grupo 0XOWLGLIXVLyQGHPHQVDMHVQRSHUVLVWHQWHV,6,6-*URXSV« ± Sistemas de colas de mensajes (Message-oriented middleware) Paso de mensajes persistentes /ODPDGDVDSURFHGLPLHQWRVUHPRWRV53&21&'&(« Invocación de métodos remotos (RMI) ± (QWRUQRVGLVWULEXLGRVEDVDGRVHQREMHWRV-DYD50,&25%$« Servicios web o Sistemas orientados a servicios Memoria compartida (tema 5) ± Distributed Shared Memory ± Espacios de tuplas Sistemas Distribuidos 61 API de paso de mensajes Fernando Pérez Costoya Esquemas de direccionamiento Usando número de proceso (MPI): ± En envío: nº proceso destinatario ± En recepción: nº proceso origen; sólo interacción 1 o 1 int MPI_Send(void *buf, int count, MPI_Datatype datatype, int dest, int tag, MPI_Comm comm) int MPI_Recv(void *buf, int count, MPI_Datatype, int source, int tag, MPI_Comm comm, MPI_Status *status) Sockets datagrama ssize_t sendto(int socket, const void *buffer, size_t length, int flags, const struct sockaddr *dest_addr, socklen_t dest_len); ssize_t recvfrom(int socket, void * buffer, size_t length, int flags, struct sockaddr *address, socklen_t * address_len); Esquemas con conexión ± Existen además primitivas para conectar y desconectar ± Operaciones de envío y recepción no incluyen direcciones Sistemas Distribuidos 62 Fernando Pérez Costoya Modos de interacción punto-a-punto nº proceso: 1 o 1 O cualquiera (MPI_ANY_SOURCE): interacción N o 1 ± Difícil asignar nº proceso único en entorno de propósito general Pero no en aplicación ejecutada en entorno de computación paralela puerto: N o 1 Usando puertos: buzón asociado a una máquina (sockets) ± ± ± ± ± Comunicación entre puertos Proceso reserva uso de un puerto de su máquina (bind de sockets) Envío: desde puerto origen local a puerto destino especificados Recepción: de puerto local; interacción N o 1 Sockets INET: ID puerto = dir. IP + nº puerto + protocolo (TCP|UDP) Usando colas: buzón de carácter global; interacción N o N cola: N o N ± Sistemas de colas de mensajes; desacoplamiento espacial+temporal Sistemas Distribuidos 63 Fernando Pérez Costoya Sistemas Distribuidos 64 Especificación del mensaje Con o sin información de tipos (MPI vs. sockets) ± Sin ella: aplicación debe gestionar heterogeneidad ± Con ella: sistema de comunicaciones gestiona heterogeneidad Clases de mensajes (etiquetas) Sistema de comunicación puede gestionar clases de mensajes ± En envío: especifica clase de mensaje enviado ± Recepción: especifica clase de mensaje que se quiere recibir o usa comodín (MPI_ANY_TAG) Zero-Copy 5HGXFLUDOPtQLPR§DFHURFRSLDVHQWUH]RQDVGHPHPRULD Escenario 1: envío de N datos dispersos de emisor a receptor N envíos: sobrecarga de llamada de as + fragmentación de mensajes Reserva de buffer y 1 envío: sobrecarga de copias Funciones scatter/gather: minimizar copias y llamadas ± UNIX: readv, writev, sendmsg, recvmsg Escenario 2: envío de un fichero Uso de operaciones convencionales de lectura y envío Múltiples canales sobre una misma comunicación Diversas aplicaciones como por ejemplo: ± Dos copias de memoria: de buffer de sistema a de usuario y viceversa ± Establecer prioridades entre mensajes ± En cliente-servidor puede identificar operación a realizar ± En editor-subscriptor basado en temas como identificador de tema Disponible en MPI como parámetro de primitivas (tag) No soportado en sockets, aunque sí mensajes urgentes (OOB) Sistemas Distribuidos 65 Fernando Pérez Costoya Fernando Pérez Costoya Uso de proyección de ficheros (mmap) y envío ± Una copia de memoria a buffer de sistema en envío Uso de operaciones de transferencia directa entre descriptores ± No requiere copias entres buffers; reduce nº llamadas al sistema ± Linux: sendfile, splice Sistemas Distribuidos 66 Fernando Pérez Costoya Datos dispersos: Envío múltiple dir1 Datos dispersos: Envío con copia dir1 Envía(dest, dir1, tam1, ...) tam1 tam1 tipo1 dir2 tam2 Envía(dest, dir2, tam2, ...) tipo2 dir3 tam3 dir2 tam2 dir tam tipo1 COPIA Envía(dest, dir, tam, ...) tipo2 Envía(dest, dir3, tam3, ...) dir3 tam3 tipo3 tipo3 Sistemas Distribuidos 67 Fernando Pérez Costoya Datos dispersos: Envío gather Sistemas Distribuidos 68 Fernando Pérez Costoya Datos dispersos: Recepción scatter dir1 dir1 tam1 tam1 tipo1 Envía(dest,dir1,tam1,dir2,tam2,dir3,tam3,...) tipo1 Recibe(org,dir1,tam1,dir2,tam2,dir3,tam3,...) dir2 tam2 dir2 tam2 tipo2 tipo2 dir3 tam3 dir3 tam3 tipo3 tipo3 Sistemas Distribuidos 69 Fernando Pérez Costoya Envío convencional de fichero Sistemas Distribuidos 70 Envío con proyección de fichero Proceso UHDGI« buffer de usuario buffer de sistema Proceso PPDS«I« VHQGV« buffer de usu|sis VHQGV« buffer de sistema buffer de sistema SO Sistemas Distribuidos 71 Fernando Pérez Costoya SO Fernando Pérez Costoya Sistemas Distribuidos 72 Fernando Pérez Costoya Envío zero-copy de fichero Serialización de datos Emisor y receptor misma interpretación de información ± Misma cuestión, y soluciones, para lector y escritor de un fichero Proceso Procesadores, lenguajes, compiladores difieren en: ± ± ± ± ± VHQGILOHIV« buffer de sistema Orden de bytes en tipos numéricos (endian) 7DPDxRGHGDWRVQXPpULFRVHQ&¢WDPDxRGHLQWORQJ«" Strings (con longitud vs. carácter terminador (¿qué carácter?)) Formatos de texto (ISO-8859-1, UTF-« 2UJDQL]DFLyQHVWUXFWXUDVGDWRVFRPSDFWDFLyQDOLQHDPLHQWRV«« 6HQHFHVLWDQ³serializarÓRVGDWRVSDUDHQYLDUDOPDFHQDU ± ± ± ± SO Asegurando misma interpretación en sistema heterogéneo Eficientemente (en serializaciónHQXVRGHUHGGLVFR« Facilitando la programación de la serialización Admitiendo cambios incrementales en protocolo ± P.e. protocolo con nuevo campo opcional pero cliente antiguo sigue OK Sistemas Distribuidos 73 Fernando Pérez Costoya Operación para serializar información en emisor Define cómo se transmiten/almacenan datos (wire protocol) ± Y la operación inversa (unmarshalling) en receptor Secuencia de bits que representan cada dato Con paso de mensajes puede ser: Alternativas: ± Responsabilidad del programador (sockets) ± Sockets tampoco ofrece funciones serialización (excepto para int: htonl« ± Automático (MPI) RPC/RMI lo realizan automáticamente Alternativas: Formato propio vs. Estándar (mejor) Texto vs. binario: menos compacto pero interpretable por usuarios Información de tipos implícita o explícita: ± Implícita: emisor y receptor conocen tipos de parámetros no viaja info. de tipos con datos ± S. de comunicación en emisor convierte a formato de receptor transformar a formato de cualquier receptor ± S. de comunicación en receptor convierte a su formato transformar desde formato de cualquier emisor ± S. de comunicación en emisor convierte a formato externo Sólo transformar de nativo a externo y viceversa ,QHILFLHQWHVLIRUPDWRGHHPLVRU UHFHSWRUSHURGHH[WHUQR Fernando Pérez Costoya Componentes de un s. de serialización No sólo define un wire protocol, además puede incluir: IDL (Interface Definition Language) y API para la serialización Lenguaje IDL para especificar datos a transmitir/almacenar Permite definir datos con independencia de la plataforma Usando, habitualmente, lenguaje específico (véase sección sobre RPC) Compilador IDL: a partir de especificación genera tipos/clases nativos Aplicación usa tipos nativos generados y API para (de)serializar ± Explícita: disponible información explícita de tipos Viaja mezclada con datos o como referencia a un esquema Explícita más flexible (permite reflexión) pero menos compacto Información de nombres de campos implícita vs. explícita: ± Explícita: viaja nombre de campo con datos Puede facilitar cambios incrementales de un protocolo Información explícita de campos y tipos Función de deserialización genérica Sistemas Distribuidos 76 Fernando Pérez Costoya Ejemplos de formatos de serialización XDR (RFC 1832): binario, info. implícita campos y tipos Soluciones basadas XML: texto, inf. explícita campos y tipos ± Info de tipos mediante referencia a XML Schema JSON: texto, info. explícita campos y tipos Protocol Buffers (Google): binario, no explícita campos y tipos ± Pero sí viaja ID único y longitud de cada campo con datos ± Facilita cambios incrementales en protocolo API hipotético para serialización Java Serialization: binario, info. explícita campos y tipos (QFRGHGDWRWLSRĺEXIIHU 'HFRGHEXIIHUWLSRĺGDWR ± Info de campos y tipos mezclada con datos; no requiere IDL Si información de tipos/campos explícita: Decode(buffer) Puede estar integrado en entorno de RPC/RMI ± ¡Buenas noticias!: Programador no realiza serialización ± Código generado usa automáticamente API de serialización Sistemas Distribuidos 77 Fernando Pérez Costoya Formato de serialización de datos Marshalling Sistemas Distribuidos 75 Sistemas Distribuidos 74 Fernando Pérez Costoya 0XFKRVRWURV$61$SDFKH7KULIW$SDFKH$YUR%621« Wikipedia: Comparison data serialization formats Ejemplos: http://laurel.datsi.fi.upm.es/~ssoo/SD.dir/serializacion Sistemas Distribuidos 78 Fernando Pérez Costoya XDR JSON (wikipedia) struct dato {int id; string nombre<>; }; // especificación (fichero .x) struct dato d; XDR x; char buf[TAM]; d.id=1; d.nombre="yo"; xdrmem_create(&x, buf, TAM, XDR_ENCODE); xdr_dato (&x, &d); // serializa write(1, buf, xdr_getpos(&x)); XDR x; int tam; char buf[TAM]; struct dato d = {0, NULL}; tam=read(0, buf, TAM); xdrmem_create(&x, buf, tam, XDR_DECODE); xdr_dato (&x, &d); // deserializa printf("id %d nombre %s\n", d.id, d.nombre); Contenido = 12 bytes: µ\¶µR¶ Sistemas Distribuidos 79 Fernando Pérez Costoya Sistemas Distribuidos 80 Fernando Pérez Costoya Protocol Buffers (con C++) JSON (con Javascript) <!DOCTYPE html><html><body><script> var pers = new Object(); pers.nombre="yo"; pers.tfno=666; var buf = JSON.stringify(pers); // Serializa a {"nombre":"yo","tfno":666} alert(buf); Especificación (fichero .proto) Serialización a un fichero (C++) var p = JSON.parse(buf); // Deserialización genérica alert(p.nombre + " " + p.tfno); </script></body></html> Sistemas Distribuidos 81 Deserialización desde un fichero (C++) Fernando Pérez Costoya Sistemas Distribuidos 82 Fernando Pérez Costoya El precio de un entero (a=150) Java Serialization public class Dato implements Serializable { int id; String nombre; public Dato(int i, String n) {id = i; nombre = n; }} Definición Contenido Formato https://developers.google.com/protocol-buffers/docs/encoding class Encode { static public void main (String args[]) { Dato d = new Dato(1, "yo"); try { ObjectOutputStream o = new ObjectOutputStream(System.out); /* serialización */ o.writeObject(d); o.close(); } catch (java.io.IOException e) { System.err.println("Error serializando");}}} struct dato {int a;}; class Decode { static public void main (String args[]) { try { ObjectInputStream i = new ObjectInputStream(System.in); /* deserialización genérica */ Dato d = (Dato) i.readObject(); i.close(); System.out.println(d.id + " " + d.nombre); } catch (Exception e) { System.err.println("Error deserializando");} }} var d=new Object(); d.a=150; public class D implements Serializable {int a;} 00 00 96 00 ^³D´` 30B XDR JSON Java Contenido = ¡69 B!; http://www.javaworld.com/article/2072752/the-java-serialization-algorithm-revealed.html Sistemas Distribuidos 83 Fernando Pérez Costoya Sistemas Distribuidos 84 Fernando Pérez Costoya Grado de sincronía y buffering Po envía M a Pd: copia entre buffers de procesos: BPo o BPd ± Además puede haber buffers en nodo emisor BNe y/o receptor BNr Posibles buffers en comunicación Minimizar copias entre buffers (ideal: zero copy) Nr Ne De menor a mayor grado de sincronía 1. Envío devuelve control inmediatamente No requiere BNe pero Po no puede reutilizar BPo hasta que sea seguro ± Fin de operación o mensaje copiado en algún buffer (BNe o BNr) BPo BPd R M Requiere operación para comprobar si ya se puede reutilizar 2. Envío devuelve control después de BPo o BNe Po puede reutilizar BPo, pero posible bloqueo si BNe lleno BNr BNe 3. Envío devuelve control cuando M llega a nodo receptor (BNr) No requiere BNe; ACK de Nr a Ne 4. Envío devuelve control cuando M llega a Pd (BPd) No requiere BNe ni BNr; ACK de Nr a Ne 5. Envío devuelve control cuando Pd tiene respuesta No requiere BNe ni BNr: BPo ļ BPd ; respuesta sirve de ACK Sistemas Distribuidos 85 Fernando Pérez Costoya Retorno inmediato Nr BPd M Fernando Pérez Costoya Retorno después de copia local Ne BPo Sistemas Distribuidos 86 Nr Ne BPo BPd M BNe M Sistemas Distribuidos 87 Fernando Pérez Costoya Retorno después de llegada BPd M ACK M Sistemas Distribuidos 89 BNr Fernando Pérez Costoya Retorno después de recepción Nr Ne BPo Sistemas Distribuidos 88 BPo BPd M M ACK M Fernando Pérez Costoya Nr Ne M Sistemas Distribuidos 90 Fernando Pérez Costoya Retorno después de respuesta Modo de operación en recepción Recepción generalmente bloqueante Opción no bloqueante: retorna si no hay datos Opción asíncrona: Nr Ne ± Especifica buffer donde se almacenará el mensaje y ± Retorna inmediatamente ± S. comunicaciones realiza recepción mientras proceso ejecuta BPd R/M BPo M/R R Espera temporizada: se bloquea un tiempo máximo Espera múltiple: espera por varias fuentes de datos M Sistemas Distribuidos 91 Fernando Pérez Costoya Sockets: grado de sincronía y buffering Paso de mensajes adecuado para cualquier arquitectura ± Retorno después de copia local con bloqueo si buffer local lleno ± Buffer reservado por SO Si aplicación no quiere bloquearse en envío: ± Usar modo no bloqueante en descriptor socket: error si buffer lleno ± Usar select/poll/epoll para comprobar que envío no bloquea ± Usar E/S asíncrona (aio_write): modo de envío tipo 1 Espera múltiple temporizada mediante select/poll/epoll Paso de mensajes y arquitecturas E/S pull S resp. susc.| cons. resp. recibo envío envío recibo susc. ev. X notif. ev. Y recibo envío ± Si pull con intermediario I: buen encaje Su envía suscripción(evento X) y espera confirmación de I Pero justo antes I envía notificación de evento Y a Su Soluciones: uso de múltiples puertos y concurrencia en subscriptor P2P: arquitectura simétrica Sistemas Distribuidos 94 Fernando Pérez Costoya Multidifusión: comunicación de grupo Destino de mensaje o grupo de procesos petic. envío recibo Editor/subscriptor: su asimetría no siempre encaja con p. mens. ± ¿Quién envía y quién recibe? Fernando Pérez Costoya envío recibo ± Cliente: envía petición y recibe respuesta ± Servidor: recibe petición y envía respuesta ± Si push con intermediario I: encaje problemático ± Usar modo no bloqueante en descriptor socket: error si buffer vacío ± Usar select/poll/epoll para comprobar que hay datos que recibir ± Usar E/S asíncrona (aio_read) Sistemas Distribuidos 93 ± Pero cuidado con su asimetría: uno envía y otro recibe Cliente/servidor: su asimetría encaja con la del paso mensajes 6X_(GHQYtDQRSVD,\UHFLEHQUHVSXHVWDVGH,ĺ,VLHPSUHSDVLYR Modo de operación de recepción bloqueante Si aplicación no quiere bloquearse en recepción: C Fernando Pérez Costoya Adecuación a arquitecturas del SD Modo de operación de envío tipo 2 C/S Sistemas Distribuidos 92 I notif resp. recibo S envío OK ± Envío/recepción especifican dirección de grupos de procesos ± Desacoplamiento espacial envío recibo OK Trabajo seminal: ISIS (posteriores Horus, Ensemble, JGroups) Adecuación a arquitectura del SD: E ± Cliente-servidor replicado Facilita actualizaciones múltiples E/S push S P2P P1 envío recibo petic. recurso A I notif. ev. Y envío recibo E Ļ ± Modelo editor/subscriptor Envío de notificaciones (p.e. 1 grupo/tema) ± Arquitecturas para CD Operaciones colectivas en proc. paralelo (pueden incluir cálculos) petic. recurso B envío P2 recibo Ļ Implementación depende de si red tiene multicast (IP-multicast) ± Si no, se implementa enviando N mensajes Un proceso puede pertenecer a varios grupos (grupos solapados) Sistemas Distribuidos 95 Fernando Pérez Costoya Sistemas Distribuidos 96 Fernando Pérez Costoya Aspectos de diseño de com. de grupo Orden FIFO P1 Atomicidad: o reciben 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 ± FIFO: mensajes de misma fuente llegan en orden de envío m4 m2 m1 P2 m3 No garantía sobre mensajes de distintos emisores ± CausalHQWUHJDUHVSHWDUHODFLyQ³FDXVD-HIHFWR´ Si no hay relación, no garantiza ningún orden de entrega ± Total: Todos los mensajes recibidos en mismo orden por todos P3 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 P4 3URSLHGDGGHQRPLQDGD³Virtual Synchrony´ Sistemas Distribuidos 97 Fernando Pérez Costoya Sistemas Distribuidos 98 Mantenimiento de orden FIFO Nodo Ni almacena vector de contadores Vi (1 posición/nodo) Mantenimiento de orden FIFO P1 ± Vi[i] : nº último mensaje enviado por Ni ± 9L>M@MLQ~OWLPRPHQVDMHGH1MUHFLELGRSRU1L Ni envía mensaje M que incluye contador Cm: Fernando Pérez Costoya P2 ± Vi[i]++; Cm=Vi[i] 0000 1000 1 m1 0000 2000 2 1000 3 m2 3000 m4 1 2000 2100 3100 m3 Nj recibe mensaje M de Ni ± No se entrega M si Cm > Vj[i] + 1 No han llegado todavía mensajes previos de Ni Retenido hasta que lleguen mensajes de Ni que faltan [Vj[i] + 1, Cm) P3 0000 1000 2000 3000 3100 ± En entrega: Vj[i]=Cm P4 2000 0000 mensaje entregado Sistemas Distribuidos 99 Fernando Pérez Costoya Orden causal P1 m1 P2 m2 2100 3100 mensaje retenido Sistemas Distribuidos 100 Fernando Pérez Costoya Mantenimiento de orden causal m3 Nodo Ni almacena vector de contadores Vi (1 posición/nodo) m4 Ni envía mensaje M que incluye vector Vm: ± Vi[i] : nº último mensaje enviado por Ni ± 9L>M@MLQ~OWLPRPHQVDMHGH1MUHFLELGRSRU1L ± Vi[i]++; Vm = Vi Nj recibe mensaje M de Ni: No se entrega M a Nj si ± O bien Vm[i] > Vj[i] + 1 No han llegado todavía mensajes previos de Ni (FIFO causal) Retenido hasta que lleguen mensajes de Ni que faltan [Vj[i] + 1, Vm[i]) P3 ± O bien NNLWDOTXH9P>N@!9M>N@ No han llegado todavía mensajes de Nk que ya ha recibido Ni Retenido hasta que lleguen mensajes de Nk que faltan [Vj[k] +1 , Vm[k]] ± En entrega: Vj[i]=Vm[i] P4 %DVDGRHQYHFWRUHVGHUHORMHVOyJLFRVWHPD³VLQFURQL]DFLyQ´ Sistemas Distribuidos 101 Fernando Pérez Costoya Sistemas Distribuidos 102 Fernando Pérez Costoya Mantenimiento de orden causal P1 P2 P3 0000 0000 0100 1100 1100 m1 m2 m4 1100 1200 1200 0100 0100 0000 m3 2100 2100 0100 1100 P1 2200 m2 P2 2200 1200 m1 2200 1100 P4 0000 1100 Orden total 1200 2200 Sistemas Distribuidos 103 Fernando Pérez Costoya Mantenimiento de orden total Por simplicidad, sólo solución basada en secuenciador S ± 6³FXHOORGHERWHOOD´\SXQWR~QLFRGHIDOOR P3 P4 Sistemas Distribuidos 104 MOM ² Sistemas de colas de mensajes Message-oriented middleware: WebSphere MQ, MSMQ, JMS AMQP protocolo estándar para MOM Proceso S en el sistema asigna número único a cada mensaje ± S gestiona contador creciente Cs para cada grupo (QYtRUHFHSFLyQPHQVDMHVDFRODVFRQFRPXQLF³SHUVLVWHQWH´ ± &RPXQLFDFLyQ³FRQYHQFLRQDO´ Ni envía mensaje de datos M: a todos miembros grupo G + S ± Mensaje de datos M no incluye contador; sólo algún tipo de ID de M Destinatario debe estar presente cuando se recibe mensaje ± &RPXQLFDFLyQ³SHUVLVWHQWH´ No es necesario que proceso receptor esté presente Sistema de comunicación (p.e. red de intermediarios) guarda mensaje Recepción de M en S: ± Cs++; asigna Cs a M ± Envía a miembros G mensaje especial Ms = {ID de M, Cs} Nodo Ni incluye Ci: nº próximo mensaje Ms que espera recibir Recepción de M en Ni: siempre se retiene Recepción de Ms = {ID de M, Cs} en Ni: ± Ms retenido hasta que recibido M y Cs == Ci o entrega de M Sistemas Distribuidos 105 Fernando Pérez Costoya Fernando Pérez Costoya Sistema de colas de mensajes Comunicación desacoplada en espacio y tiempo API típico: ± ± ± ± SEND: envía mensaje a cola RECEIVE: recibe mensaje de cola (bloqueante) POLL: recibe mensaje de cola (no bloqueante) NOTIFY: proceso pide ser notificado cuando llegue mensaje a cola Sistemas Distribuidos 106 Fernando Pérez Costoya MOM ² Sistemas de colas de mensajes 2 modelos de comunicación habituales: ± Basado en colas punto-a-punto ± Basado en temas editor/subscriptor Adecuación a arquitecturas de SD ± C/S: punto-a-SXQWRĺPXOWL-servidor con reparto automático de carga ± Ed/Su: modelo basado en temas; NOTIFY permite esquema push Características avanzadas habituales: ± Filtrado de mensajes: receptor selecciona en cuáles está interesado por propiedades, por contenido,... Puede usarse como filtro por contenido en arquit. Ed./Su. ± Mensajería con transacciones ± Transformaciones de mensajes Distributed Systems: Concepts and Design. G. Coulouris et al. Sistemas Distribuidos 107 Fernando Pérez Costoya Apropiado para integración de aplicaciones de empresa (EAI) Sistemas Distribuidos 108 Fernando Pérez Costoya Página 1 de 2 Curso 2014/2015. Segundo semestre Una nueva empresa, denominada Everybody's Talkin', proporciona un servicio de chat organizado en canales (o salas), cada uno generalmente dedicado a un cierto asunto de conversación. Este servicio sigue un esquema editor-subscriptor basado en temas, donde cada tema corresponde a una sala, y con un único proceso intermediario. El servicio consta de tres módulos software: E, instalado en las máquinas de la empresa, U, la aplicación que utilizan los usuarios para tener acceso al servicio, y O, la aplicación destinada a otras empresas que les permite espiar las conversaciones. La aplicación gráfica U presenta inicialmente la lista de salas disponibles (operación no contemplada en el ejercicio), tal que si el usuario selecciona una de ellas (OP1), se abre una ventana de texto (tendrá tantas ventanas abiertas como salas haya elegido), de manera que cada línea que escribe el usuario en esa ventana (OP2) aparecerá en las ventanas de texto del resto de los usuarios conectados a ese canal (OP3) y viceversa, hasta que el usuario cierre esa ventana (OP4). El objetivo real de la empresa es proporcionar un marco donde la gente se sienta relajada para intercambiar libremente opiniones para, de esta manera, ofrecer a otras empresas la posibilidad de espiar estas conversaciones, ya sea para vender a los usuarios más propicios sus productos o por otras razones más oscuras. A estas otras empresas, previo pago, se les ofrece la aplicación O que proporciona la posibilidad de hacer un seguimiento sofisticado de múltiples aspectos como, por ejemplo, detectar cuando algún usuario escribe una determinada palabra. 1. ¿Qué módulos realizan el papel de subscriptores? a. U y O b. Sólo U c. Sólo O d. E Explicación El módulo U realiza el rol de subscriptor puesto que está interesado en ser notificado de lo que escriben otros usuarios en los canales a los que se ha subscrito. El módulo O también hace ese mismo papel de subscriptor ya que necesita espiar las conversaciones que se producen en el sistema lo que requiere ser notificado del contenido de las mismas. 2. ¿Qué módulos realizan el papel de editores? a. Sólo U b. U y O c. Sólo O d. E Explicación El módulo U realiza el rol de editor puesto que todo lo que escribe un usuario conectado a un canal debe llegar a todos los otros usuarios asociados al mismo. 3. ¿Qué módulos realizan el papel de proceso intermediario? a. E b. Sólo U c. Sólo O d. U y O Explicación El proceso E debe incluir la funcionalidad de la distribución de la información que escribe un usuario en un canal al resto de los usuarios conectados al mismo. Por tanto, realiza el papel de intermediario. 4. ¿Qué acción implica OP1? a. subscripción b. baja c. publicación d. notificación Explicación La operación OP1 permite que un usuario entre en un canal. Por tanto, corresponde a una operación de subscripción. 5. ¿Qué acción implica OP2? a. publicación b. baja c. subscripción d. notificación Explicación La operación OP2 permite a un usuario de un canal introducir una línea de texto que deberá ser comunicada a todos los usuarios actuales de ese canal. Se trata, por tanto, de una operación de publicación. 6. ¿Qué acción implica OP3? a. notificación b. baja c. publicación d. subscripción Explicación En la operación OP3, la ventana asociada a un canal de un determinado usuario se actualiza para mostrar una línea de texto escrita por otro usuario de ese canal, correspondiéndose, por tanto, con una operación de notificación. 7. ¿Qué acción implica OP4? a. baja b. subscripción c. publicación Página 2 de 2 d. notificación Explicación El cierre de la ventana asociada a un canal conlleva la baja en el tema asociado a ese canal. 8. Suponiendo que se usa un esquema de binding, ¿qué módulos deben darse de alta en el mismo? a. E b. U y O c. Sólo U d. Sólo O Explicación El único proceso que debe de darse de alta en el binder es el proceso intermediario (E) puesto que el resto de los procesos deben llegar a conocer su dirección. 9. Suponiendo que se usa un esquema de leasing para mejorar la tolerancia a fallos del esquema editor/subscriptor, ¿qué módulos deben renovar el lease? a. U y O b. E c. Sólo U d. Sólo O Explicación Cuando se aplica un mecanismo de leasing en un esquema editor-subscriptor, son los subscriptores los encargados de enviar el mensaje de renovación. Por tanto, se trata de los procesos U y O. 10. Para la aplicación O, se plantea usar un esquema con un filtro de eventos por contenido en vez de un filtro por temas. ¿Para cuál de estos casos ese cambio sería más ventajoso en el sentido de reducir el número de mensajes recibidos pero no deseados por O? a. Interés en cuando un determinado usuario escribe en cualquier sala una determinada palabra. b. Interés en cuando cualquier usuario escribe en una determinada sala una determinada palabra. c. Interés en cuando un determinado usuario escribe en una determinada sala una determinada palabra. d. Interés en cuando cualquier usuario escribe en alguna sala incluida en un determinado conjunto de salas una determinada palabra. Explicación Veamos cada caso planteado analizando en cuál el uso de un filtro por contenido sería más efectivo (es decir, descartaría más eventos no deseados). • En el caso de estar interesado en ser notificado cuando cualquier usuario escribe una determinada palabra en una sala dada, el subscriptor tendría que suscribirse al tema asociado a esa sala y descartar todos los eventos que no incluyan esa palabra. • En cuanto al caso de estar interesado en ser notificado cuando un cierto usuario escribe una determinada palabra en una sala dada, el subscriptor tendría que suscribirse al tema asociado a esa sala y descartar todos los eventos que correspondan a texto escrito por otros usuarios o que, estando escritos por el usuario especificado, no incluyan esa palabra. • Con respecto al caso de estar interesado en ser notificado cuando cualquier usuario escribe una determinada palabra en alguna sala incluida en un determinado conjunto de salas determinado, el subscriptor tendría que suscribirse a los temas correspondientes a esas salas y descartar todos los eventos que no incluyan esa palabra. • Por lo que se refiere al caso de estar interesado en ser notificado cuando un cierto usuario escribe una determinada palabra en cualquier sala, el subscriptor tendría que suscribirse a todas las salas y descartar todos los eventos que correspondan a texto escrito por otros usuarios o que, estando escritos por el usuario especificado, no incluyan esa palabra. El uso de un filtro por contenido especificando como función que el usuario sea una determinada persona y que la línea escrita contiene esa palabra dada sería más beneficioso que en los casos previos puesto que el número de eventos que se descartan va a ser mayor (nótese que en este caso, con un filtro por temas, el subscriptor tendría que recibir todos los eventos del sistema). 11. Suponiendo un esquema push y que no se usa un mecanismo de leasing, ¿cuántos tipos de mensajes diferentes enviaría U a E? a. 3 b. 1 c. 2 d. 4 Explicación Teniendo en cuenta que este módulo actúa como editor y subscriptor, enviará los siguientes mensajes: 1. Alta en una subscipción. 2. Baja de una subscipción. 3. Generar un evento. 12. Suponiendo un esquema pull y que no se usa un mecanismo de leasing, ¿cuántos tipos de mensajes diferentes enviaría O a E? a. 3 b. 1 c. 2 d. 4 Explicación Teniendo en cuenta que este módulo sólo actúa como subscriptor y usa un esquema pull, enviará los siguientes mensajes: 1. Alta en una subscipción. 2. Baja de una subscipción. 3. Obtener el próximo evento. Página 1 de 4 Curso 2014/2015: primer semestre Una nueva empresa, denominada TeLoContamos, se va a dedicar a la retransmisión en directo de todo tipo de espectáculos basándose en la información generada en tiempo real por los reporteros de la empresa destinados a cada espectáculo. Los usuarios que contraten este servicio dispondrán de una aplicación (U) que instalarán en sus equipos. Esta aplicación permitirá a un usuario seleccionar (operación OPU1) cualquiera de los espectáculos que se estén retransmitiendo en ese momento (puede tener seleccionados varios simultáneamente), recibiendo a partir de entonces toda la información generada por los reporteros que cubren el mismo, hasta que el usuario indique que ya no está interesado en él (OPU2). Para realizar las retransmisiones, cada reportero de la empresa tendrá instalada en su dispositivo portátil una aplicación (R) que le permitirá iniciar la retransmisión (OPR1) de un determinado espectáculo, enviar comentarios sobre el mismo (OPR2) y terminar esa retransmisión (OPR3), pudiendo estar cubriendo un mismo reportero varios espectáculos simultáneamente. Por otro lado, dado que puede haber varios reporteros cubriendo un mismo espectáculo, para que esta retransmisión simultánea sea coherente y la información generada por los reporteros se complemente, cuando un reportero seleccione el inicio de la retransmisión de un determinado espectáculo (OPR1), comenzará a recibir también la información generada por los otros reporteros que cubren dicho espectáculo, y esto seguirá hasta que el reportero indique que ha finalizado su retransmisión (OPR3). Por último, en la sede de la empresa estará instalado el software (E) requerido para proporcionar esta funcionalidad. A la hora de desarrollar esta aplicación distribuida se barajan dos posibles arquitecturas. Como primera opción, una arquitectura editor/subscriptor basada en temas, donde cada espectáculo es un tema, pudiéndose optar por un esquema push (ESH) o pull (ESL). Como alternativa, se plantea un esquema cliente/servidor donde E actúa como servidor (no puede iniciar peticiones de conexión; sólo las acepta), mientras que U y R actúan como clientes (realizan peticiones de conexión usando una conexión por cada operación; no aceptan peticiones de conexión), distinguiéndose entre un esquema con estado (CSE) y uno sin estado (CSS). 1. ¿Qué módulo realiza el papel de subscriptor? a. U y R b. U c. R d. E Explicación Tanto U, cuando un usuario selecciona un espectáculo, como R, cuando un reportero inicia una transmisión, están interesados en ser notificados de los comentarios pertinentes en cada caso. Por tanto, desempeñan el papel de subscriptores. 2. ¿Qué módulo realiza el papel de editor? a. R b. U y R c. U d. E Explicación El módulo R realiza el papel de editor publicando los comentarios del reportero que lo usa. 3. ¿Qué módulo realiza el papel de proceso intermediario? a. E b. U y R c. U d. R Explicación El módulo E instalado en la empresa incluye la funcionalidad de la distribución de los comentarios que recibe a los subscriptores interesados en los mismos. Por tanto, realiza el papel de intermediario. 4. ¿Qué solución proporciona al usuario mayor inmediatez en la visibilidad de la información retransmitida? a. ESH b. ESL c. CSE d. CSS Explicación La solución ESH proporciona mayor inmediatez, puesto que en la misma el módulo E envía inmediatamente los comentarios a los interesados, mientras que tanto en ESL como en las soluciones cliente-servidor, el interesado debe realizar una consulta periódica a E para obtener los eventos. 5. ¿Qué solución no requiere almacenar en E los comentarios que generan los reporteros? Página 2 de 4 a. b. c. d. ESH ESL CSE CSS Explicación En ESH, al retransmitir E inmediatemente los comentarios, no es necesario que los almacene. En cambio, en las otras tres soluciones sí se requiere puesto que hay que guardarlos hasta que los interesados los soliciten. 6. ¿Para qué solución tendría menos sentido proporcionar en la aplicación U un botón para actualizar la información de las retransmisiones presentada hasta el momento? a. ESH b. ESL c. CSE d. CSS Explicación En las soluciones basadas en un sondeo periódico, puede ser conveniente incluir en U un botón de actualización para forzar una consulta inmediata sin esperar a que se cumpla el periodo de sondeo. Dada la inmediatez del ESH, no se requiere esta funcionalidad. 7. ¿Qué solución tendría mayor tolerancia de fallos ante el reinicio de E, de manera que, aunque se pueda perder algún comentario, los usuarios puedan recuperar inmediatamente el servicio? a. CSS b. ESL c. ESH d. CSE Explicación En las soluciones editor/subscriptor, el reinicio de E, que actúa de proceso intermediario en este caso, dejaría sin servicio a los usuarios actuales puesto que se habrá perdido toda la información de subscripción. En el caso de CSE, tampoco podría reanudarse inmediatemente el servicio, ya que E guarda información de estado de los usuarios (como, por ejemplo, cuál fue el último evento recogido por un proceso interesado en un determinado espectáculo). Sin embargo, la solución CSS no requiere ninguna información de estado en el servidor usando para ello peticiones autocontenidas (en el ejemplo, la información sobre el último evento recibido por un cliente viajaría en la propia petición) lo que permite que continúe inmediatamente el servicio a los clientes después de un reinicio de E. 8. ¿En la solución editor/subscriptor, qué acción implica OPU1 en U? a. subscripción b. baja c. publicación d. notificación Explicación La subscripción al espectáculo seleccionado por el usuario de U. 9. ¿En la solución editor/subscriptor, qué acción implica OPU2 en U? a. baja b. subscripción c. publicación d. notificación Explicación La baja de la subscripción previa al espectáculo seleccionado por el usuario de U. 10. ¿En la solución editor/subscriptor, qué acción implica OPR1 en R? a. subscripción b. baja c. publicación d. notificación Explicación Dado que cuando un reportero inicia una retransmisión de un determinado espectáculo debe ser notificado de los comentarios que realizan los reporteros que también lo retransmiten, OPR1 causará la subscripción a dicho espectáculo. Página 3 de 4 11. ¿En la solución editor/subscriptor, qué acción implica OPR2 en R? a. publicación b. baja c. subscripción d. notificación Explicación OPR2 envía el comentario escrito por el reportero, por lo que se trata de una acción de publicar en un modelo editorsubscriptor. 12. ¿En la solución editor/subscriptor, qué acción implica OPR3 en R? a. baja b. subscripción c. publicación d. notificación Explicación Al finalizar una retransmisión de un espectáculo, se dará de baja de la subscripción del mismo. 13. ¿En qué solución OPU2 no requeriría contactar con E? a. CSS b. ESL c. ESH d. CSE Explicación En las soluciones editor/subscriptor, OPU2 contacta con E para darse de baja del tema. En CSE, en esta operación, U contacta con E para indicarle que ha terminado el seguimiento de ese espectáculo, lo que permitiría que E libere el estado almacenado asociado al mismo. Sin embargo, en CSS, dado que no hay ningún estado asociado al cliente almacenado en el servidor, no es necesario que contacte con el mismo. 14. Evidentemente, el servicio debe garantizar que un usuario no reciba repetido ningún comentario. ¿En qué solución esto requeriría que U almacenara, e incluyera en los mensajes correspondientes, la marca de tiempo del último evento recibido de cada espectáculo seleccionado? a. CSS b. ESL c. ESH d. CSE Explicación Los esquemas editor/subscriptor garantizan que no se duplican eventos, por lo que no es necesario que los subscriptores almacenen ningún tipo de información. En CSE, el estado que almacena el servidor le permite saber cuál es el último evento que ha recogido un cliente. Sin embargo, en CSS, al no disponer de ninguna información de estado de los clientes, es necesario que éstos almacenen esta información y la envíen en sus mensajes de petición. 15. ¿De qué proceso necesitan conocer a priori su puerto el resto de los procesos en la solución cliente/servidor? a. Sólo de E b. De U y de R c. Sólo de U d. Sólo de R Explicación En un esquema cliente/servidor, la única dirección que debe ser conocida a priori es la del servidor. 16. ¿De qué proceso necesitan conocer a priori su puerto el resto de los procesos en la solución editor/subscriptor? a. Sólo de E b. De U y de R c. Sólo de U d. Sólo de R Explicación En un esquema editor/subscriptor, la única dirección que debe ser conocida a priori es la del proceso intermediario. 17. Suponiendo que se usa un esquema de leasing para mejorar la tolerancia a fallos de la solución editor/subscriptor, ¿qué proceso otorgará el lease? a. E Página 4 de 4 b. U y R c. U d. R Explicación Cuando se aplica un mecanismo de leasing en un esquema editor-subscriptor, es el proceso intermediario el encargado de otorgar los leases siendo los subscriptores los que lo renuevan. 18. Suponiendo que se usa un esquema de leasing para mejorar la tolerancia a fallos de la solución cliente/servidor con estado, ¿qué proceso otorgará el lease? a. E b. U y R c. U d. R Explicación Cuando se aplica un mecanismo de leasing en un esquema cliente-servidor con estado, es el proceso servidor el encargado de otorgar los leases siendo los clientes los que lo renuevan. 19. Para la solución editor/subscriptor, se plantea usar un esquema con un filtro de eventos por contenido en vez de un filtro por temas. ¿Para cuál de estos casos ese cambio sería más ventajoso en el sentido de reducir el número de notificaciones no deseadas? a. Interés en todas las retransmisiones de un determinado reportero. b. Interés en todas las retransmisiones. c. Interés en un cierto espectáculo pero sólo en los comentarios de un determinado grupo de reporteros. d. Interés en un cierto conjunto de espectáctulos pero sólo en los comentarios de un determinado reportero. Explicación Veamos cada caso planteado analizando, en primer lugar, si el uso de un filtro por contenido tendría alguna ventaja en ese caso y, si hay varios en los que sí, en qué caso sería más efectivo (es decir, descartaría más eventos no deseados). • En el caso de estar interesado en todas las retransmisiones, no hay ningún beneficio en usar un filtro por contenido puesto que está interesado en todos los eventos, no teniendo que descartar ninguno. • Por lo que se refiere al caso de estar interesado en un espectáculo dado pero sólo en los comentarios de un grupo de reporteros, el subscriptor tendría que suscribirse al tema asociado a ese espectáculo y descartar todos los eventos que no estén vinculados con uno de los reporteros de interés. El uso de un filtro por contenido especificando como función que el escritor del comentario pertenezca a ese grupo de reporteros sería, por tanto, beneficioso ya que descartaría todos los demás eventos. • En cuanto al caso de estar interesado en los comentarios que haga un determinado reportero sobre un conjunto de espectáculos concreto, el subscriptor tendría que suscribirse a los temas asociados a esos espectáculos y descartar todos los eventos que no estén vinculados con ese reportero de interés. El uso de un filtro por contenido especificando como función que el escritor del comentario sea ese reportero sería, por tanto, beneficioso ya que descartaría todos los demás eventos. • Con respecto al caso de estar interesado en los comentarios que haga un determinado reportero sobre cualquier espectáculo, el subscriptor tendría que suscribirse a todos los temas (espectáculos) y descartar todos los eventos que no estén vinculados con ese reportero de interés. El uso de un filtro por contenido especificando como función que el escritor del comentario sea un determinado reportero sería más beneficioso que en los casos previos puesto que el número de eventos que se descartan va a ser mayor. 20. Suponga que se crea para la solución editor/subscriptor con esquema push una jerarquía de temas (por ejemplo, para expresar el interés en todos los partidos de tenis del torneo de Wimbledon que se estén retransmitiendo en ese instante se usaría deportes/tenis/wimbledon/*). ¿Podría aumentar o diminuir el número de operaciones de subscripción (S) y el de notificaciones (N) si se usa el esquema jerárquico en vez de uno plano? a. Menos S b. Más S c. Menos N d. Más N Explicación El uso de un tema de más alto nivel en la subscripción va a permitir poder usar una única operación de subscripción en vez de tener que suscribirse a cada uno de los temas de nivel inferior incluidos en el mismo. Por tanto, se va a reducir el número de mensajes requeridos para esta operación de subscripción. Por otro lado, ya sea usando una subscripción de alto nivel o las de bajo nivel equivalentes, el número de notificaciones será el mismo. Página 1 de 4 Curso 2013/2014: segundo semestre. Primera parte Una agencia de noticias internacional (proceso de tipo A) proporciona un servicio de distribución de noticias. La agencia tiene contratados reporteros (proceso de tipo R) en el todo el mundo para recoger noticias in situ. Asimismo, la agencia tiene dos tipos de clientes: medios de comunicación (proceso de tipo M), interesados en algunas de las noticias que distribuye la agencia, y agencias de noticias locales (proceso de tipo L), que, además de estar interesados en algunas de las noticias de la agencia internacional, le suministran noticias locales a la agencia de noticias internacional. El servicio está basado en un esquema editor-subscriptor con un filtro de eventos por tema organizado jerárquicamente en niveles (por ejemplo, el tema Internacional corresponde a las noticias internacionales de los cinco continentes, mientras que Internacional/Asia sólo incluye las que se han producido en ese continente). 1. ¿Qué tipos de procesos realizan el papel de subscriptores? a. M y L b. R y L c. A y L d. A y R Explicación Los dos tipos de clientes (es decir, los medios de comunicación y las agencias de noticias locales) están interesados en ser notificados de las noticias que les puedan interesar. Por tanto, desempeñan el papel de subscriptores. 2. ¿Qué tipos de procesos realizan el papel de editores? a. R y L b. M y L c. A y L d. A y R Explicación Tanto los reporteros como las agencias locales de noticias pueden enviar noticias a la agencia de noticias internacional. Por tanto, desempeñan el papel de editores. 3. ¿Qué tipo de proceso realiza el papel de intermediario? a. A b. R c. M d. L Explicación La aplicación de la agencia internacional incluye la funcionalidad de la distribución de las noticias que recibe a los clientes que puedan estar interesados en las mismas. Por tanto, realiza el papel de intermediario. 4. Algunos procesos tienen que conocer la dirección (IP + puerto) de otros procesos. De las 12 combinaciones posibles (A tiene que conocer la dirección de R; R la de A; A la de M; etc.), ¿cuántas se requieren? a. 3 b. 4 c. 5 d. 6 Explicación En un esquema editor-subscriptor, tanto los subscriptores como los editores tienen que conocer la dirección del intermediario. Por tanto, los procesos G, M y L tienen que saber la dirección de A. 5. El uso de un tema de primer nivel en vez del conjunto de temas de segundo nivel equivalente permite reducir el número de mensajes: a. De M a A b. De R a A. c. De A a M. d. De A a L. Explicación El uso de un tema de alto nivel en la subscripción (como, por ejemplo, Internacional) va a permitir poder usar una única operación de subscripción en vez de tener que suscribirse a cada uno de los temas de segundo nivel incluidos en el mismo (en el ejemplo, Internacional/Asia, Internacional/Europa, etc.). Por tanto, se va a Página 2 de 4 reducir el número de mensajes requeridos para esta operación de subscripción, es decir, mensajes desde los subscriptores (M y L) al proceso intermediario (A). Por otro lado, ya sea usando una subscripción de alto nivel o las de bajo nivel equivalentes, el número de notificaciones será el mismo. 6. Se plantea usar un esquema con un filtro de eventos por contenido en vez de un filtro por temas. ¿Para cuál de estos casos ese cambio sería más ventajoso en el sentido de reducir el número de notificaciones? a. Interés en las noticias internacionales protagonizadas por una determinada persona. b. Interés en las noticias de África o Asia protagonizadas por una determinada persona. c. Interés en todas las noticias internacionales. d. Interés en las noticias de todos los continentes excepto Europa. Explicación Veamos cada caso planteado analizando, en primer lugar, si el uso de un filtro por contenido tendría alguna ventaja en ese caso y, si hay varios en los que sí, en qué caso sería más efectivo (es decir, descartaría más eventos no deseados). • En el caso de estar interesado en todas las noticias internacionales el subscriptor puede suscribirse al tema de alto nivel correspondiente. En cualquier caso, no hay ningún beneficio en usar un filtro por contenido puesto que está interesado en todos esos eventos, no teniendo que descartar ninguno. • El caso de estar interesado en las noticias de todos los continentes excepto Europa es similar al anterior: se realizaría una subscripción a cada uno de los cuatro temas de segundo nivel correspondientes, no existiendo ningún beneficio en el uso de un filtro por contenido, ya que el subscriptor no va a descartar ningún evento. • En cuanto al caso de interés en ser notificado de las noticias de África o Asia protagonizadas por una determinada persona, el subscriptor tendría que suscribirse a los temas asociados a cada uno de estos dos continentes y descartar todos los eventos que no estén vinculados con la persona de interés. El uso de un filtro por contenido especificando como función que el protagonista de la noticia sea una determinada persona sería, por tanto, beneficioso ya que descartaría todos los demás eventos. • Con respecto al caso de estar interesado en ser notificado cuando cualquier noticia de carácter internacional esté protagonizadas por una determinada persona, sería similar al anterior. En este caso, el subscriptor podría usar el tema de primer nivel correspondiente a todas las noticias internacionales y descartar todas aquéllas en las que no está involucrada la persona de interés. El uso de un filtro por contenido especificando como función que el protagonista de la noticia sea una determinada persona sería más beneficioso que en el caso previo puesto que el número de eventos que se descartan va a ser mayor. 7. ¿Qué esquema pull o push (i) proporcionaría más inmediatez en la distribución de las noticias; (ii) generaría más mensajes? a. (i) push; (ii) pull b. (i) push; (ii) push c. (i) pull; (ii) pull d. (i) pull; (ii) push Explicación El esquema push proporciona mayor inmediatez ya que en el pull el subscriptor debe realizar una consulta periódica para obtener los eventos. En cuanto a qué esquema genera más mensajes, en primer lugar, hay que tener en cuenta que en ambos esquemas se producirían el mismo número de mensajes de subscripción entre los subscriptores y el intermediario. Asimismo, habría el mismo número de mensajes de publicación de eventos entre los editores y el intermediario. La diferencia estaría en la notificación de eventos entre los subscriptores y el intermediario. En el esquema push se generarían solamente los mensajes correspondientes a los eventos. Sin embargo, en un esquema de tipo pull, se produce una sobrecarga adicional por los mensajes periódicos del subscriptor al intermediario preguntando por la existencia de eventos a los que está subscrito. En el caso de que no se haya producido ningún evento desde la última consulta, ese mensaje no dará ningún resultado. Nótese que, para un buen funcionamiento del sistema, en ambos esquemas el subscriptor acabará obteniendo la misma cantidad de eventos. 8. Si se usa un mecanismo de leasing, ¿cuántos tipos de procesos deberían enviar el mensaje de renovación? a. 2 b. 1 c. 3 d. 4 Explicación Cuando se aplica un mecanismo de leasing en un esquema editor-subscriptor, los subscriptores (M y L, en este caso) deben renovar periódicamente el alquiler. Página 3 de 4 Curso 2013/2014: segundo semestre. Segunda parte Se pretende diseñar una aplicación cliente/servidor para proveer acceso remoto a ficheros proporcionando a las aplicaciones una interfaz UNIX y se está valorando usar un servicio con estado o sin estado. En el sistema se usa un esquema de binding que oculta tanto la dirección de la máquina donde ejecuta el servidor como su puerto de servicio pero tal que si al rearrancar el servidor en la misma máquina usa un puerto diferente, esa información no es necesario propagarla fuera de esa máquina. 9. ¿Cuántas de las siguientes operaciones sobre directorios que puede hacer una aplicación generan mensajes del cliente al servidor en un modelo de servicio sin estado: mkdir, chdir y rmdir? a. 2 b. 3 c. 0 d. 1 Explicación Nota: Dado que la redacción de la pregunta no ha sido adecuada (lamento las molestias), se ha optado por admitir como buenas dos respuestas. Las operaciones mkdir y rmdir deben ser enviadas al servidor aunque se trate de un esquema sin estado, puesto que los cambios asociados a las mismas tienen que modificar el sistema de ficheros almacenado en el servidor, creando y eliminando el directorio especificado, respectivamente. Sin embargo, la operación chdir no tiene ningún efecto sobre el sistema de ficheros del servidor en un esquema sin estado. Esta operación causa que el cliente almacene esa información de manera que a partir de ese momento todas las rutas relativas que usa la aplicación se completen con ese directorio actual antes de enviarlas al servidor (téngase en cuenta que en un esquema sin estado el cliente no puede enviar rutas relativas al sevidor). Ahora bien, sería conveniente verificar que el directorio pasado como parámetro a chdir exista y eso puede requerir (a no ser que se use una cache en el cliente) contactar con el servidor. 10. Se plantean dos implementaciones para una cache en el cliente: (i) cada petición de lectura contacta con el servidor para comprobar si el dato en la cache sigue siendo válido; (ii) cuando se modifica parte de un fichero el servidor lo notifica a los clientes que tienen copia en su cache. ¿Qué implementación no es factible? a. (ii) con servicio sin estado b. (i) con servicio sin estado c. (i) con servicio con estado d. (ii) con servicio con estado Explicación La segunda implementación requiere que el servidor conozca qué clientes tienen copia del fichero. Por tanto, necesita tener un estado asociado. 11. Se van a usar varios servidores independientes, que sólo comparten los discos, para repartir la carga del servicio de manera que cada mensaje de petición lo pueda procesar un servidor distinto. ¿Cuál de los dos modelos de servicio obligaría a que todas las peticiones de un cliente durante el acceso a un fichero tuviera que procesarlas el mismo servidor, dificultando de esta forma un reparto equilibrado de la carga? a. Servicio con estado b. Servicio sin estado c. Ambos modelos d. Ninguno de los dos modelos Explicación Para procesar en un servicio con estado una petición de lectura o escritura, hay que usar la información de estado almacenada en el servidor para saber, por ejemplo, a partir de qué posición realizar la petición. Esa necesidad conlleva que todas las peticiones correspondientes al acceso a un fichero por parte de un cliente en un sistema con un esquema con estado tenga que procesarlas el mismo servidor, puesto que, en caso contrario, no dispondría de la información de estado requerida. 12. Se va a proporcionar a las aplicaciones tres tipos de operaciones de escritura: (i) escribir en la posición actual (el clásico write de UNIX); (ii) escribir en la posición especificada en un parámetro de la llamada (función pwrite de UNIX); (iii) escribir al final del fichero (write de UNIX cuando el fichero se abre con O_APPEND). ¿Cuál de los tres tipos de escrituras requeriría más información de estado en el cliente si se usa un servicio sin estado? a. (i) b. (ii) c. (iii) Página 4 de 4 d. Ninguna requiere estado en el cliente Explicación En un esquema sin estado, la petición de escritura en la posición actual necesita que se almacene en el cliente dicha posición. Sin embargo, una escritura que incluya como parámetro la posición del fichero donde se llevará a cabo no requiere que se almacene este tipo de información puesto que ya se incluye en la propia llamada. Por último, una escritura que añada los datos al final del fichero tampoco requiere que se mantenga información de estado en el cliente puesto que la ubicación final de los datos se resolverá en el servidor cuando reciba la petición teniendo en cuenta el tamaño actual del fichero. 13. ¿Qué tipo de modelo, con estado o sin estado, suele (i) requerir un tiempo ligeramente menor para procesar las peticiones; (ii) tener mayores problemas de condiciones de carrera en el acceso a estructuras de datos cuando se usa un servidor multithread? a. (i) con estado; (ii) con estado b. (i) sin estado; (ii) con estado c. (i) con estado; (ii) sin estado d. (i) sin estado; (ii) sin estado Explicación Un servicio con estado suele requerir un tiempo ligeramente menor para procesar las peticiones puesto que la información almacenada en el memoria del servidor puede agilizar el tratamiento de la misma (por ejemplo, puede estar almacenado en memoria el inodo del fichero). Por otro lado, la presencia de un estado en el servidor aumenta la posibilidad de que se produzcan condiciones de carrera durante la actualización del mismo si se usa un servidor multithread. Considérese, por ejemplo, el campo del inodo en memoria que representa el número de veces que está abierto el fichero que habría que actualizar dentro de una sección crítica. 14. El servicio de ficheros va a incluir primitivas para establecer cerrojos. Se plantea usar leasing para los cerrojos y también para el servicio de binding. ¿Qué mensajes de renovación se producirían en cada caso? a. De C a S; De S a binders b. De C a S; De C a binders c. De S a C; De S a binders d. De S a C; De C a binders Explicación En el servicio de cerrojos, un cliente en posesión de un cerrojo debe enviar mensajes de renovación al servidor para detectar si se cae dicho cliente y liberar el cerrojo en ese caso. En cuanto al servicio de binding, el servidor, que se ha dado de alta en el mismo, debería enviar mensajes de renovación a los binders para asegurar de esta forma que sigue proporcionando el servicio y no está caído. 15. Suponiendo que en el sistema hay X máquinas y que en Y de esas máquinas ejecutan servidores de ficheros, ¿cuántos binders globales (BG) y locales (BL) harán falta como mínimo en el sistema? a. BG:1; BL:Y b. BG:0; BL:X c. BG:0; BL:Y d. BG:1; BL:X Explicación Dado que hay que esconder la máquina y el puerto de servicio pero de manera que la información sobre el puerto de servicio usado se mantenga localmente, se debe usar una solución con un único binder global y un binder local en cada máquina donde ejecuta un servidor. 16. ¿Qué información (direcciones de máquina y puertos) debe conocer a priori un cliente para localizar a un servidor en este sistema? a. 1 dirección de máquina y 2 puertos b. 1 dirección de máquina y 1 puerto c. 2 direcciones de máquina y 1 puerto d. 2 direcciones de máquina y 2 puertos Explicación En el esquema de binding requerido por este sistema (con un único binder global y múltiples locales), un cliente debe conocer la dirección y puerto de servicio del binder global, así como el puerto por el que dan servicio los binders locales. Página 1 de 4 Curso 2013/2014: primer semestre. Primera parte Considere una empresa denominada TruckTrack (TT) que ofrece a empresas de transporte de mercancías un servicio de seguimiento de la flota de camiones de la empresa contratante informándola en tiempo real según los vehículos de dicha empresa van pasando por los distintos puntos kilométricos de la red de carreteras de ese país. Cuando una empresa contrata ese servicio, la empresa TT instala en cada vehículo de la misma un cierto sistema hardware/software (SV). Asimismo, instala en el centro de proceso de datos de la empresa contratante la aplicación de seguimiento (AS). Evidentemente, en su centro de datos, la empresa TT tiene el software necesario (STT) para proporcionar ese servicio a todas las empresas que lo tienen contratado. El servicio está basado en un esquema editor-subscriptor con un filtro de eventos por tema organizado jerárquicamente en dos niveles: un tema de alto nivel representa a todos los vehículos de una empresa (EmpresaX) y uno de bajo nivel representa un vehículo concreto de una empresa (EmpresaX/Veh666). 1. ¿Qué módulos realizan el papel de subscriptores? a. AS b. STT c. SV d. STT y AS Explicación Los usuarios del módulo AS instalado en cada empresa contratante deben seleccionar sobre qué vehículos están interesados en hacer el seguimiento. Este módulo, por tanto, realiza el rol de subscriptor. 2. ¿Qué módulos realizan el papel de editores? a. SV b. STT c. AS d. STT y AS Explicación El módulo SV instalado en los vehículos genera un evento cada vez que se atraviesa un punto kilométrico. Por tanto, está realizando el rol de editor. 3. ¿Qué módulos realizan el papel de procesos intermediarios? a. STT b. SV c. AS d. STT y AS Explicación El módulo STT instalado en la empresa es el que conoce cuáles son las empresas contratantes y en qué vehículos está interesada cada una, ejerciendo, por tanto, el rol de proceso intermediario. 4. A la hora de hacer el seguimiento de todos los vehículos de una determinada empresa, ¿qué ventajas proporciona usar un tema de alto nivel: (i) disminuye el número de notificaciones de eventos; (ii) disminuye el espacio requerido para almacenar la información de subscripción? a. Sólo (ii). b. Ambas. c. Sólo (i). d. Ninguna de las dos. Explicación El uso de temas de alto nivel en la subscripción va a permitir que un subscriptor pueda mostrar su interés en el seguimiento de todos los vehículos de una empresa sin necesidad de suscribirse a cada uno de ellos. A su vez, el proceso intermediario podrá incluir a estos subscriptores de alto nivel de una empresa en una única lista asociada a la misma, en vez de tener que incorporarlos a la lista de subscriptores interesados en cada vehiculo, ahorrándose, por tanto, espacio para almacenar la información de subscripción (ii). Por otro lado, ya sea usando una subscripción de alto nivel a una determinada empresa o de bajo nivel a cada uno de sus vehículos, el número de notificaciones será el mismo. 5. Si se usa un mecanismo de leasing, ¿qué módulos deberían enviar el mensaje de renovación? Página 2 de 4 a. b. c. d. AS STT SV AS y SV Explicación El proceso intermediario (STT) guarda información de los subscriptores. Por tanto, si se usa un mecanismo de leasing para esta información, serán los subscriptores (AS) los que deberán enviar mensajes de renovación. 6. Se plantea usar un esquema con un filtro de eventos por contenido en vez de un filtro por temas. ¿Para cuál de estos casos ese cambio sería más ventajoso en el sentido de reducir el número de notificaciones? a. Interés en el momento en que cualquier vehículo de una empresa pasa por un determinado punto kilométrico. b. Interés en el seguimiento de todos los vehículos de todas las empresas (opción disponible sólo para agencias del gobierno). c. Interés en el momento en que cualquiera de dos determinados vehículos de una empresa pasan por un determinado punto kilométrico. d. Interés en el seguimiento de todos los vehículos de una empresa. Explicación Veamos cada caso planteado analizando, en primer lugar, si el uso de un filtro por contenido tendría alguna ventaja en ese caso y, si hay varios en los que sí, en qué caso sería más efectivo (es decir, descartaría más eventos no deseados). • En el caso de estar interesado en todos los vehículos de una empresa, el subscriptor debería suscribirse a los mismos, ya sea usando el tema de alto nivel correspondiente a la empresa o suscribiéndose a cada uno en concreto. En cualquier caso, no hay ningún beneficio en usar un filtro por contenido puesto que está interesado en todos esos eventos, no teniendo que descartar ninguno. • El caso de estar interesado en todos los vehículos de todas las empresas es similar al anterior: se realizaría una subscripción a todos los temas, no existiendo ningún beneficio en el uso de un filtro por contenido, ya que el subscriptor no va a descartar ningún evento. • En cuanto al caso de interés en ser notificado cuando cualquiera de dos vehículos pasa por un cierto punto kilométrico, el subscriptor tendría que suscribirse a los temas asociados a cada uno de estos dos vehículos y descartar todos los eventos que correspondan al paso por otras ubicaciones. El uso de un filtro por contenido especificando como función que la ubicación geográfica se corresponda con el punto kilométrico de interés sería, por tanto, beneficioso ya que descartaría todos los demás eventos. • Con respecto al caso de estar interesado en ser notificado cuando cualquier vehículo de la empresa pasa por un determinado punto kilométrico, como ocurría en el caso anterior, será beneficioso un filtro por contenido que sólo comunique los eventos asociados al paso de esos vehículos por dicho punto. Además, en este caso, el filtro sería más efectivo al poder descartar más eventos puesto que hay más vehículos involucrados. Curso 2013/2014: primer semestre. Segunda parte Responda a la siguientes preguntas generales sobre la arquitectura de un sistema distribuido. 7. Considere los dos siguientes patrones de comunicación: un único proceso tiene que enviar un determinado dato a varios procesos usando una única operación; varios procesos tienen que enviar un dato a un único proceso. ¿Cuántos de esos dos patrones permite implementar cada arquitectura, cliente/servidor y/o editor/subscriptor, en su modelo básico? a. C/S 1; E/S 2 b. C/S 1; E/S 1 c. C/S 2; E/S 1 d. C/S 2; E/S 2 Explicación El modelo cliente/servidor básico permite que varios procesos, actuando como clientes, envíen su dato a otro proceso, que realizaría el papel de servidor. Sin embargo, no permite que un proceso pueda Página 3 de 4 enviar un dato a múltiples procesos usando una única operación. El modelo editor/subscripor permite ambos patrones: un proceso, haciendo el papel de editor, envía un dato (un evento) a varios procesos (subscriptores) utilizando una única operación; varios procesos, en el rol de editores, envían su dato (un evento) a un proceso, que será el único subscriptor a ese evento. 8. Considere dos versiones de un servicio remoto de acceso a ficheros: con y sin estado. ¿Cuál de ellas (i) requeriría enviar en el mensaje correspondiente a la apertura del fichero siempre el camino absoluto asociado al fichero; (ii) permitiría controlar que un fichero no se borra si alguien lo tiene abierto? a. (i) sin est.; (ii) con est. b. (i) con est.; (ii) sin est. c. Ambas con estado. d. Ambas sin estado. Explicación En un servicio sin estado, el servidor no conoce cuál es el directorio actual de un proceso cliente. Por tanto, el mensaje de petición debe enviar el camino absoluto. Sin embargo, en un servicio con estado, el directorio actual de un cliente pude formar parte del estado asociado al mismo, pudiéndose enviar también caminos relativos en el mensaje de apertura. Con respecto al control en el borrado de un fichero evitando hacerlo mientras esté abierto, para implementar esa característica sería necesario que el servicio fuera con estado ya que, en caso contrario, el servidor no podría conocer si el fichero está actualmente abierto. 9. Considere un esquema de binding que permite ocultar al cliente por qué número de puerto se proporciona servicio pero no desde qué máquina. Suponiendo que en el sistema hay X máquinas y que en Y de esas máquinas ejecutan servidores, ¿cuántos binders globales (BG) y locales (BL) harán falta como mínimo en el sistema? a. BG:0; BL:Y b. BG:0; BL:X c. BG:1; BL:Y d. BG:1; BL:X Explicación En un esquema que sólo oculta el puerto y no la dirección de la máquina, no es necesario ningún binder global, pero sí tantos binders locales como máquinas en las que esté ejecutando al menos un servidor. 10. ¿Qué tipo de desacoplamiento (T: temporal; E: espacial) proporcionaría enviar una carta a un amigo (CARTA) y cuál dejar un mensaje en un contestador automático (CONT)? a. CARTA: T; CONT: T b. CARTA: E; CONT: E c. CARTA: T; CONT: E d. CARTA: E; CONT: T Explicación Una carta dirigida a un amigo implica un desacoplamiento temporal, puesto que el remitente y el destinatario no tienen que coincidir en el tiempo, pero un acoplamiento espacial, ya que el emisor de la carta debe especificar los datos del destinatario en el sobre de la misma. En cuanto a dejar un mensaje en el contestador al llamar por teléfono a un amigo, presenta el mismo tipo de des/acoplamientos: no tienen que coincidir en el tiempo (desacoplamiento temporal) pero el llamante sí tiene que conocer y marcar el número de teléfono del destinatario de la llamada (acoplamiento espacial). 11. Considere un servicio de carga(PUT)/descarga(GET) de ficheros remotos, en el que las operaciones de descarga/lectura son mucho más frecuentes que las de carga/escritura. Dado que es habitual que un cliente descargue/lea múltiples veces el mismo fichero, se plantea el uso de una cache en cada cliente. Para mantener la coherencia de la cache, se valoran dos posibles esquemas: (i) Cuando el cliente quiere descargar un fichero que tiene en su cache, contacta con el servidor para comprobar, comparando las fechas de última modificación, si la copia es válida, descargándose el fichero sólo en caso de que no lo fuera; (ii) Cuando un cliente carga/escribe una nueva versión del fichero, el servidor lo notifica a todos los clientes que tienen copia del mismo y éstos eliminan esa copia, asegurando de esta forma que las Página 4 de 4 copias en la cache son siempre válidas. ¿Qué esquema sería más escalable desde el punto de vista de ancho de banda de red consumida y cuál requeriría un servicio con un mayor estado asociado? a. (ii) más escalable y más estado. b. (i) más escalable y más estado. c. (i) más escalable; (ii) más estado. d. (i) más estado; (ii) más escalable. Explicación Con respecto a la necesidad de gestionar un estado en el servidor para mantener la coherencia de la información en las caches de los clientes, la primera solución no lo requiere, puesto que el cliente contacta con el servidor en cada apertura (nótese que la fecha de última modificación no es un estado del servicio, sino del recurso). Sin embargo, la segunda solución requiere que el servidor almacene la lista de clientes que tienen en la cache copia de cada fichero. En cuanto al ancho de banda de red consumida, en la segunda solución, en una operación de lectura/descarga, el cliente sólo contacta con el servidor si la copia es inválida. Sin embargo, en la primera solución, todas las aperturas contactan con el servidor, gastando ancho de banda de red y de servidor, incluso aunque la copia en la cache sea válida, generándose un número de mensajes adicionales, con respecto a la segunda solución, proporcional al número de clientes, el número de ficheros y el número medio de aciertos en la cache por cada fichero. Las operaciones de carga/escritura son más costosas en la segunda solución puesto que requieren que el servidor envíe mensajes de invalidación a todos los clientes que tienen copia; pero, como especifica el enunciado, las operaciones de escritura son mucho menos frecuentes. Como curiosidad y tal como se estudiará en la asignatura, el sistema de ficheros AFS en su primera versión usaba un esquema equivalente a la primera solución planteada, mientras que en su segunda versión adoptó un esquema similar a la segunda. 12. ¿Qué procesos deben enviar el mensaje de renovación si se usa un mecanismo de leasing en un esquema cliente/servidor (C/S) con binders globales (BG) y locales (BL)? a. S b. C c. BG d. BL Explicación En un sistema que usa un esquema de binding que oculta tanto el número de puerto como la máquina que proporciona cada servicio, tanto los binders globales como los locales guardan información de los servidores. Por tanto, al aplicar un esquema de leasing para mantener este tipo de información, serán los servidores los que tendrán que enviar los mensajes de renovación. Página 1 de 4 Curso 2012/2013: segundo semestre. Primera parte Se pretende desarrollar una aplicación de domótica basada en un esquema editor-subscriptor. En este sistema hay dos tipos de procesos: sensores (SE), que detectan cambios en el valor de algún parámetro físico (temperatura, luminosidad, humedad, presencia física, etc.), pudiendo haber varios por cada parámetro (por ejemplo, varios sensores de temperatura situados en distintas ubicaciones o con características diferentes), y procesos controladores (CO), cada uno de los cuales, a partir de los valores de distintos parámetros físicos gestionan algún tipo de elemento de habitabilidad (climatización, seguridad, etc.). Se va a diseñar un esquema editor-subscriptor con un único proceso intermediario (PI), un conjunto de temas fijos (cada parámetro físico corresponde a un tema), un filtro de eventos por tema, y un servicio de binding global (BG). 1. ¿Qué procesos realizan el papel de subscriptores? a. CO b. SE c. BG d. PI Explicación Son los procesos controladores (CO) los que quieren ser notificados cuando cambia algún parámetro físico de su interés. Por tanto, realizan el rol de subscriptores. 2. ¿Qué procesos realizan el papel de editores? a. SE b. CO c. BG d. PI Explicación Los sensores (SE) son los que generan eventos de notificación cuando el parámetro que supervisan cambia de valor, realizando, por tanto, el palel de editores. 3. ¿Qué procesos realizan una operación de alta en el servicio de binding? a. PI b. SE c. CO d. SE y CO Explicación Gracias al desacoplamiento espacial proporcionado por el modelo editor/subscriptor, los procesos CO y SE no tienen necesidad de conocerse entre sí. Al implementar este modelo usando un proceso intermediario (PI), éste es el único que se tiene que dar de alta en el servicio de binding. 4. ¿Para qué procesos sería razonable usar un esquema de leasing en este esquema editor-subscriptor? a. CO b. BG c. SE d. SE y CO Explicación El proceso PI guarda en su estado interno información sobre qué subscriptores hay para cada tema. Por tanto, puede ser conveniente un esquema de leasing para los procesos subscriptores (CO) que obligue a que éstos tengan que renovar sus subscripciones periódicamente. 5. ¿A qué es proporcional el tamaño de la información dinámica que almacena PI? a. al número de procesos CO b. al número de procesos SE c. al número de procesos CO + SE d. tiene tamaño fijo Explicación Página 2 de 4 El proceso PI almacena qué subscriptores hay para cada tema. Por tanto, el tamaño de la información dinámica que almacena PI es proporcional al número de procesos subscriptores (CO). 6. ¿Cuáles de las siguientes interacciones NO puede producirse en un esquema de tipo push y cuáles NO pueden darse en uno de tipo pull: (1) PI envía mensaje a CO; (2) PI envía mensaje a SE? NOTA: no tenga en cuenta los mensajes de respuesta de tipo ACK o error. a. pull: (1) y (2); push (2) b. pull: (2); push (1) y (2) c. pull: (1) y (2); push (1) d. pull: (1); push (1) y (2) Explicación Comenzando con la segunda operación (PI -> SE), ésta nunca puede producirse en un modelo editor/subscriptor, ya que no tiene sentido que el proceso que actúa como intermediario envíe algún tipo de petición a un editor. Con respecto a la primera (PI -> CO), corresponde a la forma de notificar los eventos en un esquema de tipo push, pero no puede darse en uno de tipo pull ya que en dicho esquema es el subscriptor el que pregunta por la presencia de eventos al PI. 7. Se plantea usar un esquema con un filtro de eventos por contenido en vez de un filtro por temas. ¿Para cuál de estos casos ese cambio sería más ventajoso? a. Interés en todos los parámetros físicos de una determinada posición. b. Interés en todos los parámetros del sistema. c. Interés en la temperatura y la luminosidad en cualquier punto del sistema. d. Interés en la temperatura pero sólo la medida por un cierto tipo de sensores de temperatura. Explicación Veamos cada caso planteado analizando, en primer lugar, si el uso de un filtro por contenido tendría alguna ventaja en ese caso y, si hay varios en los que sí, en qué caso sería más efectivo (es decir, descartaría más eventos no deseados). • En el caso de estar interesado en todos los parámetros del sistema, el subscriptor debería suscribirse a todos los temas (parámetros físicos) del mismo, no teniendo sentido, por tanto, usar un filtro por contenido. • Si se está interesado en la temperatura y la luminosidad en cualquier punto del sistema, habría que suscribirse a ambos temas pero sin usar un filtro por contenido al estar interesado en todos los eventos de esos dos temas. • En cuanto al caso de estar interesado en la temperatura pero sólo la medida por un cierto tipo de sensores, se debería suscribir a ese tema; pero, al estar interesado sólo en los valores obtenidos por un cierto tipo de sensores de temperatura, sería ventajoso usar un filtro por contenido especificando como función de filtro una que especifique el interés únicamente en ese tipo de sensores. • Con respecto al caso de estar interesado en todos los parámetros físicos de una determinada posición, habría que suscribirse a todos los temas, siendo adecuado usar un filtro por contenido que especifique el interés sólo en los eventos de dicha posición. Por tanto, tendría sentido usar un filtro por contenido en esos dos casos. Para determinar en qué caso el filtro sería más efectivo, habría que analizar cuál de ellos descartaría más eventos no deseados. Dado que en el caso del interés en todos los parámetros de una cierta posición hay que suscribirse a todos los temas, mientras que en el otro sólo a la temperatura, sería más efectivo para ese primer caso. Curso 2012/2013: segundo semestre. Segunda parte Responda a la siguientes preguntas generales sobre la arquitectura de un sistema distribuido. 8. ¿Cuál de estas técnicas NO mejora la escalabilidad de un servicio? a. Traerse por anticipado objetos que requerirá en el futuro el cliente. b. Uso de una cache. c. Replicación del servidor. d. Aumentar la inteligencia en el lado cliente. Explicación Página 3 de 4 Empezamos por las técnicas que sí mejoran la escalabilidad del servicio. La cache puede disminuir el número de peticiones que genera el cliente hacia el servidor puesto que algunas de ellas se resuelven localmente, lo que mejora la escalabilidad del servicio al disminuir la carga que genera el mismo sobre el servidor. La replicación puede permitir dar servicio a más clientes que en el caso de un único servidor, mejorando también la escalabilidad. En cuanto a aumentar la inteligencia en el cliente, le dota de más autonomía al mismo, con la consecuente mejora en la escalabilidad. Sin embargo, la lectura anticipada de objetos no mejora de por sí la escalabilidad puesto que, en cualquier caso, esos objetos había que traérselos e incluso, en el peor de los casos, se pueden traer al cliente objetos que finalmente no van a ser usados. El principal objetivo de las operaciones anticipadas no es mejorar la escalabilidad sino la latencia de la operación. 9. Sea una aplicación en la que un proceso G genera datos que reciben y procesan N procesos de tipo C. Suponga dos alternativas: (R1) el requisito de esta aplicación es que N es un valor dinámico y desconocido a priori; (R2) el requisito de esta aplicación es que el proceso G debe asegurarse de que los datos han sido procesados por todos los procesos C antes de continuar. ¿Qué arquitectura (cliente/servidor o editor/subscriptor) satisfaría mejor cada requisito? a. R1 E/S; R2 C/S b. R1 C/S; R2 E/S c. R1 C/S; R2 C/S d. R1 E/S; R2 E/S Explicación El primer requisito plantea que el número de los procesos receptores de los datos es dinámico. Ese requisito no encaja bien con un modelo cliente/servidor puesto que con ese modelo el cliente (proceso G en este caso) tiene que contactar con (conocer) explícitamente cuáles son los servidores (procesos C en este caso). Usando este modelo, la aplicación distribuida debe encargarse explícitamente de mantener qué procesos C existen en cada momento en el sistema. Un modelo editor/subscriptor es más adecuado puesto que resuelve ese dinamismo automáticamte, de manera que el proceso editor (proceso G en este caso) no necesita conocer (ni contactar directamente con) los procesos subscriptores (procesos C en este caso). El segundo requisito requiere que haya algún tipo de confirmación por parte de los procesos C hacia el proceso G para indicar el fin del procesamiento. Esa sincronización va implícita en la propia respuesta del servidor si se usa el modelo cliente/servidor. El modelo editor/subscriptor, sin embargo, es más asíncrono y habría que programar explícitamente esa confirmación. 10. ¿Qué tipo de desacoplamiento (T: temporal; E: espacial) proporcionaría la retransmisión en directo de un discurso por televisión (TV) y cuál el acto de dejar una nota en un tablón de una oficina (NOTA)? a. TV: E; NOTA: T y E b. TV: T y E; NOTA: E c. TV: T; NOTA: T y E d. TV: T y E; NOTA: T Explicación Un programa de televisión en directo implica un desacoplamiento espacial, puesto que el centro emisor realiza una difusión sin conocer quiénes son los receptores de la misma, pero no temporal, ya que los espectadores deben estar presentes delante de su televisión en ese instante para poder presenciarlo. Con respecto a una nota en un tablón, proporciona ambos tipos de desacoplamiento: temporal, ya que las personas que lean la nota no necesitan estar presentes cuando ésta se publicó, y espacial, puesto que la nota no necesita ir dirigida a nadie en particular sino a quienes les pueda interesar. 11. Sea un cliente que requiere enviar varias peticiones a un servidor para llevar a cabo una operación. ¿Qué parámetro mejoraría si se modifica el diseño del servicio de manera que el cliente puede enviar simultáneamente todas las peticiones? a. latencia de la operación b. escalabilidad del servicio c. tolerancia a fallos d. menor complejidad en el diseño del servidor Explicación Página 4 de 4 Enviar agrupadas todas las peticiones complica el diseño del servidor, que tendrá que ser capaz de desagruparlas antes de procesarlas, no mejorando la escalabilidad del servicio, puesto que, en términos generales, usará la misma cantidad de ancho de banda de la red y del servidor, ni mejorando tampoco la tolerancia a fallos, al no incluir ningún tipo de mecanismo con ese fin. Sin embargo, sí mejora la latencia, puesto que el cliente no tiene que esperar la respuesta de la primera petición para enviar la segunda, como ocurre con el modelo cliente/servidor convencional. Curso 2012/2013: segundo semestre. Tercera parte Se plantea diseñar un servicio que permite a una aplicación acceder a un directorio remoto ofreciendo tres operaciones: abrir el directorio, leer la siguiente en entrada y cerrar el directorio. Se está evaluando si usar un esquema con estado o sin estado. 12. ¿Cuántas de las operaciones requerirían contactar con el servidor en un servicio con estado? a. 3 b. 0 c. 1 d. 2 Explicación En un servicio con estado, las tres operaciones requerirían contactar con el servidor puesto que la apertura conllevaría el inicio de una sesión, mientras que el cierre implicaría el fin de la misma. La lectura, evidentemente, tendría que contactar también con el servidor. 13. ¿Cuántas de las operaciones requerirían contactar con el servidor en un servicio sin estado? a. 2 b. 0 c. 1 d. 3 Explicación En un servicio sin estado, la operación de apertura tendría que contactar con el servidor para comprobar si el directorio existe y es accesible por ese cliente. Sin embargo, no se crearía una sesión asociada al acceso al directorio, por lo que la operación de cierre se resolvería localmente en el cliente, sin contactar con el servidor. La lectura, evidentemente, tendría que contactar también con el servidor. 14. ¿Para qué esquema el mensaje generado en la lectura es de mayor tamaño? a. Sin estado. b. Con estado. c. No procede: La lectura no genera ningún mensaje en un esquema sin estado. d. No procede: La lectura no genera ningún mensaje en un esquema con estado. Explicación Los mensajes de un protocolo sin estado tienden a ser más grandes, ya que deben ser auto-contenidos, incluyendo toda la información requerida para su procesamiento. En este caso, además de otra posible información, el mensaje de lectura en una solución sin estado debe incluir cuál es la posición actual dentro del directorio. Esa información de posición no habría que incluirla en la versión con estado puesto que ya la conoce el servidor (es parte del estado almacenado por el mismo). 15. ¿Dónde se almacena la información sobre qué entrada de directorio toca leer a continuación: en el cliente (C) o en el servidor (S)? a. Con estado: S; Sin estado: C. b. Con estado: C; Sin estado: S. c. Con estado: C; Sin estado: C. d. Con estado: S; Sin estado: S. Explicación En un esquema sin estado, el servidor no almacena ninguna información sobre las peticiones de los clientes por lo que esa información debe almacenarla el cliente. Sin embargo, en un esquema con estado, esa información la guardaría el servidor como parte de dicho estado. Página 1 de 2 Ejercicio del tema comunicación en los sistemas distribuidos 1. ¿Qué tipo de desacoplo proporciona un esquema de comunicación basado en sockets: espacial (E) o temporal (T)? a. Ninguno b. Ambos c. E d. T Explicación En la comunicación con sockets, el proceso que inicia la misma debe conocer la dirección del destinatario, no existiendo, por tanto, desacoplamiento espacial. Por otro lado, para que se complete la comunicación, ambos procesos deben coincidir en el tiempo, lo que implica que no hay tampoco desacoplamiento temporal. 2. ¿Qué tipo de desacoplo proporciona un esquema de comunicación basado en colas de mensajes: espacial (E) o temporal (T)? a. Ambos b. Ninguno c. E d. T Explicación En un sistema de colas de mensajes, el proceso que inicia la comunicación especifica simplemente la dirección de una cola, no requiriendo conocer quiénes son los destinatarios, lo que significa que hay desacoplamiento espacial. Por otro lado, el sistema de colas almacena el mensaje hasta que sea recibido, incluso aunque, para entonces, el proceso remitente haya dejado de existir, existiendo, por tanto, también desacoplamiento temporal. 3. ¿Qué tipo de desacoplo proporciona un esquema de comunicación basado en mensajes unidireccionales de MPI: espacial (E) o temporal (T)? a. Ninguno b. Ambos c. E d. T Explicación En la comunicación con MPI, el proceso que inicia la misma debe conocer el identificador del destinatario, no existiendo, por tanto, desacoplamiento espacial. Por otro lado, para que se complete la comunicación, ambos procesos deben coincidir en el tiempo, lo que implica que no hay tampoco desacoplamiento temporal. 4. ¿Qué tipo de desacoplo proporciona un esquema de comunicación de grupo: espacial (E) o temporal (T)? a. E b. Ninguno c. Ambos d. T Explicación En un sistema de comunicación de grupo, el proceso que inicia la comunicación especifica simplemente una dirección de grupo, no requiriendo conocer quiénes son los destinatarios, lo que significa que hay desacoplamiento espacial. Por otro lado, para que se complete la comunicación, los procesos involucrados deben coincidir en el tiempo, lo que implica que no hay desacoplamiento temporal. 5. Ordene de menor a mayor, en cuanto al número de copias de memoria requeridas, las siguientes técnicas que se podrían usar a la hora de enviar un fichero: (1) mmap + send (2) read + send; (3) sendfile. a. 3 1 2 b. 3 2 1 c. 2 1 3 d. 1 3 2 Explicación Con la opción de ir leyendo y enviando cada bloque del fichero (read + send), se requieren dos copias de memoria por cada bloque: del buffer del sistema de ficheros al del usuario y desde éste hasta el asociado al sistema de comunicaciones. Con mmap + send, sólo se produce la copia del buffer del sistema de ficheros al asociado al sistema de comunicaciones. Con sendfile no se requiere ninguna copia de memoria. 6. ¿Qué ventajas tiene un mecanismo de envio asíncrono frente a uno síncrono: (1) programación más fácil; (2) mayor concurrencia? a. 1 y 2 Página 2 de 2 b. sólo 1 c. sólo 2 d. ninguna Explicación Las operaciones asíncronas proporcionan mayor concurrencia, dado que el proceso continúa su ejecución mientras se realiza la operación, pero proporcionan un modelo de programación más complejo, ya que el proceso no puede reutilizar el buffer hasta que concluya la operación. 7. ¿Cuál de las siguientes tecnologías de serialización es menos eficiente: XDR (X), Java Serialization (J) o Protocol Buffers (P)? a. J b. P c. X d. No hay diferencias significativas entre ellas. Explicación El mecanismo de serialización de Java incurre en una sobrecarga significativamente mayor que el de las otras dos técnicas. 8. ¿Cuál de las siguientes tecnologías de serialización genera mensajes más grandes: XDR (X), Java Serialization (J) o Protocol Buffers (P)? a. J b. P c. X d. No hay diferencias significativas entre ellas. Explicación El mecanismo de serialización de Java incurre en un gasto de memoria significativamente mayor que el de las otras dos técnicas. 9. ¿Cuáles de estas tecnologías de serialización usan un mecanismo de deserialización genérico: XDR (X), JSON (S), Java Serialization (J) y Protocol Buffers (P)? a. SJ b. SP c. XJ d. XP Explicación Tanto con JSON como con la serialización de Java, en los mensajes se incluye información suficiente para realizar un proceso de deserialización genérico. En cambio, en XDR y Protocol Buffers se requiere conocer el tipo de datos de información contenida en un mensaje para poder realizar la deserialización. 10. ¿Qué requiere la implementación de un mecanismo de comunicación en grupo causal frente a uno FIFO: (i) más mensajes; (ii) mensajes más grandes? a. (ii) b. (i) c. Ambas. d. Ninguna. Explicación Requiere el mismo número de mensajes pero de mayor tamaño puesto que en cada mensaje, en vez de un único contador, hay que incluir un contador por cada proceso que pertenece al grupo. 11. Suponga un sistema de comunicación en grupo causal donde P3 tiene un vector (1,1,1) y recibe un mensaje M de P1 con un vector (3,3,0). ¿Cuántos mensajes adicionales tiene que recibir antes de entregar M? a. 3 b. 2 c. 4 d. 5 Explicación Dado que el mensaje proviene de P1, la primera componente del vector recibido está indicando que es el tercer mensaje de P1 pero, sin embargo, la primera componente del vector de P3 indica que hasta el momento sólo se ha recibido uno, por lo que falta el segundo mensaje. En cuanto a la segunda componente del mensaje recibido, indica que el proceso P1 ya ha recibido tres mensajes de P2 pero, sin embargo, la segunda componente del vector de P3 indica que éste hasta el momento sólo ha recibido uno de P2, por lo que faltan dos mensajes de dicho proceso.

Grado de acoplamiento Modelo cliente/servidor Esquema cliente

Documentos relacionados

Productos

Apoyo

Grado de acoplamiento Modelo cliente/servidor Esquema cliente

Documentos relacionados

Añadir este documento a la recogida (s)

Añadir a este documento guardado

Sugiéranos cómo mejorar StudyLib