Por Qu

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 gt 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
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
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
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
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 -gt 192.1.2.255
• Para una subred de 16 hosts 197.84.66.192 -gt
  197.84.66.207

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
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
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
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 gt 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
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
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
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
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
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
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("//"args0"
  /elNumero",n)
• System.out.println("Numero
  creado")
• catch (Exception e)

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 gt debe saber con qué
  nombre se registró y en qué máquina esta
  corriendo.

rmiregistry
Naming.lookup(2)
Naming.rebind(1)
Internet
Cliente
servidor
Objeto.metodo() (3)
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("//"arg
  s0"/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
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
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
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.codebasefile///c\publico
  \
  -Djava.rmi.server.hostnameciguena
  
  -Djava.security.policypolicy.txt NumeroImpl
• Echar a correr cliente(s)
• java -Djava.security.policypolicy.txt Cliente
• Una vez obtenida la referencia por el cliente el
  flujo de datos corre
• cliente -gtstub-gtskel-gtServer-gtskel-gtstub-gtcliente

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

25
Diagrama conceptual de CORBA
26
Implementación de CORBA
27
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 ORBs 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
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 ORBs 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.

29
como ha evolucionado?
30
No es único

• Competidores
• DCOM
• RMI/RMP
• HTTP/CGI
• Servlets
• Sockets
• .............

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