Comunicación y Objetos Distribuidos

Licenciatura en Sistemas
Sistemas Informáticos Distribuidos
TRABAJO PRÁCTICO Nº 6
“Comunicación y Objetos Distribuidos”
Comunicación y Objetos Distribuidos
1) Describa los siguientes ítems relacionados con los protocolos de Internet:
1.1 Características De Las Comunicaciones Entre Procesos
La comunicación entre procesos, en inglés IPC (Interprocess Communication) es una función básica de
los Sistemas operativos. Los procesos pueden comunicarse entre sí a través de compartir espacios de
memoria, ya sean variables compartidas o buffers, o a través de las herramientas provistas por las rutinas
de IPC. La IPC provee un mecanismo que permite a los procesos comunicarse y sincronizarse entre sí.
Normalmente a través de un sistema de bajo nivel de paso de mensajes que ofrece la red subyacente.
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).
Los procesos pueden estar corriendo en una o más computadoras conectadas a una red. Las técnicas de
IPC están divididas dentro de métodos para: paso de mensajes, sincronización, memoria compartida y
llamadas de procedimientos remotos (RPC). El método de IPC usado puede variar dependiendo del ancho
de banda y latencia (el tiempo desde el pedido de información y el comienzo del envió de la misma) de la
comunicación entre procesos, y del tipo de datos que están siendo comunicados.
Para que estos procesos se comuniquen para el intercambio de datos o información de control. Hay unos
cuantos métodos. Se pueden considerar los siguientes:
•
•
•
•
•
•
Tubería (Pipes)
Señales (Signals)
Colas de Mensajes
Semáforos
Memoria Compartida
Sockets
1.2 Sockets
Los sockets proporcionan una comunicación de dos vías, punto a punto entre dos procesos. Los sockets
son muy versátiles y son un componente básico de comunicación entre interprocesos e intersistemas. Un
socket es un punto final de comunicación al cual se puede asociar un nombre. Este tiene un tipo y uno o
más procesos asociados.
Los sockets existen en los dominios de comunicación. Un socket de dominio es una representación que da
una estructura de direccionamiento y un conjunto de protocolos. Los sockets se conectan solamente con
sockets en el mismo dominio. Veintitrés dominios de sockets son identificados, de los cuales solamente
los dominios de UNIX e Internet son normalmente sockets de Linux usados para comunicarse entre
procesos en un sólo sistema, como otras formas de comunicación entre procesos.
El dominio de UNIX da un espacio de direcciones de socket en un sistema. Los sockets de dominio de
UNIX son nombrados con las rutas de UNIX. Los sockets pueden también ser usados para comunicar
procesos entre diferentes sistemas. El espacio de direcciones del socket entre los sistemas conectados es
llamado el dominio de Internet.
La comunicación del dominio de Internet usa la suite del protocolo de Internet TCP/IP.
2
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
• 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.
Tamaño del Mensaje:
• El mensaje integro puede ser de hasta 216 byte pero es usual uno de 8 Kilobyte. La aplicación debiera
dividir el mensaje en partes.
• Mensajes excesivamente grandes afectan el rendimiento de al red.
Bloqueo: UDP usa las operaciones
• envía, no bloqueante, o sea la esta operación retorna el control una vez encaminado el mensaje a la capa
IP en su socket.
• Recordar que si el mensaje es muy grande, se envía por parte.
• La aplicación se encarga de particionar y rearmar el mensaje
• recibe bloqueante, o sea el mensaje enviado se almacena en una cola de mensajes en el puerto del
proceso receptor. Este proceso activará su operación recibe y se bloqueará hasta recibir todo el mensaje.
Para esto utiliza un hilo de proceso receptor.
• Tiempo límite (timeout): la operación recibe puede tener asociado un timeout por seguridad (por falla
emisor o red).
• Si el mensaje tiene un destino inexistente, se descarta
• Esta operación recibe mensajes de cualquier otro.
Modelo de Fallo
• Fallos por Omisión
o Emisor
o Canal
o Buffer de llegada (lleno)
• Ordenación, puede ocurrir que la aplicación requiera que los mensajes estén ordenados.
Utilización de UDP
• En Aplicaciones que aceptan fallos de omisión, ocacionales (ejemplo DNS, Web).
• No sobrecarga la red debido a que:
o No se requiere información de estado ni en el origen ni en el destino.
o No existe retransmisiones ni transmisión extra
o El efecto de la latencia es menor Latencia
1.4 Comunicación De Streams (TCP)
Este visualiza la comunicación como un flujo de bytes (stream), y los procesos pueden leer desde este
flujo o escribir en él. Esta abstracción oculta algunas características propias de la red:
• 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 tiempo (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
paquetes: 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 receptor) y este debiera responderle con un accept.
3
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.
„
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 cierra sus conectores.
„
Aspectos importantes
• Coordinación entre el emisor y receptor en el tipo de datos emitidos y recibidos.
• Ocurren bloqueos cuando:
„ El receptor intenta leer y no existen datos en la cola.
„ El emisor intenta escribir y el buffer está lleno
• El servidor atiende a cada cliente a través de un hilo independiente, que si se bloquea no afecta a los
otros clientes.
„
Modelo de Fallo
• Integridad de los datos: se obtiene a través del cheque de suma para detectar paquetes IP corruptos.
Además, utiliza un número de serie para ordenar y evitar la duplicidad de los paquetes.
• Validez: se consigue reenviando el paquete, cada vez que timeout. Lo que garantiza la entrega.
• Conexión rota: cuando los timeout ocurren con demasiada frecuencia, TCP declara la comunicación
rota. Esto significa que TCP no proporciona una comunicación fiable.
• Conexión rota: cuando los timeout ocurren con demasiada frecuencia, TCP declara la comunicación
rota. Esto significa que TCP no proporciona una comunicación fiable.
• Fallos: Cuando una conexión es declarada rota se notifica, pero el emisor sólo se entera si intenta leer
en el stream. Esto hace que el cliente no distinga si el fallo ocurrió en el proceso o falló la red. Ni puede
saber si su último mensaje fue leído por el receptor.
„
Utilización de TCP
• En Internet los servicios ya poseen puertos públicos bien conocidos para prestación de algunos
servicios:
„ HTTP : para la web
„ FTP : transmisión de archivos
„ Telnet : acceso remoto
„ SMTP : transferencias de correos
2) Describa las siguientes representaciones externas de datos empaquetados:
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,..)
2.2 Serialización Objetos en Java
Java serializa los objetos (en una secuancia 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 deJava)y el programados
no interviene directamente en este proceso.
2.3 Referencia Objetos Remotos
•
Objeto cuyos métodos pueden invocarse desde otras Máquinas Virtuales
•
Descrito por una o más Interfaces Remotas (las que implementa) en las que se declaran los
métodos que pueden ser invocados por objetos desde otras VMs
Difiere de un objeto local en:
4
•
•
Se puede hacer conversión de tipos (Cast) a una interfaz remota que el objeto implemente
Su tipo se puede revisar con el operador instanceof : prueba las interfaz remota que un objeto
implementa
•
Es subclase de RemoteObject, clase que redefine métodos de java.lang Object : toString( ), equals(
), hashCode ( ), clone ( ), de modo adecuado para objetos remotos, por ejemplo, dos referencias remotas
son iguales si apuntan al mismo objeto remoto, sin importar el contenido o estado de dicho objeto
Definición
Invocación a Método Remoto:
•
Acción de invocar un método de una interfaz remota en un objeto remoto
•
Tiene la misma sintaxis de una invocación a un método local
Difiere de una invocación local en:
•
Argumentos no remotos en invocaciones remotas se pasan por valor (copia)
•
Objetos remotos se pasan por referencia
•
Hay Excepciones Remotas. Estas excepciones no son de tipo runtime, por lo que deben ser
cachadas o lanzadas de manera adecuada.
Objetos Remotos: se pasan por referencia (talones, usados para invocar métodos remotos).
•
Los objetos remotos no viajan, en cambio se envían referencias (que permiten crear talones o
sustitutos) a quienes los reciben, ya sea como argumentos de un método o como resultados de un método
•
Un talón se debe convertir al tipo (cast) de las interfaces remotas que implememte la clase del
objeto remoto al que corresponde. El tipo del talón determina que métodos remotos se pueden invocar en
el objeto remoto (aquellos que se declaran en la interfaz correspondiente)
•
Si un objeto remoto implementa varias interfaces remotas un cliente solo puede convertir el talón
a una de ellas (y por lo tanto solo podrá invocar los métodos declarados en esa interfaz)
•
Dos talones que se refieren al mismo objeto remotos en el mismo servidor se consideran iguales
bajo la operacion equals
3) Describa la función y o finalidad de los siguientes casos
3.1 El Modelo de Objetos, y Objetos Distribuidos
„ Modelo de Objetos Locales
„ Referencia a Objetos
„ Forma de acceder a un objeto
„ Interfaces
„ Métodos (argumentos, resultados y excepciones)
„ Acciones (mensajes locales)
„ Informa acerca del estado del receptos
„ Cambia el estado del receptos
„ Puede afectar a otros objetos (“indirectamente”)
„ Excepciones
„ Tratamiento de errores separados del código principal del módulo
„ Liberación de Memoria
„ Cuando un objeto deja de ser accesible
„ Objetos Distribuidos
„ Un sistema podría estar compuestos de un conjunto de objetos locales.
„ Ese mismo sistema podría “esparcir” sus objetos en computadores o procesos diferentes.
„ Bajo este esquema, algunos objetos podrían ser vistos como objetos clientes y mientras
que otros como objetos servidores (Arquitectura Cliente-Servidor).
„ Es posible implementar objetos locales que representen a los objetos remotos, lo que
facilita la programación de este tipo de sistema (Modelo Cliente-Servidor con Proxy).
5
B’
M1()
M2()
M3()
A
M1()
M2()
A.x = B.M1();
CLIENTE
B
M1()
M2()
M3()
B.y = A.M2();
SERVIDOR (PROXY)
SERVIDOR
3.2. El Modelo De Objetos Distribuidos
En este modelo se distribuyen objetos coarse grained. Del punto de vista del paralelismo es la tercer
forma de realizar el paradigma cliente/servidor (a parte de socket y RPC), así, los objetos distribuidos son
tareas paralelas y MPMD, donde cada interacción entre dos objetos sigue el patrón cliente/servidos. En
muchos casos la estructura del sistema es peer-to-peer, lo cual significa que el rol de cliente o servidos
puede cambiar.
Al relacionar el modelo de objetos distribuidos con el paradigma cliente/servidor, los métodos pasan a ser
servicios. Cada objeto distribuido está sujeto a un proceso server que realiza las operaciones del objeto.
Los procesos clientes deben pedirlo a un proceso server.
La mecanismo de comunicación entre un cliente y un servidor es llamado remote method invocation
(RMI), el cual es una adaptación de RPC, por lo cual tiene ciertos progresos con respecto a este. Una
diferencia a tener en cuenta es que una misma invocación (mismo método y parámetros) puede dar
resultados diferentes según el estado del objeto, mientras que en RPC, el mismo llamado (igual
procedimiento y parámetros) produce el mismo resultado (a menos que acceda a Base de Datos o
variables globales).
Se utilizan en sistemas middleware como CORBA, DCOM,
JavaRMI.
local
remote
C
E
invocation loca
invocation
invocation
A
B
remote
invocation
F
local
invocation
D
„ Referencia a objetos remotos
„ Se debe poseer referencias únicas a objetos remotos.
„ Paso de referencia de objetos remotos como parámetros o como resultado de las
invocaciones.
„ Interfases Remotas
„ Solo pone a disposición métodos remotos
„ Se puede utilizar un IDL
„ CORBA usa IDEL
„ JAVA utiliza la misma forma de definir interfaces en un contexto local
„ Ambos soportan herencias múltiples para sus interfaces.
6
remot objec
Dat
remot
interfac
{
m
m
m
implementatio
of
m
m
m
„ Acciones en un Sistema de Objetos Distribuidos
„ Como en el caso local, las acciones de un objeto remoto, puede afectar a otros
objetos también remotos.
„ En cada caso se emplea RMI, para tener acceso a los objetos remotos.
A
B
A sufre un cambio y notifica a
B, C y D
C
D
„ Compactación Automática
„ Si el lenguaje lo permite, la compactación ocurre localmente (caso lenguaje Java)
„ Si no los diferentes objetos debieran colaborar para detectar referencias no
accesibles para compactar la memoria disponible
„ Excepciones
„ Cada objeto debiera manejar, además de los errores locales, aquellos errores
propios de un ambiente distribuidos.
ƒ Fallas en la Red
ƒ Fallas en el objeto remoto
3.3. Diseño E Implementación para RMI
Es otro sistema middleware como CORBA y DCOM. No soporta interoperabilidad entre lenguajes, solo
trabaja con Java. Su funcionalidad es bastante más reducida que los anteriores.
Desde la versión 1.1 de JDK, Java tien su propio ORB: RMI (Remote Method Invocation). A pesar de
que RMI es un ORB en el sentido general, no es un modelo compatible con CORBA.
RMI es nativo de Java, es decir, es una extensión al núcleo del lenguaje. RMI depende totalmente del
núcleo de la Serializción de Objetos de Java, así como de la implementación tanto de la portabilidad
como de los mecanismos de carga y descarga de objetos en otros sistemas, etc.
El uso de RMI resulta muy natural para todo aquel programador de Java ya que éste no tiene que aprender
una nueva tecnología completamente distinta de aquella con la cual desarrollará. Sin embargo, RMI tiene
algunas limitaciones debido a su estrecha integración con Java, la principal de ellas es que esta tecnología
no permite la interacción con aplicaciones escritas en otro lenguaje.
7
RMI como extensión de Java, es una tecnología de programación, fue diseñada para resolver problemas
escribiendo y organizando código ejecutable. Así RMI constituye un punto específico en el espacio de las
tecnologías de programación junto con C, C++, Smalltalk, etc.
Cuestiones de Diseño sobre RMI
„ Semántica de la invocación RMI
„ Un objeto local es invocado sólo una vez pero no es así necesariamente con un objeto
distribuido.
„ Reenvío del mensaje de petición (reintento)
„ Filtrado de mensajes duplicados
„ Reenvío de mensajes de resultados
„ Invocación Pudiera ser
„ Un método se invoca solamente una vez
„ Fallo por omisión de la invocación o de la respuesta
„ Fallo del servidor donde reside el método remoto
„ Después de un time out no se reintenta
„ Es útil en aplicación donde se puede tolerar esos tipos de fallos
„ Invocación Al menos una vez
„ A menos que reciba una respuesta o una excepción, reenvía el mensaje de
invocación.
„ Fallo por caída del servidor
„ Fallo producto invocar más de una vez un método (pude generar resultados
erróneos
„ Aceptable si la invocación a un método es idempotente (si se activa más de una vez
produce los mismos resultados, ejemplo: saldo de una cuenta)
„ Invocación Máximo una vez
„ El proceso envía sólo una mensaje de invocación al método remoto
„ Recibe una respuesta o una excepción.
„ Es necesario considerar todos los fallos posibles para enmascararlos.
„ Transparencia
„ Semántica de invocación
„ Ubicación
„ Empaquetado
„ Paso de Mensaje
„ Recuperación ante fallos
„ Latencia es mayor al invocar un objeto remoto
„ Ante una invocación fallida, construir mecanismos para restaurar el estado del
objeto remoto
„ Implementación RMI
„ Modulo de Referencias Remotas
„ Traduce referencias locales y remotas
„ Utiliza una tabla de referencias de métodos locales y métodos remotos
„ Los objetos remotos son registrados en el servidor, y el proxy correspondiente, en
la tabla local.
„ Un mensaje de respuesta puede contener una referencia a un objeto remoto, ésta
referencia se registrará en la tabla local.
„ La capa RMI
„ Proxy: Representa al objeto remoto, redirigiendo mensajes de invocación y
entregando resultados o excepciones.
„ Esqueleto del objeto remoto
„ Distribuidor del mensaje de petición/respuesta
3.4 Compactación Automática De Memoria
• Recuperación de memoria cuando nadie tenga una referencia a un objeto remoto o local
• Información de creación/eliminación de proxys en clientes
8
• Concesiones en Jini
9