Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Módulo 9: Desarrollo de Aplicaciones.

Presentación del tema: "Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Módulo 9: Desarrollo de Aplicaciones."— Transcripción de la presentación:

1 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 1 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)

2 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 2 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);

3 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 3 Comunicación Servidor-Cliente sin conexión  Hasta ahora hemos visto cómo se logran comunicar 2 programas estableciendo entre ellos un circuito virtual a través de una conexión TCP/IP.  Sabemos que en una conexión de este tipo se genera mucho tráfico y que la comunicación es más lenta, ya que el protocolo subyacente de confirmación, retransmisión, descarte y/o reordenación de paquetes se basa en mensajes de datagramas.  Habíamos visto que a veces el usuario debería optar por una transmisión sin conexión, especialmente si no es necesario garantizar la llegada de todos los datagramas.  Para eso existen en JAVA todos lor recursos de modo de mandar un datagrama aislado a un destinatario dado.

4 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 4 Manejo de Datagramas en JAVA  La comunicación se basa en armar paquetes UDP y enviarlos a la internet con la siguiente información:  Datos: un arreglo de bytes  Número de port del destinatario: int  Dirección Internet del destinatario: InetAddress  El servidor se pone a escuchar en un socket dado si hay paquetes destinados a él.  El cliente arma un paquete y lo lanza a la internet.  El servidor recibe el paquete y extrae los datos, número de port y dirección internet del enviador.  Si necesita responder manda un paquete a la dirección (port y dirección internet) que venía en el paquete recibido

5 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 5 UDP: comunicación con datagramas DATAGRAMA: un mensaje independiente, autocontenido, enviado a través de la internet, cuya llegada, tiempo de llegada y contenido no están garantizados (como el cooreo regular en algunos países....) Una vez que un servidor está escuchando, el cliente podría crear un datagrama con la dirección del servidor, número de puerto y el mensaje. A SERVER A CLIENT 4444 www.waseda1.jp message 4444 www.waseda2.jp ?

6 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 6 Mandando datagramas con protocolo UDP Luego éste podría abrir un socket y enviar el datagrama a la internet. El “algoritmo de enrutamiento” encontrará el camino al computador blanco. A SERVER A CLIENT 4444 www.waseda1.jp 3333 www.waseda2.jp ?

7 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 7 Antes que el datagrama abandone al cliente, éste recibe la dirección del computador de origen y el número de socket. A SERVER A CLIENT 4444 www.waseda1.jp 3333 www.waseda2.jp ! Mandando datagramas con protocolo UDP

8 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 8 Luego de que el datagrama es enviado, el computador del cliente puede empezar a escuchar en el puerto creado para enviar el datagrama si es que se espera una respuesta del servidor. A SERVER A CLIENT 4444 www.waseda1.jp 3333 www.waseda2.jp ? Mandando datagramas con protocolo UDP

9 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 9 El servidor puede extraer la dirección del cliente y el número del puerto para crear otro datagrama con la respuesta. A SERVER A CLIENT 4444 www.waseda1.jp 3333 www.waseda2.jp answer ? Mandando datagramas con protocolo UDP

10 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 10 Finalmente el datagrama es enviado con la respuesta al “cliente”. Cuando un datagrama es enviado no hay garantía de que llegará al su destino. Si se desea comunicación confiable, debera proveerse de un mecanismo de chequeo, o usar... A SERVER A CLIENT 4444 www.waseda1.jp 3333 www.waseda2.jp ? TiroPaquetes ReciboPaquetes Mandando datagramas con protocolo UDP

11 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 11 Clases para Datagramas en JAVA: envío  Definición: Un datagrama es un mensaje independiente, autocontenido que se manda de un programa a otro por la red pero que su llegada, tiempo de llegada y contenido no estan garantizados.  Crear un socket por donde mandar el datagrama  DatagramSocket ds = new DatagramSocket();  Crear y armar el datagrama  byte[] datos = new byte[256];  InetAddress direccion = InetAddress.getByName(“www.ctc.cl”);  DatagramPacket paquete = new DatagramPacket(datos, datos.length,direccion,4444);  Mandarlo  ds.send(paquete);  Esperar respuesta  socket.receive(packet); //limpiarlo antes !!!

12 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 12 Clases para Datagramas en JAVA: recepción  Para poder recibir tengo que escuchar en un port acordado (ya que de otra manera no hay cómo ponerse de acuerdo)  socket = new DatagramSocket(4444);  Preparar un Datagrama para recibir datos  byte[] datos = new byte[256];  DatagramPacket paquete = new DatagramPacket(datos,datos.length);  Ponerse a escuchar si alguien manda un datagrama a este computador a este port  socket.receive(paquete);  Sacar los datos, el port y la dirección de donde venía  int port = paquete.getPort();  InetAddress dirección = paquete getAddress();  String contenido = new String(paquete.getData());  Mandar una respuesta  DatagramPacket respuesta = new DatagramPacket(datos, datos.length, port, direccion);

13 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 13 El Reloj Remoto Un servidor reloj remoto estará poniendo al día el reloj con los paquetes UDP Servidor reloj remoto UDPClockClient UDPClockServer

14 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 14 El Servidor Reloj Remoto Múltiple UDPClockServerThread UDPCLockMServer Un servidor reloj remoto estará poniendo al día el reloj con los paquetes UDP

15 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 15 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”

16 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 16 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

17 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 17 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.

18 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 18 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.

19 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 19 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

20 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 20 ¿ 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

21 Universidad de Chile - Tupper 2007, Santiago - Fono: 678 4888 - Fax: 698 8427 - Email: victoria.gaete @die.uchile.cl2000/1 Módulo 9: Desarrollo de Aplicaciones en Redes de Computadores 21 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)