Download Sistemas Distribuidos

Asignatura:
Sistemas Distribuidos
Docente:
José Luis Caero
Trabajo Práctico:
Nº 6
Integrantes:
Florencia Gutiérrez Keen, Adolfo Chércoles, Walter Daniel Zalazar, Jorge
García, Javier Salazar
1. Describa los siguientes items relacionados con los protocolos de internet:
1.1: Características de las comunicaciones entre procesos
1.2: Sockets
1.3: Comunicación de datagramas UDP
1.4: Comunicación de Streams TCP
2. Describa los siguientes representaciones externa de datos y empaquetados:
2.1: Representación común de datos de CORBA
2.2: Serialización objetos Java
2.3: Referencia objetos remotos
3. Describa la función y/o finalidad de los siguientes casos
3.1: El modelo de objetos y objetos distribuidos
3.2: El modelo de objetos distribuidos
3.3: Diseño e implementación para RMI
3.4: Compactación automática de memoria
Página 1 de 6
Asignatura:
Sistemas Distribuidos
Docente:
José Luis Caero
Trabajo Práctico:
Nº 6
Integrantes:
Florencia Gutiérrez Keen, Adolfo Chércoles, Walter Daniel Zalazar, Jorge
García, Javier Salazar
1.1 Características de las comunicaciones entre procesos
La comunicación se establece siguiendo una serie de reglas (protocolos de comunicación). Los protocolos
desarrollados para internet son los mayormente usados: IP (capa de red), protocolo de control de
transmisión (capa de transporte) y protocolo de transferencia de archivos, protocolo de transferencia de
hipertexto (capa de aplicación). Características:
Sincronizada: El proceso que envía se “bloquea” hasta que el mensaje se haya enviado, mientras que en el
proceso receptor, activa un recibe y también se bloquea hasta que el mensaje se haya recibido.
Asíncrona: EL proceso emisor no se bloquea al enviar, mientras que el proceso receptor puede tener las
dos variantes: bloqueado o no bloqueado. En este último caso, se utiliza un buffer de mensajes recibidos.
Destino: el proceso receptor puede tener asociada:
 Una dirección_IP+Puerto_local, que la hace más bien estática
 O un nombre (que deberá ser traducida por un servicio de nombres) que le permita cambiar de
localidad del proceso receptor.
 Ejemplo: www.unap.cl || 64.76.169.121:80
 Observación: un proceso recibe por un puerto pero puede responder a través de varios otros.
Fiabilidad : Se define en término de validez e integridad
 Un sistema provee validez si entrega todo el mensaje o una parte que sea aceptable para el
proceso receptor.
 Un sistema de comunicación resguarda la integridad si entrega los mensajes sin corromperse ni
duplicarse.
Ordenación: En algunos casos de comunicación entre procesos, es requisito mantener el orden de llegada
de mensajes, de acuerdo al orden de salida de los mismo.
En otro tipo de aplicaciones, el orden no podría tener mayor relevancia.
1.2 Sockets
Los sockets no son más que puntos o mecanismos de comunicación entre procesos que permiten que un
proceso hable ( emita o reciba información ) con otro proceso incluso estando estos procesos en distintas
máquinas. Esta característica de interconectividad entre máquinas hace que el concepto de socket nos
sirva de gran utilidad. Esta interfaz de comunicaciones es una de las distribuciones de Berkeley al sistema
UNIX, implementándose las utilidades de interconectividad de este Sistema Operativo ( rlogin, telnet, ftp,
... ) usando sockets.
1.3 Comunicación de datagramas UDP:
- Un mensaje enviado vía UDP, no posee reintentos y acuso de recibo por parte del proceso receptor.
- Si algo falla el mensaje podría no llegar a su destino
Página 2 de 6
Asignatura:
Sistemas Distribuidos
Docente:
José Luis Caero
Trabajo Práctico:
Nº 6
Integrantes:
Florencia Gutiérrez Keen, Adolfo Chércoles, Walter Daniel Zalazar, Jorge
García, Javier Salazar
-
El receptor posee un puerto específico para recibir mensajes
El cliente podrá utilizar cualquier puerto para enviarlos.
El receptor averiguará por el mensaje entrante, la IP y el puerto del proceso emisor, lo que le permite
enviar una respuesta
1.4 Comunicación de Streams TCP:
Etapas de la comunicación:
 El proceso cliente envía una solicitud connect al la dirección ip y puerto del servidor.
 EL servidor posee una cola para recibir las solicitudes connect y a al momento de realizar un
accept, dispone un nuevo puerto para el stream de comunicación con el cliente.
 Cuando se establece la comunicación, cada proceso dispone de dos stream uno para escribir y otro
para leer.
 Para finalizar la comunicación uno de los procesos cierra cu conector de envió, el receptor detecta
esto y cierrar sus conectores.
Aspectos importantes:
 Coordinación entre el emisor y receptor en el tipo de datos emitidos y recibidos.
 Ocurren bloqueos cuando:
o El receptor intenta leer y no existen datos en la cola.
o El emisor intenta escribir y el buffer está lleno
o El servidor atiende a cada cliente a través de un hilo independiente, que si se bloquea no
afecta a los otros clientes.
Características:
 Tamaño de los mensajes: la aplicación decide sobre el tamaño de los mensajes y el protocolo
inferior TCP los traduce a paquetes IP y se asegura que lleguen a destino.
Por su parte, el proceso receptor “consume” los datos enviados según las necesidades de la
aplicación.
 Mensajes perdidos: Para cada paquete IP que TCP envía desde el emisor debe esperar un acuse de
recibo desde el receptor, si pasado un tiepo (timeout) no lo recibe, lo considera como paquete
perdido y reenvía el paquete IP nuevamente. (el protocolo de ventana deslizante mejora este
mecanismo).
 Control de Flujo: TCP regula y coordina el proceso de envío (producción) y recepción (consumo) de
los paquete: por ejemplo, si el receptor lee muy lento, bloquea al emisor hasta que el lector haya
leído una cantidad suficiente de byte.
 Duplicación y Ordenación de los Mensajes: A cada paquete IP se le asocia un Id único que permite
al receptor ordenarlos y eliminar paquetes repetidos.
 Destino de los mensajes: Para establecer la comunicación, el proceso emisor envía una solicitud
connect al receptor (necesita conocer dirección ip y puerto del recepetor) y este debiera
responderle con un accept. Una vez establecida la comunicación, los procesos leen y escriben en el
stream, sin preocuparse por la dirección IP y el número de puerto
Página 3 de 6
Asignatura:
Sistemas Distribuidos
Docente:
José Luis Caero
Trabajo Práctico:
Nº 6
Integrantes:
Florencia Gutiérrez Keen, Adolfo Chércoles, Walter Daniel Zalazar, Jorge
García, Javier Salazar
2.1 Representación común de datos de CORBA:
CORBA utiliza la representación externa para envío de los datos, lo que le permite trabajar con una
variedad de lenguajes (fortrasn c, c++, java,..)
Métodos para intercambio de datos
- Cada vez que dos procesos se envían mensajes, estos son pasados a bytes para la transmisión y luego
reconstruidos en procesos receptor.
- Es necesario ponerse de acuerdo acerca del tipo de dato que se está enviando.
- No todas las máquinas hacen el mismo tratamiento interno acerca de los tipos de datos (ejemplo:
punto flotante, ASCII, Unicode).
-
-
El emisor y el receptor utilizan un formato común y externo.
Cada dato es acompañado de un identificador tipo de dato externo, para su traducción correcta en el
receptor
Si para algunos datos, ambos poseen el mismo tratamiento interno, en ese caso no utilizará el formato
externo.
Representación Externa de datos: Estándar acordado para tratar datos simples y las estructuras de
datos.
Empaquetado (marshalling) : es el ensamblado de un conjunto de datos para transmitirlos al receptor.
Desempaquetado(unmarshalling) : desensamblado en el destino, para obtener la colección
equivalente de datos.
2.2 Serialización objetos Java:
Java serializa los objetos (en una secuencia de bits) antes del envío y el receptor reconstruye el objeto
basado en un árbol de clases que debe conocer previamente ( tal vez por medio de un mensaje previo o
que ya esté almacenado en disco).
En ambos casos toda esta tarea es realizada por el midleware (CORBA o RMI de Java) y el programador no
interviene directamente en este proceso.
2.3 Referencia objetos remotos:
RMI (Java Remote Method Invocation) es un mecanismo ofrecido por Java para invocar un método de
manera remota. Forma parte del entorno estándar de ejecución de Java y provee de un mecanismo simple
para la comunicación de servidores en aplicaciones distribuidas basadas exclusivamente en Java. Si se
requiere comunicación entre otras tecnologías debe utilizarse CORBA o SOAP en lugar de RMI.
RMI se caracteriza por la facilidad de su uso en la programación por estar específicamente diseñado para
Java; proporciona paso de objetos por referencia (no permitido por SOAP), recolección de basura
distribuida (Garbage Collector distribuido) y paso de tipos arbitrarios (funcionalidad no provista por
CORBA).
Por medio de RMI, un programa Java puede exportar un objeto, lo que significa que éste queda accesible a
través de la red y el programa permanece a la espera de peticiones en un puerto TCP. A partir de este
momento, un cliente puede conectarse e invocar los métodos proporcionados por el objeto.
Página 4 de 6
Asignatura:
Sistemas Distribuidos
Docente:
José Luis Caero
Trabajo Práctico:
Nº 6
Integrantes:
Florencia Gutiérrez Keen, Adolfo Chércoles, Walter Daniel Zalazar, Jorge
García, Javier Salazar
La invocación se compone de los siguientes pasos:
-
Encapsulado (marshalling) de los parámetros (utilizando la funcionalidad de serialización de Java).
Invocación del método (del cliente sobre el servidor). El invocador se queda esperando una respuesta.
Al terminar la ejecución, el servidor serializa el valor de retorno (si lo hay) y lo envía al cliente.
El código cliente recibe la respuesta y continúa como si la invocación hubiera sido local.
3.1 El modelo de objetos y objetos distribuidos
DOM (Document Object Model), es esencialmente una interfaz de programación de aplicaciones que
proporciona un conjunto estándar de objetos para representar documentos HTML y XML, un modelo
estándar sobre cómo pueden combinarse dichos objetos, y una interfaz estándar para acceder a ellos y
manipularlos.
A través del DOM, los programas pueden acceder y modificar el contenido, estructura y estilo de los
documentos HTML y XML, que es para lo que se diseñó principalmente.
El responsable del DOM es el consorcio W3C (World Wide Web Consortium).
En efecto, el DOM es una API para acceder, añadir y cambiar dinámicamente contenido estructurado en
documentos con lenguajes como ECMAScript
3.2 El modelo de objetos distribuidos
DCOM (Distributed Component Object Model)es una tecnología propietaria de Microsoft para desarrollar
componentes software distribuidos sobre varios ordenadores y que se comunican entre sí. Extiende el
modelo COM de Microsoft y proporciona el sustrato de comunicación entre la infraestructura del servidor
de aplicaciones COM+ de Microsoft. Ha sido abandonada en favor del framework .NET
La adición de la "D" a COM fue debido al uso extensivo de DCE/RPC, o más específicamente la versión
mejorada de Microsoft, conocida como MSRPC.
En términos de las extensiones que añade a COM, DCOM tenía que resolver los problemas de
1. Aplanamiento - Serializar y deserializar los argumentos y valores de retorno de las llamadas a los
métodos "sobre el cable".
2. Recolección de basura distribuida, asegurándose que las referencias mantenidas por clientes de las
interfaces sean liberadas cuando, por ejemplo, el proceso cliente ha caído o la conexión de red se
pierde.
3.3 Diseño e implementación para RMI
La arquitectura RMI puede verse como un modelo de cuatro capas.
Primera capa
La primera capa es la de aplicación y se corresponde con la implementación real de las aplicaciones cliente
y servidor. Aquí tienen lugar las llamadas a alto nivel para acceder y exportar objetos remotos. Cualquier
aplicación que quiera que sus métodos estén disponibles para su acceso por clientes remotos debe
declarar dichos métodos en una interfaz que extienda java.rmi.Remote. Dicha interfaz se usa básicamente
para "marcar" un objeto como remotamente accesible. Una vez que los métodos han sido implementados,
el objeto debe ser exportado. Esto puede hacerse de forma implícita si el objeto extiende la clase
UnicastRemoteObject (paquete java.rmi.server), o puede hacerse de forma explícita con una llamada al
método exportObject() del mismo paquete.
Segunda capa
Página 5 de 6
Asignatura:
Sistemas Distribuidos
Docente:
José Luis Caero
Trabajo Práctico:
Nº 6
Integrantes:
Florencia Gutiérrez Keen, Adolfo Chércoles, Walter Daniel Zalazar, Jorge
García, Javier Salazar
La capa 2 es la capa proxy, o capa stub-skeleton. Esta capa es la que interactúa directamente con la capa de
aplicación. Todas las llamadas a objetos remotos y acciones junto con sus parámetros y retorno de objetos
tienen lugar en esta capa.
Tercera capa
La capa 3 es la de referencia remota, y es responsable del manejo de la parte semántica de las
invocaciones remotas. También es responsable de la gestión de la replicación de objetos y realización de
tareas específicas de la implementación con los objetos remotos, como el establecimiento de las
persistencias semánticas y estrategias adecuadas para la recuperación de conexiones perdidas. En esta
capa se espera una conexión de tipo stream (stream-oriented connection) desde la capa de transporte.
Cuarta Capa
La capa 4 es la de transporte. Es la responsable de realizar las conexiones necesarias y manejo del
transporte de los datos de una máquina a otra. El protocolo de transporte subyacente para RMI es JRMP
(Java Remote Method Protocol), que solamente es "comprendido" por programas Java.
Toda aplicación RMI normalmente se descompone en 2 partes:
1. Un servidor, que crea algunos objetos remotos, crea referencias para hacerlos accesibles, y espera
a que el cliente los invoque
2. Un cliente, que obtiene una referencia a objetos remotos en el servidor, y los invoca.
Usar RMI para desarrollar aplicaciones distribuidas comprende los siguientes pasos:
1.
Diseñar e implementar los componentes para una aplicación distribuida.
2.
Compilar las fuentes.
3.
Hacer las clases accesibles a la red.
4.
Correr la aplicación.
3.4 Compactación automática de memoria
Recuperación de memoria cuando nadie tenga una referencia a un objeto remoto o local
Página 6 de 6