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 Broadcasting: implementación Veamos una primera solución: En el servidor usamos un thread para oir y registrar a los clientes. El programa principal (que es otro thread) queda en un ciclo infinito leyendo lineas del teclado y ditribuyéndolas a los clientes conectados. El cleinte simplemente se conecta y lee en un ciclo infinito lo que el servidor le manda y lo muestra en la pantalla (no escribe al servidor). Veamos una segunda solución: El servidor lee el mensaje desde otro socket. Queda escuchando en el socket 4444 para los clientes que quieren recibir los mensajes y en 4445 a clientes que quieren mandar mensajes. Haremos otro programa cliente que haga esto. La tercera solución corresponde al cliente definitivo que también tiene un thread que lee y escribe en pantalla lo que el servidor manda y el programa principal acepta lineas del teclado y las manda al servidor. Veamos los casos 1 y 2 andando. Programas

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 Comunicación Servidor-Cliente sin conexión Ambos programas abren un socket para enviar y/o recibir datagramas. Pueden o no estar asociados a un port dado El que recibe primero el datagrama (servidor) debería esperar paquetes en un port dado para que el enviador (cliente) sepa dónde enviarlos para que los reciba. El enviador no necesita poner un número de port explícitamente (aunque vaya a recibir paquetes de respuesta) ya que en el datagrama irán los datos del host y port de dónde fue enviado. Veamos ejemplos:

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 Multicasting Qué pasa cuando se quiere hacer un broadcasting de datos demasiado pesados ? Por cada cliente, el servidor queda mucho rato pegado escribiendo datos. Imáginé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

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

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

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

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

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

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

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

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

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

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 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. Naming.lookup(2)

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 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 Naming.lookup(2)

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

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 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 -> skel->stub->Server->stub->skel->cliente