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