Sistemas Distribuidos: Ejercicio del tema arquitectura de los sistemas distribuidos

Febrero del 2013.


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?
    1. CO
    2. SE
    3. BG
    4. 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.
  1. ¿Qué procesos realizan el papel de editores?
    1. SE
    2. CO
    3. BG
    4. 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.
  1. ¿Qué procesos realizan una operación de alta en el servicio de binding?
    1. PI
    2. SE
    3. CO
    4. 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.
  1. ¿Para qué procesos sería razonable usar un esquema de leasing en este esquema editor-subscriptor?
    1. CO
    2. BG
    3. SE
    4. 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.
  1. ¿A qué es proporcional el tamaño de la información dinámica que almacena PI?
    1. al número de procesos CO
    2. al número de procesos SE
    3. al número de procesos CO + SE
    4. tiene tamaño fijo
Explicación
El proceso PI almacena qué subscriptores hay para cada tema. Por tanto, el tamaño de la información dinámica que almacena PI es proporcional al número de procesos subscriptores (CO).
  1. ¿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.
    1. pull: (1) y (2); push (2)
    2. pull: (2); push (1) y (2)
    3. pull: (1) y (2); push (1)
    4. 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.
  1. 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?
    1. Interés en todos los parámetros físicos de una determinada posición.
    2. Interés en todos los parámetros del sistema.
    3. Interés en la temperatura y la luminosidad en cualquier punto del sistema.
    4. Interés en la temperatura pero sólo la medida por un cierto tipo de sensores de temperatura.
Explicación
Veamos cada caso planteado analizando, en primer lugar, si el uso de un filtro por contenido tendría alguna ventaja en ese caso y, si hay varios en los que sí, en qué caso sería más efectivo (es decir, descartaría más eventos no deseados). Por tanto, tendría sentido usar un filtro por contenido en esos dos casos. Para determinar en qué caso el filtro sería más efectivo, habría que analizar cuál de ellos descartaría más eventos no deseados. Dado que en el caso del interés en todos los parámetros de una cierta posición hay que suscribirse a todos los temas, mientras que en el otro sólo a la temperatura, sería más efectivo para ese primer caso.

Segunda parte

Responda a la siguientes preguntas generales sobre la arquitectura de un sistema distribuido.
  1. ¿Cuál de estas técnicas NO mejora la escalabilidad de un servicio?
    1. Traerse por anticipado objetos que requerirá en el futuro el cliente.
    2. Uso de una cache.
    3. Replicación del servidor.
    4. Aumentar la inteligencia en el lado cliente.
Explicación
Empezamos por las técnicas que sí mejoran la escalabilidad del servicio. La cache puede disminuir el número de peticiones que genera el cliente hacia el servidor puesto que algunas de ellas se resuelven localmente, lo que mejora la escalabilidad del servicio al disminuir la carga que genera el mismo sobre el servidor. La replicación puede permitir dar servicio a más clientes que en el caso de un único servidor, mejorando también la escalabilidad. En cuanto a aumentar la inteligencia en el cliente, le dota de más autonomía al mismo, con la consecuente mejora en la escalabilidad. Sin embargo, la lectura anticipada de objetos no mejora de por sí la escalabilidad puesto que, en cualquier caso, esos objetos había que traérselos e incluso, en el peor de los casos, se pueden traer al cliente objetos que finalmente no van a ser usados. El principal objetivo de las operaciones anticipadas no es mejorar la escalabilidad sino la latencia de la operación.
  1. 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?
    1. R1 E/S; R2 C/S
    2. R1 C/S; R2 E/S
    3. R1 C/S; R2 C/S
    4. 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.

  1. ¿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)?
    1. TV: E; NOTA: T y E
    2. TV: T y E; NOTA: E
    3. TV: T; NOTA: T y E
    4. 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.
  1. 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?
    1. latencia de la operación
    2. escalabilidad del servicio
    3. tolerancia a fallos
    4. menor complejidad en el diseño del servidor
Explicación
Enviar agrupadas todas las peticiones complica el diseño del servidor, que tendrá que ser capaz de desagruparlas antes de procesarlas, no mejorando la escalabilidad del servicio, puesto que, en términos generales, usará la misma cantidad de ancho de banda de la red y del servidor, ni mejorando tampoco la tolerancia a fallos, al no incluir ningún tipo de mecanismo con ese fin. Sin embargo, sí mejora la latencia, puesto que el cliente no tiene que esperar la respuesta de la primera petición para enviar la segunda, como ocurre con el modelo cliente/servidor convencional.

Tercera parte

Se plantea diseñar un servicio que permite a una aplicación acceder a un directorio remoto ofreciendo tres operaciones: abrir el directorio, leer la siguiente en entrada y cerrar el directorio. Se está evaluando si usar un esquema con estado o sin estado.
  1. ¿Cuántas de las operaciones requerirían contactar con el servidor en un servicio con estado?
    1. 3
    2. 0
    3. 1
    4. 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.
  1. ¿Cuántas de las operaciones requerirían contactar con el servidor en un servicio sin estado?
    1. 2
    2. 0
    3. 1
    4. 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.
  1. ¿Para qué esquema el mensaje generado en la lectura es de mayor tamaño?
    1. Sin estado.
    2. Con estado.
    3. No procede: La lectura no genera ningún mensaje en un esquema sin estado.
    4. 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).
  1. ¿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)?
    1. Con estado: S; Sin estado: C.
    2. Con estado: C; Sin estado: S.
    3. Con estado: C; Sin estado: C.
    4. 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.