Download postituloBaloian7 - DCC

Módulo ECI - 11: Fundamentos de Redes de Computadores
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
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
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:
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
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”
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
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.
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
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
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
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.
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
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
7
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
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
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.
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl
9
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.
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
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) {}
}
}
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
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)
Internet
rmiregistry
Naming.rebind(1)
Cliente
Objeto.metodo() (3)
servidor
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
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(2)
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
13
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
Naming.lookup(2)
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
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
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
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
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
16
Universidad de Chile - Tupper 2007, Santiago - Fono/Fax: (56 2) 698 8427 - Email: hthiemer @ cec.uchile.cl