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. 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).
II. Después que se ha construido el mensaje, se lo pasa a la capa de transporte para su
transmisión (paso 2).
III. 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. 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.
V. 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
VI. 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.
VII. 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.
VIII. Después que la respuesta retorna a la máquina cliente (paso 8)
IX. La misma se entrega al stub cliente (paso 9) que desempaqueta las respuestas.
X. 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