Grado de acoplamiento Modelo cliente/servidorlaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sd/sd_arquitectur… · Normalmente, acoplamiento espacial y temporal Servidor ofrece

Fernando Pérez CostoyaSistemas Distribuidos

1

Grado de acoplamiento

Sea cual sea el modelo, conlleva interacción entre entidadesInteracción tradicional implica acoplamiento espacial y temporalDesacoplamiento espacial (de referencia)

Entidad inicia interacción no hace referencia directa a la otra entidadNo necesitan conocerse entre sí

Desacoplamiento temporal (menos frecuente)no tienen que coincidir

Ej. de ambos desacoplamientos: memoria compartida2 desacoplamientos son independientes entre sí

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 indirectionFernando Pérez CostoyaSSistemas Distribuidos

2

Modelo cliente/servidor

Arquitectura asimétrica: 2 roles en la interacciónCliente: Solicita servicio

Activo: inicia interacciónServidor: Proporciona servicio

Pasivo: responde a petición de servicio

Desventajas de arquitectura cliente/servidorproblemas de escalabilidad

Servidor punto crítico de falloMal aprovechamiento de recursos de máquinas cliente

Normalmente, acoplamiento espacial y temporalServidor ofrece colección de servicios que cliente debe conocerNormalmente, petición especifica recurso, operación y args.

NFS: READ, file_handle, offset, countHTTP: GET /index.html HTTP/1.1


3

Esquema cliente/servidor

Cliente Servidor

Interfaz de ServicioPetición (args.)

Respuesta

Resp=Código(args)

Alternativas en diseño de la interfaz de servicioOperaciones específicas para cada servicio

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 CostoyaSSistemas Distribuidos

4

Reparto funcionalidad entre C y S

¿Qué parte del trabajo realiza el cliente y cuál el servidor?

Pesados (Thick/Fat/Rich Client) vs. Ligeros (Thin/Lean/Slim Client)

Ventajas de clientes ligerosMenor coste de operación y mantenimientoMejor seguridad

Ventajas de clientes pesadosMayor autonomíaMejor escalabilidad

Cliente gasta menos recursos de red y de servidorMás ágil en respuesta al usuario


5

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 negocioAcceso a datos

¿Qué labor de la aplicación se le asigna a máquina cliente?

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 GUIGUI + parte de la lógica de negocioGUI + lógica de negocioGUI + lógica de negocio + parte de lógica de acceso


6

Cliente/servidor con caché

Mejora latencia, reduce consumo red y recursos servidorAumenta escalabilidad

Mejor operación en SD La que no usa la red

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 desconectadoCODAHTML5 Offline Web Applications

Pre-fetching: puede mejorar latencia de operaciones peroSi datos anticipados finalmente no requeridos: gasto innecesario

Para arreglar la falacia 2 hemos estropeado la 3


7

Cliente/servidor con proxy

Componentes intermediarios entre cliente y servidor

Pueden procesar/filtrar información y/o realizar labor de cachéSímil con clases FilterInputStream|FilterOutputStream de Java

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

proxies de forma transparenteEsta característica es una de las claves del éxito de la Web


8

Cliente/servidor jerárquico

Servidor actúa como cliente de otro servicioIgual que biblioteca usa servicio de otra biblioteca

División verticalFuncionalidad dividida en varios niveles (multi-tier)P. ej. Aplicación típica con 3 capas:

PresentaciónAplicación: lógica de negocioAcceso a datos

Cada nivel puede implementarse como un servidor

División horizontalMúltiples servidores idénticos cooperan en servicioTraducir un nombre de fichero en SFDTraducir de nombre de máquina a IP usando DNS


9

Esquema multi-servidor

Servidor único:Cuello de botella: afecta a latencia y ancho de bandaPunto ú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)Escalado horizontal (scale-out)Mejora latencia, escalabilidad y tolerancia a fallosRequiere esquema de reparto de carga

Si servicio requiere datos replicados (p.e. DNS, Google FS)Necesidad (y sobrecarga) de mantener coherencia entre las réplicasEsquema simétrico: Actualización simultánea en todas las réplicasEsquema asimétrico: Actualizar en primario y propagar a secundarios

Push: primario envía cambios a secundariosPull: secundario solicita cambios a primario


10

Scale-up vs Scale-out

p p p p p

p

C

C

C

C

C

C

C

C

C

SS

S

S

S


11

Código móvil

Viaja el código en vez de los datos y/o resultadosRequiere:

Arquitecturas homogéneas oInterpretación de código oMáquinas virtuales

Modelos alternativosCódigo por demanda (COD)

Servidor envía código a clienteP.e. applets

Evaluación remota (REV)Cliente dispone de código pero ejecución debe usar recursos servidorP.ej. Cyber-Foraging

Agentes móvilesComponente autónomo y activo que viaja por SD


12

Código por demanda

Cliente Servidor

Interfaz de ServicioPetición

Código

Resp=Código(args)


13

Evaluación remota

Cliente Servidor

Interfaz de Servicio

Resp=Código(args)

Petición(args)+Código

Respuesta


14

Localización del servidor

Servidor en máquina con dirección DM y usando puerto PS¿Cómo lo localiza el cliente? Binding

Otro servidor proporciona esa información problema huevo-gallina

Binder: mantiene correspondencias ID servicio (DM, PS)Cliente debe conocer dirección y puerto del Binder

Características deseables de ID de servicio:Ámbito globalMejor nombre de texto de carácter jerárquico (como pathname)Transparencia de ubicaciónPosible replicación: ID servicio (DM1, PS1) | (DM2, PS2) ....Convivencia de múltiples versiones del servicio

Suele estar englobado en un mecanismo más generalServicio de nombres (tema 4): Gestiona IDs de todos los recursos


15

Alternativas en la ID del servicio

1. Uso directo de dirección DM y puerto PSNo proporciona transparencia

2. Nombre servicio + dir servidor (Java RMI Registry, Sun RPC)Servidor (binder) en cada nodo: nombre de servicio puertoImpide migración del servidor

3. Nombre de servicio con ámbito global (DCE, CORBA, Mach)Servidor con ubicación conocida en el sistemaDos opciones:a) Sólo binder global: nombre de servicio [DM+PS]b) Opción: binder global (BG) + binder local (BL) en puerto conocido

BG: ID [DM] ; BL: ID [PS]

Uso de caché en clientes para evitar repetir traducciónMecanismo para detectar que traducción en caché ya no es válida


16

M1 M2

(1) ID servicio = [DM+pto]

DM2 + ptoSDM2 + ptoSC S

Dirección de servicioInfo. de contacto

1


17

S

(2) ID servicio = [DM+idsrv]: Alta

DM2 + ptoS

DM2+idsrv

DM2 + ptoBM1

C

M2

binderIdsrv ptoS

Binder ptoB

M2

Idsrv ptoS

Binder ptoB

1

2

Info. conocida Mensaje Info. binder


18

S

(2) ID servicio = [DM+idsrv]: Consulta

DM2 + ptoS

DM2 + ptoBM1

C

M2

binderIdsrv ptoS

Binder ptoB

M2Binder ptoB

¿idsrv?1

ptoS

2

DM2+idsrv


19

S

(3a) ID servicio = [idsrv]; Sólo BG: Alta

DM2 + ptoS

idsrv

DM3 + ptoBM1

C

M3

binderIdsrv DM2 + ptoS

M2binder DM3+ptoB

1

2

binder DM3 +ptoB

Idsrv DM2 + ptoS


20

S

(3a) ID servicio = [idsrv]; Sólo BG: Consulta

DM2 + ptoS

idsrv

DM3 + ptoBM1

C

M3

binder

M2

¿idsrv?1

2

idsrv DM2 + ptoS

binder DM3+ptoB

binder DM3 +ptoB

DM2 + ptoS


21

S

(3b) ID servicio = [idsrv]; BG+BL: Alta

DM2 + ptoS

idsrv DM2 + ptoL

M1

C

M2

BLIdsrv ptoS

M2 1

2

BL ptoL | BG DM3+ptoB

Idsrv ptoS

DM3 + ptoB

M3

BG


Idsrv DM2

3

Idsrv DM24Fernando Pérez CostoyaSSistemas Distribuidos

22

S

(3b) ID servicio = [idsrv]; BG+BL: Consulta

DM2 + ptoS

idsrv DM2 + ptoLM1

C

M2

BL

Idsrv ptoS

M2


DM3 + ptoB

M3

BG

Idsrv DM2

¿idsrv?

1¿idsrv?

DM2

ptoS2

3



23

Recapitulación del Binding

Caso con BG y BL + versiones:Servidor:

Elige puerto localInforma a binder local del alta:

(id. servicio + versión) = puertoInforma a binder global del alta:

(id. servicio + versión) = dir máquinaAl terminar, notifica la baja a ambos binder :

Ambos eliminan (id. servicio + versión)Cliente:

Consulta a binder global (id. servicio + versión) dir. máquina

Consulta a binder en dir. máquina(id. servicio + versión) puerto


24

Servicio a múltiples clientes

Servidor concurrente (p.e. servidor web Apache)Un flujo de ejecución atiende sólo una petición en cada momentoSe bloquea esperando datos de ese cliente y envía respuesta

Servidor basado en eventos (p.e. servidor web Nginx)Un flujo de ejecución atiende múltiples peticiones simultáneamenteEspera (y trata) evento asociado a cualquiera de las peticiones

Evento: actividad asociada con 1 petición (p.e. llegada datos de cliente)Implementación en UNIX de espera simultánea; alternativas:

select/poll/epoll; uso de señales de t.real; operaciones asíncronas (aio)Para aprovechar paralelismo HW: un flujo de ejecución/procesador

Servidor concurrente vs. basado en eventos:Peor escalabilidad (The C10K problem: http://kegel.com/c10k.html)

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


25

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 peticionesSobrecarga de creación y destrucción

Conjunto (pool) de N T/P pre-arrancados:Al finalizar trabajo, en espera de más peticionesPoca carga gasto innecesarioMucha carga insuficientes

Esquema híbrido con mínimo m y máximo Mm pre-arrancados; m T/P MSi petición, ninguno libre y nº < M se creaSi inactivo tiempo prefijado y nº > m se destruye


26

Gestión de conexiones

En caso de que se use un esquema con conexión1 conexión por cada petición

1 operación cliente-servidorconexión, envío de petición, recepción de respuesta, cierre de conexión

Más sencillo pero mayor sobrecarga (¡9 mensajes con TCP!)Protocolos de transporte orientados a C/S (T/TCP, TCP Fast Open)

Conexiones persistentes: N peticiones cliente misma conexión Más complejo pero menor sobrecargaEsquema usado en HTTP/1.1 (además, pipeline de peticiones)Dado que servidor admite nº limitado de conexiones

Dificulta reparto de servicio entre clientesImplica que servidor mantiene un estadoDificulta reparto de carga en esquema con escalado horizontalFacilita server push


27

Evolución de HTTP

Cliente necesita pedir varios objetos al mismo servidorHTTP/1.0

Sobrecarga conexiones + latencia de conexiones y peticiones

HTTP/1.0 + conexiones persistentes

Latencia de peticiones

HTTP/1.1 (conexiones persistentes + pipeline de peticiones)

No latencia acumuladaServicio paralelo de peticiones

aunque respuestas deben llegar en orden


28

HTTP: conexiones simultáneas

Paralelismo también mediante conexiones simultáneasHTTP/1.0

Connect | GET | Resp | Close

Connect | GET | Resp | Close

HTTP/1.0 + conexiones persistentes

HTTP/1.1 (conexiones persistentes + pipeline de peticiones)


29

Client Pull vs Server Push

C/S: modo pull

Escenario: servidor dispone de información actualizadaP.e. retransmisión web en modo texto de acontecimiento deportivoP.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 hayLong Polling: Servidor no responde hasta que tenga datosServer Push

Cliente mantiene conexión persistente y servidor envía actualizacionesWeb: HTTP Server Push, Server-Sent Events, Web Sockets

Usar editor/subscriptor en vez de cliente/servidor


30

Servicio con/sin estado

¿Servidor mantiene información de clientes?Ventajas de servicio con estado (aka con sesión remota):

Mensajes de petición más cortosMejor 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 RESTEstado sobre servicios sin estado

Cliente almacena estado y lo envía al servidor (p.e. HTTP+cookies)


31

C S

Servicio de ficheros con estado: OPEN

x

N | pos 0x

x3


32

C

read(3,b,t)

Servicio de ficheros con estado: READ

DATOS, tl (leído)

READ, x, tN | ant+tlx

x3

S


33

C

lseek(3,m,p)

Servicio de ficheros con estado: LSEEK

p

LSEEK,x,m=SEEK_SET,pN | pos px

x3

S


34

C

close(3)

Servicio de ficheros con estado: CLOSE

OK

CLOSE, x-x

-3

S


35

C

Servicio de ficheros sin estado: OPEN

NN | pos 03

S


36

C

read(3,b,t)

Servicio de ficheros sin estado: READ

DATOS, tl (leído)

READ, N, ant, tN | ant+tl3

S


37

C

lseek(3,m,p)

Servicio de ficheros sin estado: LSEEK

N | pos p3

S


38

C

close(3)

Servicio de ficheros sin estado: CLOSE

-3

S


39

Leases

Mecanismo para mejorar tolerancia a fallos en SDDetección y tratamiento de caídas de nodos

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

Modo de operaciónA otorga a B un lease que dura un plazo de tiempoB debe enviar a A mensaje de renovación lease antes de fin de plazoSi B cae y no renueva leaseSi A cae, en reinicio obtiene renovaciones

No confundir con un simple temporizadorProceso envía petición a otro y arranca temporizador

Si se cumple antes de ACK, vuelve a enviar petición ( lease)Fernando Pérez CostoyaSSistemas Distribuidos

40

Aplicaciones de leases

Aparecerán a menudo: Binding, caídas del cliente, suscripción en Ed/Su, caché de SFD, etc.

Leases en servicios con estadoAlgunos servicios son inherentemente con estado

P. ej. cerrojos distribuidos

Uso de leases en servicio de cerrojos distribuidoServidor asigna lease a cliente mientras en posesión de cerrojoClientes en posesión de cerrojos deben renovar su lease

Rearranque de S: debe procesar primero peticiones de renovaciónTiempo de reinicio de servicio > tiempo de renovación

Reconstrucción automática de estado después de re-arranque de SCaída de cliente: falta de renovación

Revocación automática de cerrojos de ese cliente


41

Serv. cerrojos con estado: leases (1)

S

lock(m1)

..............

unlock(m1)

C1

m1 librem2 C2m3 libre

lock(m2)

..............

unlock(m2)

C2

lock(m3)

..............

unlock(m3)

C3

c1 lock(m1)c2 lease(m2)

cola de mensajes de S


42


S

lock(m1)

..............

unlock(m1)

C1

m1 C1m2 C2m3 libre

lock(m2)

..............

unlock(m2)

C2

lock(m3)

..............

unlock(m3)

C3

cola de mensajes de Sc1 lease(m1)c2 lease(m2)


43


S

lock(m1)

..............

unlock(m1)

C1

m1 C1m2 C2m3 libre

lock(m2)

..............

unlock(m2)

C2

lock(m3)

..............

unlock(m3)

C3

cola de mensajes de S


44


S

lock(m1)

..............

unlock(m1)

C1

lock(m2)

..............

unlock(m2)

C2

lock(m3)

..............

unlock(m3)

C3

cola de mensajes de Sc1 lease(m1)c3 lock(m3) c2 lease(m2)

Ø Treinicio>Tlease


45


S

lock(m1)

..............

unlock(m1)

C1

m1 C1m2 C2m3 libre

lock(m2)

..............

unlock(m2)

C2

lock(m3)

..............

unlock(m3)

C3

c3 lock(m3) cola de mensajes de S


46

Comportamiento del servicio ante fallos

¿Qué se garantiza con respecto al servicio ante fallos?Nada: Servicio puede ejecutar 0 a N vecesAl 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Í)

Tipos de fallos:Pérdida de petición o de respuesta (sólo si comunicación no fiable)Caída del servidorCaída del cliente


47

Fallos con comunicación fiable

Si cae servidor no siempre puede saber si ejecutado servicioSemántica de como mucho una vez

Si llega respuesta, se ha ejecutado exactamente una vezSi 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 plazoUsar un sistema de transacciones distribuidas


48

Fallos con comunicación no fiable

Pérdida de petición/respuestaSi no respuesta, retransmisión cuando se cumple plazoNº de secuencia en mensaje de peticiónSi pérdida de petición, retransmisión no causa problemasSi pérdida de respuesta, retransmisión causa re-ejecución

Si operación idempotente, no es erróneo pero gasta recursosSi 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 servidorSi llega finalmente respuesta, semántica de al menos una vezSi no llega, no hay ninguna garantía (0 a N veces)


49

Caída del cliente

Gasto de recursos inútil en el servidor

Alternativas:Uso de épocas:

Peticiones de cliente llevan asociadas un nº de épocaEn rearranque de cliente C: transmite (++nº de época) a servidoresServidor aborta servicios de C con nº de época menor

Uso de leases:Servidor asigna lease mientras dura el servicioSi cliente no renueva lease se aborta el servicio

Abortar un servicio no es trivialPuede dejar incoherente el estado del servidor (p.e. cerrojos)En ocasiones puede ser mejor no abortar


50

Modelo editor/subscriptor

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

Paradigma asíncrono y desacoplado en espacio

Normalmente, push: suscriptor recibe eventoAlternativa, pull: suscriptor pregunta si hay eventos de interésPull requiere que se almacenen eventos (+ complejo)

Posibilita mecanismo desacoplado en el tiempo

Facilita uso en sistemas heterogéneosDiversos aspectos relacionados con la calidad de servicio

Ejemplos: Mercado bursátil, subastas, chat, app domótica, etc.


51

Operaciones modelo editor/subscriptor

Estructura típica del evento: [atrib1=val1; atrib2=val2;Un atributo puede ser el tema del evento

suscribe(tipo) [S ]: interés por cierto tipo de eventos Posible uso de leases en suscripción

baja(tipo) [S ]: cese del interéspublica(evento) [E ]: generación de eventonotifica(evento) [ S]: envío de evento (esquema push)obtiene() [S ]: lee siguiente(s) evento(s) (esquema pull)

Puede ser bloqueante o no (si no hay eventos, respuesta inmediata)

Extensión de modelo: creación dinámica de tipos de eventosanuncia(tipo) : se crea un nuevo tipo de eventobaja_tipo(tipo): se elimina tipo de eventonotifica_tipo(tipo) [ S]: aviso de nuevo tipo de eventos


52

Modelo editor/subscriptor (push)

Ed1Su1

Su2

Su3

Su4

Ed2

Ed3

suscribe(tipo5)

suscribe(tipo3)

baja(tipo1)

publica(ev5)

notifica(ev5)

suscribe(tipo5)

notifica(ev5)


53

Modelo editor/subscriptor (pull)

Ed1Su1

Su2

Su3

Su4

Ed2

Ed3

suscribe(tipo5)

suscribe(tipo3)

baja(tipo1)

publica(ev5)

obtiene()

suscribe(tipo5)

obtiene()


54

Filtro de eventos por tema

S se subscribe a tema y recibe notificaciones sobre el mismoTemas disponibles:

Carácter estático: implícitamente conocidosCarácter dinámico: uso de operación de anuncio

Ej. Creación de un nuevo valor en el mercado

Organización del espacio de temas:PlanoJerárquico: (Ej. bolsas_europeas/españa/madrid)Uso de comodines en suscripción (Ej. bolsas_europeas/españa/*)

Filtrados adicionales deben hacerse en aplicaciónEj. Interesado en valores inmobiliarios de cualquier bolsa española

Aplicación debe subscribirse a todas las bolsas españolas ydescartar todos los eventos no inmobiliarios


55

Filtro de eventos por contenido

Debe cumplirse condición sobre atributos del eventoExtensión del esquema previo: tema es un atributo del evento

Filtrado de grano más fino y dinámico que usando temasEj. Interés en valores inmobiliarios de cualquier bolsa española

Menor consumo de ancho de bandaLlegan menos datos a nodos subscriptor

Simplifica app. subscriptora pero complica esquema Ed/SuPuede involucrar varios tipos de eventos de forma complejaEjemplo (Tanenbaum):

Avísame cuando la habitación H420 esté desocupada más de 10

segundos estando la puerta abierta


56

Cliente/servidor vs. Editor/suscriptor

generadatos

Cl

imprimedatos

Se1

almacenadatos

Se2

proyectadatos

Se3

generadatos

Ed

imprimedatos

Su1

almacenadatos

Su2

proyectadatos

Su3

¿Y si queremos que generador sepa cuándo ha procesado datos cada consumidor?¿En cuál es más fácil añadir nuevo consumidor de datos?


57

Implementaciones editor/suscriptor

Comunicación directaNo proporciona desacoplamiento espacial

Uso de intermediario (broker)Desacoplamiento espacial pero cuello de botella y único punto de fallo

Uso de red de intermediarios

Posible uso de comunicación de grupo en cualquiera de ellasEj. Comunicación directa + comunicación de grupo

Ed/Su basado en temas: tema = dirección de grupo


58

Implementación ed/su sin intermediario

Ed1Su1

Su2

Su3

Su4

Ed2

Ed3

Contacto directo ed./ suscr.

Acoplamiento espacial


59

Implementación ed/su con intermediario

Ed1Su1

Su2

Su3

Su4

Ed2

Ed3

Proceso intermediario

Desacoplamiento espacial

Cuello botella y punto fallo

Int.


60

Implementación ed/su con red interm.

Ed1Su1

Su2

Su3

Su4

Ed2

Ed3

Red de intermediarios

Desacoplamiento espacial

Escalabilidad y fiabilidad

Int.

Int.Int.

Int.

Int.

Int.

Int.

Int.


61

Paradigmas de comunicación

Paso de mensajes Comunicación punto a punto

Comunicación de grupo

Sistemas de colas de mensajes (Message-oriented middleware)Paso de mensajes persistentes

Invocación de métodos remotos (RMI)

Servicios web Sistemas orientados a serviciosMemoria compartida (tema 5)

Distributed Shared MemoryEspacios de tuplas


62

API de paso de mensajes

MPIint 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 datagramassize_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 desconectarOperaciones de envío y recepción no incluyen direcciones


63

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 1

O cualquiera (MPI_ANY_SOURCE): interacción N 1Difícil asignar nº proceso único en entorno de propósito general

Pero no en aplicación ejecutada en entorno de computación paralela

Usando puertos: buzón asociado a una máquina (sockets)Comunicación entre puertosProceso reserva uso de un puerto de su máquina (bind de sockets)Envío: desde puerto origen local a puerto destino especificadosRecepción: de puerto local; interacción N 1Sockets INET: ID puerto = dir. IP + nº puerto + protocolo (TCP|UDP)

Usando colas: buzón de carácter global; interacción N NSistemas de colas de mensajes; desacoplamiento espacial+temporal


64

Modos de interacción punto-a-punto

nº proceso: 1 1

puerto: N 1

cola: N N


65

Especificación del mensaje

Con o sin información de tipos (MPI vs. sockets)Sin ella: aplicación debe gestionar heterogeneidadCon 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 enviadoRecepción: especifica clase de mensaje que se quiere recibir

o usa comodín (MPI_ANY_TAG)Múltiples canales sobre una misma comunicaciónDiversas aplicaciones como por ejemplo:

Establecer prioridades entre mensajesEn cliente-servidor puede identificar operación a realizarEn 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)


66

Zero-Copy

Escenario 1: envío de N datos dispersos de emisor a receptorN envíos: sobrecarga de llamada de as + fragmentación de mensajesReserva de buffer y 1 envío: sobrecarga de copiasFunciones scatter/gather: minimizar copias y llamadas

UNIX: readv, writev, sendmsg, recvmsg

Escenario 2: envío de un ficheroUso de operaciones convencionales de lectura y envío

Dos copias de memoria: de buffer de sistema a de usuario y viceversaUso de proyección de ficheros (mmap) y envío

Una copia de memoria a buffer de sistema en envíoUso de operaciones de transferencia directa entre descriptores

No requiere copias entres buffers; reduce nº llamadas al sistemaLinux: sendfile, splice


67

Datos dispersos: Envío múltiple

dir1

dir2

dir3

tipo1

tipo2

tipo3

tam3

tam2

tam1

Envía(dest, dir2, tam2, ...)




68

Datos dispersos: Envío con copia

dir1

dir2

dir3

tipo1

tipo2

tipo3

tam3

tam2

tam1

Envía(dest, dir, tam, ...)COPIA

dir

tam


69

Datos dispersos: Envío gather

dir1

dir2

dir3

tipo1

tipo2

tipo3

tam3

tam2

tam1

Envía(dest,dir1,tam1,dir2,tam2,dir3,tam3,...)


70

Datos dispersos: Recepción scatter

dir1

dir2

dir3

tipo1

tipo2

tipo3

tam3

tam2

tam1

Recibe(org,dir1,tam1,dir2,tam2,dir3,tam3,...)


71

Envío convencional de fichero

Proceso

SO

buffer desistema

buffer desistema

buffer deusuario


72

Envío con proyección de fichero

Proceso

SO

buffer deusu|sis

buffer desistema


73

Envío zero-copy de fichero

Proceso

SO

buffer desistema


74

Serialización de datos

Emisor y receptor misma interpretación de informaciónMisma cuestión, y soluciones, para lector y escritor de un fichero

Procesadores, lenguajes, compiladores difieren en:Orden de bytes en tipos numéricos (endian)

Strings (con longitud vs. carácter terminador (¿qué carácter?))Formatos de texto (ISO-8859-1, UTF-

serializarAsegurando misma interpretación en sistema heterogéneoEficientemente (en serializaciónFacilitando la programación de la serializaciónAdmitiendo cambios incrementales en protocolo

P.e. protocolo con nuevo campo opcional pero cliente antiguo sigue OK


75

Marshalling

Operación para serializar información en emisorY la operación inversa (unmarshalling) en receptor

Con paso de mensajes puede ser:Responsabilidad del programador (sockets)

Sockets tampoco ofrece funciones serialización (excepto para int: htonlAutomático (MPI)

RPC/RMI lo realizan automáticamenteAlternativas:

S. de comunicación en emisor convierte a formato de receptortransformar a formato de cualquier receptor

S. de comunicación en receptor convierte a su formatotransformar desde formato de cualquier emisor

S. de comunicación en emisor convierte a formato externoSólo transformar de nativo a externo y viceversa


76

Formato de serialización de datos

Define cómo se transmiten/almacenan datos (wire protocol)Secuencia de bits que representan cada dato

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ámetrosno viaja info. de tipos con datos

Explícita: disponible información explícita de tiposViaja mezclada con datos o como referencia a un esquema

Explícita más flexible (permite reflexión) pero menos compactoInformación de nombres de campos implícita vs. explícita:

Explícita: viaja nombre de campo con datosPuede facilitar cambios incrementales de un protocolo

Información explícita de campos y tiposFunción de deserialización genérica


77

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/almacenarPermite 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 nativosAplicación usa tipos nativos generados y API para (de)serializar

API hipotético para serialización

Si información de tipos/campos explícita: Decode(buffer)

Puede estar integrado en entorno de RPC/RMI¡Buenas noticias!: Programador no realiza serializaciónCódigo generado usa automáticamente API de serialización


78

Ejemplos de formatos de serialización

XDR (RFC 1832): binario, info. implícita campos y tiposSoluciones basadas XML: texto, inf. explícita campos y tipos

Info de tipos mediante referencia a XML Schema

JSON: texto, info. explícita campos y tiposProtocol Buffers (Google): binario, no explícita campos y tipos

Pero sí viaja ID único y longitud de cada campo con datosFacilita cambios incrementales en protocolo

Java Serialization: binario, info. explícita campos y tiposInfo de campos y tipos mezclada con datos; no requiere IDL

Wikipedia: Comparison data serialization formats

Ejemplos: http://laurel.datsi.fi.upm.es/~ssoo/SD.dir/serializacion


79

XDR

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); // serializawrite(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); // deserializaprintf("id %d nombre %s\n", d.id, d.nombre);

Contenido = 12 bytes: Fernando Pérez CostoyaSSistemas Distribuidos

80

JSON (wikipedia)


81

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

var p = JSON.parse(buf); // Deserialización genérica

alert(p.nombre + " " + p.tfno);

</script></body></html>


82

Protocol Buffers (con C++)

Especificación (fichero .proto)

Serialización a un fichero (C++)

Deserialización desde un fichero (C++)


83

Java Serialization

public class Dato implements Serializable {int id; String nombre; public Dato(int i, String n) {id = i; nombre = n; }}

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

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

Contenido = ¡69 B!; http://www.javaworld.com/article/2072752/the-java-serialization-algorithm-revealed.html


84

El precio de un entero (a=150)

https://developers.google.com/protocol-buffers/docs/encoding

struct dato {int a;}; 00 00 96 00 XDR

Definición Contenido Formato

var d=new Object(); d.a=150; JSON

public class D implements Serializable {int a;} 30B Java


85

Grado de sincronía y buffering

Po envía M a Pd: copia entre buffers de procesos: BPo BPdAdemás puede haber buffers en nodo emisor BNe y/o receptor BNr

Minimizar copias entre buffers (ideal: zero copy)

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 seguroFin de operación o mensaje copiado en algún buffer (BNe o BNr)

Requiere operación para comprobar si ya se puede reutilizar2. Envío devuelve control después de BPo BNe

Po puede reutilizar BPo, pero posible bloqueo si BNe lleno3. Envío devuelve control cuando M llega a nodo receptor (BNr)

No requiere BNe; ACK de Nr a Ne4. Envío devuelve control cuando M llega a Pd (BPd)

No requiere BNe ni BNr; ACK de Nr a Ne5. Envío devuelve control cuando Pd tiene respuesta

No requiere BNe ni BNr: BPo BPd ; respuesta sirve de ACK


86

M

Ne

BPo

Nr

BPd

Posibles buffers en comunicación

BNe

R

BNr


87

M

Ne

BPo

Nr

BPd

Retorno inmediato


88

M

Ne

BPo

Nr

BPd

Retorno después de copia local

MBNe


89

M

Ne

BPo

Nr

BPd

Retorno después de llegada

MBNrM

ACK


90

M

Ne

BPo

Nr

BPd

Retorno después de recepción

M

ACK

M


91

M/R

Ne

BPo

Nr

BPd

Retorno después de respuesta

M

R/M

R


92

Modo de operación en recepción

Recepción generalmente bloqueanteOpción no bloqueante: retorna si no hay datosOpción asíncrona:

Especifica buffer donde se almacenará el mensaje yRetorna inmediatamenteS. comunicaciones realiza recepción mientras proceso ejecuta

Espera temporizada: se bloquea un tiempo máximoEspera múltiple: espera por varias fuentes de datos


93

Sockets: grado de sincronía y buffering

Modo de operación de envío tipo 2Retorno después de copia local con bloqueo si buffer local llenoBuffer reservado por SO

Si aplicación no quiere bloquearse en envío:Usar modo no bloqueante en descriptor socket: error si buffer llenoUsar select/poll/epoll para comprobar que envío no bloqueaUsar E/S asíncrona (aio_write): modo de envío tipo 1

Modo de operación de recepción bloqueanteSi aplicación no quiere bloquearse en recepción:

Usar modo no bloqueante en descriptor socket: error si buffer vacíoUsar select/poll/epoll para comprobar que hay datos que recibirUsar E/S asíncrona (aio_read)

Espera múltiple temporizada mediante select/poll/epoll


94

Adecuación a arquitecturas del SD

Paso de mensajes adecuado para cualquier arquitecturaPero cuidado con su asimetría: uno envía y otro recibe

Cliente/servidor: su asimetría encaja con la del paso mensajes Cliente: envía petición y recibe respuestaServidor: recibe petición y envía respuesta

Editor/subscriptor: su asimetría no siempre encaja con p. mens.Si pull con intermediario I: buen encaje

Si push con intermediario I: encaje problemáticoSu envía suscripción(evento X) y espera confirmación de IPero justo antes I envía notificación de evento Y a SuSoluciones: uso de múltiples puertos y concurrencia en subscriptor

P2P: arquitectura simétrica¿Quién envía y quién recibe?


95

Paso de mensajes y arquitecturas

C Senvío

reciborecibo

envío OK

S

petic.

resp.C/S

Eenvío

recibo reciboenvíosusc.| cons.

resp.E/S pull OKrecibo

envío Inotif

resp.

S Eenvío

recibo reciboenvíosusc. ev. XE/S push recibo

envío Inotif. ev. Y

notif. ev. Y

P1 P2envío

recibo recibo

envíopetic. recurso A

P2Ppetic. recurso B


96

Multidifusión: comunicación de grupo

Destino de mensaje grupo de procesosEnvío/recepción especifican dirección de grupos de procesosDesacoplamiento espacial

Trabajo seminal: ISIS (posteriores Horus, Ensemble, JGroups)Adecuación a arquitectura del SD:

Cliente-servidor replicadoFacilita actualizaciones múltiples

Modelo editor/subscriptorEnvío de notificaciones (p.e. 1 grupo/tema)

Arquitecturas para CDOperaciones colectivas en proc. paralelo (pueden incluir cálculos)

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)


97

Aspectos de diseño de com. de grupo

Atomicidad: o reciben el mensaje o ningunoCon unidifusión fiable (TCP): en medio, se puede caer emisorCon multicast IP: pérdida de mensajes

Orden de recepción de los mensajesFIFO: mensajes de misma fuente llegan en orden de envío

No garantía sobre mensajes de distintos emisoresCausal -

Si no hay relación, no garantiza ningún orden de entrega Total: Todos los mensajes recibidos en mismo orden por todos

El grupo suele tener carácter dinámicoSe pueden incorporar y retirar procesos del grupoGestión de pertenencia debe coordinarse con la comunicación

Virtual Synchrony


98

Orden FIFO

P1

P2

P4

P3

m1 m2

m3

m4


99

Mantenimiento de orden FIFO

Nodo Ni almacena vector de contadores Vi (1 posición/nodo)Vi[i] : nº último mensaje enviado por Ni

Ni envía mensaje M que incluye contador Cm:Vi[i]++; Cm=Vi[i]

Nj recibe mensaje M de NiNo se entrega M si Cm > Vj[i] + 1

No han llegado todavía mensajes previos de NiRetenido hasta que lleguen mensajes de Ni que faltan [Vj[i] + 1, Cm)

En entrega: Vj[i]=Cm


100

Mantenimiento de orden FIFO

P1

P2

P4

P3

10001 2

3

0000

0000

0000

0000 2000 3000

m1 m2

1000

1000 2000

3000

1

m32100 3100

2000 3100

m4

2100 31002000mensaje entregado mensaje retenido


101

Orden causal

P1

P2

P4

P3

m1 m2

m3

m4


102

Mantenimiento de orden causal

Nodo Ni almacena vector de contadores Vi (1 posición/nodo)Vi[i] : nº último mensaje enviado por Ni

Ni envía mensaje M que incluye vector Vm: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])

O bien No han llegado todavía mensajes de Nk que ya ha recibido NiRetenido hasta que lleguen mensajes de Nk que faltan [Vj[k] +1 , Vm[k]]

En entrega: Vj[i]=Vm[i]


103

Mantenimiento de orden causal

P1

P2

P4

0100

P3

1100 2100

1200

0000

0000

0000

0000

0100

m1

0100

01001100

m2

1100

1100

1100

2100m3

1200

m42200

2200

2200

2200

1100 1200

1200


104

Orden total

P1

P2

P4

P3

m2

m1


105

Mantenimiento de orden total

Por simplicidad, sólo solución basada en secuenciador S

Proceso S en el sistema asigna número único a cada mensajeS gestiona contador creciente Cs para cada grupo

Ni envía mensaje de datos M: a todos miembros grupo G + SMensaje de datos M no incluye contador; sólo algún tipo de ID de M

Recepción de M en S:Cs++; asigna Cs a MEnvía a miembros G mensaje especial Ms = {ID de M, Cs}

Nodo Ni incluye Ci: nº próximo mensaje Ms que espera recibirRecepción de M en Ni: siempre se retieneRecepción de Ms = {ID de M, Cs} en Ni:

Ms retenido hasta que recibido M y Cs == Ci entrega de M


106

MOM Sistemas de colas de mensajes

Message-oriented middleware: WebSphere MQ, MSMQ, JMSAMQP protocolo estándar para MOM

Destinatario debe estar presente cuando se recibe mensaje

No es necesario que proceso receptor esté presenteSistema de comunicación (p.e. red de intermediarios) guarda mensaje

Comunicación desacoplada en espacio y tiempoAPI típico:

SEND: envía mensaje a colaRECEIVE: recibe mensaje de cola (bloqueante)POLL: recibe mensaje de cola (no bloqueante)NOTIFY: proceso pide ser notificado cuando llegue mensaje a cola


107

Sistema de colas de mensajes

Distributed Systems: Concepts and Design. G. Coulouris et al.


108

MOM Sistemas de colas de mensajes

2 modelos de comunicación habituales:Basado en colas punto-a-puntoBasado en temas editor/subscriptor

Adecuación a arquitecturas de SDC/S: punto-a- -servidor con reparto automático de cargaEd/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 transaccionesTransformaciones de mensajes

Apropiado para integración de aplicaciones de empresa (EAI)

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 1 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 2 de 2

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 1 de 4

a. ESH


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


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 auto-contenidas (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


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


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 2 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 editor-subscriptor.

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


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


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 3 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 4 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 1 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


• 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) pushc. (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 2 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 3 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 bindersc. 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 4 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 1 de 4

a. AS

b. STT c. SV d. 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 2 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 3 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 4 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 1 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


• 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 2 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 3 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 4 de 4

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

Página 2 de 2

Documents

Grado de acoplamiento Modelo cliente/servidorlaurel.datsi.fi.upm.es/_media/docencia/asignaturas/sd/sd_arquitectur… · Normalmente, acoplamiento espacial y temporal Servidor ofrece