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í – “Vidas” de entidades que interaccionan no tienen que coincidir Ej. Uso de memoria compartida 2 desacoplamientos son independientes entre sí Estos modos de operación “indirectos” proporcionan flexibilidad 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) • Pasivo: responde a petición de servicio – Servidor “cuello de botella” → 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 • ¿Qué parte del trabajo realiza el cliente y cuál el servidor? • “Grosor del cliente”: Cantidad de trabajo que realiza – Pesados (Thick/Fat/Rich Client) vs. Ligeros (Thin/Lean/Slim Client) • Ventajas de clientes ligeros – Menor coste de operación y mantenimiento – Mejor seguridad • Énfasis en operaciones (“acciones”) – Mayor autonomía – Mejor escalabilidad • Énfasis en recursos: ops. CRUD (HTTP GET, PUT, DELETE, POST) – Más ágil en respuesta al usuario – Operaciones específicas para cada servicio – Mismas ops. para todos servicios pero sobre distintos recursos (REST) – Ejemplo: • AddBook(nb) vs. PUT /books/ISBN-8448130014 HTTP/1.1 Sistemas Distribuidos 3 Fernando Pérez Costoya • Ventajas de clientes pesados • Alternativas en diseño de la interfaz de servicio 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 • Cliente gasta menos recursos de red y de servidor • Ej. “inteligencia en cliente”: Javascript valida letra NIF en form. 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 → La que no usa la red • ¿Qué labor se asigna a máquina cliente? (“grosor” creciente) – Envía eventos de ratón/teclado y recibe info. a dibujar en forma de: • Píxeles (VNC) o Primitivas gráficas (X11) • Cambio de roles: servidor gráfico en máquina cliente – – – – • 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 • 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 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 – 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 5 Fernando Pérez Costoya Sistemas Distribuidos 6 Fernando Pérez Costoya Cliente/servidor con proxy Cliente/servidor jerárquico • Componentes intermediarios entre cliente y servidor • Servidor actúa como cliente de otro servicio – NOTA: Término corresponde también a un patrón de diseño • Actúan como “tuberías” – Igual que biblioteca usa servicio de otra biblioteca • División vertical – Pueden procesar/filtrar información y/o realizar labor de caché • Funcionalidad dividida en varios niveles (multi-tier) – P. ej. Aplicación típica con 3 capas: • Símil con clases FilterInputStream|FilterOutputStream de Java • Presentación • Aplicación: lógica de negocio • Acceso a datos • Diversos tipos: forward proxy, reverse proxy, gateways, ... • Mejor si interfaz de servicio uniforme: – Proxy se comporta como cliente y servidor convencional – Se pueden “enganchar” sucesivos proxies de forma transparente – Esta característica es una de las claves del éxito de la Web Sistemas Distribuidos 7 Fernando Pérez Costoya – 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 8 Cliente/servidor con replicación Fernando Pérez Costoya Cliente/servidor con replicación • Servidor único: – Cuello de botella: afecta a latencia y ancho de banda – Punto único de fallo: afecta a fiabilidad • Uso de múltiples servidores (interacción M-N) • Si sólo uno implicado en servicio → reparto de carga – P.ej. leer el valor de un dato replicado en varios servidores – Mejora latencia, escalabilidad y tolerancia a fallos • Si múltiples servidores deben cooperar para ofrecer servicio – P. ej. actualizar simultáneamente dato replicado en varios servidores – Mejora tolerancia a fallos pero no latencia y escalabilidad C C S C p p S C p S C C p p C S p S p S C p C S • Necesidad de coherencia (sobrecarga para mantenerla): – Esquema simétrico: Actualizar simultánea en todas las réplicas – Esquema asimétrico: Actualizar en primario y propagar a secundarios 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 DMS y usando puerto PS – ¿Cómo lo localiza el cliente? → Binding – Otro servidor proporciona esa información → problema huevo-gallina Interfaz de Servicio Petición(args)+Código Cliente • Binder: mantiene correspondencias ID servicio → (DMS, PS) – Cliente debe conocer dirección y puerto del Binder Servidor Respuesta • Características deseables de ID de servicio: – – – – – Resp=Código(args) Ámbito global Mejor nombre de texto de carácter jerárquico (como pathname) Transparencia de ubicación Posible replicación: ID servicio → (DMS1, PS1) | (DMS2, PS2) .... Convivencia de múltiples versiones del servicio • Suele estar englobado en un mecanismo más general – Servicio de nombres (tema 5): Gestiona IDs de todos los recursos Sistemas Distribuidos 13 Fernando Pérez Costoya Sistemas Distribuidos 14 Alternativas en la ID del servicio Símil basado en “hechos reales” 1. Uso directo de dirección DMS y puerto PS – No proporciona transparencia 2. Nombre servicio + dir servidor (Java RMI Registry, Sun RPC) – – • Servidor (binder) en cada nodo: nombre de servicio → puerto Impide migración del servidor Nombre de servicio con ámbito global (DCE, CORBA, Mach) – – Servidor con ubicación conocida en el sistema Dos opciones: • • • • Suponiendo nº tfno persona = (nº tfno empresa + extensión) Quiero contactar con persona P (TP = TE + EP) Alternativas: 1. Conozco TP: lo uso 2. Conozco TE y extensión de información de la empresa • Llamo a servicio información de la empresa y obtengo TP 3. Conozco teléfono general de información de personas • Llamo a servicio información general y obtengo TP 4. Conozco tfno gral info. empresas y extensión info. de toda empresa 3. Sólo binder global: nombre de servicio → [DMS+PS] 4. Opción: binder global (BG) + binder local (BL) en puerto conocido • Fernando Pérez Costoya • • BG: ID → [DMS] ; BL: ID → [PS] Llamo a servicio información general de empresas y obtengo TE Llamo a servicio información de la empresa y obtengo EP Uso de caché en clientes para evitar repetir traducción – Mecanismo para detectar que traducción en caché ya no es válida Sistemas Distribuidos 15 Fernando Pérez Costoya (1) ID servicio = [DM+pto] Sistemas Distribuidos 16 Fernando Pérez Costoya (2) ID servicio = [DM+idsrv]: Alta M2 2 Idsrv → ptoS M1 C DM2 + ptoS 1 DM2 + ptoS DM2 + ptoB binder M1 M2 S C DM2+idsrv 1 Binder → ptoB Idsrv → ptoS M2 DM2 + ptoS S Info. de contacto Sistemas Distribuidos 17 Dirección de servicio Info. conocida Fernando Pérez Costoya Sistemas Distribuidos 18 Mensaje Info. binder Binder → ptoB Fernando Pérez Costoya (2) ID servicio = [DM+idsrv]: Consulta (3) ID servicio = [idsrv]; Sólo BG: Alta M2 Idsrv → ptoS M1 1 C DM2+idsrv M3 Idsrv → DM2 + ptoS DM2 + ptoB binder ¿idsrv? C ptoS Binder → ptoB M2 2 2 M1 idsrv Idsrv → DM2 + ptoS M2 1 binder→ DM3+ptoB DM2 + ptoS S DM2 + ptoS S Binder → ptoB Sistemas Distribuidos 19 Fernando Pérez Costoya binder→ DM3 +ptoB Sistemas Distribuidos 20 (3) ID servicio = [idsrv]; Sólo BG: Consulta M1 C 1 idsrv DM3 + ptoB binder ¿idsrv? M1 M2 2 DM2 + ptoS S binder→ DM3 +ptoB Sistemas Distribuidos 21 Fernando Pérez Costoya (4) ID servicio = [idsrv]; BG+BL: Consulta BL → ptoL | BG→ DM3+ptoB C ¿idsrv? M2 ¿idsrv? M1 idsrv 2 M3 BG DM3 + ptoB Idsrv → DM2 Sistemas Distribuidos 23 DM2 + ptoL BL 3 Idsrv → ptoS idsrv 2 DM2 + ptoL BL Idsrv → ptoS M2 1 M3 Idsrv → DM2 BG DM3 + ptoB 3 4 Idsrv → DM2 DM2 + ptoS S BL → ptoL | BG→ DM3+ptoB Sistemas Distribuidos 22 Fernando Pérez Costoya Recapitulación del Binding • Caso con BG y BL + versiones: – Servidor: • Elige puerto local • Informa a binder local del alta: – (id. servicio + versión) = puerto Idsrv → ptoS 1 DM2 ptoS C M2 BL → ptoL | BG→ DM3+ptoB DM2 + ptoS binder→ DM3+ptoB Fernando Pérez Costoya (4) ID servicio = [idsrv]; BG+BL: Alta M3 idsrv→ DM2 + ptoS DM3 + ptoB binder • Informa a binder global del alta: – (id. servicio + versión) = dir máquina • Al terminar, notifica la baja a ambos binder : M2 DM2 + ptoS S BL → ptoL | BG→ DM3+ptoB Fernando Pérez Costoya – Ambos eliminan (id. servicio + versión) – Cliente: • Consulta a binder global – (id. servicio + versión) → dir. máquina • Consulta a binder en dir. máquina – (id. servicio + versión) → puerto Sistemas Distribuidos 24 Fernando Pérez Costoya Servicio a múltiples clientes • Servidor secuencial • Creación dinámica de T/P según llegan peticiones – Único flujo de ejecución atiende múltiples peticiones • Operaciones asíncronas y/o espera por múltiples eventos (select/poll) – Uso de “máquina de estados” para seguimiento de clientes – Solución compleja y que no aprovecha paralelismo HW • Servidor concurrente – Solución más natural y que aprovecha paralelismo HW – Threads (T) vs. Procesos (P) • Generalmente threads: Más ligeros y comparten más recursos Sistemas Distribuidos 25 Fernando Pérez Costoya Gestión de conexiones – Sobrecarga • Conjunto de N T/P pre-arrancados: – Al finalizar trabajo, en espera de más peticiones – Poca carga → gasto innecesario – Mucha carga → insuficientes • Esquema híbrido con mínimo m y máximo M – m pre-arrancados; m ≤ T/P ≤ M – Si petición, ninguno libre y nº < M → se crea – Si inactivo tiempo prefijado y nº > m → se destruye Sistemas Distribuidos 26 Fernando Pérez Costoya Evolución de HTTP • En caso de que se use un esquema con conexión • 1 conexión por cada petición – 1 operación cliente-servidor • conexión, envío de petición, recepción de respuesta, cierre de conexión – Más sencillo pero mayor sobrecarga (¡9 mensajes con TCP!) – Propuestas de protocolos de transporte orientados a C/S (T/TCP) • Varias peticiones de cliente usan misma conexión – 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 – Dificulta reparto de servicio entre clientes – Implica que servidor mantiene un estado Sistemas Distribuidos 27 Servicio concurrente: alternativas • Cliente necesita pedir varios objetos al mismo servidor • HTTP/1.0 • Connect | GET | Resp | Close | Connect | GET | Resp | Close | … • Sobrecarga conexiones + latencia de conexiones y peticiones • HTTP/1.0 + conexiones persistentes • Connect | GET | Resp | GET | Resp | … | Close • Latencia de peticiones • HTTP/1.1 (conexiones persistentes + pipeline de peticiones) • Connect | GET | GET | … | Resp | Resp | … | Close • No latencia acumulada • Servicio paralelo de peticiones • aunque respuestas deben llegar en orden Fernando Pérez Costoya HTTP: conexiones simultáneas Sistemas Distribuidos 28 Fernando Pérez Costoya Servicio con/sin estado • Paralelismo también mediante conexiones simultáneas • HTTP/1.0 • ¿Servidor mantiene información de clientes? • Ventajas de servicio con estado (aka con sesión remota): • HTTP/1.0 + conexiones persistentes • Ventajas de servicio sin estado: • Connect | GET | Resp | Close • …………………………… • Connect | GET | Resp | Close • Connect | GET | Resp | GET | Resp | … | Close • …………………………… • Connect | GET | Resp | GET | Resp | … | Close – Mensajes de petición más cortos – Mejor rendimiento (se mantiene información en memoria) – Favorece optimización de servicio: estrategias predictivas – Más tolerantes a fallos (ante rearranque del servidor) • Peticiones autocontenidas. • HTTP/1.1 (conexiones persistentes + pipeline de peticiones) • Connect | GET | GET | … | Resp | Resp | … | Close • …………………………… • Connect | GET | GET | … | Resp | Resp | … | Close – Reduce nº de mensajes: no comienzos/finales de sesión. – Más económicos para servidor (no consume memoria) • Servicio sin estado base de la propuesta REST – Se estudia en detalle en asignatura Sistemas Orientados a Servicios • 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 open(“f”,...) 3 Servicio de ficheros con estado: READ x N | pos 0 OPEN, “f” x S read(3,b,t) 3 x x N | ant+tl READ, x, t DATOS, tl (leído) “f”; inodo N Sistemas Distribuidos 31 “f”; inodo N 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 - CLOSE, x “f”; inodo N Fernando Pérez Costoya Servicio de ficheros sin estado: OPEN C S open(“f”,...) 3 N | pos 0 Sistemas Distribuidos 34 Fernando Pérez Costoya Servicio de ficheros sin estado: READ C S read(3,b,t) BUSCAR, “f” N 3 N | ant+tl READ, N, ant, t DATOS, tl (leído) “f”; inodo N Sistemas Distribuidos 35 - OK “f”; inodo N Sistemas Distribuidos 33 x Fernando Pérez Costoya “f”; inodo N 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 - “f”; inodo N Sistemas Distribuidos 37 “f”; inodo N Fernando Pérez Costoya Sistemas Distribuidos 38 Leases Aplicaciones de leases • Mecanismo para mejorar tolerancia a fallos en SD – Detección y tratamiento de caídas de nodos – Proceso A gestiona algún tipo de recurso vinculado con proceso B • Proceso B no tiene por qué contactar de nuevo con A – Si B cae, A no lo detecta y el recurso queda “abandonado” • Modo de operación 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 lease, se detecta recurso “abandonado” Si A cae, en reinicio obtiene renovaciones • Puede “reconstruir” los recursos – Proceso envía petición a otro y arranca temporizador • 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) C2 • 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 rearranque de S – Caída de cliente: falta de renovación • No confundir con un simple temporizador C1 • Aparecerán a menudo: • Binding, caídas del cliente, suscripción en E/S, caché de SFD, etc. • Aplicación típica (genérica) de leases: – – – – Fernando Pérez Costoya C3 • Revocación automática de cerrojos de ese cliente 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 → libre m2 → C2 m3 → libre Sistemas Distribuidos 41 c1 → lock(m1) cola de mensajes de S c2 → lease(m2) S Fernando Pérez Costoya m1 → C1 m2 → C2 m3 → libre Sistemas Distribuidos 42 c1 → lease(m1) cola de mensajes de S c2 → 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 → C1 m2 → C2 m3 → 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) m1 → C1 m2 → C2 m3 → libre Sistemas Distribuidos 45 c3 → lock(m3) 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Í) • Operación idempotente + al menos 1 vez ≈ exactamente 1 • 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 → lease(m1) c3 → lock(m3) cola de mensajes de S c2 → 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 • Menos “traumática”: problema de computación huérfana – Gasto de recursos inútil en el servidor • Alternativas: – 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 – Uso de leases: • Paradigma asíncrono y desacoplado en espacio – Editores y subscriptores no se conocen entre sí (≠ cliente/servidor) • Normalmente, push: suscriptor recibe evento – Alternativa, pull: suscriptor pregunta si hay eventos de interés – Híbrido: suscriptor recibe notificación pero tiene que solicitar evento – Pull e híbrido requieren que se almacenen eventos (+ complejo) • Servidor asigna lease mientras dura el servicio • Si cliente no renueva lease se aborta el servicio – Posibilitan 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 • Sistema de eventos distribuidos (Jini, s. eventos/notifi. CORBA) • Suscriptor S (subscriber): interés por ciertos eventos (filtro) • Editor E (publisher) genera un evento Fernando Pérez Costoya Operaciones modelo editor/subscriptor • Facilita uso en sistemas heterogéneos • Diversos aspectos relacionados con la calidad de servicio – orden de entrega, fiabilidad, persistencia, prioridad, transacciones,… Sistemas Distribuidos 50 Fernando Pérez Costoya Modelo editor/subscriptor • Estructura típica del evento: [atrib1=val1; atrib2=val2; …] – Un atributo puede ser el tema del evento • suscribe(tipo) [S→]: interés por cierto tipo de eventos Su1 • • • • Su2 suscribe(tipo5) notifica(ev5) Ed1 – Posible uso de leases en suscripción baja(tipo) [S→]: cese del interés publica(evento) [E→]: generación de evento notifica(evento) [→S]: envío de evento (push) Extensión de modelo: creación dinámica de tipos de eventos – anuncia(tipo) [E→]: se crea un nuevo tipo de evento – baja_tipo(tipo) [E→]: se elimina tipo de evento – notifica_tipo(tipo) [→S]: aviso de nuevo tipo de eventos • Ejemplos de aplicación – Mercado bursátil, subastas, chat, aplicación domótica, etc. Sistemas Distribuidos 51 Fernando Pérez Costoya Filtro de eventos por tema Su4 publica(ev5) suscribe(tipo5) notifica(ev5) suscribe(tipo1) Ed2 Ed3 Posible extensión: anuncio de nuevo tipo de evento (E→S) Sistemas Distribuidos 52 Fernando Pérez Costoya Filtro de eventos por contenido • 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 • Debe cumplirse condición sobre atributos del evento – Extensión del esquema previo: tema es un atributo del evento • Uso de lenguaje para expresión de la condición (≈ SQL) • Filtrado de grano más fino y dinámico – Ej. Interés en valores de mercado en alza • Ej. Creación de un nuevo valor en el mercado • Menor consumo de ancho de banda • Organización del espacio de temas: – Llegan menos datos a nodos subscriptor – Plano – Jerárquico: (Ej. bolsas_europeas/españa/madrid) – Uso de comodines en la suscripción • Más complejidad – Puede involucrar varios tipos de eventos • Filtrados adicionales deben hacerse en aplicación – En ocasiones filtro por tema resulta un grano demasiado grueso • Ej. Interesado en todas los valores de un ámbito de negocio Sistemas Distribuidos 53 Su3 suscribe(tipo3) Fernando Pérez Costoya • Gestión de eventos compuestos aumenta complejidad: – Ejemplo (Tanenbaum): – “Avísame cuando la habitación H420 esté desocupada más de 10 segundos estando la puerta abierta” Sistemas Distribuidos 54 Fernando Pérez Costoya Filtro de eventos por tipo Cliente/servidor vs. Editor/suscriptor • Aplicable sólo a sistemas distribuidos basados en objetos • Interés en un eventos de una determinada clase Cl Ed genera datos – Como es habitual, esa clase pertenece a una jerarquía de herencia genera datos • Permite ambos esquemas previos • Filtro por temas jerárquicos: – Clase = tema • Jerarquía de clases = Jerarquía de temas • Filtro por contenido – En suscripción, se especifica función de filtrado imprime datos almacena datos proyecta datos imprime datos almacena datos proyecta datos Se1 Se2 Se3 Su1 Su2 Su3 • Ventaja: las que proporciona todo el sistema de tipado – Pero requiere un sistema que use un esquema de objetos homogéneo Sistemas Distribuidos 55 Fernando Pérez Costoya Implementaciones editor/suscriptor ¿En cuál es más fácil añadir nuevo consumidor de datos? Sistemas Distribuidos 56 Fernando Pérez Costoya Implementación ed/su sin intermediario • Comunicación directa • Uso de intermediario (broker) • Uso de red de intermediarios Su1 Su2 – Distribución de eventos y aplicación de filtros “inteligente” Ed1 Ed2 Su3 • Posible uso de comunicación de grupo en cualquiera de ellas Su4 – Ej. Comunicación directa + comunicación de grupo Ed3 • Ed/Su basado en temas: tema = dirección de grupo Contacto directo ed./ suscr. ↓ Acoplamiento espacial Sistemas Distribuidos 57 Fernando Pérez Costoya Implementación ed/su con intermediario Su1 Su2 Ed1 Int. Fernando Pérez Costoya Implementación ed/su con red interm. Su1 Int. Su2 Ed2 Su3 Su4 Sistemas Distribuidos 58 Su3 Ed3 Su4 Int. Int. Int. Int. Int. Ed1 Int. Ed2 Int. Ed3 Proceso intermediario ↑ Desacoplamiento espacial Red de intermediarios ↓ Cuello botella y punto fallo ↑ Desacoplamiento espacial ↑ Escalabilidad y fiabilidad Sistemas Distribuidos 59 Fernando Pérez Costoya Sistemas Distribuidos 60 Fernando Pérez Costoya 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 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. 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 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. 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. 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 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). 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. 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. 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 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. 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. 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 4 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. 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 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 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.