Cuestionario De Clase_comunicacion_20133322.docx

CUESTIONARIO DE CLASE Alumno: Alex Daniel Ticona Bejarano

CUI: 20133322

TEMA DE CLASE: COMUNICACIÓN 1. El término middleware y sistemas distribuidos son equivalentes? Si no, cuál es la diferencia? No, Como elemento característico de los sistemas distribuidos, surge el concepto de “Middleware”, la capa de software que se ubica entre el sistema operativo y las aplicaciones de los usuarios. En un Sistema Distribuido, el middleware (lógica de la mediación) es un software de conectividad que permite ofrecer un conjunto de servicios que hacen posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogéneas. Como se muestra en la figura el middleware funciona como una capa de abstracción de software distribuida que se sitúa entre las capas de aplicaciones y las capas inferiores (sistema operativo y red)

2. Porque el objetivo de RPC es que se de la transparencia? Porque su funcionalidad es útil para el desarrollador mas no su implementación y a composición de los métodos y mecanismos de comunicación que utiliza. Esto permite al desarrollador agilizar las tareas que permite desarrollar un RPC. RPC es un programa que utiliza una computadora para ejecutar código en otra máquina remota sin tener que preocuparse por las comunicaciones entre ambas. El protocolo que se utiliza para esta llamada es un gran avance sobre los sockets de Internet usados hasta el momento. De esta manera el programador no tenía que estar pendiente de las comunicaciones, estando estas encapsuladas dentro de las RPC. 3. Qué es marshaling y stub: Qué pasos involucran, explique cómo actúan en RMI, cómo es el proceso de comunicación en RMI Marshalling: es el proceso de codificación de los parámetros. Stub: es un objeto que encapsula el método que deseamos invocar remotamente. Así el llamado remoto es semejante a un llamado local. Éste prepara información con la identificación el objeto remoto a invocar, el método a invocar y codificación de los parámetros (Marshalling).

RMI Si tenemos acceso a objetos en otras máquinas, podemos llamar a métodos de ese objeto remoto. RMI maneja los detalles de enviar los parámetros, el objeto remoto debe ser activado para ejecutar el método y los valores deben ser retornados de regreso al llamador,

Proceso de comunicación de RMI La idea es tener un objeto cliente, donde podamos podamos completar un requerimiento de datos. El cliente luego prepara el requerimiento que envía a un objeto ubicado en un servidor. El objeto remoto prepara la información requerida (accediendo a bases de datos, otros objetos, etc). Finalmente el objeto remoto envía la respuesta al cliente. En lo posible esta interacción debería ser lo más semejante posible a requerimientos hechos localmente.

4. Cuáles son los pasos involucrados en la implementación de un RPC En esta figura, la llamada remota toma 10 pasos:

I.

II. III.

En el primero de los cuales el programa cliente (o procedimiento) llama al procedimiento stub enlazado en su propio espacio de direcciones. Los parámetros pueden pasarse de la manera usual y hasta aquí el cliente no nota nada inusual en esta llamada ya que es una llamada local normal. El stub cliente reúne luego los parámetros y los empaqueta en un mensaje. Esta operación se conoce como reunión de argumentos (parameter marshalling). Después que se ha construido el mensaje, se lo pasa a la capa de transporte para su transmisión (paso 2). En un sistema LAN con un servicio sin conexiones, la entidad de transporte probablemente sólo le agrega al mensaje un encabezamiento y lo coloca en la subred sin mayor trabajo (paso 3).

IV.

V.

VI.

VII.

VIII. IX. X.

En una WAN, la transmisión real puede ser más complicada. Cuando el mensaje llega al servidor, la entidad de transporte lo pasa al stub del servidor (paso 4), que desempaqueta los parámetros. El stub servidor llama luego al procedimiento servidor (paso 5), pasándole los parámetros de manera estándar. El procedimiento servidor no tiene forma de saber que está siendo activado remotamente, debido a que se lo llama desde un procedimiento local que cumple con todas las reglas estándares. Únicamente el stub sabe que está ocurriendo Después que ha completado su trabajo, el procedimiento servidor retorna (paso 6) de la misma forma en que retornan otros procedimientos cuando terminan y, desde luego, puede retornar un resultado a un llamador. El stub servidor empaqueta luego el resultado en un mensaje y lo entrega a la interfaz con transporte (paso 7), posiblemente mediante una llamada al sistema, al igual que en el paso 2. Después que la respuesta retorna a la máquina cliente (paso 8) La misma se entrega al stub cliente (paso 9) que desempaqueta las respuestas. Finalmente, el stub cliente retorna a su llamador, el procedimiento cliente y cualquier valor devuelto por el servidor en el paso 6, se entrega al cliente en el paso 10.

El propósito de todo el mecanismo de la figura anterior es darle al cliente (procedimiento cliente) la ilusión de que está haciendo una llamada a un procedimiento local. Dado el éxito de la ilusión, ya que el cliente no puede saber que el servidor es remoto, se dice que el mecanismo es transparente. Sin embargo, una inspección más de cerca revela algunas dificultades en alcanzar la total transparencia algo particular. 5. Cuál es la diferencia entre sockets y MPI? MPI proporciona una abstracción conveniente y de alto nivel para enviar y recibir mensajes (¡no flujos!). Simplemente llame a MPI_SEND con un identificador entero del receptor y el mensaje que desea enviar, y se produce la magia: el mensaje llega al destino. El programador de aplicaciones MPI no necesita administrar conexiones, flujos, canalización, multiplexación, ... o uno de los otros cien problemas necesarios para un alto rendimiento de rendimiento de la red. Por lo tanto, los programadores de aplicaciones MPI pueden centrarse en el problema computacional que están tratando de resolver, no en la red subyacente. La mayoría de las implementaciones de MPI utilizan sockets para la comunicación basada en TCP. Las probabilidades son buenas de que cualquier implementación de MPI dada se optimice mejor y proporcione un paso de mensajes más rápido que una aplicación local que utiliza sockets directamente. El paso de mensajes es un paradigma, no una tecnología. En la instalación más general, MPI usará sockets para comunicarse. Podría ver una aceleración cambiando a MPI, pero solo en la medida en que no haya optimizado su comunicación de socket