Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - cec.uchile.cl Módulo ECI - 11: Fundamentos de Redes de Computadores.

Presentación del tema: "Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - cec.uchile.cl Módulo ECI - 11: Fundamentos de Redes de Computadores."— Transcripción de la presentación:

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 1 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”

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 2 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

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 3 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.

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 4 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.

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 5 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

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 6 ¿ 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

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 7 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)

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 8 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.

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 9 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

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 10 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.

11 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 11 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

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 12 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

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 13 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.

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 14 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.

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 15 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) {} }

16 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 16 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. Cliente rmiregistry servidor Internet Naming.rebind(1) Naming.lookup(2) Objeto.metodo() (3)

17 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 17 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.

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 18 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

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 19 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

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 20 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

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 21 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)

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 22 ¿que soluciona Corba?  Aplicaciones. Procesos clientes y servidores que representan la lógica del negocio como objetos que pueden residir en distintas máquinas.  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. Provee servicios básicos de Hw y scheduling.

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 23 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.

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 24 Conceptos claves en CORBA Los conceptos claves de CORBA son: 3Esencialmente especifica los servicios de middleware que serán usados por las aplicaciones (objetos). 3Existe una interfaz entre aplicaciones clientes y servidoras. Una lenguaje de definición de interfaz (IDL) ha sido definido específicamente para CORBA. 3Cualquier objeto puede ser un cliente, un servidor o ambos. Para efectos de descripción CORBA usa el modelo Cliente/Servidor. 3Soporta “static binding” y “dinamic binding” 3No 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).

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 25 Diagrama conceptual de CORBA

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 26 Implementación de CORBA

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 27 ¿como ha evolucionado? 3CORBA es una especificación. Como cualquier especificación hubo áreas dejadas a la interpretación de los implementadores. 3A través de Internet Inter-ORB Protocol (IIOP), la OMG espera que ORB’s de diferentes vendedores puedan comunicarse fácilmente entre si. 3Recientemente 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. 3Se 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 28 ¿como ha evolucionado? 3CORBA es una especificación. Como cualquier especificación hubo áreas dejadas a la interpretación de los implementadores. 3A través de Internet Inter-ORB Protocol (IIOP), la OMG espera que ORB’s de diferentes vendedores puedan comunicarse fácilmente entre si. 3Recientemente 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. 3Se ha adaptado a los tiempos y a la competencia.

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 29 ¿como ha evolucionado?

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 30 No es único Competidores: DCOM RMI/RMP HTTP/CGI Servlets Sockets.............

31 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 31 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)

32 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 32 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);