Download ClasesCC52n-7 - DCC

Módulo ECI - 11: Fundamentos de Redes de Computadores
Por Qué Multicasting y Broadcasting
Qué pasa cuando se quiere hacer enviar los mismos
de datos demasiado pesados a mucha gente?
Por cada cliente, el servidor queda mucho rato
“pegado” escribiendo datos.
Imaginémonos ahora la situación en una
videoconferencia: se trata de transmitir varios
frames de video por segundo a una cantidad grande
de “oyentes” => no es posible en la práctica!
En el Multicasting se trata de transmitir una sola
vez la información a un punto en la internet, y desde
ahí la leen los clientes.
Esto implica que el hardware (el de la red, se
entiende) debe ser “multicastingable”
1
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Multicast y Broadcast
Multicast y Broadcast son protocolos de red
que permiten a una aplicación poner un
paquete en una red para ser recibidos por
todos. De esta manera sólo es necesario
enviarlo una vez.
Broadcast funciona generalmente sólo dentro
de la red local y le llega a todas las máquinas
Multicast le llega sólo a los miembros del
grupo registrados (interesados).
Broadcast requiere soporte de la red local.
Multicast requiere de host y routers IGMP
2
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Multicast
Multicast es muy parecido a UDP excepto
que se transmite a direcciones IP en el rango
(224.0.0.0 - 239.255.255.255)
Para recibir el paquete un cliente debe
expresar interés en unirse al grupo y la red se
preocupa de informar alor routers relevantes
Cualquier host puede transmitir al grupo
Requiere de mayor complejidad en el
algoritmo de ruteo ya que el ruteador debe
saber en cuáles de las redes adyacentes hay
interesados.
3
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
MBone
Multicast no está muy extendido en la
internet,hay muchas redes que no lo soportan
Existe una subred llamada MBone que
comunica islas de redes multicastingable a
través de túneles.
Un tunel comunica a los ruteadores de dos
redes entre si haciéndolos aparecer como que
son redes contiguas (los ruteadores tienen ip
de ambas redes)
Los ruteadores deben saber rutear paquetes
Mbone.
4
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Broadcast
Broadcast es similar a Multicast pero en una red
local
Toda redbasada en Broadcast (como la ethernet)
tiene una dirección IP de broadcast, es decir la
reciben todos los computadores
Hay que ponerse de acuerdo solo en el número del
port
Usualmente la direscción de broadcast es la última
posible para la subred:
 Clase C: 192.1.2.0 -> 192.1.2.255
 Para una subred de 16 hosts 197.84.66.192 ->
197.84.66.207
5
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
¿ Broadcast o Multicast ?
Si se puede elegir es preferible multicast ya
que no molesta a los que no están interesados
Muchas veces se necesitan privilegios para
escribir a la dirección broadcast.
Multicast permite varios grupos multicast en
la misma red (diferentes grupos de interés)
El tráfico que generan es el mismo: un sólo
paquete que lo leen varios
Broadcast se hace en java con las clases para
transmitir UDP. Sólo cambia la dirección
6
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Soporte de Java para Multicast
MulticastSocket: extensión del DatagramSocket
 MulticastSocket( ) lo amarra a un port UDP libre
 MulticastSocket(int port) a un port específico
Varios socket multicast pueden escuchar del
mismo port (no así para los socket Datagram)
Los mismos de Datagram (send, receive)
 joinGroup(InetAddress group)
 leaveGroup(InetAddress group)
 setTimeToLive(int ttl)
7
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Llamadas remotas: RPC (remote procedure call)
 Fue el primer mecanismo que se implementó para facilitar
el llamado remoto de funciones entre dos procesos en
máquinas distintas
 la motivación fue la implementación del NFS de Sun
 Existen 2 formas de diseñar aplicaciones distribuidas
 Orientado a la comunicación: se empieza diseñando el protocolo
 Orientadao a la aplicación: se desarrolla el programa como si
fuera local, luego se divide en módulos que se ejecutan separados
 el paradigma de rpc se focaliza en la aplicación. Permite al
programador concentrarse en el desarrollo de un programa
convencional que trata de resolver el problema planteado
antes de tratar de dividirlo para que opere en multples
computadores.
8
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Llamadas remotas: RPC (2)
 Se trata de extender el concepto de llamadas a
procedimientos (funciones, métodos) que son ejecutados
en otros computadores.
 El proceso que hace la llamada se bloquea hasta que
retorna la llamada del rpocedimiento remoto.
 Tiene analogía con el concepto cliente-servidor: el
computador que pide que se ejecute un procedimiento en
otro es el cliente, el servidor es el que ejecuta el
procedimiento.
 A un procedimiento remoto se le pueden pasar parámetros
y puede retornar resultados => datos viajan por la red
 XDR: un protocolo para estandarizar el formato de los
datos que viajan por la red (eXtrernal Data Representation)
 De esta manera cliente y servidor pueden intercambiar
datos
9
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Llamadas remotas: Cómo se programan ?
 Se debe primero especificar un archivo con el protocolo
del proceso remoto que se va a tener: nombre del proceso,
parámetros que recibe, resultado que retorna
 Este es el llamado archivo de interfaz (entre cliente y
servidor): el cliente no conoce la implementación del
procedimiento pero sí cómo se llama.
 El servidor implementa el procedimiento declarado (con
ayuda de una biblioteca que lo conierte en proceso
llamable desde otro computador)
 El cleinte, usando el archivo de interfaz, escribe un
programa que llama a este procedimiento.
 1. Primero debe establecer contacto con el servidor (existe una
función para ello)
 2. Hacer la llamada como si fuera un procedimiento local, dando
los parámetros necesarios y recibiendo lo que retorna el
procedimiento.
10
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Objetos Remotos en JAVA
 La tecnología RMI (Remote Method Invocation) permite a un
programa corriendo en una máquina virtual de java (un intérprete)
invocar el método de un objeto localizado en otra máquina virtual de
java (ubicada en cualquier parte de la red TCP/IP que se pueda
acceder desde el lugar)
 Normalmente se tiende a ver aplicaciones que usan RMI como
aplicaciones de cliente servidor. Una típica aplicación de servidor crea
un objeto, lo “publica” para que pueda ser accesible de cualquier otro
lado y espera a que llamen clientes pidiendo la invocación de sus
métodos. Una típica aplicación cliente obtiene una referencia al objeto
remoto en el servidor y luego invoca sus métodos como si fuera un
objeto local.
 RMI provee mecanismos con los cuales el cliente y el servidor se
pueden intercambiar información, convirtiendolas en aplicaciones de
objetos distribuidos. Estos mecanismos deben hacer posible: 1)
localizar objetos remotos, 2) comunicarse con los objetos remotos 3)
traspasar el código de los objetos remotos (deben ser serializables
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
11
Módulo ECI - 11: Fundamentos de Redes de Computadores
Interfaces, objetos y métodos remotos
 Como en otras aplicaciones, una aplicación distribuida que
usa RMI está constituida por interfaces y clases. Las
interfaces definen los métodos que serán conocidos por
los clientes de los objetos remotos. Las clases remotas
implementan estos y quizas otros métodos también.
 Un objeto remoto se implementa siguiendo los siguientes
pasos:
1) Diseño e implementación de las componentes de la
aplicación distribuida
2) Compilar los códigos fuentes y generar los llamados
“stubs” y skeletons
3) echar a andar la aplicación
12
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Diseñar e implementar las componentes de la
aplicación
 Definir las interfaces remotas: Una interfaz remota
especifica los métodos que pueden ser invocados en forma
remota por un cliente. Los clientes conocerán los objetos
remotos sólo a través de las interfaces.
 Implementación de los objetos remotos: los objetos
remotos deben implementar una o más interfaces remotas.
Además pueden implementar otros métodos que no
corresponden a las interfaces remotas y que son de uso
local.
 Implementar los clientes: Los clientes que usan los objetos
remotos se pueden implementar una vez que las interfaces
remotas están definidas.
13
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Un ej: Un objeto remoto que contiene un número
//el archivo de definición de la interfaz
import java.rmi.*;
public interface Numero extends Remote {
public int getNumero() throws RemoteException;
}
 Este es la definición de la interfaz: implica que los clientes
sólo conocerán el método getNumero() de el objeto
remoto. Para los clientes la clase de este objeto es
Numero, no importa cómo lo haya llamado en el archivo
de implementación del tipo de objeto.
14
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Un ej: Un objeto remoto (2 la implementación)
//el archivo de definición de la implementación
import java.rmi.*;
import java.rmi.server.UnicastRemoteObject;
public class NumeroImpl extends UnicastRemoteObject implements
Numero
{ int cont = 0;
public int getNumero() throws RemoteException {
int ret = cont++;
return ret;
}
public static void main(String args[]) {
System.setSecurityManager(new RMISecurityManager());
try { NumeroImpl n = new NumeroImpl();
Naming.rebind("//"+args[0]+"/elNumero",n);
System.out.println("Numero creado");
} catch (Exception e) {}
}
}
15
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Aclaración: Existe un servidor de
comunicaciones !!!!)
 Es un programa que provee java llamado rmiregistry
 Se echa a correr en la máquina donde está el programa servidor
del objeto remoto
 Cualquier cliente que quiera ocupar el objeto remoto debe
pedirle a él una referencia al objeto remoto antes de ocuparlo
=> debe saber con qué nombre se registró y en qué máquina
esta corriendo.
Naming.lookup(2)
rmiregistry
Naming.rebind(1)
Internet
Cliente
Objeto.metodo() (3)
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
servidor
16
Módulo ECI - 11: Fundamentos de Redes de Computadores
Un ej: Un objeto remoto que contiene un
número (3 el cliente)
//el archivo del cliente
import java.rmi*;
import java.rmi.server.*;
class ClienteNumero {
public static void main(String args[]) {
try {
Numero N = (Numero)
Naming.lookup("//"+args[0]+"/elNumero");
System.out.println("El numero vale ahora”
+N.getNumero();
} catch( Exception e) {}
}
}
 Notar que el cliente sólo conoce al objeto remoto por su interfaz. Por
eso, para el cliente el número no es de tipo NumeroImpl sino Numero.
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
17
Módulo ECI - 11: Fundamentos de Redes de Computadores
Compilar los códigos fuentes y generar las
clases y los llamados “stubs” y skeletons
Una vez implementados las 3 clases hay que
compilarlas para generar
 Numero.class: la interfaz que define lo que se conocerá
del objeto en toda la red.
 NumeroImpl.class: que es el que implementa el objeto
remoto. Además de implementar el constructor y el
método de la interfaz contiene un main que lo único
que hace es crear el objeto y registrarlo o publicarlo
con un nobre dado.
 Cliente.class
 Esto se hace con el compilador javac
18
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Compilar los códigos fuentes y generar las
clases y los llamados “stubs” y skeletons(2)
 Una vez generadas las 3 clases hay que compilar la clase
implementadora para generar el stub y skel.
 NumeroImpl_stub.class: Es el llamado stub del objeto
remoto. Es el encargado de recibir y transmitir los datos
necesarios para servir a los clientes que piden acceso al
objeto remoto NumeroImpl.
 NumeroImpl_skel.class: es como un esqueleto de la clase.
Tiene sólo la estructura de la clase pero es suficiente
información para que el cliente pueda reunir todo los
antecedentes para llegar a hacer un pedido al stub
 Esto se hace con el compilador rmic NumeroImpl
19
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Echar a andar toda la aplicación
 Echar a correr rmiregistry:
 java rmiregistry
 Echar a correr el programa servidor de objeto remoto:
 java -Djava.rmi.server.codebase=file:///c:\publico\
-Djava.rmi.server.hostname=ciguena
-Djava.security.policy=policy.txt NumeroImpl
 Echar a correr cliente(s):
 java -Djava.security.policy=policy.txt Cliente
 Una vez obtenida la referencia por el cliente el flujo de
datos corre:
 cliente ->stub->skel->Server->skel->stub->cliente
20
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
CORBA:
Common Object Request Broker Arquitecture
 CORBA es una especificación. No es un software o aplicación.
 Auspiciado por Object Managament Group (OMG), para
establecer una especificación de inter-operabilidad entre
plataformas.
 OMG es fundada en 1989, por American Airlines, Canon, Data
General, HP, Philips Telecomunicaciones, Sun , 3Com y Unisys
 Hay un gran número de implementaciones de CORBA. Estas
son conocidas como Object Request Broker (ORB)
21
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
¿que soluciona Corba?
· Infraestructura IT
 Aplicaciones. Procesos clientes y servidores que
representan la lógica del negocio como objetos
que pueden residir en distintas máquinas.
Aplicaciones
Middleware
Servicios
de Red
Servicios
Locales
 Middleware. Soporte que permite la
comunicación entre aplicaciones.
 Servicios de Red. Transporta la información entre
computadores.
 Servicios Locales. Ejemplo, bases de datos y
administradores de transacciones.
Sistema Operativo
 Sistema Operativo. Provee servicios básicos de
Hw y scheduling.
22
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Definición Middleware
 Conjunto de servicios comunes no relacionado con “la
lógica de negocio” que permite que aplicaciones servidoras y
clientes interactuen con otras a través de una Red. En esencia
el Middleware es el software que reside sobre la red ,
permitiendo software de aplicacion orientados sólo a “logica
de negocio.
Middleware
23
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Conceptos claves en CORBA
Los conceptos claves de CORBA son:
 Esencialmente especifica los servicios de middleware que serán usados por
las aplicaciones (objetos).
 Existe una interfaz entre aplicaciones clientes y servidoras. Una lenguaje de
definición de interfaz (IDL) ha sido definido específicamente para CORBA.
 Cualquier objeto puede ser un cliente, un servidor o ambos. Para efectos de
descripción CORBA usa el modelo Cliente/Servidor.
 Soporta “static binding” y “dinamic binding”
 No conoce los detalles de las implementaciones fundamentales de los
objetos. Un “object adapter” mapea modelos genéricos a implementaciones,
siendo la principal manera en que las implementaciones de los objetos
acceden los servicios provistos por el ORB (object Request Broker).
24
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Diagrama conceptual de CORBA
C
C++
Java
C
C++
Java
Cobol
IDL
IDL
IDL
IDL
Cobol
Client Stubs
Server Skeletons
Corba ORB
25
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Implementación de CORBA
Cliente
Implementación Objetos
Skeleton
estático
Repositorio
de
Interfaces
Invocación
Dinámica
Stub Cliente
IDL
iinterfaz
ORB
Invocación
Skeleton
Dinámico
Object Adapter
Repositorio de
Implementaci
ones
Corba ORB
26
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
¿como ha evolucionado?
 CORBA es una especificación. Como cualquier especificación
hubo áreas dejadas a la interpretación de los implementadores.
 A través de Internet Inter-ORB Protocol (IIOP), la OMG espera
que ORB’s de diferentes vendedores puedan comunicarse
fácilmente entre si.
 Recientemente las especificaciones “Portable Object Adapter”
(POA) permite a clientes escritos para acceder un ORB en
particular, pueda acceder fácilmente otros productos de diferentes
vendedores.
 Se ha adaptado a los tiempos y a la competencia.
27
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
¿como ha evolucionado?
 CORBA es una especificación. Como cualquier especificación
hubo áreas dejadas a la interpretación de los implementadores.
 A través de Internet Inter-ORB Protocol (IIOP), la OMG espera
que ORB’s de diferentes vendedores puedan comunicarse
fácilmente entre si.
 Recientemente las especificaciones “Portable Object Adapter”
(POA) permite a clientes escritos para acceder un ORB en
particular, pueda acceder fácilmente otros productos de diferentes
vendedores.
 Se ha adaptado a los tiempos y a la competencia.
28
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
¿como ha evolucionado?
CORBA
Feb '92
Ÿ CORBA 1.1
Ÿ Especificación
conocida
'92
Ÿ Primeros
productos
CORBA
comerciales
'89
Ÿ OMG es
fundada
Dec '94
Ÿ anuncia
CORBA 2.0
Dec '93
Ÿ CORBA 1.2
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Oct '91
Ÿ CORBA 1.1
1988
1989
1990
1991
Jun '99
CORBA 3.0
Asincrono
Java
Firewalls
POA
Obj. por
valor
Ÿ OMG (750)
Ÿ ........
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
1992
1993
1994
Ago '96
CORBA 2.0
Sep '98
IIOP
Ÿ anuncia
Ago'97
C++
CORBA 3.0
Seguridad Ÿ CORBA 2.1
Ÿ IIOP / SSL Feb '98
COM
Ÿ CORBA 2.2
.......
Ÿ DCOM
1995
1996
1997
1998
1999
29
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
No es único
Competidores:
DCOM
RMI/RMP
HTTP/CGI
Servlets
Sockets
.............
30
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
Módulo ECI - 11: Fundamentos de Redes de Computadores
Transmitiendo Objetos por TCP
Transmisión: marshaling, delivery y
unmarshaling.
La clave para esto es la serialización de los
objetos: convertirlos en una representación que
pueda ser transmitida
Todos los objetos que provee Java son
serializables.
Basta poner implements Serializable para los
definidos por el usuario (no incluye statics o
referencias a cosas locales, como archivos o
sockets)
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
31
Módulo ECI - 11: Fundamentos de Redes de Computadores
Transmitiendo Objetos por TCP
La clase para transmitirlos son:
 ObjectInputStream readObjetct()
 ObjectOutputStream writeObject()
Se puede cambiar el procedimiento
estándar de serialización declarando que la
clase implementa la interfaz Externalizable
Esto implica implementar
 Void writeExternal(ObjectOutputStram o)
 Void readExternal(ObjectInputStream i);
32
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl