Grado de acoplamiento Modelo cliente/servidor Esquema cliente

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